[要約] RFC 6211は、Cryptographic Message Syntax (CMS) におけるアルゴリズム識別子の保護を強化するための方法を定義しています。この文書の目的は、CMS署名や暗号化プロセスにおいて使用されるアルゴリズムの識別子が改ざんされるリスクを軽減することにあります。これは、CMS署名されたデータやCMS暗号化されたデータのセキュリティを向上させるために利用されます。関連するRFCには、RFC 5652（CMSの仕様を定義）などがあります。RFC 6211は、セキュリティを重視する通信において、アルゴリズムの整合性を保証するための重要な役割を果たします。
Internet Engineering Task Force (IETF) J. Schaad
Request for Comments: 6211 Soaring Hawk Consulting
Category: Standards Track April 2011
ISSN: 2070-1721
Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute
暗号化メッセージ構文（CMS）アルゴリズム識別子保護属性
Abstract
概要
The Cryptographic Message Syntax (CMS), unlike X.509/PKIX certificates, is vulnerable to algorithm substitution attacks. In an algorithm substitution attack, the attacker changes either the algorithm being used or the parameters of the algorithm in order to change the result of a signature verification process. In X.509 certificates, the signature algorithm is protected because it is duplicated in the TBSCertificate.signature field with the proviso that the validator is to compare both fields as part of the signature validation process. This document defines a new attribute that contains a copy of the relevant algorithm identifiers so that they are protected by the signature or authentication process.
X.509 / PKIX証明書とは異なり、暗号化メッセージ構文（CMS）は、アルゴリズム置換攻撃に対して脆弱です。アルゴリズム置換攻撃では、攻撃者は、使用されているアルゴリズムまたはアルゴリズムのパラメーターを変更して、署名検証プロセスの結果を変更します。 X.509証明書では、検証アルゴリズムが署名検証プロセスの一部として両方のフィールドを比較することを条件として、TBSCertificate.signatureフィールドで複製されるため、署名アルゴリズムは保護されています。このドキュメントでは、関連するアルゴリズム識別子のコピーを含む新しい属性を定義して、署名または認証プロセスによって保護されるようにします。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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/rfc6211.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6211で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Attribute Structure . . . . . . . . . . . . . . . . . . . . . . 5
3. Verification Process . . . . . . . . . . . . . . . . . . . . . 7
3.1. Signed Data Verification Changes . . . . . . . . . . . . . 7
3.2. Authenticated Data Verification Changes . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . . 8
6.2. Informational References . . . . . . . . . . . . . . . . . 9
Appendix A. 2008 ASN.1 Module . . . . . . . . . . . . . . . . . 10
The Cryptographic Message Syntax [CMS], unlike X.509/PKIX certificates [RFC5280], is vulnerable to algorithm substitution attacks. In an algorithm substitution attack, the attacker changes either the algorithm being used or the parameters of the algorithm in order to change the result of a signature verification process. In X.509 certificates, the signature algorithm is protected because it is duplicated in the TBSCertificate.signature field with the proviso that the validator is to compare both fields as part of the signature validation process. This document defines a new attribute that contains a copy of the relevant algorithm identifiers so that they are protected by the signature or authentication process.
X.509 / PKIX証明書[RFC5280]とは異なり、暗号化メッセージ構文[CMS]は、アルゴリズム置換攻撃に対して脆弱です。アルゴリズム置換攻撃では、攻撃者は、使用されているアルゴリズムまたはアルゴリズムのパラメーターを変更して、署名検証プロセスの結果を変更します。 X.509証明書では、検証アルゴリズムが署名検証プロセスの一部として両方のフィールドを比較することを条件として、TBSCertificate.signatureフィールドで複製されるため、署名アルゴリズムは保護されています。このドキュメントでは、関連するアルゴリズム識別子のコピーを含む新しい属性を定義して、署名または認証プロセスによって保護されるようにします。
In an algorithm substitution attack, the attacker looks for a different algorithm that produces the same result as the algorithm used by the signer. As an example, if the creator of the message used SHA-1 as the digest algorithm to hash the message content, then the attacker looks for a different hash algorithm that produces a result that is of the same length, but with which it is easier to find collisions. Examples of other algorithms that produce a hash value of the same length would be SHA-0 or RIPEMD-160. Similar attacks can be mounted against parameterized algorithm identifiers. When looking at some of the proposed randomized hashing functions, such as that in [RANDOM-HASH], the associated security proofs assume that the parameters are solely under the control of the originator and not subject to selection by the attacker.
アルゴリズム置換攻撃では、攻撃者は、署名者が使用したアルゴリズムと同じ結果を生成する別のアルゴリズムを探します。例として、メッセージの作成者がダイジェストアルゴリズムとしてSHA-1を使用してメッセージのコンテンツをハッシュした場合、攻撃者は同じ長さの結果を生成する別のハッシュアルゴリズムを探しますが、これは簡単です。衝突を見つけるために。同じ長さのハッシュ値を生成する他のアルゴリズムの例は、SHA-0またはRIPEMD-160です。パラメータ化されたアルゴリズム識別子に対して同様の攻撃を仕掛けることができます。 [RANDOM-HASH]のように、提案されたランダム化ハッシュ関数のいくつかを見ると、関連するセキュリティ証明は、パラメータが発信者の制御下にあり、攻撃者による選択の影響を受けないと想定しています。
Some algorithms have been internally designed to be more resistant to this type of attack. Thus, an RSA PKCS #1 v.15 signature [RFC3447] cannot have the associated hash algorithm changed because it is encoded as part of the signature. The Digital Signature Algorithm (DSA) was originally defined so that it would only work with SHA-1 as a hash algorithm; thus, by knowing the public key from the certificate, a validator can be assured that the hash algorithm cannot be changed. There is a convention, undocumented as far as I can tell, that the same hash algorithm should be used for both the content digest and the signature digest. There are cases, such as third-party signers that are only given a content digest, where such a convention cannot be enforced.
一部のアルゴリズムは、この種の攻撃に対してより耐性を持つように内部的に設計されています。したがって、RSA PKCS＃1 v.15署名[RFC3447]は、署名の一部としてエンコードされているため、関連するハッシュアルゴリズムを変更できません。デジタル署名アルゴリズム（DSA）は当初、ハッシュアルゴリズムとしてSHA-1でのみ機能するように定義されていました。したがって、証明書から公開鍵を知ることにより、検証者はハッシュアルゴリズムを変更できないことを保証できます。コンテンツダイジェストと署名ダイジェストの両方に同じハッシュアルゴリズムを使用する必要があるという、私の知る限りでは文書化されていない規約があります。コンテンツダイジェストのみが与えられているサードパーティの署名者など、そのような規則を適用できない場合があります。
As with all attacks, the attack is going to be desirable on items that are both long term and high value. One would expect that these attacks are more likely to be made on older documents, as the algorithms being used when the message was signed would be more likely to have degraded over time. Countersigning, the classic method of protecting a signature, does not provide any additional protection against an algorithm substitution attack because countersignatures sign just the signature, but the algorithm substitution attacks leave the signature value alone while changing the algorithms being used.
すべての攻撃と同様に、攻撃は長期的で価値の高いアイテムに対して望ましいものです。メッセージの署名時に使用されているアルゴリズムは時間とともに劣化する可能性が高いため、これらの攻撃は古いドキュメントに対して行われる可能性が高いと予想されます。副署名は署名を保護する従来の方法ですが、副署名は署名のみに署名するため、アルゴリズム置換攻撃に対する追加の保護は提供されませんが、アルゴリズム置換攻撃では、使用されるアルゴリズムを変更する間、署名値はそのままになります。
Using the SignerInfo structure from CMS, let's take a more detailed look at each of the fields in the structure and discuss what fields are and are not protected by the signature. I have included a copy of the ASN.1 here for convenience. A similar analysis of the AuthenticatedData structure is left to the reader, but it can be done in much the same way.
CMSのSignerInfo構造を使用して、構造内の各フィールドをさらに詳しく見て、署名によって保護されているフィールドと保護されていないフィールドについて説明します。便宜上、ここにASN.1のコピーを含めました。 AuthenticatedData構造の同様の分析は読者に任されていますが、ほとんど同じ方法で行うことができます。
SignerInfo ::= SEQUENCE {
version CMSVersion,
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
version is not protected by the signature. As many implementations of CMS today ignore the value of this field, that is not a problem. If the value is increased, then no changes in the processing are expected. If the value is decreased, implementations that respect the structure would fail to decode, but an erroneous signature validation would not be completed successfully.
バージョンは署名によって保護されていません。現在、CMSの多くの実装ではこのフィールドの値を無視しているため、これは問題ではありません。値を大きくすると、処理に変化はありません。値が減少すると、構造を尊重する実装はデコードに失敗しますが、誤った署名検証は正常に完了しません。
sid can be protected using either version of the signing certificate authenticated attribute. SigningCertificateV2 is defined in [RFC5035]. SigningCertificate is defined in [ESS-BASE]. In addition to allowing for the protection of the signer identifier, the specific certificate is protected by including a hash of the certificate to be used for validation.
sidは、いずれかのバージョンの署名証明書認証属性を使用して保護できます。 SigningCertificateV2は[RFC5035]で定義されています。 SigningCertificateは[ESS-BASE]で定義されています。署名者識別子の保護に加えて、特定の証明書は、検証に使用される証明書のハッシュを含めることによって保護されます。
digestAlgorithm has been implicitly protected by the fact that CMS has only defined one digest algorithm for each hash value length. (The algorithm RIPEMD-160 was never standardized.) There is also an unwritten convention that the same digest algorithm should be used both here and for the signature algorithm. If newer digest algorithms are defined so that there are multiple algorithms for a given hash length (it is expected that the SHA-3 project will do so), or that parameters are defined for a specific algorithm, much of the implicit protection will be lost.
digestAlgorithmは、CMSが各ハッシュ値の長さに対して1つのダイジェストアルゴリズムしか定義していないという事実によって暗黙的に保護されています。 （アルゴリズムRIPEMD-160は決して標準化されていません。）また、同じダイジェストアルゴリズムをここと署名アルゴリズムの両方に使用する必要があるという不明確な規則もあります。新しいダイジェストアルゴリズムが特定のハッシュ長に対して複数のアルゴリズムが存在するように定義されている場合（SHA-3プロジェクトがそうすることが予想される）、または特定のアルゴリズムに対してパラメーターが定義されている場合、暗黙的な保護の多くが失われます。
signedAttributes are directly protected by the signature when they are present. The Distinguished Encoding Rules (DER) encoding of this value is what is hashed for the signature computation.
signedAttributesは、存在する場合、署名によって直接保護されます。この値のDistinguished Encoding Rules（DER）エンコーディングは、署名計算のためにハッシュされるものです。
signatureAlgorithm has been protected by implication in the past. The use of an RSA public key implied that the RSA v1.5 signature algorithm was being used. The hash algorithm and this fact could be checked by the internal padding defined. This is no longer true with the addition of the RSA-PSS signature algorithms. The use of a DSA public key implied the SHA-1 hash algorithm as that was the only possible hash algorithm and the DSA was the public signature algorithm. This is still somewhat true as there is an implicit tie between the length of the DSA public key and the length of the hash algorithm to be used, but this is known by convention and there is no explicit enforcement for this.
signatureAlgorithmは、過去の含意によって保護されてきました。 RSA公開鍵の使用は、RSA v1.5署名アルゴリズムが使用されていることを意味していました。ハッシュアルゴリズムとこの事実は、定義された内部パディングによって確認できます。これは、RSA-PSS署名アルゴリズムの追加によりもはや当てはまりません。 DSA公開鍵の使用は、SHA-1ハッシュアルゴリズムを暗示していました。これは、それが唯一可能なハッシュアルゴリズムであり、DSAが公開署名アルゴリズムであったためです。 DSA公開鍵の長さと使用するハッシュアルゴリズムの長さの間に暗黙の結びつきがあるため、これはまだいくらか当てはまりますが、これは慣例により既知であり、これに対する明示的な強制はありません。
signature is not directly protected by any other value unless a counter signature is present. However, this represents the cryptographically computed value that protects the rest of the signature information.
副署名が存在しない限り、署名は他の値によって直接保護されません。ただし、これは、残りの署名情報を保護する暗号で計算された値を表します。
unsignedAttrs is not protected by the signature value. The SignedData structure was explicitly designed that unsignedAttrs are not protected by the signature value.
unsignedAttrsは、署名値によって保護されていません。 SignedData構造は、unsignedAttrsが署名値によって保護されないように明示的に設計されています。
As can be seen above, the digestAlgorithm and signatureAlgorithm fields have been indirectly rather than explicitly protected in the past. With new algorithms that have been or are being defined, this will no longer be the case. This document defines and describes a new attribute that will explicitly protect these fields along with the macAlgorithm field of the AuthenticatedData structure.
上記からわかるように、digestAlgorithmフィールドとsignatureAlgorithmフィールドは、以前は明示的に保護されていたのではなく、間接的に保護されていました。定義済みまたは定義中の新しいアルゴリズムでは、これは当てはまりません。このドキュメントでは、AuthenticatedData構造のmacAlgorithmフィールドとともにこれらのフィールドを明示的に保護する新しい属性を定義および説明します。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The following defines the algorithm protection attribute:
以下は、アルゴリズム保護属性を定義します。
The algorithm protection attribute has the ASN.1 type CMSAlgorithmProtection:
アルゴリズム保護属性には、ASN.1タイプCMSAlgorithmProtectionがあります。
aa-cmsAlgorithmProtection ATTRIBUTE ::= {
TYPE CMSAlgorithmProtection
IDENTIFIED BY { id-aa-CMSAlgorithmProtection }
}
The following object identifier identifies the algorithm protection attribute:
次のオブジェクト識別子は、アルゴリズム保護属性を識別します。
id-aa-CMSAlgorithmProtection OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 52 }
The algorithm protection attribute uses the following ASN.1 type:
アルゴリズム保護属性は、次のASN.1タイプを使用します。
CMSAlgorithmProtection ::= SEQUENCE {
digestAlgorithm DigestAlgorithmIdentifier,
signatureAlgorithm [1] SignatureAlgorithmIdentifier OPTIONAL,
macAlgorithm [2] MessageAuthenticationCodeAlgorithm
OPTIONAL
}
(WITH COMPONENTS { signatureAlgorithm PRESENT,
macAlgorithm ABSENT } |
WITH COMPONENTS { signatureAlgorithm ABSENT,
macAlgorithm PRESENT })
The fields are defined as follows:
フィールドは次のように定義されています。
digestAlgorithm contains a copy of the SignerInfo.digestAlgorithm field or the AuthenticatedData.digestAlgorithm field including any parameters associated with it.
digestAlgorithmには、SignerInfo.digestAlgorithmフィールドまたはそれに関連するパラメーターを含むAuthenticatedData.digestAlgorithmフィールドのコピーが含まれています。
signatureAlgorithm contains a copy of the signature algorithm identifier and any parameters associated with it (SignerInfo.signatureAlgorithm). This field is populated only if the attribute is placed in a SignerInfo.signedAttrs sequence.
signatureAlgorithmには、署名アルゴリズム識別子のコピーとそれに関連付けられているパラメーター（SignerInfo.signatureAlgorithm）が含まれています。このフィールドは、属性がSignerInfo.signedAttrsシーケンスに配置されている場合にのみ入力されます。
macAlgorithm contains a copy of the message authentication code algorithm identifier and any parameters associated with it (AuthenticatedData.macAlgorithm). This field is populated only if the attribute is placed in an AuthenticatedData.authAttrs sequence.
macAlgorithmには、メッセージ認証コードアルゴリズム識別子とそれに関連付けられているパラメーター（AuthenticatedData.macAlgorithm）のコピーが含まれています。このフィールドは、属性がAuthenticatedData.authAttrsシーケンスに配置されている場合にのみ入力されます。
Exactly one of signatureAlgorithm or macAlgorithm SHALL be present.
signatureAlgorithmまたはmacAlgorithmのいずれか1つだけが存在する必要があります。
An algorithm protection attribute MUST have a single attribute value, even though the syntax is defined as a SET OF AttributeValue. There MUST NOT be zero or multiple instances of AttributeValue present.
構文がSET OF AttributeValueとして定義されている場合でも、アルゴリズム保護属性は単一の属性値を持つ必要があります。ゼロまたは複数のAttributeValueのインスタンスが存在してはなりません（MUST NOT）。
The algorithm protection attribute MUST be a signed attribute or an authenticated attribute; it MUST NOT be an unsigned attribute, an unauthenticated attribute, or an unprotected attribute.
アルゴリズム保護属性は、署名された属性または認証された属性でなければなりません。署名されていない属性、認証されていない属性、または保護されていない属性であってはなりません。
The SignedAttributes and AuthAttributes syntax are each defined as a SET of Attributes. The SignedAttributes in a signerInfo MUST include only one instance of the algorithm protection attribute. Similarly, the AuthAttributes in an AuthenticatedData MUST include only one instance of the algorithm protection attribute.
SignedAttributesおよびAuthAttributes構文はそれぞれ、属性のセットとして定義されます。 signerInfoのSignedAttributesには、アルゴリズム保護属性のインスタンスを1つだけ含める必要があります。同様に、AuthenticatedDataのAuthAttributesには、アルゴリズム保護属性のインスタンスを1つだけ含める必要があります。
While the exact verification steps depend on the structure that is being validated, there are some common rules to be followed when comparing the two algorithm structures:
正確な検証手順は検証される構造に依存しますが、2つのアルゴリズム構造を比較する際に従うべきいくつかの一般的なルールがあります。
o A field with a default value MUST compare as identical, independently of whether the value is defaulted or is explicitly provided. This implies that a binary compare of the encoded bytes is insufficient.
o デフォルト値を持つフィールドは、値がデフォルトであるか明示的に提供されているかに関係なく、同一であると比較する必要があります。これは、エンコードされたバイトのバイナリ比較が不十分であることを意味します。
o For some algorithms, such as SHA-1, the parameter value of NULL can be included in the ASN.1 encoding by some implementations and be omitted by other implementations. It is left to the implementer of this attribute to decide the comparison for equality is satisfied in this case. As a general rule, the same implementation is expected to produce both encoded values thus making it unlikely that this corner case should exist. This is an issue because some implementations will omit a NULL element, while others will encode a NULL element for some digest algorithms such as SHA-1 (see the comments in Section 2.1 of [RFC3370]). The issue is even worse because the NULL is absent in some cases (e.g., [RFC3370]), but is required in other cases (e.g., [RFC4056]).
o SHA-1などの一部のアルゴリズムの場合、一部の実装ではNULLのパラメーター値をASN.1エンコードに含め、他の実装では省略することができます。この場合、同等性の比較が満たされるかどうかは、この属性の実装者に委ねられます。一般的なルールとして、同じ実装で両方のエンコードされた値が生成されることが予想されるため、このコーナーケースが存在する可能性は低くなります。一部の実装はNULL要素を省略し、他はSHA-1などの一部のダイジェストアルゴリズムのNULL要素をエンコードするため、これは問題です（[RFC3370]のセクション2.1のコメントを参照）。 NULLが存在しない場合もあるため（[RFC3370]など）、他の場合には必要になる場合もあります（[RFC4056]など）。
If a CMS validator supports this attribute, the following additional verification steps MUST be performed:
CMSバリデーターがこの属性をサポートする場合、次の追加の検証手順を実行する必要があります。
1. The SignerInfo.digestAlgorithm field MUST be compared to the digestAlgorithm field in the attribute. If the fields are not the same (modulo encoding), then signature validation MUST fail.
1. SignerInfo.digestAlgorithmフィールドは、属性のdigestAlgorithmフィールドと比較する必要があります。フィールドが同じでない場合（モジュロエンコーディング）、署名の検証は失敗する必要があります。
2. The SignerInfo.signatureAlgorithm field MUST be compared to the signatureAlgorithm field in the attribute. If the fields are not the same (modulo encoding), then the signature validation MUST fail.
2. SignerInfo.signatureAlgorithmフィールドは、属性のsignatureAlgorithmフィールドと比較する必要があります。フィールドが同じでない場合（モジュロエンコーディング）、署名の検証は失敗する必要があります。
If a CMS validator supports this attribute, the following additional verification steps MUST be performed:
CMSバリデーターがこの属性をサポートする場合、次の追加の検証手順を実行する必要があります。
1. The AuthenticatedData.digestAlgorithm field MUST be compared to the digestAlgorithm field in the attribute. If the fields are not same (modulo encoding), then authentication MUST fail.
1. AuthenticatedData.digestAlgorithmフィールドは、属性のdigestAlgorithmフィールドと比較する必要があります。フィールドが同じでない場合（モジュロエンコーディング）、認証は失敗する必要があります。
2. The AuthenticatedData.macAlgorithm field MUST be compared to the macAlgorithm field in the attribute. If the fields are not the same (modulo encoding), then the authentication MUST fail.
2. AuthenticatedData.macAlgorithmフィールドは、属性のmacAlgorithmフィールドと比較する必要があります。フィールドが同じでない場合（モジュロエンコーディング）、認証は失敗する必要があります。
All identifiers are assigned out of the S/MIME OID arc.
すべての識別子は、S / MIME OIDアークから割り当てられます。
This document is designed to address the security issue of algorithm substitutions of the algorithms used by the validator. At this time, there is no known method to exploit this type of attack. If the attack could be successful, then either a weaker algorithm could be substituted for a stronger algorithm or the parameters could be modified by an attacker to change the behavior of the hashing algorithm used. (One example would be changing the initial parameter value for [RFC6210].)
このドキュメントは、バリデーターによって使用されるアルゴリズムのアルゴリズム置換のセキュリティ問題に対処することを目的としています。現時点では、この種の攻撃を悪用する既知の方法はありません。攻撃が成功した場合、弱いアルゴリズムを強いアルゴリズムに置き換えるか、パラメータを攻撃者が変更して、使用するハッシュアルゴリズムの動作を変更することができます。 （1つの例は、[RFC6210]の初期パラメーター値を変更することです。）
The attribute defined in this document is to be placed in a location that is protected by the signature or message authentication code. This attribute does not provide any additional security if placed in an unsigned or unauthenticated location.
このドキュメントで定義されている属性は、署名またはメッセージ認証コードによって保護されている場所に配置されます。この属性は、署名されていない場所や認証されていない場所に配置された場合、追加のセキュリティを提供しません。
[ASN.1-2008] ITU-T, "ITU-T Recommendations X.680, X.681, X.682, and X.683", 2008.
[ASN.1-2008] ITU-T、「ITU-T勧告X.680、X.681、X.682、およびX.683」、2008。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 5652, September 2009.
[CMS] Housley、R。、「Cryptographic Message Syntax（CMS）」、RFC 5652、2009年9月。
[ESS-BASE] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[ESS-BASE] Hoffman、P。、「Enhanced Security Services for S / MIME」、RFC 2634、1999年6月。
[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月。
[RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility", RFC 5035, August 2007.
[RFC5035] Schaad、J。、「Enhanced Security Services（ESS）Update：Adding CertID Algorithm Agility」、RFC 5035、2007年8月。
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, June 2010.
[RFC5912] Hoffman、P。およびJ. Schaad、「X.509（PKIX）を使用した公開鍵インフラストラクチャ用の新しいASN.1モジュール」、RFC 5912、2010年6月。
[RANDOM-HASH] Halevi, S. and H. Krawczyk, "Strengthening Digital Signatures via Random Hashing", January 2007, <http://webee.technion.ac.il/~hugo/rhash/rhash.pdf>.
[RANDOM-HASH] Halevi、S.およびH. Krawczyk、「Strandthening Digital Signatures via Random Hashing」、2007年1月、<http://webee.technion.ac.il/~hugo/rhash/rhash.pdf>。
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[RFC3370] Housley、R。、「Cryptographic Message Syntax（CMS）Algorithms」、RFC 3370、2002年8月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447] Jonsson、J。およびB. Kaliski、「Public-Key Cryptography Standards（PKCS）＃1：RSA Cryptography Specifications Version 2.1」、RFC 3447、2003年2月。
[RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS)", RFC 4056, June 2005.
[RFC4056] Schaad、J。、「暗号化メッセージ構文（CMS）でのRSASSA-PSS署名アルゴリズムの使用」、RFC 4056、2005年6月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、2008年5月。
[RFC6210] Schaad, J., "Experiment: Hash Functions with Parameters in the Cryptographic Message Syntax (CMS) and S/MIME", RFC 6210, April 2011.
[RFC6210] Schaad、J。、「実験：暗号化メッセージ構文（CMS）とS / MIMEのパラメーターを持つハッシュ関数」、RFC 6210、2011年4月。
The ASN.1 module defined uses the 2008 ASN.1 definitions found in [ASN.1-2008]. This module contains the ASN.1 module that contains the required definitions for the types and values defined in this document. The module uses the ATTRIBUTE class defined in [RFC5912].
定義されたASN.1モジュールは、[ASN.1-2008]にある2008 ASN.1定義を使用します。このモジュールには、このドキュメントで定義されているタイプと値に必要な定義を含むASN.1モジュールが含まれています。このモジュールは、[RFC5912]で定義されているATTRIBUTEクラスを使用します。
CMSAlgorithmProtectionAttribute
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0)
id-mod-cms-algorithmProtect(52) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
-- Cryptographic Message Syntax (CMS) [CMS]
-暗号化メッセージ構文（CMS）[CMS]
DigestAlgorithmIdentifier, MessageAuthenticationCodeAlgorithm,
SignatureAlgorithmIdentifier
FROM CryptographicMessageSyntax-2009
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) }
-- Common PKIX structures [RFC5912]
-一般的なPKIX構造[RFC5912]
ATTRIBUTE
FROM PKIX-CommonTypes-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57)};
--
-- The CMS Algorithm Protection attribute is a Signed Attribute or
-- an Authenticated Attribute.
--
-- Add this attribute to SignedAttributesSet in [CMS]
-- Add this attribute to AuthAttributeSet in [CMS]
--
aa-cmsAlgorithmProtection ATTRIBUTE ::= {
TYPE CMSAlgorithmProtection
IDENTIFIED BY { id-aa-cmsAlgorithmProtect }
}
id-aa-cmsAlgorithmProtect OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs9(9) 52 }
CMSAlgorithmProtection ::= SEQUENCE {
digestAlgorithm DigestAlgorithmIdentifier,
signatureAlgorithm [1] SignatureAlgorithmIdentifier OPTIONAL,
macAlgorithm [2] MessageAuthenticationCodeAlgorithm
OPTIONAL
}
(WITH COMPONENTS { signatureAlgorithm PRESENT,
macAlgorithm ABSENT } |
WITH COMPONENTS { signatureAlgorithm ABSENT,
macAlgorithm PRESENT })
END
終わり
Author's Address
著者のアドレス
Jim Schaad Soaring Hawk Consulting
ジムシャードソアリングホークコンサルティング
EMail: ietf@augustcellars.com