Internet Engineering Task Force (IETF) S. Santesson
Request for Comments: 5816 3xA Security
Updates: 3161 N. Pope
Category: Standards Track Thales
ISSN: 2070-1721 March 2010
ESSCertIDv2 Update for
Abstract
抽象
This document updates RFC 3161. It allows the use of ESSCertIDv2, as defined in RFC 5035, to specify the hash of a signer certificate when the hash is calculated with a function other than the Secure Hash Algorithm (SHA-1).
この文書の更新RFC 3161、RFC 5035で定義されたように、それはハッシュがセキュアハッシュアルゴリズム（SHA-1）以外の関数を用いて計算された場合、署名者証明書のハッシュを指定するために、ESSCertIDv2の使用を可能にします。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5816.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5816で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................2
2. Updates to RFC 3161 .............................................3
2.1. Changes to Section 2.4.1, Request Format ...................3
2.2. Changes to Section 2.4.2, Response Format ..................3
2.2.1. Signature of Time-Stamp Token .......................3
2.2.2. Verifying the Time-Stamp Token ......................4
3. Security Considerations .........................................4
4. References ......................................................5
4.1. Normative References .......................................5
4.2. Informative References .....................................5
The time-stamping protocol defined in RFC 3161 [RFC3161] requires that the Cryptographic Message Syntax (CMS) SignedData [RFC5652], used to apply a digital signature on the time-stamp token, include a signed attribute that identifies the signer's certificate.
RFC 3161 [RFC3161]で定義されたタイムスタンププロトコルは、暗号メッセージ構文タイムスタンプトークンにデジタル署名を適用するために使用される（CMS）のSignedData [RFC5652]は、署名者の証明書を識別する署名した属性を含めることを必要とします。
This identifier only allows SHA-1 [SHA1] to be used as the hash algorithm to generate the identifier value.
この識別子は、SHA1 [SHA1]識別子値を生成するハッシュアルゴリズムとして使用されることを可能にします。
The mechanism used in [RFC3161] employed ESSCertID from RFC 2634 [ESS]. RFC 5035 [ESSV2] updated ESSCertID with ESSCertIDv2 to allow the use of any hash algorithm.
[RFC3161]で使用されるメカニズムは、RFC 2634 [ESS]からESSCertIDを用います。 ESSCertIDv2とRFC 5035 [ESSV2]更新ESSCertIDは、任意のハッシュアルゴリズムの使用を可能にします。
The changes to RFC 3161 [RFC3161] defined in this document allow ESSCertIDv2 to be used to include an identifier of the signing certificate as defined in RFC 5035 [ESSV2].
この文書で定義されたRFC 3161への変更[RFC3161]はESSCertIDv2は、RFC 5035 [ESSV2]で定義されるように署名証明書の識別子を含めるために使用されることを可能にします。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
Last paragraph on Page 5.
5ページの最後の段落。
Old:
古い：
If the certReq field is present and set to true, the TSA's public key certificate that is referenced by the ESSCertID identifier inside a SigningCertificate attribute in the response MUST be provided by the TSA in the certificates field from the SignedData structure in that response. That field may also contain other certificates.
CERTREQフィールドが存在し、Trueに設定されている場合、応答にSigningCertificate属性の内部ESSCertID識別子によって参照されるTSAの公開鍵証明書は、その応答のSignedData構造からの証明書フィールドにTSAによって提供されなければなりません。そのフィールドは、他の証明書が含まれていてもよいです。
New:
新着：
If the certReq field is present and set to true, the TSA's public key certificate that is referenced by the ESSCertID [ESS] field inside a SigningCertificate attribute or by the ESSCertIDv2 [ESSV2] field inside a SigningCertificateV2 attribute in the response MUST be provided by the TSA in the certificates field from the SignedData structure in that response. That field may also contain other certificates.
CERTREQフィールドがtrueに存在し、設定されている場合は、SigningCertificate属性内または応答でSigningCertificateV2属性内部ESSCertIDv2 [ESSV2]フィールドでESSCertID [ESS]フィールドで参照されているTSAの公開鍵証明書を提供する必要がありその応答でのSignedData構造からの証明書フィールドにTSA。そのフィールドは、他の証明書が含まれていてもよいです。
Fifth paragraph on Page 8, just before the definition of TSTInfo.
ちょうどTSTInfoの定義の前に8ページの第五段落、。
Old:
古い：
The time-stamp token MUST NOT contain any signatures other than the signature of the TSA. The certificate identifier (ESSCertID) of the TSA certificate MUST be included as a signerInfo attribute inside a SigningCertificate attribute.
タイムスタンプトークンは、TSAの署名以外の任意の署名を含めることはできません。 TSA証明書の証明書識別子（ESSCertID）はSigningCertificate属性内部のSignerInfo属性として含まなければなりません。
New:
新着：
The time-stamp token MUST NOT contain any signatures other than the signature of the TSA. The certificate identifier (either ESSCertID [ESS] or ESSCertIDv2 [ESSV2]) of the TSA certificate MUST be included as a signerInfo attribute inside a SigningCertificate attribute.
タイムスタンプトークンは、TSAの署名以外の任意の署名を含めることはできません。 TSA証明書の証明書識別子（ESSCertID [ESS]のいずれか、またはESSCertIDv2 [ESSV2]）はSigningCertificate属性内部のSignerInfo属性として含まなければなりません。
Note: As mentioned in RFC 5035 [ESSV2], the SigningCertificateV2 attribute MUST be used if any algorithm other than SHA-1 is used and SHOULD NOT be used for SHA-1.
注：SHA-1以外のアルゴリズムが使用され、SHA-1のために使用されるべきでない場合、RFC 5035で説明したように[ESSV2]、SigningCertificateV2属性が使用されなければなりません。
Note: For backwards compatibility, in line with RFC 5035, both ESSCertID and ESSCertIDv2 MAY be present. Systems MAY ignore ESSCertIDv2 if RFC 5035 has not been implemented.
注：後方互換性のために、RFC 5035に沿って、ESSCertIDとESSCertIDv2の両方が存在してもよいです。 RFC 5035が実装されていない場合、システムはESSCertIDv2を無視するかもしれません。
Third paragraph on Page 11.
11ページ第三段落。
Old:
古い：
The purpose of the tsa field is to give a hint in identifying the name of the TSA. If present, it MUST correspond to one of the subject names included in the certificate that is to be used to verify the token. However, the actual identification of the entity that signed the response will always occur through the use of the certificate identifier (ESSCertID Attribute) inside a SigningCertificate attribute which is part of the signerInfo (See Section 5 of [ESS]).
TSAフィールドの目的は、TSAの名前を識別するのにヒントを与えることです。存在する場合、それはトークンを検証するために使用される証明書に含まれるサブジェクト名のいずれかに対応しなければなりません。しかし、応答に署名したエンティティの実際の同定は常にのSignerInfoの一部であるSigningCertificate属性内の証明書識別子（ESSCertID属性）の使用を介して発生する（[ESS]のセクション5を参照）。
New:
新着：
The purpose of the tsa field is to give a hint in identifying the name of the TSA. If present, it MUST correspond to one of the subject names included in the certificate that is to be used to verify the token. However, the actual identification of the entity that signed the response will always occur through the use of the certificate identifier (ESSCertID inside a SigningCertificate attribute or ESSCertIDv2 inside a SigningCertificateV2 attribute) that is part of the signerInfo (see Section 5 of [ESS] and Section 3 of [ESSV2]).
TSAフィールドの目的は、TSAの名前を識別するのにヒントを与えることです。存在する場合、それはトークンを検証するために使用される証明書に含まれるサブジェクト名のいずれかに対応しなければなりません。しかし、応答に署名したエンティティの実際の同定は常にのSignerInfoの一部である証明書識別子（SigningCertificateV2属性内部SigningCertificate属性またはESSCertIDv2内部ESSCertID）の使用を介して発生する（[ESS]の第5章を参照【ESSV2]のセクション3）。
This document incorporates the security considerations of RFC 5035 [ESSV2] with further explanations in this section.
この文書では、次のセクションでさらに説明して[ESSV2] RFC 5035のセキュリティ上の配慮が組み込まれています。
ESSCertID provides a means based on the SHA-1 hash algorithm for identifying the certificate used to verify the signature on a time stamp. The use of ESSCertIDv2 aims to enable implementers to comply with policies that require phasing out all uses of the SHA-1 algorithm.
ESSCertIDは、タイムスタンプの署名を検証するために使用される証明書を特定するためのSHA-1ハッシュアルゴリズムに基づく手段を提供します。 ESSCertIDv2の使用はSHA-1アルゴリズムのすべての使用を段階的に廃止する必要がポリシーに準拠する実装を可能にすることを目指しています。
The update provided by this document is motivated by reasons of interoperability and migration to other hash algorithms rather than mitigating new security issues.
この文書で提供された更新は、他のハッシュアルゴリズムに相互運用性と移行の理由のが動機ではなく、新たなセキュリティ問題を軽減しています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[ESS] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[ESS]ホフマン、P.、エド。、 "セキュリティ強化サービスS / MIMEのために"、RFC 2634、1999年6月。
[ESSV2] Schaad, J., "Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility", RFC 5035, August 2007.
[ESSV2] Schaad、J.、 "拡張セキュリティサービス（ESS）更新：CertIDアルゴリズムアジリティを追加"、RFC 5035、2007年8月。
[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, August 2001.
[RFC3161]アダムス、C.、カイン、P.、ピンカス、D.、およびR. Zuccherato、 "インターネットX.509公開鍵インフラストラクチャのタイムスタンププロトコル（TSP）"、RFC 3161、2001年8月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 5652, September 2009.
[RFC5652] Housley氏、R.、 "暗号メッセージ構文（CMS）"、RFC 5652、2009年9月。
[SHA1] Secure Hash Standard. FIPS Pub 180-1. National Institute of Standards and Technology. 17 April 1995.
[SHA1]ハッシュスタンダードセキュア。 FIPS 180-1をパブ。アメリカ国立標準技術研究所。 1995年4月17日。
Authors' Addresses
著者のアドレス
Stefan Santesson 3xA Security AB Sweden
ステファンSantesson 3XAセキュリティABスウェーデン
EMail: sts@aaa-sec.com
メールアドレス：sts@aaa-sec.com
Nick Pope Thales Information Systems Security Long Crendon, Aylesbury United Kingdom
ニック・ポープタレス情報システムセキュリティロングCrendon、アリスバーリーイギリス
EMail: nick.pope@thales-esecurity.com
メールアドレス：nick.pope@thales-esecurity.com