Media Access Control (MAC) Addresses in X.509 Certificates

MACAddress otherName In this document "otherName", "OtherName" and "GeneralName.otherName" all refer to a GeneraName.otherName field included in a SAN or IAN. The new name form is identified by the object identifier (OID) id‑on‑MACAddress (TBD1) and declared below using the OTHER-NAME class declaration syntax. The name form has variants to convey a EUI-48 as an OCTET STRING comprising of 6 octets, or a EUI-64 as an OCTET STRING comprising of 8 octets. Constraints on EUI-48 and EUI-64 values are conveyed as OCTET STRINGs whose lengths are twice the octet length of the identifiers. The first set of N octets (where N is the length of the address octets) define the bit pattern of the constraint that the address must match, and the second set of N octets defines the bit mask that defines the set of significant bits in the bit pattern. The following sub-sections describe how to encode EUI-48 and EUI-64 values and their corresponding constraints.

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 natively possesses a 48‑bit MAC identifier, the 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.

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:

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.
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 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 , NCE are valid in and MUST be placed only in CA certificates.

Generation and Validation Rules A certificate MAY include one or more MACAddress otherName values if, and only if, the subject device owns (or is expected to own) the corresponding MAC address for the certificate lifetime. MAC addresses SHOULD NOT appear in more than one valid certificate issued by the same Certification Authority (CA) at the same time, unless different layer‑2 interfaces share a public key. A Relying party that matches a presented MAC address to a certificate SHALL perform a byte-for-byte comparison of the OCTET STRING contents. Canonicalization, case folding, or removal of delimiter characters MUST NOT be performed. Wildcards are not supported. Self-signed certificates that carry a MACAddress otherName SHOULD include the address of one of the device's physical ports.

Name Constraints Extension Path Processing The MACAddress otherName follows the general rules for otherName constraints in , Section 4.2.1.10. An NCE MAY impose permittedSubtrees and excludedSubtrees on OtherNames of type id‑on‑MACAddress. In the pseudo-code 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'. Length is either 6 or 8 representing the encoded name's length.

Matching Rule To determine if a name matches a given constraint, the certificate-consuming application performs the following algorithm:

If the name is 6 octets (representing an EUI-48 value) and the constraint is 16 octets (representing an EUI-64 constraint), then the name does not match the constraint.
If the name is 8 octets (representing an EUI-64 value) and the constraint is 12 octets (representing an EUI-48 constraint), then the name does not match the constraint.
Extract the value bit pattern from the upper (big-endian) N octets of the constraint, where N is "6" for EUI-48 identifiers and "8" for EUI-64 identifiers.
Extract the mask bit pattern from the lower (big-endian) N octets of the constraint, where N is "6" for EUI-48 identifiers and "8" for EUI-64 identifiers.
Perform an exclusive OR (XOR) operation with the value bit string extracted in step 3 and the octets of the name value.
Perform a bitwise AND operation with the bit string calculated in step 5 and the mask bit pattern.
If the result of step 6 is a bit string consisting of entirely zeros, then the name matches the constraint. Conversely, if the result of the operation is a bit string with at least one bit asserted, then the name does not match the constraint.

The algorithm can be alternatively expressed as: For example, a constraint of '000000000000 030000000000'H will be matched by any universal/unicast EUI-48 address such as 00-00-5e-00-50-34. A constraint of '00005E000000 FFFFFF000000'H will be matched by any universal/unicast address with a OUI of 00-00-5E - i.e., it will also match 00-00-5e-00-50-34. Note that '00-00-5E' is an OUI controlled by IANA. Implementations are not required to implement this algorithm, but MUST calculate an identical result to this algorithm for a given set of inputs.

OtherName.MACAddress Path Validation Processing This section describes the Path Validation Processing specific to OtherName.MACAddress constraints. N.B., It is possible to build hierarchies of NCEs for OtherName.MACAddress's that prohibit ALL names, even if that wasn't intended. For example, say that your level 1 NCE contained only a "permitted_subtrees" of only (OtherName.MACAddress) global/unicast EUI-48, and your level 2 NCE contained only a "permitted_subtress" of "any address" (i.e. the initial constraint set). This would result in an empty permitted_subtrees set as an "any address" constraint is not contained within a "global/unicast" constraint. The worked example is left to the reader. The following is a utility function used to determine whether or not the set of matching addresses for one MACAddress constraint is a subset of the matching addresses for another constraint. Examples - given the following (using the IANA assigned DOI) - 'child' is a constraint wholly contained within 'parent': 'child' is a subset of parent because: 1) They are the same length (both EUI-48 constraints) and 2) The child.mask ANDed with the parent.mask equals the parent mask and 3) The bits in the child.value under the parent.mask are set to the same values as the bits in the parent.value under the parent mask. Note that the child mask allows for any combination of the local/universal and unicast/multicast address bits within the OUI of 00-00-0e. If you had 'constraint child2 = '00005E005000 FFFFFFFFFFF00'H and compared it to 'child', 'child2' would be a subset of 'child'. 'child2' uses the same OUI as 'child', but further restricts the matching addresses to universal/unicast by turning on the '0300000000'H mask bits and also restricts the range of valid addresses from 00-00-5E-00-50-00 to 00-00-5E-00-50-FF - i.e., to the 'example' range for the 00-00-5E OUI.

Initialization Per sections 6.1.1 (h) and (i) of , we need to specify NCE OtherName.MACAddress set values for both the initial-permitted-subtrees and for initial-excluded-subtrees. For initial-permitted-subtree, the first constraint is "accept all EUI-48 MACAddresses", and the second constraint is "accept all EUI-64 MACAddresses":

Intersection Operation See Section 6.1.4 (g) (1) of . As we walk down the tree from the root, the set of permitted_subtrees can only stay the same or shrink. At each level, we clear the set of permitted_subtrees and for each NCE OtherName.MACAddress.permitted_subtree constraint in the certificate we look to see if there is a permitted_subtree constraint at the previous level that equals or encloses this new constraint. If so, we add this new constraint to the current level's set of permitted_subtrees. We repeat this going down the tree for the remaining CA certificates. The intersection of the set of OtherName.MACAddress current permitted_subtrees with each certificate in the path is as follows: 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 += requestedSubtree; break; } } } permitted_subtrees{} (i) = tempPermittedSubtree; // } end for each CA cert on path ]]>

Union Operation See Section 6.1.4 (g) (2) of . Unlike permitted_subtrees which is the intersection of the NCEs at each level, excluded_subtrees are the union of all constraints. Starting with an excluded_trees empty set, with each level add to that set any constraints from the CA certificates that are not already in the set, or that are not covered by a constraint already in the set. The union of the set of OtherName.MACAddress current excluded_subtrees with each certificate in the path is as follows: