RFC 5816 - ESSCertIDv2 Update for RFC 3161 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc5816
タイトル : RFC 5816 - RFC 3161のESSCERTIDV2アップデート
翻訳編集 : 自動生成

[要約] RFC 5816は、RFC 3161のESSCertIDv2の更新を提案しています。目的は、RFC 3161のセキュリティ上の課題を解決し、ESSCertIDv2の使用を改善することです。

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 RFC 3161

RFC 3161のESSCERTIDV2アップデート

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を更新します。RFC5035で定義されているEsscertIdv2を使用して、セキュアハッシュアルゴリズム（SHA-1）以外の関数でハッシュが計算されたときに署名者証明書のハッシュを指定できます。

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.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5816で取得できます。

著作権表示

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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.

このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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

1. Introduction

1. はじめに

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.

この識別子は、SHA-1 [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を採用しました。RFC 5035 [ESSV2]は、ESSCERTIDV2を使用して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]で定義されている署名証明書の識別子を含めることができます。

1.1. Terminology

1.1. 用語

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]で説明されているように解釈されます。

2. Updates to RFC 3161

2. RFC 3161の更新

2.1. Changes to Section 2.4.1, Request Format

2.1. セクション2.4.1の変更、要求形式

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に設定されている場合、応答のSIGNISINCECTIFICATE属性内の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に設定されている場合、singingcertificate属性内のesscertid [ess]フィールドまたはsigningcertififatev2属性内のesscertidv2 [essv2]フィールドが応答のsigningcertidv2 [essv2]フィールドが参照するTSAの公開鍵証明書は、応答によって提供されなければなりません。その応答におけるSignedData構造から証明書のフィールドのTSA。そのフィールドには、他の証明書も含まれている場合があります。

2.2. Changes to Section 2.4.2, Response Format

2.2. セクション2.4.2の変更、応答形式

2.2.1. Signature of Time-Stamp Token

2.2.1. タイムスタンプトークンの署名

Fifth paragraph on Page 8, just before the definition of TSTInfo.

TSTINFOの定義の直前の8ページの5番目の段落。

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]のいずれか）は、SINGINALCERTIFIFATE属性内のSINIGNERINFO属性として含める必要があります。

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.

注：RFC 5035 [ESSV2]で述べたように、SHA-1以外のアルゴリズムが使用され、SHA-1には使用しないでください。

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を無視する場合があります。

2.2.2. Verifying the Time-Stamp Token

2.2.2. タイムスタンプトークンの確認

Third paragraph on Page 11.

11ページの3番目の段落。

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の名前を識別するためのヒントを与えることです。存在する場合、トークンの検証に使用される証明書に含まれる主題名の1つに対応する必要があります。ただし、応答に署名したエンティティの実際の識別は、SignerInfoの一部であるSigniveCertificate属性内の証明書識別子（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の名前を識別するためのヒントを与えることです。存在する場合、トークンの検証に使用される証明書に含まれる主題名の1つに対応する必要があります。ただし、応答に署名したエンティティの実際の識別は、常に証明書識別子（signingcertificate属性内のesscertidまたはsigningcertificatev2属性内のessigncertidv2内のesscertid）を使用して発生します（signerinfoの一部）（[ess]のセクション5を参照してください）[ESSV2]のセクション3）。

3. Security Considerations

3. セキュリティに関する考慮事項

This document incorporates the security considerations of RFC 5035 [ESSV2] with further explanations in this section.

このドキュメントには、RFC 5035 [Essv2]のセキュリティに関する考慮事項が組み込まれており、このセクションではさらに説明があります。

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.

このドキュメントで提供される更新は、新しいセキュリティの問題を軽減するのではなく、相互運用性と他のハッシュアルゴリズムへの移行の理由によって動機付けられています。

4. References

4. 参考文献

4.1. Normative References

4.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[ESS] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.

[ESS] Hoffman、P.、ed。、「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。、「Enhanced Security Services（ESS）アップデート：CertID Algorithm Agilityの追加」、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] Adams、C.、Cain、P.、Pinkas、D。、およびR. Zuccherato、「Internet 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月。

4.2. Informative References

4.2. 参考引用

[SHA1] Secure Hash Standard. FIPS Pub 180-1. National Institute of Standards and Technology. 17 April 1995.

[SHA1]安全なハッシュ標準。FIPS Pub 180-1。国立標準技術研究所。1995年4月17日。

Authors' Addresses

著者のアドレス

Stefan Santesson 3xA Security AB Sweden

Stefan Santesson 3XAセキュリティABスウェーデン

   EMail: sts@aaa-sec.com

Nick Pope Thales Information Systems Security Long Crendon, Aylesbury United Kingdom

ニック・ポープ・タレス情報システムセキュリティロングクレンドン、エルズベリー英国

   EMail: nick.pope@thales-esecurity.com