<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.39 (Ruby 2.5.9) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-lamps-macaddress-on-07" category="std" consensus="true" submissionType="IETF" xml:lang="en" number="10031" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.34.0 -->
  <link href="https://datatracker.ietf.org/doc/draft-ietf-lamps-macaddress-on-latest" rel="prev"/>
  <front>
    <title abbrev="MAC Addresses in X.509 Certificates">Media Access Control (MAC) Addresses in X.509 Certificates</title>
    <seriesInfo name="RFC" value="10031"/>
    <author initials="R." surname="Housley" fullname="Russ Housley">
      <organization abbrev="Vigil Security">Vigil Security, LLC</organization>
      <address>
        <email>housley@vigilsec.com</email>
      </address>
    </author>
    <author initials="C." surname="Bonnell" fullname="Corey Bonnell">
      <organization abbrev="TurboLight Solutions">TurboLight Solutions, LLC</organization>
      <address>
        <email>corey.bonnell@turbolightsolutions.com</email>
      </address>
    </author>
    <author initials="J." surname="Mandel" fullname="Joe Mandel">
      <organization abbrev="AKAYLA">AKAYLA, Inc.</organization>
      <address>
        <email>joe@akayla.com</email>
      </address>
    </author>
    <author initials="T." surname="Okubo" fullname="Tomofumi Okubo">
      <organization abbrev="Penguin Securities">Penguin Securities Pte. Ltd.</organization>
      <address>
        <email>tomofumi.okubo+ietf@gmail.com</email>
      </address>
    </author>
    <author initials="M." surname="StJohns" fullname="Michael StJohns">
      <organization>NthPermutation Security LLC</organization>
      <address>
        <email>msj@nthpermutation.com</email>
      </address>
    </author>
    <date year="2026" month="August"/>
    <area>SEC</area>
    <workgroup>lamps</workgroup>
    <keyword>MACsec</keyword>
    <keyword>802.1AE</keyword>
    <keyword>X.509</keyword>
    <keyword>SubjectAltName</keyword>
    <abstract>
      <?line 80?>

<t>This document defines a new <tt>GeneralName.otherName</tt> for inclusion in the X.509 Subject Alternative Name (SAN) and Issuer Alternative Name (IAN) extensions to carry an IEEE Media Access Control (MAC) address. The new name form makes it possible to bind a Layer 2 interface identifier to a public key certificate. Additionally, this document defines how constraints on this name form can be encoded and processed in the X.509 Name Constraints extension (NCE).</t>
    </abstract>
  </front>
  <middle>
    <?line 84?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>Deployments that use X.509 certificates to identify a device by a Media Access Control (MAC) address need a standard way to encode it in the Subject Alternative Name (SAN) extension defined in <xref target="RFC5280"/>. This document defines a new <tt>otherName</tt> form "<tt>MACAddress</tt>". The name form carries either a 48-bit IEEE 802 MAC address (EUI-48) or a 64-bit extended identifier (EUI-64) in an <tt>OCTET STRING</tt> <xref target="X680"/>. Additionally, the name form also can convey constraints on EUI-48 or EUI-64 values when included in the Name Constraints extension (NCE) defined in <xref section="4.2.1.10" sectionFormat="of" target="RFC5280"/>. The new name form enables certificate-based authentication at Layer 2 and facilitates secure provisioning in Internet of Things (IoT) and automotive networks, in particular.</t>
      <t>Note that while this construct may be used to carry EUI-48 or EUI-64 addresses in an Issuer Alternative Name (IAN) extension, there are probably few, if any, reasons to do so.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <?line -18?>

