要約

  • RFC 10031のid-on-MACAddressは、EUI-48をちょうど6オクテット、EUI-64を8オクテットで格納する。証明書名の照合は完全なバイト一致であり、ワイルドカードはない。
  • 有効な証明書パスやName Constraintsへの適合はPKI上の判断である。現在のポート、フレーム送信元、機器の完全性、利用者の身元、ローカルなアクセス権を直接観測するものではない。
  • 重要な判断では、IEEEまたはローカル割当、CAの確認、パス検証、レイヤー2観測、認可、識別子の存続期間を別々のレシートとして残す必要がある。

MACアドレスを証明書へ入れる発想には、強い簡潔さがある。ネットワークインターフェースに近い短い値を公開鍵へ結び付け、CAの署名を添える。管理画面では「機器の身元」が完成したように見える。

RFC 10031が完成させたのは、身元そのものではなく名称の文法である。2026年8月にIETF標準化過程で公開されたMedia Access Control (MAC) Addresses in X.509 Certificatesの著者は、Russ Housley、Corey Bonnell、Joe Mandel、Tomofumi Okubo、Michael StJohnsの5人だ。文書はGeneralName.otherNameで使うid-on-MACAddressを定義する。48ビットのIEEE 802アドレスは6オクテット、EUI-64は8オクテットで表す。人が読むコロン区切りやハイフン区切りは証明書に持ち込まない。

照合は提示値と証明書値のバイト単位の完全一致である。大文字・小文字、区切り文字、先頭ゼロの解釈差が消え、レイヤー2の証明書認証や、IoT・自動車ネットワークの安全なプロビジョニングに利用できる名前形式が得られる。

しかし、同じバイト列であることと、同じ現物が今そこにあることは別だ。証明書は発行時の主張を保存する。現在のスイッチポートを読み取らず、フレームの出所も検査しない。アドレスが複製、共有、再割当、ランダム化されたかも自動では分からない。

Housleyの経歴は、この境界を考える背景になる。2026年8月31日に取得したIETF Datatrackerのプロフィールは、RFC 10031を含む127件のRFCを掲げる。1982年からコンピュータ／ネットワークセキュリティに携わり、2002年にVigil Securityを設立し、2007～2013年にIETF Chair、2013～2015年にIAB Chairを務めたと記載する。同日にはLAMPSのchairとIEEE-SA liaison managerも掲載されていた。これは長い標準化活動の記録であり、RFCを単独で所有したことや、個別のCA、端末、運用網を支配することの証明ではない。

証明書より先に割当がある

CAが値を証明する前に、その値を使う根拠が必要だ。グローバルに割り当てられた空間とローカル管理空間では、根拠の作り方が違う。

IEEE Registration Authorityは、IEEE標準に従って識別子を維持・発行する。MA-L、MA-M、MA-SとCIDは別の製品であり、CIDからEUI-48やEUI-64を生成することはできない。RFC 9542も、グローバル割当のEUI-48とローカルアドレスを区別し、権威ある登録情報はIEEEの情報源で確認すべきだとする。

したがって、先頭の見慣れたオクテットだけで製造者や現在の所有者を推定してはならない。ローカル管理アドレスでは、値がOUIに似ていても、そのOUIの保有者に特別な権限はない。RFC 9542は、ローカルネットワークがStructured Local Address Planに従っているかを自動判定する方法がないことも指摘する。

割当のレシートには、アドレスの種類、割当者、ブロックまたはローカル規則、下位値、対象インターフェース、確認日が要る。ローカル値なら、適用範囲と衝突管理も残す。ビットは分類を助けるが、誰が選んだかまでは語らない。

ここでは権限が連鎖ではなく分業されている。IEEEは登録を管理する。メーカーや所有者、ネットワーク運用者は自らの範囲で値を割り当てる。CAは申請を確認する。接続先ネットワークは行為を許すか決める。一つの署名が次の権限を自動取得することはない。

CAが署名するのは確認手続きの結論

RFC 10031は、証明書に含めるMACアドレスが証明書の存続中、対象機器に所有されるか、所有される見込みであることをCAに確認させる。同一レイヤー2インターフェースを共有する場合を除き、異なる機器の証明書に同じ値を入れてはならない。自己署名証明書では、物理ポート一つのアドレスを使う。

この義務の実力は、確認方法で決まる。製造台帳、管理された登録経路、機器内鍵の保有証明、認証済み資産台帳、現物確認は、それぞれ異なる誤りに耐える。仕様自身も、結び付きはCAの検証手続きと同程度にしか強くなく、なりすましを考慮すべきだと述べる。動的割当や共有値は一意性と説明責任を弱める。

発行レシートには、加入者、機器とインターフェースの申告、正確な6／8オクテット、証明方法と時刻、発行者、シリアル番号、有効期間、失効状態を残すべきだ。フィールドの存在だけでは、確認の質を評価できない。

また、発行時に正しくても事実は変化する。ポート交換、仮想インターフェースの再作成、共有、再割当が起きる。証明書の期限内でも、発行理由が現在は成立しない場合がある。失効は、変化を検知して通知し、依存側が参照して初めて効く。

