web-dev-qa-db-ja.com

PKIインフラストラクチャタスクにはどの拡張キー使用法が必要ですか？ （OSPFおよびCRL署名などのOID）

階層全体のEKUを指定し、PKIツリーのメンテナンスタスクに必要なOIDを文書化する制約付きPKIを構築しています。

一部のクライアントがCRLまたはOCSP URLさえチェックしない場合があるように、クライアントがEKUツリー全体を検証しない場合があることを理解しています。私の目的は、相互運用性のテストに使用できるインフラストラクチャのベースラインを作成し、サードパーティがCAによって使用される証明書を検証する（または検証しない）方法を文書化することです。

質問

クライアントがCRL、OSPF、またはPKIインフラストラクチャのメンテナンスに関連するその他の証明書を検証する場合、サポートのベースラインとSMIMEを有効にするには、ルートEKUにどのOIDを含める必要がありますか？

たとえば、PKIインフラストラクチャに関連する可能性があるいくつかのOIDには、サブCAの署名（OIDが存在する場合）、および限定従属も含まれる場合があります。しかし、私が抱えている問題は、私が見つけることができるOIDは、Microsoftの名前空間1.3.6.1.4.1.311または このWebページに単純にリストされています に該当します。MicrosoftはPKIを発明していないため、相互運用性の問題を作成したくありませんOIDのみを含めることで... CA検証にIBMまたはOracle（Java）の実装を含めたいと思います。

回答例

理想的な回答には、OIDのリスト（任意の形式）と、それが使用される目的の説明ができるだけ詳細に含まれます。以下はMicrosoft証明書サーバー用の「Capolicy.inf」形式ですが、私が気にしているのは情報だけです...

 ;OID = 1.3.6.1.4.1.311.20.2.1; Certificate Request Enrollment
 OID = 1.3.6.1.5.5.7.3.9;  OCSP Signing (Required for OCSP)
 ;OID = 1.3.6.1.5.5.7.48.1.5; OCSP signing (SHOWS AS UNKNOWN in some software)
 OID = 1.3.6.1.5.5.7.3.4 ; SMIME
 ; OID = 1.2.840.113549.1.9.15 ; On MSFT.com... Safari reports SMIME
 ; Should I include timestamping OIDs?

また、含めるべきでない特定のOIDがある場合は、それらも含めてください。たとえば、以下は論争の的であるように見え、証明書の権利を不必要にエスカレーションする可能性があります

;OID = 1.3.6.1.4.1.311.10.3.9 ; szOID_ROOT_LIST_SIGNER
;OID = 1.3.6.1.4.1.311.10.3.1 ; szOID_KP_CTL_USAGE_SIGNING
certificatespublic-key-infrastructurecertificate-authoritycertificate-revocationsmime
3
goodguys_activate

EKUはExtended Key Usage;これは X.509（RFC 5280） 、セクション4.2.1.12で説明されている証明書拡張です。 RFCが言うように：

通常、この拡張機能はエンドエンティティ証明書にのみ表示されます。

「証明書ポリシー」に反するため、証明書パスに沿ったEKUの継承と伝播の概念はありません。 EKU拡張機能は、拡張機能を備えた証明書内の公開鍵の可能な使用法、およびその公開鍵をのみ通知します。そのため、「ルートEKU」の概念は私にはあまり意味がありません。

原則として、EKUがなくても、いくつかの場合を除いて、実行が妨げられることはありません。

  • 委任されたOCSPレスポンダの証明書（つまり、OCSP応答がCA自体によって署名されていない場合）は、OID 1.3.6.1.5.5.7.3.9（ RFC 256 、セクション4.2.2.2）。

  • タイムスタンプ機関の証明書には、OID 1.3.6.1.5.6.7.3.8（ RFC 3161 を参照）のセクション2.3を含むEKUが必要です。 onlyの存在OID、他のOIDを除く）。

その他の役割の場合、EKU拡張の存在は必須ではありませんが、存在する場合はそれに従う必要があります。たとえば S/MIME証明書の処理 、セクション4.4.4を参照してください：if拡張がまったく存在する場合、証明書は1.3.6.1.5.5.7.3.4 OIDが存在する場合、または特別な2.5.29.37.0 OIDが存在する場合にのみ、S/MIMEを使用します（これは「任意の拡張キー使用法」ですが、拡張機能がない場合は、「任意の拡張キー使用法」OIDを持つEKUと同等と見なされます。

CAまたはCRL署名の「拡張キー使用法」はありません（これらの場合、基本的な「キー使用法」拡張で十分と見なされます）。

一部のシステムには、システム固有の追加要件があります。たとえば、Active Directoryコンテキストでのスマートカードログオンの場合、スマートカード上の証明書とドメインコントローラー自体に発行された証明書は、どちらもMicrosoft固有の1.3.6.1を備えている必要があります。 4.1.311.20.2.2。マイクロソフトはEKUの完全なファンです。 EKU拡張からの情報を複製する独自の拡張（「アプリケーションポリシー」、明らかに文書化されていない）も考案しました。

6
Tom Leek