[要約] RFC 5752は、Cryptographic Message Syntax (CMS) における複数署名の取り扱いに関する技術仕様を定めた文書です。このRFCの目的は、CMSでのメッセージやデータに対して複数の署名者による署名を可能にし、それによってデータの認証性、完全性、および発信元の確認を強化することにあります。利用場面としては、電子メールのセキュリティ強化、ソフトウェア配布の際の署名検証、電子契約書の認証などが挙げられます。関連するRFCとしては、RFC 5652（CMSの基本仕様）、RFC 3161（タイムスタンププロトコル）、RFC 5280（X.509公開鍵基盤）などがあります。
Internet Engineering Task Force (IETF) S. Turner
Request for Comments: 5752 IECA
Category: Standards Track J. Schaad
ISSN: 2070-1721 Soaring Hawk
January 2010
Multiple Signatures in Cryptographic Message Syntax (CMS)
暗号メッセージ構文（CMS）の複数の署名
Abstract
概要
Cryptographic Message Syntax (CMS) SignedData includes the SignerInfo structure to convey per-signer information. SignedData supports multiple signers and multiple signature algorithms per signer with multiple SignerInfo structures. If a signer attaches more than one SignerInfo, there are concerns that an attacker could perform a downgrade attack by removing the SignerInfo(s) with the 'strong' algorithm(s). This document defines the multiple-signatures attribute, its generation rules, and its processing rules to allow signers to convey multiple SignerInfo objects while protecting against downgrade attacks. Additionally, this attribute may assist during periods of algorithm migration.
暗号化メッセージ構文（CMS）SignedDataには、署名者ごとの情報を伝えるためのSignerInfo構造が含まれています。 SignedDataは、複数のSignerInfo構造を持つ複数の署名者と署名者ごとの複数の署名アルゴリズムをサポートします。署名者が複数のSignerInfoを添付する場合、攻撃者が「強力な」アルゴリズムを使用してSignerInfoを削除することにより、ダウングレード攻撃を実行する可能性があるという懸念があります。このドキュメントでは、ダウングレード攻撃から保護しながら署名者が複数のSignerInfoオブジェクトを伝達できるように、multiple-signatures属性、その生成ルール、およびその処理ルールを定義します。さらに、この属性は、アルゴリズムの移行期間中に役立つ場合があります。
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/rfc5752.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc5752で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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に記載されているように保証なしで提供されます。
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標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Rationale .......................................................3
2.1. Attribute Design Requirements ..............................4
3. Multiple Signature Indication ...................................5
4. Message Generation and Processing ...............................6
4.1. SignedData Type ............................................6
4.2. EncapsulatedContentInfo Type ...............................7
4.3. SignerInfo Type ............................................7
4.4. Message Digest Calculation Process .........................7
4.4.1. multiple-signatures Signed Attribute Generation .....7
4.4.2. Message Digest Calculation Process ..................7
4.5. Signature Generation Process ...............................8
4.6. Signature Verification Process .............................8
5. Signature Evaluation Processing .................................8
5.1. Evaluation of a SignerInfo Object ..........................9
5.2. Evaluation of a SignerInfo Set .............................9
5.3. Evaluation of a SignedData Set ............................10
6. Security Considerations ........................................11
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................12
Appendix A. ASN.1 Module...........................................13
Appendix B. Background.............................................15
B.1. Attacks....................................................15
B.2. Hashes in CMS..............................................15
The Cryptographic Message Syntax (CMS; see [CMS]) defined SignerInfo to provide data necessary for relying parties to verify the signer's digital signature, which is also included in the SignerInfo structure. Signers include more than one SignerInfo in a SignedData if they use different digest or signature algorithms. Each SignerInfo exists independently and new SignerInfo structures can be added or existing ones removed without perturbing the remaining signatures.
暗号化メッセージ構文（CMS。[CMS]を参照）は、依存者が署名者のデジタル署名を検証するために必要なデータを提供するSignerInfoを定義しました。これもSignerInfo構造に含まれています。署名者は、異なるダイジェストまたは署名アルゴリズムを使用する場合、SignedDataに複数のSignerInfoを含めます。各SignerInfoは独立して存在し、残りの署名を乱すことなく、新しいSignerInfo構造を追加または削除できます。
The concern is that if an attacker successfully attacked a hash or signature algorithm, the attacker could remove all SignerInfo structures except the SignerInfo with the successfully attacked hash or signature algorithm. The relying party is then left with the attacked SignerInfo even though the relying party supported more than just the attacked hash or signature algorithm.
問題は、攻撃者がハッシュまたは署名アルゴリズムへの攻撃に成功した場合、攻撃者はハッシュまたは署名アルゴリズムへの攻撃に成功したSignerInfoを除くすべてのSignerInfo構造を削除する可能性があることです。依存パーティは、攻撃されたハッシュまたは署名アルゴリズム以上のものをサポートしていたとしても、攻撃されたSignerInfoが残ります。
A solution is to have signers include a pointer to all the signer's SignerInfo structures. If an attacker removes any SignerInfo, then relying parties will be aware that an attacker has removed one or more SignerInfo objects.
解決策は、すべての署名者のSignerInfo構造へのポインターを署名者に含めることです。攻撃者がSignerInfoを削除すると、依存パーティは、攻撃者が1つ以上のSignerInfoオブジェクトを削除したことを認識します。
Note that this attribute ought not be confused with the countersignature attribute (see Section 11.4 of [CMS]) as this is not intended to sign over an existing signature. Rather, it is to provide a pointer to additional signatures by the signer that are all at the same level. That is, countersignature provides a serial signature while the attribute defined herein provides pointers to parallel signatures by the same signer.
この属性は既存の署名に署名することを意図していないため、countersignature属性（[CMS]のセクション11.4を参照）と混同しないでください。むしろ、すべて同じレベルにある署名者による追加の署名へのポインタを提供することです。つまり、副署名はシリアル署名を提供し、ここで定義された属性は同じ署名者による並行署名へのポインタを提供します。
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 rationale for this specification is to protect against downgrade attacks that remove the 'strong' signature to leave the 'weak' signature, which has presumably been successfully attacked. If a CMS SignedData object has multiple SignerInfo objects, then the attacker, whether it be Alice, Bob, or Mallory, can remove a SignerInfo object without the relying party being aware that more than one was generated.
この仕様の根拠は、おそらく攻撃に成功していると思われる「弱い」シグネチャを残すために「強い」シグネチャを削除するダウングレード攻撃から保護することです。 CMS SignedDataオブジェクトに複数のSignerInfoオブジェクトがある場合、攻撃者は、Alice、Bob、Malloryのいずれであっても、依存パーティが複数のオブジェクトが生成されたことを知らなくても、SignerInfoオブジェクトを削除できます。
Removal of a SignerInfo does not render the signature invalid nor does it constitute an error. In the following scenario, a signer generates a SignedData with two SignerInfo objects, one with a 'weak' algorithm and one with a 'strong' algorithm; there are three types of relying parties:
SignerInfoを削除しても、署名は無効にならず、エラーにもなりません。次のシナリオでは、署名者は2つのSignerInfoオブジェクトを使用してSignedDataを生成します。1つは「弱い」アルゴリズムを使用し、もう1つは「強い」アルゴリズムを使用します。証明書利用者には3つのタイプがあります。
1) Those that support only a 'weak' algorithm. If both SignerInfo objects are present, the relying party processes the algorithm it supports. If both SignerInfo objects are not present, the relying party can easily determine that another SignerInfo has been removed, but not changed. In both cases, if the 'weak' signature verifies, the relying party MAY consider the signature valid.
1）「弱い」アルゴリズムのみをサポートするもの。両方のSignerInfoオブジェクトが存在する場合、依存パーティは、サポートするアルゴリズムを処理します。両方のSignerInfoオブジェクトが存在しない場合、依存パーティは、別のSignerInfoが削除されたが変更されていないことを簡単に判断できます。どちらの場合も、「弱い」署名が検証された場合、証明書利用者は署名が有効であると見なしてもよい（MAY）。
2) Those that support only a 'strong' algorithm. If both SignerInfo objects are present, the relying party processes the algorithm it supports. If both SignerInfo objects are not present, the relying party can easily determine that another SignerInfo has been removed, but the relying party doesn't care. In both cases, if the 'strong' signature verifies, the relying party MAY consider the signature valid.
2）「強力な」アルゴリズムのみをサポートするもの。両方のSignerInfoオブジェクトが存在する場合、依存パーティは、サポートするアルゴリズムを処理します。両方のSignerInfoオブジェクトが存在しない場合、依存パーティは別のSignerInfoが削除されたことを簡単に判別できますが、依存パーティは気にしません。どちらの場合も、「強力な」署名が検証された場合、証明書利用者は署名が有効であると見なすことができます（MAY）。
3) Those that support both a 'weak' algorithm and a 'strong' algorithm. If both SignerInfo objects are present, the relying party processes both algorithms. If both SignerInfo objects are not present, the relying party can easily determine that another SignerInfo has been removed. In both cases, if the 'strong' and/or 'weak' signatures verify, the relying party MAY consider the signature valid. (Policy may dictate that both signatures are required to validate if present.)
3）「弱い」アルゴリズムと「強い」アルゴリズムの両方をサポートするもの。両方のSignerInfoオブジェクトが存在する場合、依存パーティは両方のアルゴリズムを処理します。両方のSignerInfoオブジェクトが存在しない場合、依存パーティは別のSignerInfoが削除されたことを簡単に判断できます。どちらの場合も、「強い」または「弱い」、あるいはその両方の署名が確認された場合、証明書利用者は署名が有効であると見なすことができます（MAY）。 （ポリシーでは、両方の署名が存在する場合、検証する必要があると規定している場合があります。）
Local policy MAY dictate that the removal of the 'strong' algorithm results in an invalid signature. See Section 5 for further processing.
ローカルポリシーは、「強力な」アルゴリズムを削除すると無効な署名が生じることを指示する場合があります。以降の処理については、セクション5を参照してください。
The attribute will have the following characteristics:
属性には次の特性があります。
1) Use CMS attribute structure;
1）CMS属性構造を使用します。
2) Be computable before any signatures are applied;
2）署名が適用される前に計算可能であること。
3) Contain enough information to identify individual signatures (i.e., a particular SignerInfo); and
3）個々の署名（つまり、特定のSignerInfo）を識別するのに十分な情報が含まれている。そして
4) Contain enough information to resist collision, preimage, and second preimage attacks.
4）衝突、プリイメージ、および2番目のプリイメージ攻撃に抵抗するのに十分な情報が含まれています。
The multiple-signatures attribute type specifies a pointer to a signer's other multiple-signatures attribute(s). For example, if a signer applies three signatures, there must be two attribute values for multiple-signatures in each SignerInfo. The 1st SignerInfo object points to the 2nd and 3rd SignerInfo objects. The 2nd SignerInfo object points to the 1st and 3rd SignerInfo objects. The 3rd SignerInfo object points to the 1st and 2nd SignerInfo objects.
multiple-signatures属性タイプは、署名者の他の複数の署名属性へのポインターを指定します。たとえば、署名者が3つの署名を適用する場合、各SignerInfoに複数の署名の2つの属性値が必要です。 1番目のSignerInfoオブジェクトは、2番目と3番目のSignerInfoオブジェクトを指します。 2番目のSignerInfoオブジェクトは、1番目と3番目のSignerInfoオブジェクトを指します。 3番目のSignerInfoオブジェクトは、1番目と2番目のSignerInfoオブジェクトを指します。
The multiple-signatures attribute MUST be a signed attribute. The number of attribute values included in a SignerInfo is the number of signatures applied by a signer less one. This attribute is multi-valued, and there MAY be more than one AttributeValue present. The following object identifier identifies the multiple-signatures attribute:
multiple-signatures属性は、署名された属性でなければなりません。 SignerInfoに含まれる属性値の数は、署名者によって適用された署名の数から1を引いた数です。この属性は複数値であり、複数のAttributeValueが存在する場合があります。次のオブジェクト識別子は、複数署名属性を識別します。
id-aa-multipleSignatures OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
id-aa(16) 51 }
multiple-signatures attribute values have the ASN.1 type MultipleSignatures:
multiple-signatures属性値には、ASN.1タイプMultipleSignaturesがあります。
MultipleSignatures ::= SEQUENCE {
bodyHashAlg DigestAlgorithmIdentifier,
signAlg SignatureAlgorithmIdentifier,
signAttrsHash SignAttrsHash,
cert ESSCertIDv2 OPTIONAL}
SignAttrsHash ::= SEQUENCE {
algID DigestAlgorithmIdentifier,
hash OCTET STRING }
The fields in MultipleSignatures have the following meaning:
MultipleSignaturesのフィールドには次の意味があります。
- bodyHashAlg includes the digest algorithmIdentifier for the referenced multiple-signatures attribute.
- bodyHashAlgには、参照される複数の署名属性のダイジェストalgorithmIdentifierが含まれています。
- signAlg includes the signature algorithmIdentifier for the referenced multiple-signatures attribute.
- signAlgには、参照される複数の署名属性の署名algorithmIdentifierが含まれています。
- signAttrsHash has two fields:
- signAttrsHashには2つのフィールドがあります。
-- algId MUST match the digest algorithm for the SignerInfo in which this multiple-signatures attribute value is placed.
-algIdは、この複数の署名の属性値が配置されているSignerInfoのダイジェストアルゴリズムと一致する必要があります。
-- hash is the hash value of the signedAttrs (see Section 4.3).
-hashは、signedAttrsのハッシュ値です（セクション4.3を参照）。
- cert is optional. It identities the certificate used to sign the SignerInfo that contains the other multiple-signatures attribute(s). It MUST be present if the fields in the other multiple-signatures attribute(s) are the same.
- 証明書はオプションです。これは、他の複数の署名属性を含むSignerInfoの署名に使用される証明書を識別します。他の複数の署名属性のフィールドが同じである場合、それは存在しなければなりません。
The following is an example:
次に例を示します。
SignedData
DigestAlg=sha1,sha256
SignerInfo1 SignerInfo2
digestAlg=sha1 digestAlg=sha256
signatureAlg=dsawithsha1 signatureAlg=ecdsawithsha256
signedAttrs= signedAttrs=
signingTime1 signingTime1
messageDigest1 messageDigest2
multiSig1= multiSig2=
bodyHash=sha256 bodyHash=sha1
signAlg=ecdsawithsha256 signAlg=dsawithsha1
signAttrsHash= signAttrsHash=
algID=sha1 algID=sha256
hash=value1 hash=value2
The following are the additional procedures for message generation when using the multiple-signatures attribute. These paragraphs track with Sections 5.1-5.6 in [CMS].
次に、multiple-signatures属性を使用する場合のメッセージ生成の追加手順を示します。これらの段落は、[CMS]のセクション5.1〜5.6で追跡されます。
The following steps MUST be followed by a signer when generating SignedData:
SignedDataを生成するときは、次の手順の後に署名者が続く必要があります。
- The signer MUST indicate the CMS version.
- 署名者はCMSバージョンを示さなければなりません（MUST）。
- The signer SHOULD include the digest algorithm used in SignedData.digestAlgorithms, if the digest algorithm's identifier is not already present.
- 署名者は、ダイジェストアルゴリズムの識別子がまだ存在しない場合、SignedData.digestAlgorithmsで使用されるダイジェストアルゴリズムを含める必要があります（SHOULD）。
- The signer MUST include the encapContentInfo. Note that the encapContentInfo is the same for all signers in this SignedData.
- 署名者はencapContentInfoを含める必要があります。 encapContentInfoは、このSignedDataのすべての署名者で同じであることに注意してください。
- The signer SHOULD add certificates sufficient to contain certificate paths from a recognized "root" or "top-level certification authority" to the signer, if the signer's certificates are not already present.
- 署名者の証明書がまだ存在しない場合、署名者は、認識された「ルート」または「トップレベルの証明機関」から署名者への証明書パスを含めるのに十分な証明書を追加する必要があります。
- The signer MAY include the Certificate Revocation Lists (CRLs) necessary to validate the digital signature, if the CRLs are not already present.
- 署名者は、CRLがまだ存在しない場合、デジタル署名の検証に必要な証明書失効リスト（CRL）を含めることができます（MAY）。
- The signer MUST:
- 署名者は：
-- Retain the existing signerInfo objects.
-既存のsignerInfoオブジェクトを保持します。
-- Include their signerInfo object(s).
-signerInfoオブジェクトを含めます。
The procedures for generating EncapsulatedContentInfo are as specified in Section 5.2 of [CMS].
EncapsulatedContentInfoを生成する手順は、[CMS]のセクション5.2で指定されています。
The procedures for generating SignerInfo are as specified in Section 4.4.1 of [CMS] with the following addition:
SignerInfoを生成する手順は、[CMS]のセクション4.4.1に指定されているとおりですが、以下が追加されています。
The signer MUST include the multiple-signatures attribute in signedAttrs.
署名者は、signedAttrsにmultiple-signatures属性を含める必要があります。
The procedure for generating the multiple-signatures signed attribute is as follows:
マルチシグネチャの署名付き属性を生成する手順は次のとおりです。
1) All other signed attributes are placed in the respective SignerInfo structures, but the signatures are not yet computed for the SignerInfo.
1）他のすべての署名済み属性は、それぞれのSignerInfo構造に配置されますが、SignerInfoの署名はまだ計算されていません。
2) The multiple-signatures attributes are added to each of the SignerInfo structures with the SignAttrsHash.hash field containing a zero-length octet string.
2）multipleSignatures属性は、SignerInfo構造のそれぞれに追加され、SignAttrsHash.hashフィールドには長さゼロのオクテット文字列が含まれます。
3) The correct SignAttrsHash.hash value is computed for each of the SignerInfo structures.
3）SignerInfo構造体ごとに正しいSignAttrsHash.hash値が計算されます。
4) After all hash values have been computed, the correct hash values are placed into their respective SignAttrsHash.hash fields.
4）すべてのハッシュ値が計算された後、正しいハッシュ値がそれぞれのSignAttrsHash.hashフィールドに配置されます。
The remaining procedures for generating the message-digest attribute are as specified in Section 5.4 of [CMS].
メッセージダイジェスト属性を生成するための残りの手順は、[CMS]のセクション5.4で指定されています。
The procedures for signature generation are as specified in Section 5.5 of [CMS].
署名生成の手順は、[CMS]のセクション5.5で指定されています。
The procedures for signature verification are as specified in Section 5.6 of [CMS] with the following addition:
署名検証の手順は、[CMS]のセクション5.6に指定されているとおりですが、以下が追加されています。
If the SignedData signerInfo includes the multiple-signatures attribute, the attribute's values must be calculated as described in Section 4.4.1.
SignedData signerInfoにmultiple-signatures属性が含まれている場合、属性の値はセクション4.4.1の説明に従って計算する必要があります。
For every SignerInfo to be considered present for a given signer, the number of MultipleSignatures AttributeValue(s) present in a given SignerInfo MUST equal the number of SignerInfo objects for that signer less one and the hash value present in each of the MultipleSignatures AttributeValue(s) MUST match the output of the message digest calculation from Section 4.4.1 for each SignerInfo.
特定の署名者に存在すると見なされるすべてのSignerInfoについて、特定のSignerInfoに存在するMultipleSignatures AttributeValue（s）の数は、その署名者のSignerInfoオブジェクトの数から1を引いた数と、MultipleSignatures AttributeValue（s）のそれぞれに存在するハッシュ値に等しくなければなりません。 ）各SignerInfoについて、セクション4.4.1のメッセージダイジェスト計算の出力と一致する必要があります。
The hash corresponding to the n-th SignerInfo must match the value in the multiple-signatures attribute that points to the n-th SignerInfo present in all other SignerInfo objects.
n番目のSignerInfoに対応するハッシュは、他のすべてのSignerInfoオブジェクトに存在するn番目のSignerInfoを指すmultiple-signatures属性の値と一致する必要があります。
This section describes recommended processing of signatures when there are more than one SignerInfo present in a message. This may be due to either multiple SignerInfo objects being present in a single SignedData object or multiple SignerData objects embedded in each other.
このセクションでは、メッセージに複数のSignerInfoが存在する場合の署名の推奨処理について説明します。これは、単一のSignedDataオブジェクトに存在する複数のSignerInfoオブジェクト、または相互に埋め込まれた複数のSignerDataオブジェクトが原因である可能性があります。
The text in this section is non-normative. The processing described is highly recommended, but is not forced. Changes in the processing that have the same results with somewhat different orders of processing is sufficient.
このセクションのテキストは非規範的です。説明されている処理は強く推奨されていますが、強制されていません。多少異なる処理順序で同じ結果が得られる処理の変更で十分です。
Order of operations:
操作の順序：
1) Evaluate each SignerInfo object independently.
1）各SignerInfoオブジェクトを個別に評価します。
2) Combine the results of all SignerInfo objects at the same level (i.e., attached to the same SignerData object).
2）すべてのSignerInfoオブジェクトの結果を同じレベルで結合します（つまり、同じSignerDataオブジェクトにアタッチします）。
3) Combine the results of the nested SignerData objects. Note that this should ignore the presence of other CMS objects between the SignedData objects.
3）ネストされたSignerDataオブジェクトの結果を結合します。これは、SignedDataオブジェクト間の他のCMSオブジェクトの存在を無視する必要があることに注意してください。
When evaluating a SignerInfo object, there are three different pieces that need to be examined.
SignerInfoオブジェクトを評価する場合、3つの異なる部分を調べる必要があります。
The first piece is the mathematics of the signature itself (i.e., can one actually successfully do the computations and get the correct answer?). This result is one of three results. The mathematics succeeds, the mathematics fails, or the mathematics cannot be evaluated. The type of things that lead to the last state are non-implementation of an algorithm or required inputs, such as the public key, are missing.
最初の部分は、署名自体の数学です（つまり、実際に計算を実行して正しい答えを得ることができますか？）。この結果は、3つの結果のうちの1つです。数学が成功するか、数学が失敗するか、または数学を評価できません。最後の状態につながるもののタイプは、アルゴリズムの非実装であるか、公開鍵などの必要な入力が欠落しています。
The second piece is the validation of the source of the public key. For CMS, this is generally determined by extracting the public key from a certificate. The certificate needs to be evaluated. This is done by the procedures outlined in [PROFILE]. In addition to the processing described in that document, there may be additional requirements on certification path processing that are required by the application in question. One such set of additional processing is described in [SMIME-CERT]. One piece of information that is part of this additional certificate path processing is local and application policy. The output of this processing can actually be one of four different states: Success, Failure, Indeterminate, and Warning. The first three states are described in [PROFILE]; Warning would be generated when it is possible that some information is currently acceptable, but may not be acceptable either in the near future or under some circumstances.
2番目の部分は、公開鍵のソースの検証です。 CMSの場合、これは通常、証明書から公開鍵を抽出することによって決定されます。証明書を評価する必要があります。これは、[PROFILE]で概説されている手順によって行われます。そのドキュメントで説明されている処理に加えて、問題のアプリケーションが必要とする証明書パス処理に関する追加の要件がある場合があります。このような追加処理の1つは、[SMIME-CERT]で説明されています。この追加の証明書パス処理の一部である情報の1つは、ローカルポリシーとアプリケーションポリシーです。この処理の出力は、実際には、成功、失敗、不確定、警告の4つの異なる状態のいずれかになります。最初の3つの状態は[PROFILE]で説明されています。一部の情報は現在受け入れ可能であるが、近い将来または特定の状況下では受け入れられない可能性がある場合、警告が生成されます。
The third piece of the validation is local and application policy as applied to the contents of the SignerInfo object. This would cover such issues as the requirements on mandatory signed attributes or requirements on signature algorithms.
検証の3番目の部分は、SignerInfoオブジェクトのコンテンツに適用されるローカルおよびアプリケーションポリシーです。これは、必須の署名付き属性の要件や署名アルゴリズムの要件などの問題をカバーします。
Combining the results of the individual SignerInfo objects into a result for a SignedData object requires knowledge of the results for the individual SignerInfo objects, the required application policy, and any local policies. The default processing if no other rules are applied should be:
個々のSignerInfoオブジェクトの結果をSignedDataオブジェクトの結果に結合するには、個々のSignerInfoオブジェクトの結果、必要なアプリケーションポリシー、およびローカルポリシーに関する知識が必要です。他のルールが適用されない場合のデフォルトの処理は次のとおりです。
1) Group the SignerInfo objects by the signer.
1）SignerInfoオブジェクトを署名者ごとにグループ化します。
2) Take the best result from each signer.
2）各署名者から最良の結果を取得します。
3) Take the worst result from all of the different signers; this is the result for the SignedData object.
3）すべての異なる署名者からの最悪の結果を取得します。これは、SignedDataオブジェクトの結果です。
Application and local policy can affect each of the steps outlined above.
アプリケーションとローカルポリシーは、上記の各手順に影響を与える可能性があります。
In Step 1:
ステップ1：
- If the subject name or subject alternative name(s) cannot be used to determine if two SignerInfo objects were created by the same identity, then applications need to specify how such matching is to be done. As an example, the S/MIME message specification [SMIME-MSG] could say that as long as the same rfc822Name exists in either the subject name or the subject alt name they are the same identity. This would be true even if other information that did not match existed in these fields.
- サブジェクト名またはサブジェクトの別名を使用して、2つのSignerInfoオブジェクトが同じIDによって作成されたかどうかを判断できない場合、アプリケーションは、このようなマッチングの実行方法を指定する必要があります。例として、S / MIMEメッセージ仕様[SMIME-MSG]は、サブジェクト名またはサブジェクト代替名のいずれかに同じrfc822Nameが存在する限り、それらは同じIDであると言うことができます。一致しない他の情報がこれらのフィールドに存在する場合でも、これは当てはまります。
- Some applications may specify that this step should be skipped; this has the effect of making each SignerInfo object independent of all other SignerInfo objects even if the signing identity is the same. Applications that specify this need to be aware that algorithm rollover will not work correctly in this case.
- 一部のアプリケーションは、このステップをスキップするように指定する場合があります。これには、署名IDが同じであっても、各SignerInfoオブジェクトを他のすべてのSignerInfoオブジェクトから独立させる効果があります。これを指定するアプリケーションは、この場合、アルゴリズムのロールオーバーが正しく機能しないことに注意する必要があります。
In Step 2:
ステップ2：
- The major policy implication at this step is the treatment of and order for the indeterminate states. In most cases, this state would be placed between the failure and warning states. Part of the issue is the question of having a multi-state or a binary answer as to success or failure of an evaluation. Not every application can deal with the statement "try again later". It may also be dependent on what the reason for the indeterminate state is. It makes more sense to try again later if the problem is that a CRL cannot be found than if you are not able to evaluate the algorithm for the signature.
- この段階での主要な政策的含意は、不確定国家の扱いと秩序です。ほとんどの場合、この状態は障害状態と警告状態の間に置かれます。問題の一部は、評価の成功または失敗に関するマルチステートまたはバイナリの答えを持っているという問題です。すべてのアプリケーションが「後で再試行する」というステートメントを処理できるわけではありません。また、不確定状態の理由が何であるかに依存する場合もあります。署名のアルゴリズムを評価できない場合よりも、CRLが見つからない場合に後で再試行する方が理にかなっています。
In Step 3:
ステップ3：
- The same policy implications from Step 2 apply here.
- ステップ2と同じポリシーの意味がここに適用されます。
Simple applications will generally use the worst single outcome (success, unknown, failure) as the outcome for a set of SignedData objects (i.e., one failure means the entire item fails). However, not all applications will want to have this behavior.
単純なアプリケーションは、通常、SignedDataオブジェクトのセットの結果として最悪の単一の結果（成功、不明、失敗）を使用します（つまり、1つの失敗はアイテム全体が失敗することを意味します）。ただし、すべてのアプリケーションがこの動作を望んでいるわけではありません。
A work flow application could work as follows:
ワークフローアプリケーションは次のように機能します。
The second signer will modify the original content, keep the original signature, and then sign the message. This means that only the outermost signature is of significance during evaluation. The second signer is asserting that they successfully validated the inner signature as part of its processing.
2番目の署名者は、元のコンテンツを変更し、元の署名を保持してから、メッセージに署名します。これは、最も外側の署名のみが評価中に重要であることを意味します。 2番目の署名者は、処理の一部として内部署名を正常に検証したと主張しています。
A Signed Mail application could work as follows:
署名付きメールアプリケーションは次のように機能します。
If signatures are added for the support of [ESS] features, then the fact that an outer layer signature cannot be validated can be treated as a non-significant failure. The only thing that matters is that the originator signature is valid. This means that all outer layer signatures that fail can be stripped from the message prior to display leaving only the inner-most valid signature to be displayed.
[ESS]機能をサポートするために署名が追加された場合、外側の層の署名を検証できないという事実は、重大ではない障害として扱うことができます。重要なのは、発信者の署名が有効であることだけです。つまり、失敗したすべての外側の層の署名は、表示する前にメッセージから削除され、最も内側の有効な署名だけが表示されます。
Security considerations from the hash and signature algorithms used to produce the SignerInfo apply.
SignerInfoの生成に使用されるハッシュおよび署名アルゴリズムのセキュリティに関する考慮事項が適用されます。
If the hashing and signing operations are performed by different entities, the entity creating the signature must ensure that the hash comes from a "trustworthy" source. This can be partially mitigated by requiring that multiple hashes using different algorithms are provided.
ハッシュ操作と署名操作が異なるエンティティによって実行される場合、署名を作成するエンティティは、ハッシュが「信頼できる」ソースからのものであることを確認する必要があります。これは、異なるアルゴリズムを使用する複数のハッシュを提供することを要求することで部分的に軽減できます。
This attribute cannot be relied upon in the event that all of the algorithms used in the signer attribute are 'cracked'. It is not possible for a verifier to determine that a collision could not be found that satisfies all of the algorithms.
署名者属性で使用されているすべてのアルゴリズムが「クラック」されている場合、この属性は信頼できません。検証者が、すべてのアルゴリズムを満たす衝突が見つからなかったと判断することはできません。
Local policy and applications greatly affect signature processing. The application of local policy and the requirements specific to an application can both affect signature processing. This means that a signature valid in one context or location can fail validation in a different context or location.
ローカルポリシーとアプリケーションは、署名処理に大きく影響します。ローカルポリシーの適用とアプリケーション固有の要件は、どちらも署名処理に影響を与える可能性があります。つまり、あるコンテキストまたは場所で有効な署名は、別のコンテキストまたは場所での検証に失敗する可能性があります。
[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月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 5652, September 2009.
[CMS] Housley、R。、「Cryptographic Message Syntax（CMS）」、RFC 5652、2009年9月。
[PROFILE] 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.
[プロフィール] 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月。
[SMIME-CERT] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling", RFC 5750, January 2010.
[SMIME-CERT] Ramsdell、B。およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Certificate Handling」、RFC 5750、2010年1月。
[SMIME-MSG] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[SMIME-MSG] Ramsdell、B。およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Message Specification」、RFC 5751、2010年1月。
[ESS] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[ESS] Hoffman、P.、Ed。、「Enhanced Security Services for S / MIME」、RFC 2634、1999年6月。
[ESSCertID] Schaad, J., "Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility", RFC 5035, August 2007.
[ESSCertID] Schaad、J。、「Enhanced Security Services（ESS）Update：Adding CertID Algorithm Agility」、RFC 5035、2007年8月。
[ATTACK] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[攻撃] Hoffman、P。およびB. Schneier、「インターネットプロトコルにおける暗号化ハッシュへの攻撃」、RFC 4270、2005年11月。
MultipleSignatures-2008
MultipleSignatures-2008
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs9(9) smime(16) modules(0)
id-mod-multipleSig-2008(34) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
ベギン
-- EXPORTS All
-すべてをエクスポート
-- The types and values defined in this module are exported for use
-- in the other ASN.1 modules. Other applications may use them for
-- their own purposes.
IMPORTS
輸入
-- Imports from RFC 5652 [CMS], 12.1
-RFC 5652 [CMS]、12.1からのインポート
DigestAlgorithmIdentifier, SignatureAlgorithmIdentifier
FROM CryptographicMessageSyntax2004
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs9(9) smime(16) modules(0) cms-2004(24) }
-- Imports from RFC 5035 [ESSCertID], Appendix A
-RFC 5035 [ESSCertID]、付録Aからのインポート
ESSCertIDv2
FROM ExtendedSecurityServices-2006
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs9(9) smime(16) modules(0) id-mod-ess-2006(30) }
;
；
-- Section 3.0
-セクション3.0
id-aa-multipleSignatures OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) id-aa(2) 51 }
MultipleSignatures ::= SEQUENCE {
bodyHashAlg DigestAlgorithmIdentifier,
signAlg SignatureAlgorithmIdentifier,
signAttrsHash SignAttrsHash,
cert ESSCertIDv2 OPTIONAL }
SignAttrsHash ::= SEQUENCE {
algID DigestAlgorithmIdentifier,
hash OCTET STRING }
END -- of MultipleSignatures-2008
END-MultipleSignatures-2008の
This is an informational appendix. This appendix enumerates all locations in CMS where hashes are used and the possible attacks on those hash locations.
これは情報の付録です。この付録では、ハッシュが使用されるCMS内のすべての場所と、それらのハッシュの場所に対する可能な攻撃を列挙します。
As noted in [ATTACK], the following types of resistance are needed against known attacks:
[攻撃]で述べたように、既知の攻撃に対して次のタイプの耐性が必要です。
1) Collision Resistance: Find x and y where x != y and H(x) = H(y)
2) Preimage Resistance: Given y, find x where H(x) = y
3) Second Preimage Resistance: Given y, find x where H(x) = H(y)
Note: It is known that a collision resistance attack is simpler than a second preimage resistance attack, and it is presumed that a second preimage resistance attack is simpler than a preimage attack.
注：衝突耐性攻撃は2番目のプリイメージ耐性攻撃よりも単純であることが知られており、2番目のプリイメージ耐性攻撃はプリイメージ攻撃よりも単純であると推定されます。
Within a SignerInfo there are two places where hashes are applied and hence can be attacked: the body and the signed attributes. The following outlines the entity that creates the hash, the entity that attacks the hash, and the type of resistance required:
SignerInfo内には、ハッシュが適用されるため攻撃される可能性のある場所が2つあります。それは、本体と署名済み属性です。次に、ハッシュを作成するエンティティ、ハッシュを攻撃するエンティティ、および必要な耐性のタイプの概要を示します。
1) Hash of the Body (i.e., the octets comprising the value of the encapContentInfo.eContent OCTET STRING omitting the tag and length octets, as per 5.4 of [CMS]).
1）ボディのハッシュ（つまり、encapContentInfo.eContent OCTET STRINGの値を構成するオクテットで、[CMS]の5.4に従って、タグと長さのオクテットが省略されています）。
a) If Alice creates the body to be hashed, then:
a) アリスがハッシュするボディを作成する場合、次のようになります。
i) Alice can attack the hash. This attack requires a successful collision resistance attack.
i) アリスはハッシュを攻撃できます。この攻撃には、衝突抵抗攻撃を成功させる必要があります。
ii) Mallory can attack the hash. This attack requires a successful second preimage resistance attack.
ii）マロリーはハッシュを攻撃できます。この攻撃では、2番目のプリイメージ耐性攻撃が成功する必要があります。
b) If Alice hashes a body provided by Bob, then:
b) アリスがボブから提供されたボディをハッシュすると、次のようになります。
i) Alice can attack the hash. This attack requires a successful second preimage attack.
i) アリスはハッシュを攻撃できます。この攻撃では、2番目のプリイメージ攻撃が成功する必要があります。
ii) Bob can attack the hash. This attack requires a successful Collision Resistance attack. If Alice has the ability to "change" the content of the body in some fashion, then this attack requires a successful second preimage attack. (One example would be to use a keyed hash function.)
ii）ボブはハッシュを攻撃できます。この攻撃では、衝突抵抗攻撃が成功する必要があります。アリスが何らかの方法で身体の内容を「変更」する能力を持っている場合、この攻撃には2番目のプリイメージ攻撃が成功する必要があります。 （1つの例は、キー付きハッシュ関数を使用することです。）
iii) Mallory can attack the hash. This attack requires a successful second preimage attack.
iii）マロリーはハッシュを攻撃できます。この攻撃では、2番目のプリイメージ攻撃が成功する必要があります。
c) If Alice signs using a hash value provided by Bob (in this case, Alice is presumed to never see the body in question), then:
c) ボブから提供されたハッシュ値を使用してアリスが署名する場合（この場合、アリスは問題の本文を決して見ないものと推定されます）、次のようになります。
i) Alice can attack the hash. This attack requires a successful preimage attack.
i) アリスはハッシュを攻撃できます。この攻撃には、成功するプリイメージ攻撃が必要です。
ii) Bob can attack the hash. This attack requires a successful collision resistance attack. Unlike case (b), there is nothing that Alice can do to upgrade the attack.
ii）ボブはハッシュを攻撃できます。この攻撃には、衝突抵抗攻撃を成功させる必要があります。ケース（b）とは異なり、アリスが攻撃をアップグレードするためにできることは何もありません。
iii) Mallory can attack the hash. This requires a successful preimage attack if the content is unavailable to Mallory and a successful second preimage attack if the content is available to Mallory.
iii）マロリーはハッシュを攻撃できます。マロリーがコンテンツを利用できない場合は、プリイメージ攻撃が成功し、マロリーがコンテンツを利用できる場合は、2番目のプリイメージ攻撃が成功する必要があります。
2) Hash of signed attributes (i.e., the complete Distinguished Encoding Rules (DER) encoding of the SignedAttrs value contained in the signedAttrs field, as per 5.4 of [CMS]).
2）署名された属性のハッシュ（つまり、[CMS]の5.4に従って、signedAttrsフィールドに含まれるSignedAttrs値の完全なDistinguished Encoding Rules（DER）エンコーディング）。
There is a difference between hashing the body and hashing the SignedAttrs value in that one should not accept a sequence of attributes to be signed from a third party. In fact, one should not accept attributes to be included in the signed attributes list from a third party. The attributes are about the signature you are applying and not about the body. If there is meta-information that needs to be attached to the body by a third party, then they need to provide their own signature and you need to add a countersignature. (Note: The fact that the signature is to be used as a countersignature is a piece of information that should be accepted, but it does not directly provide an attribute that is inserted in the signed attribute list.)
本文のハッシュとSignedAttrs値のハッシュには違いがあり、第三者から署名される一連の属性を受け入れることはできません。実際、署名された属性リストに含まれる属性を第三者から受け入れるべきではありません。属性は、適用する署名に関するものであり、本文に関するものではありません。第三者が本文に添付する必要のあるメタ情報がある場合は、それらが独自の署名を提供する必要があり、副署名を追加する必要があります。 （注：署名が副署名として使用されるという事実は、受け入れられるべき情報の一部ですが、署名された属性リストに挿入される属性を直接提供するものではありません。）
a) Alice can attack the hash. This requires a successful collision resistance attack.
a) アリスはハッシュを攻撃できます。これには、衝突抵抗攻撃を成功させる必要があります。
b) Mallory can attack the hash. This requires a successful second preimage resistance attack.
b) マロリーはハッシュを攻撃できます。これには、2番目のプレイメージ耐性攻撃が必要です。
c) Bob can attack the hash and Bob controls the value of the message digest attribute used. This case is analogous to the current attacks [ATTACK]. Bob can attack the hash value generated by Alice based on a prediction of the signed attributes and the hash algorithm Alice will be using to create the signature. If Bob successfully predicts these items, the attack requires a successful collision resistance attack. (It is expected that if Alice uses a keyed hashing function as part of the signature, this attack will be more difficult as Bob would have a harder time prediction the key value.)
c) ボブはハッシュを攻撃でき、ボブは使用されるメッセージダイジェスト属性の値を制御します。このケースは、現在の攻撃[攻撃]に類似しています。ボブは、署名された属性の予測に基づいてアリスによって生成されたハッシュ値を攻撃できます。ハッシュアルゴリズムは、アリスが署名の作成に使用します。ボブがこれらの項目の予測に成功した場合、攻撃には衝突抵抗攻撃の成功が必要です。 （アリスが署名の一部としてキー付きハッシュ関数を使用する場合、ボブはキー値の予測に時間がかかるため、この攻撃はより困難になると予想されます。）
It should be noted that both of these attacks are considered to be more difficult than the attack on the body since more structure is designed into the data to be hashed than is frequently found in the body and the data is shorter in length than that of the body.
ハッシュされるデータには、ボディで頻繁に見られるよりも多くの構造が設計されており、データの長さがボディのそれよりも短いため、これらの攻撃はどちらもボディへの攻撃よりも難しいと見なされます。体。
The successful prediction of the signing-time attribute is expected to be more difficult than with certificates as the time would not generally be rounded. Time stamp services can make this more unpredictable by using a random delay before issuing the signature.
署名時間属性の予測が成功することは、一般的に時間が丸められないため、証明書を使用する場合よりも難しいと予想されます。タイムスタンプサービスは、署名を発行する前にランダムな遅延を使用することにより、これをより予測不可能にすることができます。
Allowing a third party to provide a hash value could potentially make an attack simpler when keyed hash functions are used since there is more data than can be modified without changing the overall structure of the signed attribute structure.
第三者がハッシュ値を提供できるようにすると、署名付き属性構造の全体的な構造を変更せずに変更できるデータよりも多くのデータがあるため、キー付きハッシュ関数を使用すると攻撃が単純化される可能性があります。
Authors' Addresses
著者のアドレス
Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA
Sean Turner IECA、Inc. 3057 Nutley Street、Suite 106 Fairfax、VA 22031 USA
EMail: turners@ieca.com
Jim Schaad Soaring Hawk Consulting
ジムシャードソアリングホークコンサルティング
EMail: jimsch@exmsft.com