Name Constraintsは証明書の名前空間を区切る

RFC 10031は新しい名前形式に対するName Constraintsも定義する。制約は値パターンとマスクパターンの組で、EUI-48なら12オクテット、EUI-64なら16オクテットになる。後続証明書で許可または排除する部分空間を表せる。

これは提示名にワイルドカードを加える仕組みではない。エンド証明書のMAC値は常に完全値で、完全一致を求める。値とマスクは、CA証明書から下るパス上の名前空間を評価するためにある。

RFC 5280によれば、Name ConstraintsはCA証明書で用い、後続証明書のsubject名とsubjectAltNameを制限する。対象の名前形式が存在するときに作用し、自己発行証明書には通常適用しない。ただし、その証明書がパスの最終証明書なら例外となる。

制約に適合したという結果は、あるトラストアンカー、パス、ポリシー、時刻の下で、その証明書名が許容空間に入ったことを示す。IEEE割当、現在のポート、フレーム源、VLANへの許可は示さない。マスクはPKIの委任範囲を整えるが、異なるローカル網の値を世界で一意にはしない。

保存すべきパスレシートは、トラストアンカー、チェーン、ポリシー、検証時刻、SANの正確な値、許可／排除制約、失効情報から成る。これを物理観測と呼ぶと、後から原因を追えなくなる。

稼働中のネットワークは別の瞬間を見る

MACアドレスの意味は通常ローカルだ。RFC 10031は、値がレイヤー3境界を通常越えてルーティングされないため、追加証拠なしにローカル網の外まで一意と想定すべきでないと注意する。隔離された二つのネットワークは同じローカル値を正当に使える。同じネットワーク内の重複は、設定ミス、複製、攻撃のいずれでも起こる。

依存システムは、証明書のイベントを実際の接続イベントへ結び付けなければならない。認証プロトコル、鍵の証明、結果、観測した送信元MAC、物理／論理インターフェース、接続点、VLANなどの範囲、割当・ランダム化状態、重複検出、時刻を記録する。

バイトが一致すれば、認証で提示された値が証明書名と同じだと分かる。以後の全フレームが同じハードウェアから来たこと、ファームウェアが正常なこと、人間の利用者が誰かまでは分からない。必要なら別の証拠を接続する。

Running-Code Primacyは、標準を軽視する態度ではない。標準が共有する文法、PKIが出す暗号学的判断、稼働網が出す観測と結果を混ぜないための運用原則だ。

認証後の「許可」はローカルに残る

証明書パスが通っても、ネットワークは機器を隔離できる。想定外ポートにいる、要求した操作が役割を超える、保守期限が切れた、ローカルプロファイルを満たさない、といった理由がある。これは証明書検証の失敗ではなく、認可の結果である。

認可レシートには、規則と所有者、バージョン、評価属性、許可した操作、範囲、有効期限、例外、結果を残す。人が上書きしたなら、誰が何の理由で行ったかも必要だ。そうしなければ、CAがローカル管理者の判断まで行ったように見えてしまう。

最小初期仕様が有効なのは、共通部分を狭く保つからだ。RFCは移植可能な名前と制約を提供する。具体的な証明強度、アドレス範囲、衝突対応、観測、執行は、リスクを負う運用主体が決める。

安定性は追跡能力でもある

RFC 10031は、安定したMAC値を証明書へ入れると、機器や利用者の長期追跡を助け得ると警告する。可能ならアドレスのローテーション、短命証明書、ランダム化を検討するよう促す。

RFC 6973は、個人に関する情報を結合することをcorrelation、複数要素から機器やアプリケーション実体を識別することをfingerprintingと説明する。どの層でも、永続的な機器IDや証明書は通信を時間越しに結び付け得る。

暗号化されていても、証明書や認証ログを複数の主体が保持し、他の安定値と結合する場合がある。一方、ランダム化が常に安全な答えでもない。安定参照が必要な制御系があり、機器が安全に値を変えられず、証明書の期間と合わないこともある。

プライバシーの記録には、安定性が必要な理由、観測者、ネットワーク範囲、アドレスと証明書の期間、結合可能な他の項目、ローテーションの可否、ログの削除・期限を含める。署名は識別子を正確にするが、追跡不能にはしない。

6種類のレシートを接続する

重大なアクセス判断を再現するには、少なくとも六つの証拠が要る。値を使える理由を示すIEEE／ローカル割当、CAが何を確認したかを示す発行、信頼ポリシーの結果であるパス検証、現場で見えたインターフェースとアドレス、許可した操作と期間、最後に相関の範囲と終了方法である。

前の証拠が正しくても次は失敗する。正当な割当が弱い登録を経ることがある。正しく発行された証明書が失効している場合がある。有効なパスとなりすました送信元は両立する。本物の機器でも権限がない場合がある。正当な許可でもログが長すぎる場合がある。

RFC 10031は、これらを結合するための正確な名前を提供した。その名前だけで結合先の証拠まで代用させないことが、導入側の仕事である。

出典