要約

  • wolfSSL 5.9.2は、RPKを有効にしたビルドで未交渉のRaw Public KeyをX.509の代わりに受理し、チェーン検証を回避し得た高深刻度の問題を公表した。修正後は、別形式の交渉がなければX.509を期待し、不一致を拒否する。
  • RFC 7250のRPKは壊れた証明書ではない。DER形式のSubjectPublicKeyInfoを一件だけ運ぶ、明示的に選択されるTLSの証明書タイプである。秘密鍵所持は証明できるが、発行者、主体、期限、用途や業務上の権限は運ばない。
  • 安全な受理には二つの実行証拠が要る。接続が本当にRPKを交渉したこと、そして外部台帳がそのSPKIを現在も対象ホスト、サービス、機器または役割に束縛していることである。接続成功だけではどちらも証明できない。

入力形式が信頼方式を選んでしまった

wolfSSL 5.9.2のリリースノートはCVE-2026-55960をHighとした。HAVE_RPKを組み込んだ場合、相手とRPKを交渉していないのに、届いた裸の公開鍵がX.509証明書の位置で受理され得た。RPKにはチェーンがないため、その解析経路ではX.509経路が予定していた信頼検証が行われなかった。

単体ビルドではRPKは既定で無効だが、--enable-allには含まれる。公開資料は悪用件数や完全な影響バージョン範囲を示していない。そこを推測する必要はない。重要なのは、受信データが後から検証制度を切り替え、先に成立した交渉の決定を上書きした点である。

修正は順序を戻した。別の証明書タイプが明示的に選ばれていなければ期待値はX.509になる。クライアントはサーバーから受け取った形式を選択済みタイプと照合し、サーバーもクライアント認証で同じ照合をする。不一致はUNSUPPORTED_CERTIFICATEとなる。PR 10702には両方向の回帰試験も記録されている。

これはパーサーの堅牢化だけではない。SPKIを読めるコードであっても、それを受け入れる権限は交渉から与えられなければならない。検証方式は「読めたもの」から推測せず、「合意したもの」から選ぶ。

RPKが省くもの、残すもの

RFC 7250はRaw Public KeyをCertificateType 2として登録し、クライアント用とサーバー用の証明書タイプ拡張を定義した。端点は提供可能・処理可能な形式を示し、共通の一形式を選ぶ。共通項がなければ、接続を成功扱いにしてはならない。

RPKを選ぶと、CertificateメッセージにはDERエンコードされたSubjectPublicKeyInfoが一つ入る。アルゴリズム識別子、必要ならパラメータ、そして公開鍵ビット列である。X.509証明書の内側にも同じ構造があるが、主体や発行者を記述する証明書本体はない。

TLS 1.3を定めるRFC 8446にもRawPublicKey(2)がある。交渉された場合、certificate_listはSPKIを持つ一つ以下のエントリーに制限される。同時に、明示的に別タイプを交渉しない限りX.509v3が既定だと規定する。

したがって、RPKを選んだ接続にチェーンがないことは欠陥ではない。逆に、X.509を選んだ接続でSPKIが構文的に正しいことは受理理由にならない。形式の妥当性と形式の権限は別々に検査される。

署名が答えるのは「誰の鍵か」ではなく「鍵を持つか」

TLS 1.3のCertificateVerifyは、相手が提示公開鍵に対応する秘密鍵を持ち、当該handshake transcriptへ署名できることを示す。Finishedは握手状態を確定する。この暗号証明は強い。

しかし、機器名や業務ロールを生成しない。RFC 5280のX.509では、CA署名が公開鍵材料と証明書主体の結び付きを認証する。署名対象には発行者、主体、シリアル番号、有効期間、拡張も含まれる。それでも依存側はパス、名前、用途を検証しなければならず、証明書が業務権限を自動付与するわけではない。RPKでは、その署名済み属性自体が運ばれない。

