Summary

  • RFC 10031 defines an X.509 otherName for exact 48-bit and 64-bit MAC identifiers, plus masked Name Constraints that can limit which values a certification path may contain.
  • A valid path proves only the issuer’s binding of a public key to that encoded interface name under its validation policy. Spoofing, shared and changing addresses, Layer 2 scope and deployed MAC randomisation keep device identity and authorization outside that proof.

An exact name for a smaller entity

The new name form is id-on-MACAddress, entity identifier 1.3.6.1.5.5.7.8.12. In a Subject Alternative Name or Issuer Alternative Name, it carries either six octets for EUI-48 or eight for EUI-64. The bytes are stored most-significant first. Colons, hyphens and dotted display forms belong in management interfaces, not in the certificate value.

That restraint matters. A relying party compares the octets byte for byte. There are no wildcards. The certificate is not saying “something made by this vendor,” “any adapter in this chassis” or “whichever address this device uses today.” It names one value.

RFC 5280 supplies the larger PKIX structure. A Subject Alternative Name binds an asserted identity to the certificate’s public key, and the CA must verify the names it includes. RFC 10031 adds rules for this particular name: the CA must ensure that the address is owned by, or expected to be owned by, the subject device throughout the certificate lifetime. It must not put the same address in certificates for different devices unless those devices share the same Layer 2 interface.

Those are demanding issuance duties. They are not observations of the wire. The certificate can remain cryptographically valid after an interface is replaced, reassigned or disabled. A frame can carry the named source address without demonstrating possession of the certificate key. Key possession and address observation are different events, even when policy later requires both.

The certificate lifetime meets the rotating address

The standard itself refuses the easy story of permanence. Its security section says the binding is only as strong as the CA’s validation process and requires that process to account for spoofing. Dynamic and shared addresses can weaken uniqueness and accountability. An address should not be assumed unique beyond the local network without evidence that it remains stable across boundaries.

Deployed operating systems make the conflict practical. Apple documents private Wi-Fi addresses that differ by network and can operate in fixed or rotating modes. Android documents connected-mode randomisation enabled by default from Android 10, using a locally administered unicast value and normally persisting it per SSID. These are not defective devices. They are implementations deliberately reducing linkability.

A certificate that names the hardware address may therefore outlive the address exposed on a particular network. A certificate that names a private address may instead become coupled to an SSID, operating-system state or rotation event. Neither choice is universally wrong. Both require the issuer and relying party to say which interface surface the name represents and what event causes reissuance.

Disabling randomisation can make a narrow access-control design easier. It can also convert a network credential into a durable tracking handle. RFC 10031 explicitly asks deployments to consider rotating addresses, short-lived certificates or randomisation where feasible because an unchanging MAC address in a certificate can help track a device and, by extension, its user.

A mask limits issuance; it does not authorize use

RFC 10031 also defines Name Constraints for the new form. A constraint contains a value pattern and a mask pattern. Each is the length of the underlying address, so a constraint is 12 or 16 octets. Only masked bits are significant, and a value bit cannot be set where the corresponding mask bit is clear.

The mechanism can express an OUI-shaped range or require universal and unicast flag values. Permitted subtrees intersect as a certification path descends; excluded subtrees accumulate. This is useful delegation control. A subordinate CA can be restricted to a defined address set.

The result still says nothing about whether a named device may open a valve, join a production VLAN or sign a firmware release. Name Constraints govern what names may appear in an acceptable certificate path. Application policy governs what a verified subject may do now.

Even the prefix requires care. RFC 10031 warns that the universal and unicast bits do not prove that a 24-bit prefix is a registered OUI. IEEE’s allocation guidance distinguishes OUIs, CIDs, globally intended EUIs and locally administered identifiers. The registration record is evidence about an allocated block and its administration, not proof of present manufacture, asset ownership, supply-chain custody or operational role.

Build an evidence join, not a master identifier

For a Layer 2 provisioning system, the useful record is a join among several facts:

  • the certificate path, policy and revocation state;
  • proof of possession of the certified private key;
  • the exact MACAddress name and any applicable path constraints;
  • the source address observed on the current port, radio association or link;
  • the inventory entity, interface serial or hardware-root evidence used for continuity;
  • posture, tenant, role and the specific requested action.

Each fact has its own clock. A certificate expires or is revoked. A private address rotates. A board is replaced. An inventory assignment changes. A posture result goes stale. Authorization policy is revised. Storing them separately makes disagreement visible instead of forcing every change into one supposedly permanent identity.

Self-signed certificates do not erase the distinction. RFC 10031 requires such a certificate to carry the address of a physical port, but a self-signature only proves internal consistency and key possession. A relying party still needs an independent reason to trust that key and a separate policy to permit an action.

A thin standard is stronger than an identity empire

RFC 10031 is valuable because it standardises a missing field and its path-processing rules. It does not require the Internet to adopt MAC addresses as universal device passports. That narrowness follows a sound coordination pattern: define the minimum shared syntax, let deployments adopt it voluntarily where Layer 2 evidence solves a real problem, and preserve later decisions for the domain that bears the loss.

Running code should decide whether the binding survives real interface replacement, randomisation, multi-port hardware, shared interfaces, certificate renewal and rollback. If an implementation cannot distinguish “named in the certificate” from “seen on this link” and “allowed to act,” the missing component is not a larger identifier. It is an explicit decision boundary.

Sources