誰かがPolicy Constraints
とBasic Constraints
の違いを説明してくれませんか?
それらは冗長であるか、同じものに対して2つの名前があるように思えます。 Googleの検索が役に立たないため、説明が必要です。
まず、「基本的な制約」に取り組みましょう( RFC 5280、セクション4.2.1.9 )。これらは、主にCAに対して発行された証明書のためのものです。 RFC 5280は、このような「制約」を2つだけ定義しています。
これは非常に簡単です。 CA証明書は、定義により、mustに基本的な制約拡張があり、このcA
ブール値を "true"に設定してbeCA。
これはpathLenConstraint
値であり、値がゼロ以上の数値です。私のCA証明書を使用してCA証明書を発行したいとしましょうbut次に、そのCA証明書を使用して、 other CA証明書を発行します。 cA
値が「true」およびpathLenConstraint
値が「0」の基本制約拡張をCA証明書に追加します。 pathLenConstraint
は、CAから取得できる「非自己発行の中間証明書」の数です。 end 証明書(通常はサーバーまたはクライアントの証明書)は、しないをこの数の一部としてカウントしないことに注意してください。したがって、私が発行するCA証明書でpathLenConstraint
を「0」に使用すると、その証明書を使用して他の end 証明書を発行できますが、中間証明書はありません。基本制約拡張でpathLenConstraint
値が定義されていない場合、そのような制限は課されません。
ここで、「ポリシーの制約」( RFC 5280、セクション4.2.1.11 )を見てみましょう。 RFC 5280によるポリシー制約拡張は、CAに発行される証明書用です。したがって、この拡張機能はエンド証明書(例:クライアント/サーバー証明書)には実際には役立ちません。 RFCでは、この拡張は「ポリシー」の観点からCAへのパス検証を制約するためのものであると述べています。これらのポリシーは何ですか?
これを理解するには、 Certificate Policies と Policy Mappings を調べる必要があります。 「証明書ポリシー」は、「私はCA組織として、特定のポリシー/条件をいくつか持っています。このOIDによって識別されます」と空想的に言うことができます。したがって、各証明書ポリシーにはOIDがあり、通常はそのポリシーに関する詳細情報を指すいくつかのURIがあります。 RFC 5280は、たとえば、「Certification Practice Statement」(CPS)証明書ポリシーを定義しています。これには、CAの処理要件へのURI( eg 証明書を取得するための要件)が含まれています。彼らによって発行された)。私はそれらを、法律用語の使用条件/エンドユーザー使用許諾契約のタイプへのポインタと考えています。
これで、各CA組織はわずかに(乱暴にまで)異なるポリシーを持ち、 but 人々はCAに「ポリシーの方法X他のCAのポリシーYに関連していますか?」特にX509クロスサインに関しては(詳細は RFC 4158 を参照)。したがって、「私の証明書ポリシーXはその証明書ポリシーYと同等です」と言えるCA証明書が必要です。これは、ポリシーマッピング拡張機能を使用して行われます。これは、証明書ポリシーXのOIDをOID証明書ポリシーYにマッピングします。
これで証明書ポリシーが作成され、1つの証明書ポリシーから別の証明書ポリシーへのマッピングが作成されました。次に、ポリシー制約拡張はこれらを使用して、エンド証明書から中間CAを経由してルート/信頼されたCAに証明書のリストを移動するときに、ポリシー(およびポリシーのマッピング)に関して制限/要件を設定します。制限の1つであるinhibitPolicyMappings
は、「パスのN番目の中間証明書以降のポリシーマッピングを無視する」と述べています。もう1つのrequireExplicitPolicy
は、「そのパスにNを超える中間証明書がある場合は、すべてにXポリシーが必要であることを要求します」と述べています。
まとめると、基本的な制約により、CA(cA = true
)、もしそうなら、どれだけの信頼パスを作成できますか(pathLenConstraint
によって制限されます)。ポリシーの制約はすべて、信頼パスが発生する方法のウォークに関するものです:中間証明書のポリシーマッピングを許可される中間証明書の数、その後中間のポリシーマッピング証明書は無視されます(inhibitPolicyMapping = ...
)、および/または特定のポリシーが必要になるまでの信頼パスの長さ(requireExplicitPolicy = ...
)。
そのpathLenConstraint
基本制約がゼロに設定されたCA証明書に戻ります。これにより、独自の中間証明書を発行できなくなります。また、その場合、ポリシーの制約により中間証明書(発行/作成できない)の処理が変更されるため、そのCA証明書にポリシー制約を設定してもあまり役に立たないでしょう。同様に、非CA証明書(およびクライアント/サーバーのエンド証明書)に対するポリシーの制約は、同じ理由で役に立たないでしょう:それらはできない発行/中間証明書を作成します。
以上が、すべての理論です。これらすべての実際の reality の詳細については、実装などに関して、PeterのPeter Gutmannの資料を強くお勧めします X509スタイルガイド) 。
お役に立てれば!