RFC4853 日本語訳

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

Housleyがコメントのために要求するワーキンググループR.をネットワークでつないでください: 4853の不寝番セキュリティアップデート: 3852 2007年4月のカテゴリ: 標準化過程

                   Cryptographic Message Syntax (CMS)
                     Multiple Signer Clarification

暗号のメッセージ構文複数の(cm)署名者明確化

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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(2007)。

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.

このドキュメントはCryptographic Message Syntax(CMS)をアップデートします。(Cryptographic Message SyntaxはRFC3852で発行されます)。 保護されて、このドキュメントはSignedDataの適切な取り扱いをはっきりさせます。1つ以上のデジタル署名が存在しているcontent type。

Housley                     Standards Track                     [Page 1]

RFC 4853           CMS Multiple Signer Clarification          April 2007

Housley規格は複数の署名者明確化2007年4月にRFCを4853cm追跡します[1ページ]。

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.

このドキュメントはCryptographic Message Syntax[CMS]をアップデートします。 保護されたcontent typeが複数のデジタル署名、しかし、仕様を許容する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であるとサポートするなら、署名者は2つの署名、RSAがある1、およびECDSAがある1つを生成することができます、それぞれの受取人が署名の1つを有効にすることができるように。 共同体であることの2番目は各受取人が許容できる署名を見つけることができるための、より古いアルゴリズムと、より新しい署名アルゴリズムで一方向ハッシュ関数かデジタル署名アルゴリズム、署名者が内容であると署名することができる移行です、変遷におけるそれらの状態にかかわらず。 例えば、SHA-1とRSAからSHA-256とRSAまでの変遷を考えてください。 署名者は2つの署名、SHA-1がある1、およびSHA-256がある1つを生成することができます、それぞれの受取人が少なくともRSA署名の1つを有効にすることができるように。

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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[STDWORDS]で説明されるように本書では解釈されることであるべきですか?

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

3. RFC3852、セクション5に以下をアップデートしてください。 署名しているデータcontent type

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

RFC3852、セクション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.

| 受取人は独自にメッセージダイジェストを計算します。 このメッセージ| ダイジェストと署名者の公開鍵は、署名について確かめるのに使用されます。| 値。 署名者の公開鍵は発行人によって参照をつけられます。| 発行人特有の通し番号に伴う分類名| 唯一証明書を特定する対象の主要な識別子| 公開鍵を含んでいます。 署名者の証明書を含むことができます。| SignedData証明書分野で。

Housley                     Standards Track                     [Page 2]

RFC 4853           CMS Multiple Signer Clarification          April 2007

Housley規格は複数の署名者明確化2007年4月にRFCを4853cm追跡します[2ページ]。

   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.

| 受取人は独自にメッセージダイジェストを計算します。 このメッセージ| ダイジェストと署名者の公開鍵は、署名について確かめるのに使用されます。| 値。 署名者の公開鍵は発行人によって参照をつけられます。| 発行人特有の通し番号に伴う分類名| 唯一証明書を特定する対象の主要な識別子| 公開鍵を含んでいます。 署名者の証明書を含むことができます。| SignedData証明書分野で。 | | 1つ以上の署名がプレゼント、うまくいっている合法化であるときに| 1では、通常、与えられた署名者に関連している署名は扱われます。| その署名者によるうまくいっている署名として。 しかしながら、何かがあります。| 他の規則が必要であるアプリケーション環境。 1| それが1つの有効な署名以外の規則を使うアプリケーション| 各署名者はそれらの規則を指定しなければなりません。 また、簡単である、合っています。| 署名者識別子は、決定するために十分ではありません。| 署名は同じ署名者、アプリケーションで生成されました。| 仕様は署名がどれであったかを決定する方法を説明しなければなりません。| 同じ署名者で、生成されます。 異なった共同体のサポート| 受取人は署名者が、以上を含んでいるのを選ぶプライマリ理由です。| 1つの署名より。 例えば、署名しているデータcontent typeはそうするかもしれません。| そしてRSA署名アルゴリズムで生成された署名を含めてください。| ECDSA署名アルゴリズムで。 これは受取人を許容します。| 1つのアルゴリズムかもう片方に関連している署名について確かめてください。

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

4. RFC3852、セクション5.1に以下をアップデートしてください。 SignedDataはタイプします。

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

RFC3852、セクション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.

| signerInfosは1署名者あたりの情報の収集です。 そこであるかもしれない| ゼロを含む収集におけるいろいろな要素になってください。 The| セクション5.3でSignerInfoタイプの細部について議論します。 | そして以来に各署名者がデジタル署名のテクニックを使うことができる。| 将来の仕様は構文、すべての実装をアップデートするかもしれません。| 優雅に、SignerInfoの非実装しているバージョンを扱わなければなりません。 | 実装がサポートしないすべて以来の促進、あらゆる、可能| 署名アルゴリズム、実装が優雅に扱わなければならないすべて| 遭遇するとき、署名アルゴリズムを非実装しました。

   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

| signerInfosは1署名者あたりの情報の収集です。 そこであるかもしれない| ゼロを含む収集におけるいろいろな要素になってください。 いつ| 収集は1つ以上の署名、うまくいくのを表します。| 1の合法化、当然のことからの署名では、署名者はそうであるべきです。| その署名者によってうまくいっている署名として扱われます。 しかしながら| いくつかのアプリケーション環境が他の規則があるところにあります。

Housley                     Standards Track                     [Page 3]

RFC 4853           CMS Multiple Signer Clarification          April 2007

Housley規格は複数の署名者明確化2007年4月にRFCを4853cm追跡します[3ページ]。

|     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.

| 必要です。 タイプについて議論するSignerInfoの細部| セクション5.3。 a異なる、それぞれ署名者缶の使うの以来デジタル| 仕様がアップデートできた署名のテクニック、および未来| 構文、非実装されて、実装が優雅に扱わなければならないすべて| SignerInfoのバージョン。 さらに、すべて以来、実装はそうするでしょう。| あらゆる可能な署名アルゴリズムをサポートしてください、すべて| 実装は優雅に非実装している署名を扱わなければなりません。| それらであるときに、アルゴリズムは遭遇します。

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.

[cm] Housley、R.、「暗号のメッセージ構文(cm)」、RFC3852、2004年7月。

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

[STDWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

Author's Address

作者のアドレス

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

ラッセルHousley不寝番セキュリティ、スプリング小山Driveハーンドン、LLC918ヴァージニア20170米国

   EMail: housley@vigilsec.com

メール: housley@vigilsec.com

Housley                     Standards Track                     [Page 4]

RFC 4853           CMS Multiple Signer Clarification          April 2007

Housley規格は複数の署名者明確化2007年4月にRFCを4853cm追跡します[4ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(2007)。

   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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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はこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。

Acknowledgement

承認

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

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Housley                     Standards Track                     [Page 5]

Housley標準化過程[5ページ]