RFC 7250が外部手段による「鍵と提示主体の束縛」を必須とし、その束縛の状態も確認せよとする理由はここにある。製造時に書き込んだ指紋、DANEのTLSA、初回接続で保存した鍵は、どれもある時点の主張である。ローテーション、侵害、再割当て、廃止後にも正しいとは限らない。

外部台帳には、正規アイデンティティ、役割、host/service等の適用範囲、DER SPKI、登録責任者、発効・失効時刻、前後世代、配布経路、撤回状態、旧鍵を拒否した検証端を残す必要がある。

ライブラリAPIは台帳の入口にすぎない

wolfSSLの解説ではRPKを有効化し、受け入れる証明書タイプを設定し、TLSの外で受信鍵を認証する検証callbackをアプリケーションが与える。GnuTLSとのTLS 1.3例は通信に成功しても、外部検証がない段階ではpeer未検証と表示する。暗号通信の成立とアイデンティティ受理は別の結果である。

GnuTLSはhostとserviceに対して保存済み公開鍵を検索し、「記録なし」と「鍵不一致」を区別できる。有効期限も持たせられ、独自backendも使える。これは外部束縛の最小形を示すが、初回の値を誰が認可したか、更新を誰が署名したか、命中後にどの権限を与えるかは決めない。

build flagやAPIシンボルは能力の証拠でしかない。運用証拠にするには、その接続でどのcallbackが実行され、どの版の台帳を読み、どの結果で何を拒否・許可したかが必要になる。

DANEとファームウェアでは失効の速度が違う

DANEは外部束縛の一例である。RFC 6698のTLSAはDNSSECで保護され、証明書またはSPKIを選び、全体値またはdigestで照合できる。DNSサービス名と鍵材料の関係をCAチェーン以外の信頼領域で表せる。

ただし、クライアントがDNSSECを検証し、usage、selector、matching typeを解釈し、正しい対象を比較して初めて権限が実行される。TLSAを公開しただけでは受理側のコードは変わらない。

RFC 7671はローテーションを段階化する。新しい関連を先に公開し、古いDNS cacheが失効するまで待ち、対応する鍵または証明書を配備し、その後で不要な関連を削除する。移行中は複数世代が正当に見える。どの検証端が何を見ているかを観測しなければならない。

RFC 7925の制約機器では、相手の公開鍵またはhashを通信前に配る。RPKは証明書とPKIの負担を避ける入口になり得る一方、長寿命機器の更新能力が信頼維持を支配する。handshakeを小さくすることは、鍵更新を不要にすることではない。

成功一件を七つの証拠へ分解する

必要なのは、設定上の許可タイプ、ClientHelloの提示、最終選択、実際に届いた形式、秘密鍵所持の検証、外部束縛の出典・版・鮮度、そしてアプリケーションが許可した最小操作である。

これらをTLS successに畳むと、未交渉RPK、期限切れ束縛、呼ばれなかったcallback、過大な業務ロールが同じ緑色になる。逆に、正しい秘密鍵を持つ相手をタイプ不一致で拒否することは、安全な結果である。

Heng LuのRunning-Code Primacyは、ここでは証拠の置き場所を示す。RFCが意味を定め、IANAが番号を割り当て、DNSや設定が主張を発行しても、受理を実行するのは稼働中の分岐である。交渉タイプを守り、外部束縛を照会し、アプリ権限を限定するコードが最終の拒否権を持つ。wolfSSLの修正はその拒否権を回復した。

証拠の限界

公表資料から確認できるのは、問題の性質、限定されたビルド条件と修正内容である。悪用の有無、展開数、完全な影響版範囲は分からない。また、RPK一般がX.509より弱いとも言えない。

明示交渉と保護された最新台帳がある閉域環境ではRPKは妥当になり得る。X.509も誤ったパス検証や名前方針で破綻する。禁止すべきなのは、一方の資格情報が他方の受理結果だけを引き継ぎ、その検証義務を逃れることである。

Sources