要約

  • RFC 5280のcertificate profileはCRL署名用証明書にkeyUsageとcRLSignを求めていた一方、validation手順は「拡張があればbitを確認する」と書かれ、拡張の存在確認が明示されていなかった。
  • RFC 10007はv3 CRL issuer certificateについて、keyUsageが存在し、かつcRLSignが立っていることを要求する。正しい署名、同じissuer DN、有効なpathだけでは用途の許可にならない。
  • 監査可能なreceiptは、証明書version、選択したkey、拡張の有無、CRLのscopeとfreshness、path、署名、対象serialの結果、legacy例外を別々に残す。

失効確認の障害を調べると、二つのsystemが同じCRLに反対の結論を出していた。古いnodeは受理し、更新済みnodeは拒否する。CRLのbyte列は同じで、署名も壊れていない。

違っていたのは、validatorが尋ねた質問だった。

RFC 5280の旧手順は、CRL issuer certificateにkey usage extensionが存在する場合にcRLSignを確認する、としていた。拡張があればbitを見る。しかし拡張全体が欠けている場合、その条件を通らずに先へ進める実装があり得た。RFC 10007はこの非対称を解消する。

2026年6月にStandards Trackとして公開された同RFCは、Corey Bonnell、Tadahiko Ito、Tomofumi Okuboの共同著作であり、Bonnellが筆頭に記載される。これはBonnellのdocumented contributionを示すが、各CAや製品の運用権限を与えるものではない。標準はIETFの合意として読む必要がある。

同じ名前の二枚の証明書

RFC 10007の例では、CAがsubject Xにkey Aの証明書を発行し、keyUsage内のcRLSignを明示する。Xはindirect CRLのissuerとして委任され、対象証明書のdistribution pointにはcRLIssuerとしてXのDNが書かれる。

そのCAは同じXにkey Bの証明書も発行する。Bはメールや文書署名のような別用途なので、証明書にkeyUsageがない。DNは同じXであり、certificate pathも有効になり得る。

XがBでCRLを署名すると、cryptographic verificationは成功できる。issuer DNも一致する。しかしBの証明書は、BをCRL署名用として認定していない。ここで問題なのは「誰か」ではなく「何を許されたkeyか」である。

PKIの説明ではidentity bindingが前面に出やすい。だがcertificateは用途を狭める制御面でもある。一人または一組織に複数のcertified keyがあるとき、subject名だけでpurposeを継承させれば、分離したはずの権限が再び一つになる。

欠落をpermissionに変えたif文

RFC 5280 section 4.2.1.3は、証明書またはCRLの署名を検証するkeyを認定する場合、keyUsage extensionを含めcriticalにすることを要求する。cRLSignは、そのsubject public keyがCRL署名を検証する用途を持つことを示す。

profile側の意図は明確だった。それでもsection 6.3.3のalgorithmは、extensionが「presentなら」bitを確認すると書いた。keyUsageが存在してcRLSignが0ならrejectされる一方、extensionそのものがないと確認がskipされる余地が生じた。明示的な否定より無記載の方が緩くなる。

RFC 10007の更新は短い。CRL issuer certificateがv3なら、key usage extensionが存在することを確認し、cRLSignがsetであることを確認する。存在と値は別のtestである。

この違いはloggingにも必要だ。extensionがありbitがないなら、certified purposeが合わない。extensionがないなら、v3 profileの不備、またはissuer certificate selectionの誤りが疑われる。一つの「authorization failed」では修復先が分からない。

古いversionには別の根拠が要る

v1とv2のX.509 certificateにはextensions fieldがないため、RFC 10007は同じpresence checkを適用しない。この例外はformatの制約であって、v3でも欠落を許す先例ではない。古いcertificateを受理するときは、versionと適用policy、承認者、期限を記録すべきである。

更新によるinteroperability riskも隠してはいけない。CRL署名用として運用されてきたv3 certificateがkeyUsageを欠いていれば、旧validatorはCRLを受け入れ、新validatorは拒否できる。署名keyもCRLも変わっていなくても、利用可能性が変わる。

これはstrict implementationの故障というより、以前見えなかったprofile debtの顕在化である。RFC 10007はCAに正しいextensionを含めることを推奨する。certificate profileを更新できない場合、PKI policy management authorityは異なるpurposeのcertificateに異なるDNを要求すべきだとする。

unique DNは誤選択を減らせるが、既存certificateを修正しない。distribution pointやrelying party設定への影響、再発行、例外終了は別のchangeとして管理する必要がある。

cRLSignを通過しても残る検証

authorization checkは必要だが、CRL全体の品質保証ではない。validatorは適切なissuer certificateを選び、pathとsignature algorithmを確認し、distribution pointとissuing distribution pointのscope、indirect CRL、critical extension、thisUpdateとnextUpdate、complete/delta CRLの関係を処理しなければならない。

さらに対象certificateのserialが掲載されているかを評価する。authorized keyのCRLでもstaleになり得る。freshでも対象scope外かもしれない。すべて正しく検証できたCRLが、対象をrevokedと報告する場合もある。従って「cRLSign pass」を「certificate safe」に変換してはならない。

逆に、extension欠落によるrejectは、必要なauthorizationがcertificateに表現されていないことを示す。攻撃、key theft、偽CRLが発生した証明ではない。このboundaryを保てば、security findingとincident claimを混同せずに済む。

Heng Luのagencyの観点では、著者は共通grammarを提示し、CAはprofileを選び、developerはrunning codeを作り、policy ownerはlegacy exceptionを決め、service ownerは停止の影響を受ける。あるagentの証拠が次のagentの判断を自動的に代行することはない。

minimum specificationとして必要なのは、存在とbitを同じ意味で検証できることだ。deploymentの順序と期限はlocal decisionである。running codeの結果を信頼するには、最終booleanだけでなく、どのcertificateを選び何を確認したかを保存する必要がある。

検証receiptを段階で残す

最初にtarget certificate、trust anchor、CRL URI、取得したCRLのhash、取得時刻、thisUpdate、nextUpdate、algorithm、validator versionを固定する。選んだissuer certificateについてserial、Subject Key Identifier、関連するAuthority Key Identifier、DN、versionを保存する。

次にpath result、signature result、v3判定、keyUsage presence、criticality、cRLSignを独立fieldにする。v1/v2 exceptionならpolicy ID、対象population、review dateを結び付ける。

scopeも分離する。distribution point、cRLIssuer、indirect CRL、issuing distribution point、reason coverage、complete/delta relationshipを記録する。最後にtarget serialの有無、revocation date、reason、staleまたはmissing、application decisionを残す。

このreceiptなら、旧fleetと新fleetの差を再現できる。別のissuer certificateを選んだのか、presence checkがないのか、scopeで落ちたのかが分かる。単一のgreenまたはredでは、migrationは推測になる。

責任ある結論は限定的でよい。あるvalidator versionが、特定CRLと特定v3 issuer certificateを処理し、keyUsageとcRLSignを確認し、path、signature、scope、freshness、target serialについて個別の結果を得た。それがRFC 10007の価値である。信頼を大きく宣言するのでなく、許可されたkeyを狭く証明する。

情報源