3.1. Encoding a MACAddress as an Alternative Name

When the name form is included in a SAN or IAN extension as an OtherName, the syntax consists of exactly six or eight octets. Values are encoded with the most significant octet encoded first ("big-endian" or "left-to-right" encoding). No text representation is permitted in the certificate, as human-readable forms such as "00-24-98-7B-19-02" or "0024.987B.1902" are used only in management interfaces. When a device possesses a 48-bit MAC identifier, the Certification Authority (CA) MUST encode it using a 6-octet OCTET STRING as the MACAddress value. When the device's factory identifier is a 64-bit EUI-64 or when no canonical 48-bit form exists, the CA MUST encode it using an 8-octet OCTET STRING as the MACAddress value.¶

Example: 00-24-98-7B-19-02 encodes as OCTET STRING '0024987B1902'H.¶

3.2. Encoding a MACAddress Constraint

When the name form is included in the NCE, the syntax consists of an OCTET STRING that is twice as long as the OCTET STRING representation of the address type being constrained. Within the OCTET STRING, two elements are encoded:¶

1. The first set of N octets (where N is 6 for an EUI-48 constraint or 8 for an EUI-64 constraint) contains the "value bit pattern". This bit pattern encodes the bits that the masked address must contain to be considered a match.¶

2. The second set of N octets encodes the "mask bit pattern" of the constraint. Each bit that is asserted in the mask bit pattern indicates that the bit in the same position in the address is constrained by the first set of N octets.¶

For example, a constraint that specifies that the acceptable names must all be within an Organizationally Unique Identifier (OUI) of '00-00-5e' for an EUI-48 address would have a value part of '00005E000000'H, a mask part of 'FFFFFFFF000000'H, and would be encoded as OCTET STRING '00005E000000FFFFFF000000'H.¶

The bit patterns encoded in both the value bit pattern and mask bit pattern are encoded with the most significant bit encoded first ("big-endian" or "left-to-right" encoding).¶

If a bit is not asserted in the mask bit pattern, then the CA MUST NOT assert the corresponding bit in the value bit pattern. This rule ensures that a canonical encoding is used for a given mask bit pattern and value bit pattern.¶

Per Section 4.2.1.10 of [RFC5280], NCE are valid in and "MUST be used only in a CA certificate".¶

3.3. Generation and Validation Rules

The CA MUST ensure that MACAddress otherName values included in certificates that it issues are owned by (or are expected to be owned by) the subject device for the certificate's lifetime. The same MAC address MUST NOT be included in certificates issued to different devices, unless different devices share the same Layer 2 interface.¶

A relying party that matches a presented MAC address to a certificate SHALL perform a byte-for-byte comparison of the OCTET STRING contents.¶

Wildcards are not supported.¶

Self-signed certificates that carry a MACAddress otherName MUST include the address of one of the device's physical ports.¶

3.4. Path Processing for the Name Constraints Extension

The MACAddress otherName follows the general rules for otherName constraints in [RFC5280], Section 4.2.1.10. An NCE MAY impose permittedSubtrees and excludedSubtrees on OtherNames of type id-on-MACAddress.¶

In the pseudocode below, 'mask' is shorthand for the bit string formed from the mask portion of a constraint (e.g., the second set of N octets in the constraint, where N is 6 for an EUI-48 constraint or 8 for an EUI-64 constraint). Similarly, 'value' refers to the bit string formed from the first set of N octets in the constraint.¶

The declaration 'constraint' used below indicates an OtherName.MACAddress constraint value/mask pair -- with fields 'mask', 'value', and 'length'. '.length' as a field returns the byte length of the complete encoded constraint -- either 12 or 16, depending on the type of constraint. The declaration 'name' used below represents an OtherName.MACAddress name with fields 'value' and 'length'. The length is either 6 or 8 representing the encoded name's length.¶

// Returns true if 'name n' matches 'constraint c'
boolean nameMatchesConstraint (name n, constraint c) {
   return ((2 * n.length) == c.length &&
           ((c.value ^ n.value) &
            c.mask) == 0) ;
}

constraint parent = '000000000000 000000000000'H
constraint child =  '00005E000000 FCFFFF000000'H

// Both 'child' and 'parent' are OtherName.MACAddress
// constraints.
// Returns true if all addresses that match child also match
// parent; false otherwise.
// Used to calculate INTERSECTION sets for
// OtherName.MACAddress constraints.
boolean childIsSubsetOfParent (constraint c, constraint p) {
  return (
     // if the lengths are the same
     c.length == p.length &&
     // and if there are no bits set in the parent's mask that
     //   are not also set in the child's mask
     // e.g., we can add mask bits to the current set, we cannot
     //   remove them
     (c.mask & p.mask) == p.mask &&
     // and if the child's value has at least all the bits set that
     //   were set (and live) in the parent's value
     // e.g., we can't change the values of the live bits from the
     //   superior constraint
     (c.value & p.mask) == (p.value & p.mask)
    );
}

initial-permitted-subtrees{} += { 000000000000000000000000H,
                                  00000000000000000000000000000000H }
