摘要

  • RFC 10031 定义 id-on-MACAddress：EUI-48 必须恰好编码为六个八位组，EUI-64 必须恰好为八个；证书名称按字节完全相等比较，不支持通配符。
  • 证书链有效、名称相等或 Name Constraints 匹配，只能证明一项有边界的 PKI 结果；它们不能单独证明当前接口、帧来源、设备完整性、用户身份或本地许可。
  • 后果重大的决定，应分别保存 IEEE 或本地分配、CA 核验、路径验证、二层观察、授权规则与隐私生命周期六类回执，不能把它们压成一个“证书通过”。

MAC 地址很容易被误读成设备的天然身份证。它短、可比较，又出现在链路层；证书则带来公钥和签名。两者一结合，界面上很容易只剩下一盏绿色的“可信”灯。

RFC 10031 的实际贡献比这盏灯窄，也更严谨。2026年8月发布的标准轨 RFC《Media Access Control (MAC) Addresses in X.509 Certificates》，作者为 Russ Housley、Corey Bonnell、Joe Mandel、Tomofumi Okubo 和 Michael StJohns。文件定义了 X.509 GeneralName.otherName 中的 id-on-MACAddress。48 位 IEEE 802 地址占六个八位组，EUI-64 占八个；人们常见的冒号、连字符或点分显示形式不会写进证书。

依赖方拿到一个值后，按字节逐一比较，没有通配符。这样做消除了大小写、分隔符和前导零的歧义，也让基于证书的二层认证、物联网或汽车网络安全配置拥有一种可移植的名称语法。

但语法的精确不等于现场事实的精确。证书记载的是签发时形成的主张，不会实时读取交换机端口，不会辨认某一帧从哪块硬件发出，也不会检测地址后来是否被克隆、共享、轮换或重新分配。

Housley 的人物背景应放在这个边界内理解。2026年8月31日保存的 IETF Datatracker 档案列出他参与的127份 RFC，其中包括 RFC 10031。档案记载他自1982年从事计算机与网络安全，2002年创办 Vigil Security，2007年至2013年担任 IETF 主席，2013年至2015年担任 IAB 主席；同日角色表还列出 LAMPS 主席和 IEEE-SA 联络经理。这些是长期参与安全标准的时间点，不意味着他是 RFC 的唯一作者，更不意味着他控制任何 CA、设备、IEEE 登记或生产网络。

证书之前，先问地址由谁分配

CA 要把地址写进证书，首先需要一个合理的使用依据。全局分配空间与本地管理空间，证据结构并不相同。

IEEE Registration Authority 按 IEEE 标准维护和签发标识符。其登记产品区分 MA-L、MA-M、MA-S 与 CID；CID 不能用来生成 EUI-48 或 EUI-64。RFC 9542 同样区分全球分配的 EUI-48 和本地管理地址，并指出权威 IEEE 分配信息应来自 IEEE。

因此，熟悉的前几个八位组不能自动证明制造商或当前所有者。若地址属于本地管理空间，即便开头看起来像某个 OUI，OUI 持有人也没有特殊权力。RFC 9542 还明确指出，没有自动化方法能够判断一个本地网络是否遵循 Structured Local Address Plan。

分配回执至少应写明：地址类别、登记机构或本地分配者、前缀或规则、下级取值、目标接口与核验日期。本地地址还要保存本地计划、作用域与冲突处理。地址位模式可以说明类别，却无法倒推出是谁作出的分配决定。

这里存在第一道权力分界：IEEE 管理登记；厂商、设备所有者或本地网络在自身范围内选值；CA 核验申请；接收网络决定是否准入。任何一方都不会因出现在同一条证据链上，就自动继承下一方的职权。

CA 签署的是一次核验判断

RFC 10031 要求 CA 确保写入证书的 MAC 地址在证书有效期内属于、或预期属于主体设备。同一地址不应放入不同设备的证书，除非这些设备共享同一个二层接口。自签名证书若包含该名称，应使用一个物理端口的地址。

这些要求并不空泛，但其强度取决于 CA 实际采用的核验方法。制造记录、受控注册通道、设备内密钥持有证明、经过认证的资产清单、现场检查，各自能抵抗的错误和欺骗并不相同。RFC 也提醒签发者考虑地址欺骗；动态分配和共享值会削弱唯一性与可追责性。

一份可审计的签发回执，需要保留订户、设备与接口主张、六个或八个准确八位组、证据方法和时间、签发者、证书序列号、有效期与撤销状态。“证书里有这个地址”只能说明字段存在，不能说明核验质量。

更麻烦的是时间。端口会更换，虚拟接口会重建，地址会轮换或重新分配。证书仍在有效期内，不代表签发时成立的事实仍然成立。撤销可以缩短偏差，但前提是变化被发现、被报告，并被依赖方及时使用。

