X.509証明書ポリシーマッピングの質問
だから私は少し混乱しています X.509証明書ポリシーのマッピング の仕組み。それで、以下が私の証明書チェーンを描いているとしましょう：
root CA ---> intermediary CA ---> client cert
ルートCAにはポリシーマッピングがありますか？もしそうなら、subjectDomainPolicyはどのようにあるのでしょうか？ subjectDomainPolicyが親証明書issuerDomainPolicyと一致するはずであり、問題の証明書が階層の最上位の証明書である場合、subjectDomainPolicyはどのように一致できますか？そして、それが何にも一致しない場合、それはどうあるべきですか？
X.509 RFCから：
In general, certificate policies that appear in the
issuerDomainPolicy field of the policy mappings extension are not
considered acceptable policies for inclusion in subsequent
certificates in the certification path.
どうしてそうなるのでしょうか？上の図のルートCAにissuerDomainPolicyがある場合、中間CAのポリシーは同じである必要があると言っているのではないでしょうか。
証明書ポリシーの背後にある考え方は、ポリシーはルートからエンドエンティティまでの完全な認証プロセスに適用され、これはポリシーに含めることで証明書に反映されるOID inallチェーン内の証明書。ポリシーは「垂直」です。validator（証明書チェーンを検証する人）は、トラストストアは、ルートごとに、受け入れ可能なポリシーの定義を格納します。これを簡単に説明すると、一般的なトラストストアのエントリは、「I trustthisroot CA（ name + public key）は、ポリシー1.2.3.4に準拠する証明書を検証するために使用されます。ポリシー1.2.3.4がチェーン内のすべての証明書に含まれていない場合、バリデーターはチェーンを拒否します。
ただし、X.509がサポートするような階層型PKIでは、水平分離が一般的です。CAとサブCAを制御するエンティティは異なるレベルで動作し、各レベルには独自の要件と規則があります。したがって、このようなレベルベースの変更を処理するためのメカニズムが含まれており、それが証明書マッピングです。チェーンのどこかでCA証明書に「1.2.3.4から1.5.6.7へのマッピング」が表示される場合、「上位レベルではポリシー1.2.3.4と呼ばれていたものを、この時点から1.5.6.7と呼びます」という意味です。最初にポリシー1.2.3.4を必要とする検証者は、後続の証明書で現在探す必要があるのは1.5.6.7であることに注意します。
このプロセスは、次の特性によりさらに複雑になります。
- 1つのOIDをseveralOIDにマッピングできます。
- ワイルドカードである特別なOID "anyPolicy"と呼ばれます：すべてのポリシーに一致します。
- チェーン内の各証明書は、anyPolicyを禁止したり、パスのあるポイントからの明示的なポリシーを要求したりできます。
- 広く展開されている多くのCAはそれを完全に誤解しており、ポリシーを一種のコメントとして使用しています（特に、各CAに単一のCA固有のポリシーOIDを付与しています。
したがって、悲しいことに、現在展開されている証明書ポリシーは、意図したとおりに機能しません。トラストストアには、ポリシーのセットなしでルートCAのみが含まれます（つまり、これらのルートで始まるパスではすべてのポリシーが受け入れられ、明示的なポリシーは不要です。「ポリシーツリー」は空にできます）。
ルートCA自体には、ポリシーマッピングが含まれていません。これらは実際の証明書ではありません。 standard でトラストアンカーとして知られているルートCAは、アプリオリの知識です。名前と関連する公開鍵。広く普及しているのは、ルートCAを証明書としてエンコードすることであり、多くの場合は自己署名されます（証明書にオプションの「署名」フィールドがないため）。証明書のフォーマットは、便利です。ただし、証明書には、ルートCAには意味のない多くの機能（特に多くの拡張機能）が含まれている場合があります。ポリシーマッピングはそのような機能です。