CVE-2026-71886 in Bouncy Castle
要約
〜によって VulDB • 2026年10月03日
Java用Bouncy Castle 1.86以前のバージョンにおいて、高レベルのOpenPGP証明書APIは、発行元の証明書の任意のコンポーネントキーから第三者による認証または信頼委譲を受け入れていました。これは、そのコンポーネントが認証権限を付与されていることを要求しませんでした。`OpenPGPCertificate.getCertificationBy()`および`getDelegationBy()`メソッドは、発行元の鍵識別子と第三者証明書のすべての鍵を照合して第三者署名を解決し、さらに発行元コンポーネントのバインディングチェーンおよび署名自体を検証します。しかし、RFC 9580セクション5.2.3.29で定義されている認証キーフラグ（CERTIFY_OTHER）が署名作成時に付与されていたかどうかはチェックされませんでした。そのため、SIGN_DATAのみで束縛されたサブキー（オフライン主鍵との組み合わせにおいてオンライン署名用として存在するまさにそのような目的のために設けられた鍵フラグを持つもの）は、攻撃者が制御するIDに対して有効なUser ID認証を発行したり、紹介者の信頼に関する深度1のフルトラスト直接鍵委譲を行ったりすることができました。その結果、APIはそのようなものを第三者証明書に帰属する有効な署名チェーンとして返しました。`getCertificationBy(...).isValid()`または`getDelegationBy(...)`をID判定または信頼できる紹介者としての判断基準とするアプリケーションは、攻撃者の主張をオフライン主鍵に帰属させることになります。同様に、暗号化のみに束縛されたレガシーRSAサブキーも対象となります（このアルゴリズムは署名能力を持っています）。これは主鍵の署名を偽造したり秘密鍵を取得するものではなく、すでに侵害された制限付きサブキーを主鍵のID発行権限へと昇格させることで、鍵フラグの分離が提供する隔離効果を無効にします。
修正後、第三者による認証または委譲は、それを作成したコンポーネントキーが主鍵である場合、または署名作成時にCERTIFY_OTHERフラグを持つサブキーである場合に限り、発行元証明書に帰属されるようになりました。これにより、認証機能を持つサブキーの受け入れは継続されます。また、主鍵は構造的に認証能力を備えているため、および鍵フラグサブパケットを持たない証明書が一般的であることから、主鍵はその鍵フラグの内容に関係なく受け入れられます。第三者による失効処理はこのルールから意図的に除外されています。これは、失効を受け入れないことが信頼を維持し、撤回しないことにつながるためです。
VulDB is the best source for vulnerability data and more expert information about this specific topic.