Summary

  • RFC 10031 defines an X.509 otherName that carries an EUI-48 as exactly six octets or an EUI-64 as exactly eight, plus value-and-mask Name Constraints. Matching is exact byte equality; the name has no wildcard.
  • The certificate is an issuance-time assertion, not a live Layer 2 sensor. A valid path or matching name does not by itself establish current interface use, frame origin, device integrity, user identity or permission on the relying network.
  • A consequential decision needs separate receipts for IEEE or local assignment, CA proofing, path validation, observed interface and scope, local authorization and identifier lifetime. Collapsing those authorities into one green certificate result hides both spoofing risk and tracking cost.

A MAC address has the seductive appearance of a finished identity. It is short, often printed in a familiar hexadecimal form and already attached to the mechanics of a network interface. Put it into a certificate and the result can look stronger still: a compact link between an address and a public key, signed by a certification authority.

RFC 10031 makes that link syntactically precise. Published on the IETF Standards Track in August 2026, Media Access Control (MAC) Addresses in X.509 Certificates is authored by Russ Housley, Corey Bonnell, Joe Mandel, Tomofumi Okubo and Michael StJohns. It defines id-on-MACAddress, a GeneralName.otherName form for carrying a MAC value in a certificate. A 48-bit IEEE 802 address is encoded as exactly six octets; an EUI-64 is exactly eight. The certificate does not contain the punctuation of a display string. A relying party compares the presented value byte for byte. There is no wildcard.

That exactness is valuable. It removes ambiguity about whether two programs parsed colons, dashes, case or leading zeroes in the same way. It gives certificate profiles a portable name form. It also permits certificate-based Layer 2 authentication or secure provisioning designs in areas such as IoT and automotive networking.

But exact syntax is not self-authenticating reality. The six bytes in a certificate remain a claim made at issuance. They do not report which physical or logical interface is active at the moment of a connection. They do not watch the source address of a frame. They do not say whether firmware has been compromised, whether an address has been cloned, or whether a network administrator has authorised the resulting action.

The distinction is especially useful in reading Housley’s role. The IETF Datatracker profile captured on 31 August 2026 lists 127 RFCs, including RFC 10031. Its biography records security work since 1982, the founding of Vigil Security in 2002, service as IETF Chair from 2007 to 2013 and as IAB Chair from 2013 to 2015. The same dated profile lists current roles including chair of LAMPS and liaison manager to IEEE-SA. Those facts explain a long contribution to security standards. They do not make him the sole author of this RFC, the allocator of any address or the operator of any CA, device or network.

A name is not an allocation

Before a CA can bind a MAC value to a subject, somebody must have a defensible basis for using that value. Globally assigned address space and locally administered address space are not the same evidence problem.

The IEEE Registration Authority maintains and issues identifier assignments under IEEE standards. Its products distinguish MA-L, MA-M and MA-S assignments from Company ID assignments. A CID is not a block from which EUI-48 or EUI-64 values may be generated. RFC 9542 similarly distinguishes globally assigned EUI-48 space from local address use and points to IEEE sources for authoritative registration information.

The familiar first octets therefore cannot do all the evidentiary work. In locally administered space, an OUI holder has no special authority merely because the value resembles its prefix. RFC 9542 also notes that there is no automated way to determine whether a local network follows the Structured Local Address Plan. The bit pattern can classify the address; it cannot reconstruct the local allocator’s decision.

This produces the first separation of agency. IEEE registration can establish who received a prefix or identifier product. A device maker, owner or local network can select a subordinate value under its applicable rules. A CA can validate a subscriber’s claim. A relying network can decide whether to grant access. None of those acts automatically performs the next one.

For an auditable certificate, the assignment receipt should therefore name the address class, allocator, prefix or block basis, subordinate allocation, affected interface and evidence date. If the address is local, it should preserve the local plan and collision controls rather than borrowing authority from an OUI-like appearance.

The CA signs a proofing decision

RFC 10031 does not ignore ownership. It requires the CA to ensure that MAC addresses placed in the certificate are owned by, or expected to be owned by, the subject device during the certificate’s lifetime. It says the same value should not appear in certificates for different devices unless those devices share the same Layer 2 interface. A self-signed certificate carrying the name must use the address of one physical port.

These duties are substantive, but they still describe a proofing process. The binding is only as reliable as the validation the CA performed. The RFC calls out spoofing and warns that dynamic or shared assignment can weaken uniqueness and accountability.

The useful question is consequently not just whether the certificate contains id-on-MACAddress. It is what evidence the issuer accepted: a manufacturing record, a controlled enrollment channel, possession of a key inside a device, an authenticated inventory, a physical inspection, or some combination. The receipt needs the subscriber, claimed device and interface, exact octets, proof time, issuer, certificate serial, validity interval and revocation state.

Even a strong enrollment process ages. Hardware can be replaced. Virtual interfaces can be rebuilt. An address can rotate, be reassigned or be shared. A certificate can remain within its validity interval while the operational fact that justified issuance has changed. Revocation may close some of that gap, but only if the change is detected, reported and consumed by the relying party.

That is why “certificate valid” is too compressed a conclusion. It merges a historical proofing decision, a cryptographic signature, a path-policy calculation and a present-tense deployment claim into one status light.

Name Constraints fence certificate paths

RFC 10031 also defines Name Constraints for the new name form. A constraint combines a value pattern with a mask pattern. The encoded result is 12 octets for an EUI-48 constraint and 16 for EUI-64: one address-sized value followed by one address-sized mask.

