摘要

  • RFC 10031 定义 id-on-MACAddress，用精确的 6 或 8 个八位组承载 EUI-48/EUI-64，并为证书路径定义带掩码的名称约束。
  • 有效证书只说明 CA 按其核验规则把某个接口名称与公钥绑定；地址可伪造、共享、动态变化且通常只在本地链路有意义，因此设备身份和授权仍在证明范围之外。

一个很精确、也很小的名称

新名称属于 X.509 的 GeneralName.otherName，OID 是 1.3.6.1.5.5.7.8.12。EUI-48 写成 6 个八位组，EUI-64 写成 8 个，最高有效八位组在前。证书中没有冒号、连字符或点分写法；这些只用于管理界面。

依赖方按字节逐一比较，不支持通配符。这项规定阻止系统悄悄扩大语义：它不是“同一厂商的任何设备”，不是“这个机箱的全部端口”，也不是“操作系统此刻选中的地址”。它只命名一个确定值。

RFC 5280 给出证书名称与公钥绑定的基础。RFC 10031 又要求 CA 确保该地址在证书有效期内属于、或预计属于证书所指设备；除非不同设备共享同一二层接口，同一地址不得被写入不同设备的证书。

这是一项发行责任，不是持续遥测。网卡可能更换，端口可能停用，地址可能重新分配，而证书签名和有效期仍然正确。证书不会自动知道维修记录。库存系统、撤销机制和补发流程必须把物理变化接到密码学记录上。

私钥证明和链路观察不能互相代替

规范的安全章节先承认边界：绑定强度取决于 CA 的核验过程，核验必须考虑 MAC 欺骗。动态地址和共享地址会削弱唯一性与问责。没有跨网络稳定性的额外证据，就不应把一个地址视为超出本地网络的唯一标识。

私钥持有证明回答的是“对方是否控制证书对应的密钥”。交换机端口或无线关联回答的是“当前帧使用了什么源地址”。前者不能证明证书中命名的接口正在承载流量；后者不能证明发送者持有私钥，更不能证明它仍是库存中那台资产。

自签名证书也不会消除缺口。RFC 10031 要求其中的 MAC 名称来自设备物理端口，但自签名只证明内部一致性。依赖方仍需要独立信任依据，应用也仍需要授权规则。

地址变化有时正是正确行为

Apple 说明其设备可以按网络使用不同的私有 Wi-Fi 地址，并提供关闭、固定和轮换模式。Android 从 Android 10 起默认启用客户端 MAC 随机化，使用本地管理的单播地址，并通常按 SSID 保持。目标是减少旁观者把网络活动和位置串成长期轨迹。

RFC 10031 也明确指出，把不变的 MAC 地址写进证书会方便长期跟踪设备及其用户，因此应视情况考虑地址轮换、短期证书或随机化。

若证书写工厂地址，它可能适合表达物理接口来源，却未必等于链路上可见的地址。若证书写私有地址，它可能贴近当前网络，却会依赖 SSID、操作系统状态和轮换周期。两种选择都不能靠一个全球默认答案解决。发行方必须说明名称代表哪一层连续性，以及什么事件要求重新发行。

名称约束限制 CA，不授权设备

RFC 10031 为新名称定义了 Name Constraints。一个约束由值模式和掩码组成，两部分各等于地址长度，因此 EUI-48 约束是 12 个八位组，EUI-64 约束是 16 个。掩码没有覆盖的位置，值模式不得置位。

证书路径中的允许子树逐层求交，排除子树则累积求并。这样可以限制下级 CA 只能签发某段地址范围，或只接受通用单播形式。这是对发行权的有效收束。

它不是对设备行为的许可。证书路径允许某个名称，不等于该设备可以进入生产网、打开控制面、修改路由或签发软件。最终决策还需要资产归属、实时状态、租户、角色和具体动作。

OUI 也不能承担这份权力。RFC 警告，仅凭通用/本地和单播/组播位，无法证明 24 位前缀确实登记为 OUI。IEEE 还区分 OUI、CID、预期全球唯一的 EUI，以及只在本地范围保证唯一的标识。分配记录证明一个编号空间的管理关系，不证明当前制造者、所有者、供应链保管或业务角色。

保留冲突，比制造主 ID 更重要

可靠系统应分别记录：证书指纹、路径、策略与撤销状态；私钥持有；证书中的 MAC 字节；名称约束结果；实时源地址、端口或无线关联；库存对象和接口；隐私模式；设备状态；租户、角色与操作决定。

这些证据的时钟不同。证书到期，私有地址轮换，网卡更换，资产转交，状态检查过期，授权策略更新。它们发生冲突时，系统得到的是一个应当交给责任人判断的信号。若预先把全部字段压成“设备已验证”，真正的风险反而被抹掉。

RFC 10031 的力量来自边界清楚：它补上一个二层名称及其路径规则，而不是建立通用设备护照。先在确有需求的本地场景自愿采用，用运行代码验证多接口、维修、随机化和回滚，再决定是否扩展。最小共同规范不应变成最大控制权。

来源