OID発行ポリシーはスマートカードとブラウザ証明書に適していますか？
私は、さまざまなレベルの保証を備えたSMIMEおよびブラウザー証明書の発行ポリシーを調査しています。
S/MIMEおよびブラウザー証明書の目的で、保証ポリシーを使用する必要がありますか？
保証ポリシーは、エンドエンティティ証明書またはCAで適用する必要がありますか？ ... 両方とも？
OIDを生成するにはどうすればよいですか？
- このカスタムMicrosoft VBScriptを使用してランダムなOIDを生成する を使用する必要がありますか？
- [〜＃〜] ansi [〜＃〜] または [〜＃〜] iso [〜＃〜] などの中央機関に登録する必要がありますか？
- 既存のOID（互換性の理由から）
2.5.29.32.0または1.3.6.1.4.1.311.21.8.x.y.z.1.400（ ソース ）
最後に、特にカスタムOIDを使用する場合は、保証を重要としてマークしないでください。
Microsoftが「発行ポリシー」または「保証」と呼ぶものは、 X.509 ではCertificate Policiesとして知られています（セクション4.2.1.4を参照）。証明書ポリシーは次のように定義されています。
エンドエンティティ証明書では、これらのポリシー情報用語は、証明書が発行されたポリシーと、証明書を使用する目的を示します。 CA証明書では、これらのポリシー情報の用語により、この証明書を含む証明書パスの一連のポリシーが制限されます。
[〜＃〜] oid [〜＃〜] の全体的な考え方は、世界規模のネーミング階層で「オブジェクト」（抽象的な概念を含め、実際には何でもかまいません）を一意かつ明確に識別することです。そのため、ランダムに生成されたOIDは目的を完全に無効にし、容赦することはできません。証明書ポリシーの場合、OIDは特定のポリシー、つまり、証明書が発行された条件とそれが何に使用されるかを定義するドキュメントを「指す」必要があります。 OIDサブツリーを取得する必要があります。どの組織でも独自のサブツリー IANAから を取得できます（無料で永続的です）。次に、適切と思われる方法で、そのサブツリーにOIDを割り当てます。
そうは言っても、証明書ポリシーは、 RFC 5280のセクション6 で説明されている証明書検証プロセスの一部として意味があります（特に6.1.2のステップ（a）、（d）、（e）および（ f）6.1.3、およびステップ（g）6.1.5）。検証プロセスでは、パス全体に対して有効な、つまりパス内のすべての証明書に表示される証明書ポリシーのセットを計算します。特別なワイルドカードanyPolicy（これは2.5.29.32.0で、Microsoftが「All Issuance」と呼んでいます）とポリシーマッピングに関しては、さまざまな微妙な点があります。ただし、パス内のいずれかのCA証明書にCertificate Policies拡張子がまったくない場合、vallid_policy_treeはNULLになります。つまり、すべてが無効になります。証明書パスは「一般的に」検証されますが、具体的に特定されたポリシーはそこから出てきません。
悲しい真実は、多くのCAがMicrosoftがそれを促進する方法で証明書を使用することです。つまり、彼らが何をすることになっていたかに関して完全に間違っています。代わりに、ソフトウェアが一貫して無視する一種のファンシーなコメントとして証明書ポリシーを使用します（ポリシーは隣接させることができます qualifiers 。プレーンテキストまたは何かを指すURLにすることができます）読み取り可能なドキュメントではありません）。
証明書ポリシーは完全に誤用されているため、拡張機能を重要にすることは役に立ちません。実際には、200以上のページ Certification Practice Statement を指すURLを含む拡張機能をPDFファイルとして追加します。これは、少なくともCAビジネスに真剣であることを示しており、あなたがいくつかの重い法律家にふけることをいとわない点。 CPSの作成に関するガイダンスについては、 RFC 3647 を参照してください。