</section>
    <section anchor="macaddress-othername">
      <name>MACAddress otherName</name>
      <t>In this document, "<tt>otherName</tt>", "<tt>OtherName</tt>", and "<tt>GeneralName.otherName</tt>" all refer to a <tt>GeneralName.otherName</tt> field included in a SAN or IAN.  The new name form is identified by the <tt>OBJECT IDENTIFIER</tt> (OID) <tt>id-on-MACAddress</tt> (<tt>1.3.6.1.5.5.7.8.12</tt>) and declared below using the <tt>OTHER-NAME</tt> class declaration syntax. The name form has variants to convey an EUI-48 as an <tt>OCTET STRING</tt> consisting of 6 octets, or an EUI-64 as an <tt>OCTET STRING</tt> consisting of 8 octets. Constraints on EUI-48 and EUI-64 values are conveyed as <tt>OCTET STRING</tt>s 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.</t>
      <t>The following subsections describe how to encode EUI-48 and EUI-64 values and their corresponding constraints.</t>
      <section anchor="encoding-a-macaddress-as-an-alternative-name">
        <name>Encoding a MACAddress as an Alternative Name</name>
        <t>When the name form is included in a SAN or IAN extension as an <tt>OtherName</tt>, 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 "<tt>00-24-98-7B-19-02</tt>" or "<tt>0024.987B.1902</tt>" are used only in management interfaces. When a device possesses a 48-bit MAC identifier, the Certification Authority (CA) <bcp14>MUST</bcp14> encode it using a 6-octet <tt>OCTET STRING</tt> as the <tt>MACAddress</tt> value. When the device's factory identifier is a 64-bit EUI-64 or when no canonical 48-bit form exists, the CA <bcp14>MUST</bcp14> encode it using an 8-octet <tt>OCTET STRING</tt> as the <tt>MACAddress</tt> value.</t>
        <t>Example: <tt>00-24-98-7B-19-02</tt> encodes as <tt>OCTET STRING '0024987B1902'H</tt>.</t>
      </section>
      <section anchor="encoding-a-macaddress-constraint">
        <name>Encoding a MACAddress Constraint</name>
        <t>When the name form is included in the NCE, the syntax consists of an <tt>OCTET STRING</tt> that is twice as long as the <tt>OCTET STRING</tt> representation of the address type being constrained. Within the <tt>OCTET STRING</tt>, two elements are encoded:</t>
        <ol spacing="normal" type="1"><li>
            <t>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.</t>
          </li>
          <li>
            <t>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.</t>
          </li>
        </ol>
        <t>For example, a constraint that specifies that the acceptable names must all be within an Organizationally Unique Identifier (OUI) of <tt>'00-00-5e'</tt> for an EUI-48 address would have a value part of <tt>'00005E000000'H</tt>, a mask part of <tt>'FFFFFFFF000000'H</tt>, and would be encoded as <tt>OCTET STRING '00005E000000FFFFFF000000'H</tt>.</t>
        <t>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).</t>
        <t>If a bit is not asserted in the mask bit pattern, then the CA <bcp14>MUST NOT</bcp14> 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.</t>
        <t>Per <xref section="4.2.1.10" sectionFormat="of" target="RFC5280"/>, NCE are valid in and "<bcp14>MUST</bcp14> be used only in a CA certificate".</t>
      </section>
      <section anchor="generation-and-validation-rules">
        <name>Generation and Validation Rules</name>
        <t>The CA <bcp14>MUST</bcp14> ensure that <tt>MACAddress</tt> <tt>otherName</tt> 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 <bcp14>MUST NOT</bcp14> be included in certificates issued to different devices, unless different devices share the same Layer 2 interface.</t>
        <t>A relying party that matches a presented MAC address to a certificate <bcp14>SHALL</bcp14> perform a byte-for-byte comparison of the <tt>OCTET STRING</tt> contents.</t>
        <t>Wildcards are not supported.</t>
        <t>Self-signed certificates that carry a <tt>MACAddress</tt> <tt>otherName</tt> <bcp14>MUST</bcp14> include the address of one of the device's physical ports.</t>
      </section>
      <section anchor="path-processing-for-the-name-constraints-extension">
        <name>Path Processing for the Name Constraints Extension</name>
        <t>The <tt>MACAddress</tt> <tt>otherName</tt> follows the general rules for <tt>otherName</tt> constraints in <xref section="4.2.1.10" sectionFormat="comma" target="RFC5280"/>. An NCE <bcp14>MAY</bcp14> impose <tt>permittedSubtrees</tt> and <tt>excludedSubtrees</tt> on <tt>OtherNames</tt> of type <tt>id-on-MACAddress</tt>.</t>
        <t>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.</t>
        <t>The declaration 'constraint' used below indicates an <tt>OtherName.MACAddress</tt> 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 <tt>OtherName.MACAddress</tt> name with fields 'value' and 'length'. The length is either 6 or 8 representing the encoded name's length.</t>
        <section anchor="matching-rules">
          <name>Matching Rules</name>
          <t>To determine if a name matches a given constraint, the certificate-consuming application performs the following algorithm:</t>
          <ol spacing="normal" type="1"><li>
              <t>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.</t>
            </li>
            <li>
              <t>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.</t>
            </li>
            <li>
              <t>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.</t>
            </li>
            <li>
              <t>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.</t>
            </li>
            <li>
              <t>Perform an exclusive OR (XOR) operation with the value bit string extracted in step 3 and the octets of the name value.</t>
            </li>
            <li>
              <t>Perform a bitwise AND operation with the bit string calculated in step 5 and the mask bit pattern.</t>
            </li>
            <li>
              <t>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.</t>
            </li>
          </ol>
          <t>The algorithm can be alternatively expressed as:</t>
          <sourcecode type="pseudocode"><![CDATA[
// 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) ;
}
]]></sourcecode>
          <t>For example, a constraint of <tt>'000000000000 030000000000'H</tt> will be matched by any universal/unicast EUI-48 address such as <tt>00-00-5e-00-50-34</tt>.  A constraint of <tt>'00005E000000 FFFFFF000000'H</tt> will be matched by any universal/unicast address with an OUI of <tt>00-00-5E</tt> -- i.e., it will also match <tt>00-00-5e-00-50-34</tt>.  Note that <tt>'00-00-5E'</tt> is an OUI controlled by IANA (<xref section="1.3" sectionFormat="of" target="RFC9542"/>).</t>
          <t>Implementations are not required to implement this algorithm, but they <bcp14>MUST</bcp14> calculate an identical result to this algorithm for a given set of inputs.</t>
        </section>
        <section anchor="othernamemacaddress-path-validation-processing">
          <name>OtherName.MACAddress Path Validation Processing</name>
          <t>This section describes the Path Validation Processing specific to <tt>OtherName.MACAddress</tt> constraints.  N.B., it is possible to build hierarchies of NCEs for <tt>OtherName.MACAddress</tt>'s that prohibit all names, even if that was not intended. For example, say that the level 1 NCE contained only a "<tt>permitted_subtrees</tt>" of only (<tt>OtherName.MACAddress</tt>) global/unicast EUI-48, and the level 2 NCE contained only a "<tt>permitted_subtrees</tt>" of "any address" (i.e., the initial constraint set).  This would result in an empty <tt>permitted_subtrees</tt> set, as an "any address" constraint is not contained within a "global/unicast" constraint. The worked example is left to the reader.</t>
          <t>The following is a utility function used to determine whether or not the set of matching addresses for one <tt>MACAddress</tt> constraint is a subset of the matching addresses for another constraint.</t>
          <t>For example, given the following (using the IANA-assigned DOI), 'child' is a constraint wholly contained within 'parent':</t>
          <sourcecode type="pseudocode"><![CDATA[
constraint parent = '000000000000 000000000000'H
constraint child =  '00005E000000 FCFFFF000000'H
]]></sourcecode>
          <t>'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.</t>
          <t>Note that the child mask allows for any combination of the local/universal and unicast/multicast address bits within the OUI of <tt>00-00-5e</tt>.</t>
          <t>If <tt>constraint child2 = '00005E005000 FFFFFFFFFF00'H</tt> and 'child' are compared, '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 <tt>'030000000000'H</tt> mask bits and also restricts the range of valid addresses from <tt>00-00-5E-00-50-00</tt> to <tt>00-00-5E-00-50-FF</tt>, i.e., to the 'example' range for the <tt>00-00-5E</tt> OUI.</t>
          <sourcecode type="pseudocode"><![CDATA[
// 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)
    );
}
]]></sourcecode>
          <section anchor="initialization">
            <name>Initialization</name>
            <t>Per (h) and (i) in <xref section="6.1.1" sectionFormat="of" target="RFC5280"/>, we need to specify NCE <tt>OtherName.MACAddress</tt> 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":</t>
            <sourcecode type="pseudocode"><![CDATA[
initial-permitted-subtrees{} += { 000000000000000000000000H,
                                  00000000000000000000000000000000H }
initial-excluded-subtrees{} += { };
]]></sourcecode>
          </section>
          <section anchor="intersection-operation">
            <name>Intersection Operation</name>
            <t>See (g) (1) in <xref section="6.1.4" sectionFormat="of" target="RFC5280"/>.  As we walk down the tree from the root, the set of <tt>permitted_subtrees</tt> can only stay the same or shrink. At each level, we clear the set of <tt>permitted_subtrees</tt> and for each NCE <tt>OtherName.MACAddress.permitted_subtree</tt> constraint in the certificate, we look to see if there is a <tt>permitted_subtree</tt> 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 <tt>permitted_subtrees</tt>.  We repeat this going down the tree for the remaining CA certificates.</t>
            <t>The intersection of the set of <tt>OtherName.MACAddress</tt> current <tt>permitted_subtrees</tt> with each certificate in the path is as follows:</t>
            <sourcecode type="pseudocode"><![CDATA[
// 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
]]></sourcecode>
          </section>
          <section anchor="union-operation">
            <name>Union Operation</name>
            <t>See (g) (2) in <xref section="6.1.4" sectionFormat="of" target="RFC5280"/>.  Unlike <tt>permitted_subtrees</tt>, which is the intersection of the NCEs  at each level, <tt>excluded_subtrees</tt> is the union of all constraints.  Starting with an <tt>excluded_subtrees</tt> empty set, at 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.</t>
            <t>The union of the <tt>excluded_subtrees</tt> set with the <tt>OtherName.MACAddress</tt> <tt>excluded_subtrees</tt> for each certificate in the path is computed as follows:</t>
            <sourcecode type="pseudocode"><![CDATA[
// 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;
]]></sourcecode>
          </section>
        </section>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The binding of a MAC address to a certificate is only as strong as the CA's validation process. CAs <bcp14>MUST</bcp14> verify that the subscriber legitimately controls or owns the asserted MAC address. The validation process <bcp14>MUST</bcp14> account for the possibility that MAC addresses can be spoofed.</t>
      <t>Some systems dynamically assign or share MAC addresses. Such practices can undermine the uniqueness and accountability that this name form aims to provide.</t>
      <t>Unlike IP addresses, MAC addresses are not typically routed across Layer 3 boundaries. Relying parties <bcp14>SHOULD NOT</bcp14> assume uniqueness beyond their local network unless the relying party has information that addresses are stable across network boundaries.</t>
      <t>The Security Considerations section of <xref target="RFC5280"/> applies to this specification as well.</t>
      <section anchor="privacy-considerations">
        <name>Privacy Considerations</name>
        <t>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 <tt>MACAddress</tt> name <bcp14>SHOULD</bcp14> consider rotating addresses, using short-lived certificates, or employing MAC address randomization where feasible.</t>
      </section>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>IANA has made the following assignment in the "SMI Security for PKIX Module Identifier" (<tt>1.3.6.1.5.5.7.0</tt>) registry:</t>
      <table>
        <thead>
          <tr>
            <th align="left">Decimal</th>
            <th align="left">Description</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">126</td>
            <td align="left">id-mod-mac-address-other-name-2025</td>
            <td align="left">RFC 10031</td>
          </tr>
        </tbody>
      </table>
      <t>IANA has made the following assignment in the "SMI Security for PKIX Other Name Forms" (<tt>1.3.6.1.5.5.7.8</tt>) registry:</t>
      <table>
        <thead>
          <tr>
            <th align="left">Decimal</th>
            <th align="left">Description</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">12</td>
            <td align="left">id-on-MACAddress</td>
            <td align="left">RFC 10031</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="asn1-module">
      <name>ASN.1 Module</name>
      <t>This section contains the ASN.1 module for the MAC address; it follows the conventions established by <xref target="RFC5912"/>.</t>
      <sourcecode type="asn.1" markers="true"><![CDATA[
MACAddressOtherName-2025
  { iso(1) identified-organization(3) dod(6) internet(1)
    security(5) mechanisms(5) pkix(7) id-mod(0)
    id-mod-mac-address-other-name-2025(126) }

DEFINITIONS IMPLICIT TAGS ::=
BEGIN

IMPORTS
  OTHER-NAME FROM PKIX1Implicit-2009
    { iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) pkix(7) id-mod(0)
      id-mod-pkix1-implicit-02(59) }

 id-pkix FROM PKIX1Explicit-2009
   { iso(1) identified-organization(3) dod(6) internet(1)
     security(5) mechanisms(5) pkix(7) id-mod(0)
     id-mod-pkix1-explicit-02(51) } ;

-- id-pkix 8 is the otherName arc
id-on  OBJECT IDENTIFIER ::= { id-pkix 8 }

-- OID for this name form
id-on-MACAddress OBJECT IDENTIFIER ::= { id-on 12 }

-- Contents of the otherName field
MACAddressOtherNames OTHER-NAME ::= { on-MACAddress, ... }

on-MACAddress OTHER-NAME ::= {
    MACAddress IDENTIFIED BY id-on-MACAddress }

MACAddress ::= OCTET STRING (SIZE (6 | 8 | 12 | 16))

END
]]></sourcecode>
    </section>
    <section anchor="mac-address-othername-examples">
      <name>MAC Address otherName Examples</name>
      <section anchor="eui-48-identifier">
        <name>EUI-48 Identifier</name>
        <t>The following is a human-readable summary of the Subject Alternative
