RFC 4853 - Cryptographic Message Syntax (CMS) Multiple Signer Clarification 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc4853
タイトル : RFC 4853 - 暗号化メッセージ構文（CMS）の複数の署名者の明確化
翻訳編集 : 自動生成

[要約] RFC 4853は、Cryptographic Message Syntax（CMS）の複数の署名者に関する説明と明確化を提供しています。このRFCの目的は、CMSの複数の署名者に関する仕様の不明確な点を解決し、実装と相互運用性を向上させることです。

Network Working Group                                         R. Housley
Request for Comments: 4853                                Vigil Security
Updates: 3852                                                 April 2007
Category: Standards Track

Cryptographic Message Syntax (CMS) Multiple Signer Clarification

暗号化メッセージ構文（CMS）の複数の署名者の明確化

Status of This Memo

本文書の状態

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

Abstract

概要

This document updates the Cryptographic Message Syntax (CMS), which is published in RFC 3852. This document clarifies the proper handling of the SignedData protected content type when more than one digital signature is present.

このドキュメントは、RFC 3852で公開されている暗号化メッセージ構文（CMS）を更新します。このドキュメントでは、複数のデジタル署名が存在する場合のSignedData保護コンテンツタイプの適切な処理について説明します。

1. Introduction

1. はじめに

This document updates the Cryptographic Message Syntax [CMS]. The CMS SignedData protected content type allows multiple digital signatures, but the specification is unclear about the appropriate processing by a recipient of such a signed content. This document provides replacement text for a few paragraphs, making it clear that the protected content is validly signed by a given signer, if any of the digital signatures from that signer are valid.

このドキュメントは、暗号化メッセージ構文[CMS]を更新します。 CMS SignedDataで保護されたコンテンツタイプでは複数のデジタル署名が許可されていますが、そのような署名付きコンテンツの受信者による適切な処理については仕様が明確ではありません。このドキュメントは、いくつかの段落の置換テキストを提供し、その署名者のデジタル署名のいずれかが有効な場合、保護されたコンテンツが特定の署名者によって有効に署名されていることを明確にします。

This property is especially important in two cases. First, when the recipients do not all implement the same digital signature algorithm, a signer can sign the content with several different digital signature algorithms so that each of the recipients can find an acceptable signature. For example, if some recipients support RSA and some recipients support ECDSA, then the signer can generate two signatures, one with RSA and one with ECDSA, so that each recipient will be able to validate one of the signatures. Second, when a community is transitioning one-way hash functions or digital signature algorithms, a signer can sign the content with the older and the newer signature algorithms so that each recipient can find an acceptable signature, regardless of their state in the transition. For example, consider a transition from RSA with SHA-1 to RSA with SHA-256. The signer can generate two signatures, one with SHA-1 and one with SHA-256, so that each recipient will be able to validate at least one of the RSA signatures.

この特性は、2つの場合に特に重要です。まず、すべての受信者が同じデジタル署名アルゴリズムを実装していない場合、署名者は複数の異なるデジタル署名アルゴリズムを使用してコンテンツに署名できるため、各受信者は受け入れ可能な署名を見つけることができます。たとえば、一部の受信者がRSAをサポートし、一部の受信者がECDSAをサポートしている場合、署名者はRSAとECDSAの2つの署名を生成できるため、各受信者は署名の1つを検証できます。次に、コミュニティが一方向のハッシュ関数またはデジタル署名アルゴリズムを移行しているときに、署名者は古い署名アルゴリズムと新しい署名アルゴリズムを使用してコンテンツに署名できるため、移行中の状態に関係なく、各受信者は受け入れ可能な署名を見つけることができます。たとえば、SHA-1を使用するRSAからSHA-256を使用するRSAへの移行を考えてみます。署名者はSHA-1とSHA-256の2つの署名を生成できるため、各受信者は少なくとも1つのRSA署名を検証できます。

2. Terminology

2. 用語

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 [STDWORDS].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [STDWORDS]で説明されているように解釈されます。

3. Update to RFC 3852, Section 5: Signed-data Content Type

3. RFC 3852、セクション5への更新：署名付きデータコンテンツタイプ

RFC 3852, section 5, the next to the last paragraph says:

RFC 3852、セクション5、最後の段落の次は言う：

