Network Working Group B. Kaliski Request for Comments: 2314 RSA Laboratories East Category: Informational March 1998 PKCS #10: 証明書要求構文 Version 1.5 このメモの位置付け このメモは、インターネット・コミュニティに情報を提供するものである。 インターネット標準を規定するものではない。このメモの配布は無制限である。 著作権表示 Copyright (C) The Internet Society (1998). All Rights Reserved. 概要 本ドキュメントでは、証明書要求のための構文を示す。 1. 適用範囲 証明書要求は、DistinguishedName、公開鍵、そしてオプショナルな一連の属性 から構成され、それらに対し、証明書を要求しているエンティティにより署名 が行われる。証明書要求は認証局に送られ、X.509公開鍵証明書またはPKCS #6 拡張証明書に変換される。（どのような形式で認証局が新規に署名された証明書 を返送するかについては、このドキュメントの範囲外である。PKCS #7メッセージ が１つの方法として考えられる。） 証明書要求に含まれることが意図されている属性は、大きく分けて2種類ある。 １つはそのエンティティに関する他の情報、例えば、署名された証明書を返送 するとき、電子メールが利用できない場合に利用する郵送先や、エンティティが 後に証明書の失効を要求するための"challenge password"、そしてもう１つは PKCS #6 拡張証明書のための属性である。属性のリストの一部は、PKCS #9で 示されている。 認証局は、電子的ではない形式での証明書要求を必要としてもよく、また電子的 な手段を使用しない返答を行ってもよい。電子的ではない形式での証明書要求の 詳細については本ドキュメントの範囲外であるが、認証局から入手可能であろう。 このドキュメントでは、PKCS #7 暗号メッセージのサポートをすでに意図してい るが、しかしその他の仕様が開発されることも期待される。 2. 参考文献 PKCS #1 RSA Laboratories. PKCS #1: RSA Encryption Standard. Version 1.5, November 1993. PKCS #6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax. Version 1.5, November 1993. PKCS #7 RSA Laboratories. PKCS #7: Cryptographic Message Syntax. Version 1.5, November 1993. PKCS #9 RSA Laboratories. PKCS #9: Selected Attribute Types. Version 1.1, November 1993. RFC 1424 Kaliski, B., "Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services," RFC 1424, February 1993. X.208 CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988. X.209 CCITT. Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988. X.500 CCITT. Recommendation X.500: The Directory-- Overview of Concepts, Models and Services. 1988. X.501 CCITT. Recommendation X.501: The Directory-- Models. 1988. X.509 CCITT. Recommendation X.509: The Directory-- Authentication Framework. 1988. 3. 定義 このドキュメントでは、以下の定義が適用される。 AlgorithmIdentifier: （オブジェクト識別子により）algorithmと、それ に関連するparametersを特定するための型。この型はX.509により定義される。 Attribute: （オブジェクト識別子により指定される）属性型と、１つ以上の 属性値を含む型。この型はX.501で定義される。 ASN.1: Abstract Syntax Notation One。X.208で定義される。 BER: Basic Encoding Rules。X.209で定義される。 Certificate: エンティティのDistinguishedNameと公開鍵を、デジタル署名 により結びつける型。この型はX.509により定義される。この型にはまた、 証明書の発行者（署名者）のDistinguishedName、発行者が指定したシリアル 番号、発行者の署名アルゴリズム識別子と有効期間が含まれている。 DER: ASN.1に対するDistinguished Encoding Rules。X.509の第8.7節で定義 される。 Name: X.500ディレクトリ内で唯一に識別される、すなわち"他と区別される" オブジェクト型。この型はX.501で定義される。X.509証明書では、この型は 証明書の発行者と、公開鍵を証明しようとしているエンティティを識別する。 4. 記号と略号 このドキュメントでは、記号と略号は定義されない。 5. 概略 次の章では、証明書要求構文を規定する。 このドキュメントでは、CertificationRequest 型を公開する。 6. 証明書要求構文 この章では、証明書要求構文を示す。 証明書要求は、3つのパートから構成される。"証明書要求情報"、署名アルゴ リズム識別子、そして証明書要求情報に対するデジタル署名である。証明書 要求情報は、エンティティのDistinguishedName、エンティティの公開鍵、 そしてエンティティに関する他の情報を提供するための一連の属性から構成 される。 証明書要求の生成処理は、次の3つのステップから構成される。 1. DistinguishedName、公開鍵、そしてオプショナルで一連の属性が含ま れているCertificationRequestInfo 値が、エンティティにより生成 される。 2. CertificationRequestInfo 値は、エンティティの私有鍵により署名 される（第6.2節を参照）。 3. CertificationRequestInfo 値と署名アルゴリズム識別子、そしてエン ティティの署名は合わせられて、以下で示すCertificationRequest値 となる。 認証局では、次のようにしてリクエストを実行する。まずエンティティの署名を 検証し、そしてそれが有効であれば、DistinguishedNameと公開鍵、そして発行 者名、シリアル番号、有効期間、そして認証局が選択した署名アルゴリズムを 使用してX.509証明書を作成する。証明書要求にPKCS #9 extended-certificate- attributes属性が含まれていた場合には、認証局はX.509証明書とextended- certificate-attributes属性値からPKCS #6拡張証明書を作成する。 認証局がどのような形式で新規証明書を返送するかについてはこのドキュメントの 範囲外である。1つの可能性としては、signedData型をもつPKCS #7暗号メッセージ がある。またその次の可能性としては、署名されていない形式を使用する場合が 挙げられる。返送されるメッセージには、新規証明書から認証局への証明書パスが 含まれていてもよい。また認証局が有用であると考えている、相互証明書などの 他の証明書が含まれていてもよく、また証明書失効リスト(certificate-revocation lists:CRLs)が含まれていてもよい。他の可能性としては、認証局が新規証明書を 集中管理データベースに格納することである。 この章は2つのパートに分けられる。最初のパートでは、証明書要求情報である CertificationRequestInfo型を示す。そして2番目のパートでは、最上位である CertificationRequest型を示す。 注： 1. エンティティは、公開鍵/私有鍵ペアを生成した後に証明書要求を送る のが通常であるが、エンティティのDistinguishedNameが変更された 後にも送ることができる。 2. 証明書要求に対して署名をすることにより、あるエンティティが、他の パーティーの公開鍵を使用して証明書を要求することを防いでいる。 このような攻撃により、他のパーティーが署名したすべてのメッセージの 署名者を装うことができるというささいな能力をそのエンティティに 与えることになる。この攻撃は、そのエンティティが署名されたメッ セージを知らず、かつメッセージの署名部分では署名者が識別できない 場合に問題となる。しかしそのエンティティは、他のパーティー向けの メッセージを復号することはもちろんできない。 3. エンティティが、どのような方法で認証局に証明書要求を送るかに ついては、本ドキュメントの範囲外である。紙による方法、または電子的 に送信する方法などが考えうる。 4. このドキュメントは、RFC 1424で示されている、Privacy-Enhanced Mail での証明書要求構文とは互換性がない。このドキュメントの構文は、 次の3つの点でPrivacy-Enhanced Mailと異なる。それは属性値を含める ことができる点、発行者名、シリアル番号、もしくは有効期限が存在し ない点、そして署名を行わなければならない"無害な"メッセージを必要 としない点である。このドキュメントの構文は、要求のサイズを最小に するよう設計されている。これは、要求を紙で受理している認証局に とって非常に重要な制約である。 6.1 CertificationRequestInfo 証明書要求情報は、ASN.1の CertificationRequestInfo 型をもつ。 CertificationRequestInfo ::= SEQUENCE { version Version, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, attributes [0] IMPLICIT Attributes } Version ::= INTEGER Attributes ::= SET OF Attribute CertificationRequestInfo 型の各フィールドは、以下のような意味をもつ。 o version はバージョン番号である。本ドキュメントの改定版との互換性 のためのものである。本ドキュメントの本バージョンでは、この値は 0 である。 o subject は証明書の主体者（証明される公開鍵を保持しているエンティティ） のDistinguishedNameである。 o subjectPublicKeyInfo には、証明される公開鍵に関する情報が含まれて いる。その情報は、エンティティの公開鍵アルゴリズム（とそれに関連する parameters）を識別する。公開鍵アルゴリズムの例として、X.509のrsa とPKCS #1 のrsaEncryptionが挙げられる。情報にはまた、エンティティ の公開鍵のビット文字列表記が含まれる。ここで挙げたどちらの公開鍵 アルゴリズムにおいても、ビット文字列には、X.509、もしくはPKCS #1の RSAPublicKey型の値のBERエンコーディングが含まれる。 o attributes は、証明書の主体者に関する付加情報を提供する一連の 属性である。ここで有用ないくつかの属性型は、PKCS #9 で定義されて いる。その一例として、challenge password属性が挙げられる。これは エンティティが証明書の失効を要求する際のパスワードを指定するもの である。他の例としては、extended-certificate-attributes属性が挙げ られる。これはPKCS #6 拡張証明書の属性を指定するものである。 6.2 CertificationRequest 証明書要求は、ASN.1の CertificationRequest 型をもつ。 CertificationRequest ::= SEQUENCE { certificationRequestInfo CertificationRequestInfo, signatureAlgorithm SignatureAlgorithmIdentifier, signature Signature } SignatureAlgorithmIdentifier ::= AlgorithmIdentifier Signature ::= BIT STRING CertificationRequest 型の各フィールドは、以下のような意味をもつ。 o certificateRequestInfo は、"証明書要求情報"である。この値は署名対象 である。 o signatureAlgorithm は、証明書要求情報の署名に使用する署名アルゴ リズム（とそれに関するparameters）を識別する。その例としては、 PKCS #1 のmd2WithRSAEncryption やmd5WithRSAEncryptionが挙げられる。 o signature は、証明書要求情報を、証明書要求を行う主体者の私有鍵で 署名した結果である。 署名プロセスは、次の2つのステップから構成されている。 1. certificationRequestInfo フィールドの値はDERエンコード処理され、 オクテット文字列が生成される。 2. ステップ1の結果は、指定された署名アルゴリズムを使用して、証明書 要求を行う主体者の私有鍵で署名され、ビット文字列、すなわち署名 が生成される。 注: CertificationRequest の構文は、X.509のSIGNED マクロを使用したもの と同じである。 CertificationRequest ::= SIGNED CertificateRequestInfo セキュリティに関する考察 セキュリティ問題は、このメモ全体を通じて議論されている。 変更履歴 バージョン1.0 バージョン1.0は、最初のバージョンである。 謝辞 このドキュメントは、RSA Data Security, Inc の1部門である RSA 研究所の 貢献に基づいている。このドキュメントの文章を使用する場合には、 RSA Data Security, Inc の承諾を必要とする。本ドキュメントを言及、 または参照するすべてのドキュメントでは、本ドキュメントを "RSA Data Security, Inc. PKCS #10" と記述しなければならないものとする。 著者のアドレス Burt Kaliski RSA Laboratories East 20 Crosby Drive Bedford, MA 01730 Phone: (617) 687-7000 EMail: burt@rsa.com 著作権表示 Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 日本語訳 西原 啓輔 2001年9月 訳者は、訳出した文書を利用することにより発生したいかなる損害に対しても 責任を負いません。 本文書には、技術的あるいは翻訳上の誤りがある可能性があります。技術的に 正しい知識を獲得しなければならない場合は、InterNIC/IETFから発行されて いる原文を参照してください。