Name extension from a certificate containing a single <tt>MACAddress</tt>
          <tt>otherName</tt> with value <tt>00-24-98-7B-19-02</tt>:</t>
        <sourcecode type="asn.1"><![CDATA[
  SEQUENCE {
    otherName [0] {
      OBJECT IDENTIFIER id-on-MACAddress
      [0] OCTET STRING '0024987B1902'H
    }
  }
]]></sourcecode>
      </section>
      <section anchor="eui-64-identifier">
        <name>EUI-64 Identifier</name>
        <t>An EUI-64 example (<tt>AC-DE-48-00-11-22-33-44</tt>):</t>
        <sourcecode type="asn.1"><![CDATA[
  [0] OCTET STRING 'ACDE480011223344'H
]]></sourcecode>
      </section>
      <section anchor="eui-48-constraint-for-universal-unicast-addresses">
        <name>EUI-48 Constraint for Universal, Unicast Addresses</name>
        <t>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.</t>
        <ul spacing="normal">
          <li>
            <t>Individual(I)/Group(G) bit (bit 0 or mask 0x01): 0 = unicast, 1 = multicast.  Multicast prefixes are never OUIs.</t>
          </li>
          <li>
            <t>Universal(U)/Local(L) bit (bit 1 or mask 0x02): 0 = universal (IEEE-assigned), 1 = local.</t>
          </li>
        </ul>
        <t>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 <bcp14>MAY</bcp14> deploy pseudo-OUIs. CAs <bcp14>MUST</bcp14> include only addresses the subscriber legitimately controls (registered OUI or CID).  Before issuing a certificate that contains a <tt>MACAddress</tt> or a name constraint based on such a permitted set of addresses, the CA <bcp14>MUST</bcp14> verify that control: for example, by consulting the IEEE registry <xref target="IEEERA"/> or reviewing manufacturer documentation.</t>
        <t>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.</t>
        <sourcecode type="asn.1"><![CDATA[
  [0] OCTET STRING '000000000000 030000000000'H

]]></sourcecode>
      </section>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5912.xml"/>
        <reference anchor="X680" target="https://www.itu.int/rec/T-REC-X.680">
          <front>
            <title>Information Technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="2021" month="February"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.680"/>
          <seriesInfo name="ISO/IEC" value="8824-1:2021"/>
        </reference>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="IEEERA" target="https://standards.ieee.org/wp-content/uploads/import/documents/tutorials/eui.pdf">
          <front>
            <title>Guidelines for Use of Extended Unique Identifier (EUI), Organizationally Unique Identifier (OUI), and Company ID (CID)</title>
            <author>
              <organization>IEEE Standards Association</organization>
            </author>
            <date year="2017" month="August" day="03"/>
          </front>
        </reference>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9542.xml"/>
      </references>
    </references>
    <?line 435?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>We thank the participants on the LAMPS Working Group mailing list for their insightful feedback and comments. In particular, the authors extend sincere appreciation to <contact fullname="Bob Beck"/>, <contact fullname="David von Oheimb"/>, <contact fullname="Deb Cooley"/>, <contact fullname="Francois Rousseau"/>, <contact fullname="Jacqueline McCall"/>, <contact fullname="John Preuß Mattsson"/>, <contact fullname="Mahesh Jethanandani"/>, <contact fullname="Mohamed Boucadair"/>, <contact fullname="Murray Kucherawy"/>, <contact fullname="Sean Turner"/>, and <contact fullname="Tim Hollebeek"/> for their reviews and suggestions, which greatly improved the quality of this document.</t>
    </section>
  </back>

</rfc>