|  A recipient independently computes the message digest.  This message
|  digest and the signer's public key are used to verify the signature
|  value.  The signer's public key is referenced either by an issuer
|  distinguished name along with an issuer-specific serial number or by
|  a subject key identifier that uniquely identifies the certificate
|  containing the public key.  The signer's certificate can be included
|  in the SignedData certificates field.

This block of text is replaced with:

このテキストブロックは、次のものに置き換えられます。

|  A recipient independently computes the message digest.  This message
|  digest and the signer's public key are used to verify the signature
|  value.  The signer's public key is referenced either by an issuer
|  distinguished name along with an issuer-specific serial number or by
|  a subject key identifier that uniquely identifies the certificate
|  containing the public key.  The signer's certificate can be included
|  in the SignedData certificates field.
|
|  When more than one signature is present, the successful validation
|  of one signature associated with a given signer is usually treated
|  as a successful signature by that signer.  However, there are some
|  application environments where other rules are needed.  An
|  application that employs a rule other than one valid signature for
|  each signer must specify those rules.  Also, where simple matching of
|  the signer identifier is not sufficient to determine whether the
|  signatures were generated by the same signer, the application
|  specification must describe how to determine which signatures were
|  generated by the same signer.  Support of different communities of
|  recipients is the primary reason that signers choose to include more
|  than one signature.  For example, the signed-data content type might
|  include signatures generated with the RSA signature algorithm and
|  with the ECDSA signature algorithm.  This allows recipients to
|  verify the signature associated with one algorithm or the other.

4. Update to RFC 3852, Section 5.1: SignedData Type

4. RFC 3852、セクション5.1への更新：SignedDataタイプ

RFC 3852, section 5.1, the next to the last paragraph says:

RFC 3852、セクション5.1、最後の段落の次は言う：

|     signerInfos is a collection of per-signer information.  There MAY
|     be any number of elements in the collection, including zero.  The
|     details of the SignerInfo type are discussed in section 5.3.
|     Since each signer can employ a digital signature technique and
|     future specifications could update the syntax, all implementations
|     MUST gracefully handle unimplemented versions of SignerInfo.
|     Further, since all implementations will not support every possible
|     signature algorithm, all implementations MUST gracefully handle
|     unimplemented signature algorithms when they are encountered.

This block of text is replaced with:

このテキストブロックは、次のものに置き換えられます。

|     signerInfos is a collection of per-signer information.  There MAY
|     be any number of elements in the collection, including zero.  When
|     the collection represents more than one signature, the successful
|     validation of one of signature from a given signer ought to be
|     treated as a successful signature by that signer.  However,
|     there are some application environments where other rules are

|     needed.  The details of the SignerInfo type are discussed in
|     section 5.3.  Since each signer can employ a different digital
|     signature technique, and future specifications could update the
|     syntax, all implementations MUST gracefully handle unimplemented
|     versions of SignerInfo.  Further, since all implementations will
|     not support every possible signature algorithm, all
|     implementations MUST gracefully handle unimplemented signature
|     algorithms when they are encountered.

6. Security Considerations

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

The replacement text will reduce the likelihood of interoperability errors during the transition from MD5 and SHA-1 to stronger one-way hash functions, or to better signature algorithms.

置換テキストは、MD5とSHA-1からより強力な一方向ハッシュ関数、またはより優れた署名アルゴリズムへの移行中に、相互運用性エラーの可能性を減らします。

7. Normative References

7. 引用文献

[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.

[CMS] Housley、R。、「Cryptographic Message Syntax（CMS）」、RFC 3852、2004年7月。

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

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

Author's Address

著者のアドレス

Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA

Russell Housley Vigil Security、LLC 918 Spring Knoll Drive Herndon、VA 20170アメリカ

   EMail: housley@vigilsec.com

Full Copyright Statement

完全な著作権表示

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

このドキュメントは、BCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネット社会、IETFトラスト、およびインターネットエンジニアリングタスクフォースはすべてを否認します。明示または黙示を問わず、ここに含まれる情報の使用が商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害しないことを保証するものではありません。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IETF事務局に対して行われたIPR開示のコピー、および利用可能になるライセンスの保証、または一般ライセンスを取得しようとした試み、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得した結果を取得できます。 http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、この規格の実装に必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能への資金提供は、現在Internet Societyから提供されています。