This is deliberately different from wildcard matching in the certificate name itself. The presented MAC value is still compared exactly. The value-and-mask structure allows a CA certificate to describe permitted or excluded address subtrees for certificates later in the path.

RFC 5280 supplies the boundary. Name Constraints live in CA certificates and restrict namespaces for subject names in subsequent certificates. They apply to subject alternative names only when that name form appears, and are generally not applied to self-issued certificates except when the self-issued certificate is final in the path.

A successful constraint check thus answers a path question: this named value fell within the namespace allowed by these applicable CA constraints under this validation. It does not allocate the address, inspect the port, see a frame or approve a VLAN. The mask can partition a certificate namespace; it cannot make the underlying values globally collision-free.

For investigation or high-consequence automation, save the path result as its own receipt: trust anchor, policy, validation time, exact SAN octets, issuer chain, applicable permitted and excluded constraints, and revocation evidence. Do not overwrite that record with the later Layer 2 observation—or use it as a substitute for one.

The packet belongs to another moment

MAC addresses ordinarily have local significance. RFC 10031 warns against assuming uniqueness beyond the local network, particularly because the values are not normally routed across Layer 3 boundaries. Two sites can legitimately use the same locally administered value without seeing one another. One site can also see a duplicate through error, deliberate spoofing or an unmanaged reuse.

The relying system must therefore bind the certificate event to the network event it actually observed. That means retaining the authentication protocol and result, device/key proof, observed source MAC, physical or logical interface, switch port or attachment point, VLAN or comparable local scope, assignment or randomisation state, duplicate-detection result and time.

Byte equality then has a precise but limited meaning. The address presented in the authentication exchange equals the octets in the certificate. It does not prove that every later frame came from the same hardware, that the interface is incorruptible, or that the device user is a particular person. Where those claims matter, the system needs additional signals and must state what they establish.

Running-Code Primacy is the practical discipline here. The RFC coordinates a name grammar. The certificate and path result coordinate a cryptographic claim. The running network supplies the observation and outcome. A design is strongest when it keeps all three rather than asking the first to impersonate the last.

Authorization remains local

Authentication is not authorization. A network can accept that a key presented a certificate containing a particular MAC value and still deny access because the device is quarantined, the certificate profile is insufficient, the address is unexpected on that port, maintenance has expired, or the requested action exceeds policy.

The authorization record needs its own owner and lifetime. It should name the rule, evaluated attributes, granted action, network scope, expiry, exception, decision and remediation. If an operator overrides a mismatch, preserve who did so and why. If access is denied after successful path validation, report both facts rather than converting the denial into a certificate failure.

This division reflects an agency boundary at the heart of infrastructure governance. The standards authors define an interoperable mechanism. A CA controls issuance under its policy. IEEE controls its registries. A device owner controls equipment. A network administrator bears the operational risk of admitting it. The relying application turns evidence into an action. A signature by one party cannot silently import every other mandate.

The minimum shared specification is therefore useful precisely because it is narrow. It makes a MAC-address name portable and constrains how certificates may use it. Local systems remain responsible for proof strength, acceptable address class, collision treatment, observation and enforcement.

A durable name also creates a durable trail

The security appeal of a stable identifier is also its privacy hazard. RFC 10031 warns that embedding a stable MAC value in a certificate can enable long-term device or user tracking. It suggests considering address rotation, short-lived certificates or randomisation where feasible.

RFC 6973 gives the broader vocabulary. Correlation joins information related to a person; fingerprinting identifies a device or application instance from multiple elements. Persistent identifiers at any layer—including a persistent device ID or certificate—can make communications linkable over time.

Encryption does not make the question disappear. The certificate may be visible to an observer, logged by multiple systems or joined to other stable attributes. Even where the raw address is protected in transit, authentication and operations records can build a durable history.

Nor is randomisation a universal instruction. Some Layer 2 control systems require stable references; some devices cannot rotate safely; certificates and address lifetimes can become inconsistent. The defensible decision records why stability is needed, which observers can see the identifier, where it is valid, how long both address and certificate persist, what other fields are linkable, whether rotation was evaluated, and how records expire or are deleted.

The core point is not that a certificate should never name a MAC address. It is that cryptographic protection does not make the identifier privacy-neutral, just as exact encoding does not make it operationally unique.

The evidence join

A mature deployment should be able to reconstruct six adjoining but non-interchangeable claims:

  1. The IEEE or local allocation basis says why the value was available to the allocator.
  2. The CA receipt says why the issuer bound those octets to that certificate subject for that interval.
  3. The path receipt says why a relying implementation accepted the certificate and its name under a trust policy and constraints.
  4. The Layer 2 receipt says what interface, address and authentication event were actually observed in a defined local scope.
  5. The authorization receipt says why that evidence permitted a specific action and for how long.
  6. The privacy receipt says what persistence and correlation the combined design creates, and how it ends.

Each link can be valid while the next fails. An assigned value can be poorly proofed. A well-proofed certificate can be revoked. A valid path can accompany a spoofed source. An authentic device can be unauthorised. A permitted device can still create an excessive tracking trail.

RFC 10031 gives those systems a clean name to join on. Its success should be measured by whether deployments preserve the distinctions around that name, not by whether six or eight signed bytes are allowed to stand in for the whole chain.

Sources