Name Constraints 约束证书空间，不观察端口

RFC 10031 还为这种名称定义 Name Constraints。约束由一个取值模式和一个掩码模式组成：EUI-48 共十二个八位组，EUI-64 共十六个。它可以让 CA 证书描述后续证书允许或排除的地址子空间。

这不是把证书里的 MAC 名称变成通配符。主体证书呈现的地址仍是完整值，仍按字节完全相等比较。取值与掩码作用在证书路径的命名空间判断上。

RFC 5280 给出关键边界：Name Constraints 只出现在 CA 证书中，用于限制路径后续证书的主体名称；只有相应名称形式出现时，约束才作用于 subjectAltName。除路径末端外，它们通常不应用于自签发证书。

因此，匹配成功说明的是：在某个信任锚、路径、策略与验证时点下，这个名称落入适用约束允许的空间。它没有分配地址，没有看见物理端口，没有验证帧源，也没有批准某个 VLAN。掩码可以划分 PKI 名称空间，无法让现实中的地址跨网络保持全局无冲突。

路径回执应单独保存信任锚、证书链、策略、验证时间、准确 SAN 值、允许与排除约束、撤销证据。它是密码学判断，不是交换机遥测。

二层现场拥有自己的时间

MAC 地址通常只在本地范围内有意义。RFC 10031 提醒读者，这些值通常不会穿过三层边界被路由，因此没有额外证据就不应假设它们在本地网络之外唯一。两个隔离网络可以合法使用同一个本地地址；一个网络内也可能因配置错误、克隆或攻击出现重复。

依赖系统必须把证书事件与实际看到的网络事件接起来。需要记录认证协议和结果、设备密钥证明、观察到的源 MAC、物理或逻辑接口、接入点、VLAN 或同类本地范围、分配或随机化状态、重复检测及时间。

字节相等到这里才获得准确含义：认证过程中呈现的地址与证书里的值一致。它仍不保证后来每一帧来自同一硬件，不保证固件完整，也不等同于某个用户身份。若业务依赖这些结论，就要补充相应信号，而不是扩写证书的含义。

运行代码优先并非否定标准，而是把证据放回正确层次。标准协调语法；证书和路径协调签名主张；实际运行的网络提供观察与结果。三者都保留，才能在故障发生时知道是哪一层变化。

认证通过以后，本地仍可拒绝

一台设备可以成功出示证书，仍然被隔离。它可能出现在错误端口，请求超出设备角色的动作，错过维护窗口，或不满足当前网络策略。这类拒绝不是证书失效，而是授权系统作出了不同决定。

授权回执要有独立的所有者和有效期：规则、版本、评估属性、允许动作、范围、到期、例外、决定与处置。人工放行也要记下操作者与理由。否则，CA 会在报告里被误写成它从未担任过的网络管理员。

这种权力分离正是最小初始规范的价值。共同标准给出可移植名称和路径约束，承担风险的部署则决定核验强度、可接受地址类型、冲突处理、观察方法和执行动作。

稳定标识符同时是一条跟踪线

安全团队喜欢稳定值，因为稳定值容易关联；隐私风险也从同一特性产生。RFC 10031 警告，把稳定 MAC 写进证书可能导致设备和用户被长期跟踪，并建议在可行时考虑地址轮换、短期证书或随机化。

RFC 6973 将 correlation 定义为组合与个人有关的信息，将 fingerprinting 定义为利用多个信息元素识别设备或应用实例。任何层的持久标识符——包括持久设备 ID 或证书——都可能把不同时间的通信连接起来。

加密不能自动消除这个问题。证书可能被观察者看到，认证、交换和安全系统也可能各自留存日志，再与其他稳定字段连接。另一方面，随机化也不是所有环境的通用答案：有些二层控制需要稳定引用，有些设备无法安全轮换，证书寿命也可能与地址寿命错位。

隐私回执应说明稳定性的必要性、可见观察者、有效范围、地址与证书持续时间、可关联字段、轮换可行性、日志删除或到期规则。密码学保护某些属性，却不会让持久标识符失去关联能力。

一项决定，六张不能互换的回执

后果重大的部署至少要能重建六个相邻事实：IEEE 或本地分配为什么允许使用该值；CA 为什么把它绑定给证书主体；路径验证为什么接受该链和名称；二层现场实际看到了哪个接口与地址；本地策略为什么允许某项动作；合并后的标识符将被谁看到、保留多久、如何结束。

前一项成立，后一项仍可失败。合法分配可能遭遇薄弱注册；正确签发的证书可能已撤销；有效路径可能与欺骗帧同时出现；真实设备可能没有权限；合理准入也可能留下过长的跟踪轨迹。

RFC 10031 提供了一个精确的连接键。部署的成熟度，不在于是否能把六或八个八位组签进去，而在于能否证明这个连接键周围每一项权力和观察都没有被省略。

来源