initial-excluded-subtrees{} += { };

// This logic can be used for both MACAddress and iPAddress
//   OtherName types
// Initialize -
permitted_subtrees{} (0) = initial-permitted-subtrees;

// foreach (certificate i = (1..n) in the path) {
set constraint prevSubtrees{}  =
   { the set of OtherName.MACAddress.permitted_subtrees
     from the permitted_subtree{} (i-1) variable};
constraint tempPermittedSubtrees {} = {};
constraint tempRequestedSubtrees {} =
   { the set of OtherName.MACAddress.permitted_subtrees from
     the Name Constraints extension in the current certificate };

// rst => one of the requested subtrees (from the cert)
// pst -> one of the current permitted subtrees
foreach ( constraint rst in tempRequestedSubtrees) {
    foreach ( constraint pst in prevSubtrees) {
          if (childIsSubsetOfParent (rst,
                                   pst)) {
                tempPermittedSubtrees += rst;
                break;
          }
     }
 }

permitted_subtrees{} (i) = tempPermittedSubtrees;
// } end foreach CA cert on path

// Initialize
excluded_subtrees{} (0) = initial-excluded-subtrees;

// foreach (certificate i = (1..n) in the path) {
// Since we are doing a union operation we start with
// what was excluded at the previous level and try and
// add to it.
tempExcludedSubtrees {} =
  { the set of OtherName.MACAddress.excluded_subtrees from
    excluded_subtrees (i-1) };
tempRequestedSubtrees {} =
  { the set of OtherName.MACAddress.excluded_subtrees from
    the current certificate };

// note that the ordering of the loop here differs
// from the 'intersection' operation.
foreach (constraint rExcl in tempRequestedSubtrees) {
  boolean matches = false;
  foreach (constraint est in tempExcludedSubtrees) {
      // If I find a constraint in the current excluded
      // constraints that 'covers' the requested subtree,
      // I do not need to add the requested subtree
      // to the set of excluded subtrees.
      if (childIsSubsetOfParent (rExcl, est)) {
        matches = true;
        break;
      }
   }
   if (!matches) {
      tempExcludedSubtrees += rExcl;
   }
}
// } end foreach certificate in the path
excluded_subtrees{} (i) = tempExcludedSubtrees;

4.1. Privacy Considerations

A MAC address can uniquely identify a physical device and by extension, its user. Certificates that embed unchanging MAC addresses facilitate long-term device tracking. Deployments that use the MACAddress name SHOULD consider rotating addresses, using short-lived certificates, or employing MAC address randomization where feasible.¶

7.1. EUI-48 Identifier

The following is a human-readable summary of the Subject Alternative Name extension from a certificate containing a single MACAddress otherName with value 00-24-98-7B-19-02:¶

  SEQUENCE {
    otherName [0] {
      OBJECT IDENTIFIER id-on-MACAddress
      [0] OCTET STRING '0024987B1902'H
    }
  }

7.2. EUI-64 Identifier

An EUI-64 example (AC-DE-48-00-11-22-33-44):¶

  [0] OCTET STRING 'ACDE480011223344'H

7.3. EUI-48 Constraint for Universal, Unicast Addresses

The first octet of a MAC address contains two flag bits. IEEE bit numbering has bit '0' as the least significant bit of the octet because that is the bit transmitted first.¶

• Individual(I)/Group(G) bit (bit 0 or mask 0x01): 0 = unicast, 1 = multicast. Multicast prefixes are never OUIs.¶

• Universal(U)/Local(L) bit (bit 1 or mask 0x02): 0 = universal (IEEE-assigned), 1 = local.¶

These flags let the implementations exclude multicast and local addresses but still cannot prove that a 24-bit value is an IEEE-registered OUI. 36-bit Company IDs (CIDs) share the same first 24 bits, and enterprises MAY deploy pseudo-OUIs. CAs MUST include only addresses the subscriber legitimately controls (registered OUI or CID). Before issuing a certificate that contains a MACAddress or a name constraint based on such a permitted set of addresses, the CA MUST verify that control: for example, by consulting the IEEE registry [IEEERA] or reviewing manufacturer documentation.¶

The following constraint definition constrains EUI-48 values to only those that are universal and unicast; locally assigned or multicast values will not match the constraint.¶

  [0] OCTET STRING '000000000000 030000000000'H

8.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC5280]

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.

[RFC5912]

Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010, <https://www.rfc-editor.org/info/rfc5912>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[X680]

ITU-T, "Information Technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, ISO/IEC 8824-1:2021, February 2021, <https://www.itu.int/rec/T-REC-X.680>.

8.2. Informative References

[IEEERA]

IEEE Standards Association, "Guidelines for Use of Extended Unique Identifier (EUI), Organizationally Unique Identifier (OUI), and Company ID (CID)", 3 August 2017, <https://standards.ieee.org/wp-content/uploads/import/documents/tutorials/eui.pdf>.

[RFC9542]

Eastlake 3rd, D., Abley, J., and Y. Li, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 9542, DOI 10.17487/RFC9542, April 2024, <https://www.rfc-editor.org/info/rfc9542>.