web-dev-qa-db-ja.com

CRLの配布メカニズム

X.509 RFC から：

DistributionPoint ::= SEQUENCE {
     distributionPoint       [0]     DistributionPointName OPTIONAL,
     reasons                 [1]     ReasonFlags OPTIONAL,
     cRLIssuer               [2]     GeneralNames OPTIONAL }

DistributionPointName ::= CHOICE {
     fullName                [0]     GeneralNames,
     nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }

GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

GeneralName ::= CHOICE {
     otherName                       [0]     AnotherName,
     rfc822Name                      [1]     IA5String,
     dNSName                         [2]     IA5String,
     x400Address                     [3]     ORAddress,
     directoryName                   [4]     Name,
     ediPartyName                    [5]     EDIPartyName,
     uniformResourceIdentifier       [6]     IA5String,
     iPAddress                       [7]     OCTET STRING,
     registeredID                    [8]     OBJECT IDENTIFIER }

また..。

   If the DistributionPointName contains multiple values, each name
   describes a different mechanism to obtain the same CRL.  For example,
   the same CRL could be available for retrieval through both LDAP and
   HTTP.

私の質問は...配布メカニズムはそれらそれぞれに対してどのように機能するのですか？ rfc822の名前はメールだと思いますので、どうしたらいいですか？そのメールで指定されたメールアドレスを撮影し、CRLですぐに自動応答することを期待しますか？

dNSNameはドメイン名用なので、そこで何をしますか？ TXTレコードをリクエストしますか？ipAddressについてはどうですか？CRLを取得するために特定のプロトコルを使用することになっていますか？

X400Address、ediPartyName、registeredIDが何であるかがわかりません。

DirectoryNameは別のDNであると思われますが、CRLを取得する方法がどのように示されているのかはよくわかりません。サブジェクトが証明書のCRL配布ポイントディレクトリ名と一致するCAを見つけて、URI（または電子メールアドレスなど）が含まれているかどうかを確認する必要があるでしょうか。

certificatespublic-key-infrastructurecertificate-authorityx.509certificate-revocation
2
neubert

実際には、ソフトウェアがサポートできるのはuniformResourceIdentifierです。拡張機能には、CRLを指すURIが含まれます。 http://およびldap:// URLはかなり一般的です。 https://サーバー証明書も検証する必要があるため、CRLダウンロードのURLは興味深い問題を引き起こします（そのため、実際には、正しく機能しないか、まったく機能しません）。

マシンが対話する「自然な」LDAPサーバーを持っている状況（たとえば、Active Directoryフォレスト内のWindowsシステム）では、directoryNameは、その名前でLDAPサーバーに存在するものを調べることにより、自動的に処理されると考えられます。 。しかし、実際に動作することはありません。

他の名前タイプについても、ほとんど意味がないもの（例：dNSName）または人間の介入を意味するもの（rfc822Name）があります。問題の根本はGeneralNameが多くの場所で使用される本当に一般的な構造であり、特定のコンテキストで使用された場合に特定のGeneralName値が意味をなすという保証はありません。 CRL配布ポイントの一部として。

汎用バリデーターを作成していて、CRLダウンロード用にhttp:// URIを処理するだけであれば、ほとんどの場合よりも優れています（X.509のほとんどの実装では、取り消しをまったくチェックしません！）。 ldap:// URIもサポートしている場合は、「豪華」という用語が適用される可能性があります。現実的には、他の名前タイプでできる唯一の合理的なことは、それらを完全に無視することです。

これはCRLダウンロード用ですですが、CRL配布ポイントにはsegmentationという別の用途があります。これは、CRL配布ポイント拡張が重要な場合に起こります。その場合は、配布ポイント名をCRLの発行配布ポイント拡張と一致させる必要があります（上記のCRLの入手方法に関係なく）。セグメンテーションは、CAが発行した証明書のサブセットのみをカバーする、より小さなCRLを発行する方法です。正しいCRLを使用しているかどうかを確認するには、証明書とCRLの間で名前を一致させる必要があります。そのためには、他の名前タイプの処理が必要になる場合があります。ただし、これはこれらの名前を解釈することではなく、同等性テストだけです。

4
Thomas Pornin