[要約] RFC 5035は、Enhanced Security Services（ESS）のアップデートであり、CertIDアルゴリズムの柔軟性を追加することを目的としています。
Network Working Group J. Schaad
Request for Comments: 5035 Soaring Hawk Consulting
Updates: 2634 August 2007
Category: Standards Track
Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility
強化されたセキュリティサービス（ESS）アップデート：CertIDアルゴリズムの俊敏性の追加
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
概要
In the original Enhanced Security Services for S/MIME document (RFC 2634), a structure for cryptographically linking the certificate to be used in validation with the signature was introduced; this structure was hardwired to use SHA-1. This document allows for the structure to have algorithm agility and defines a new attribute for this purpose.
S/MIMEドキュメントの元の拡張セキュリティサービス（RFC 2634）では、検証で使用される証明書を暗号化するための構造を署名とともに導入しました。この構造は、SHA-1を使用するように固定されていました。このドキュメントにより、構造がアルゴリズムの俊敏性を持つことができ、この目的の新しい属性を定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Updates to RFC 2634 . . . . . . . . . . . . . . . . . . . 2
2. Replace Section 5.4 'Signing Certificate Attribute
Definitions' . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Insert New Section 5.4.1 'Signing Certificate Attribute
Definition Version 2' . . . . . . . . . . . . . . . . . . . . 4
4. Insert New Section 5.4.1.1 'Certificate Identification
Version 2' . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Insert New Section 5.4.2 'Signing Certificate Attribute
Definition Version 1' . . . . . . . . . . . . . . . . . . . . 7
6. Insert New Section 5.4.2.1 'Certificate Identification
Version 1' . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 11
In the original Enhanced Security Services (ESS) for S/MIME document [ESS], a structure for cryptographically linking the certificate to be used in validation with the signature was defined. This structure, called ESSCertID, identifies a certificate by its hash. The structure is hardwired to use a SHA-1 hash value. The recent attacks on SHA-1 require that we define a new attribute that allows for the use of different algorithms. This document performs that task.
S/MIMEドキュメント[ESS]の元の拡張セキュリティサービス（ESS）では、検証で使用される証明書を署名と結びつけるための構造が定義されました。Esscertidと呼ばれるこの構造は、そのハッシュによる証明書を識別します。構造は、SHA-1ハッシュ値を使用するように固定されています。SHA-1に対する最近の攻撃では、異なるアルゴリズムを使用できる新しい属性を定義する必要があります。このドキュメントはそのタスクを実行します。
This document defines the structure ESSCertIDv2 along with a new attribute SigningCertificateV2, which uses the updated structure. This document allows for the structure to have algorithm agility by including an algorithm identifier and defines a new signed attribute to use the new structure.
このドキュメントは、更新された構造を使用する新しい属性signiveCertificatev2とともに、ESSCERTIDV2の構造を定義します。このドキュメントにより、アルゴリズム識別子を含めることにより、構造がアルゴリズムの俊敏性を持つことができ、新しい構造を使用する新しい署名属性を定義できます。
This document specifies the continued use of ESSCertID to ensure compatibility when SHA-1 is used for certificate disambiguation.
このドキュメントは、SHA-1を証明書の乱用に使用したときに互換性を確保するために、esscertidの継続的な使用を指定します。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
This document updates Section 5.4 of RFC 2634. Once the updates are applied, the revised section will have the following structure:
このドキュメントは、RFC 2634のセクション5.4を更新します。更新が適用されると、改訂されたセクションには次の構造があります。
5.4 Signing Certificate Attribute Definitions
5.4 署名証明書属性定義
5.4.1 Signing Certificate Attribute Definition Version 2
5.4.1 署名証明書属性定義バージョン2
5.4.1.1 Certificate Identification Version 2
5.4.1.1 証明書識別バージョン2
5.4.2 Signing Certificate Attribute Definition Version 1
5.4.2 署名証明書属性定義バージョン1
5.4.2.1 Certificate Identification Version 1
5.4.2.1 証明書識別バージョン1
In addition, the ASN.1 module in Appendix A is replaced.
さらに、付録AのASN.1モジュールが置き換えられます。
5.4 Signing Certificate Attribute Definitions
5.4 署名証明書属性定義
The signing certificate attribute is designed to prevent simple substitution and re-issue attacks, and to allow for a restricted set of certificates to be used in verifying a signature.
署名証明書属性は、簡単な代替と再発行攻撃を防ぎ、署名の検証に制限された証明書を使用できるように設計されています。
Two different attributes exist for this due to a flaw in the original design. The only substantial difference between the two attributes is that SigningCertificateV2 allows for hash algorithm agility, while SigningCertificate forces the use of the SHA-1 hash algorithm. With the recent advances in the ability to create hash collisions for SHA-1, it is wise to move forward sooner rather than later.
これには、元の設計に欠陥があるため、2つの異なる属性が存在します。2つの属性の唯一の大きな違いは、SigniveCertificateV2がハッシュアルゴリズムの俊敏性を可能にし、SignalCertificateがSHA-1ハッシュアルゴリズムの使用を強制することです。SHA-1のハッシュ衝突を作成する能力の最近の進歩により、後でよりも早く前進することが賢明です。
When the SHA-1 hash function is used, the SigningCertificate attribute MUST be used. The SigningCertificateV2 attribute MUST be used if any algorithm other than SHA-1 is used and SHOULD NOT be used for SHA-1. Applications SHOULD recognize both attributes as long as they consider SHA-1 able to distinguish between two different certificates, (i.e., the possibility of a collision is sufficiently low). If both attributes exist in a single message, they are independently evaluated.
SHA-1ハッシュ関数を使用する場合、signingcertificate属性を使用する必要があります。SHA-1以外のアルゴリズムが使用されており、SHA-1には使用しないでください。アプリケーションは、SHA-1が2つの異なる証明書を区別できると考える限り、両方の属性を認識する必要があります（つまり、衝突の可能性は十分に低いです）。両方の属性が単一のメッセージに存在する場合、それらは独立して評価されます。
Four cases exist that need to be taken into account when using this attribute for correct processing:
正しい処理のためにこの属性を使用するときに考慮する必要がある4つのケースが存在します。
1. Signature validates and the hashes match: This is the success case.
1. 署名の検証とハッシュの一致：これは成功事例です。
2. Signature validates and the hashes do not match: In this case, the certificate contained the correct public key, but the certificate containing the public key is not the one that the signer intended to be used. In this case the application should attempt a search for a different certificate with the same public key and for which the hashes match. If no such certificate can be found, this is a failure case.
2. 署名の検証とハッシュは一致しません。この場合、証明書には正しい公開キーが含まれていましたが、公開鍵を含む証明書は、署名者が使用することを意図したものではありません。この場合、アプリケーションは、同じ公開キーとハッシュが一致する別の証明書の検索を試みる必要があります。そのような証明書が見つからない場合、これは障害の場合です。
3. Signature fails validation and the hashes match: In this case, it can be assumed that the signature has been modified in some fashion. This is a failure case.
3. 署名は検証に失敗し、ハッシュは一致します。この場合、署名が何らかの形で変更されていると想定できます。これは障害の場合です。
4. Signature fails validation and the hashes do not match: In this case, it can be either that the signature has been modified, or that the wrong certificate has been used. Applications should attempt a search for a different certificate that matches the hash value in the attribute and use the new certificate to retry the signature validation.
4. 署名が検証に失敗し、ハッシュは一致しません。この場合、署名が変更されたか、間違った証明書が使用されていることがあります。アプリケーションは、属性のハッシュ値に一致する別の証明書の検索を試み、新しい証明書を使用して署名検証を再試行する必要があります。
5.4.1 Signing Certificate Attribute Definition Version 2
5.4.1 署名証明書属性定義バージョン2
The signing certificate attribute is designed to prevent the simple substitution and re-issue attacks, and to allow for a restricted set of certificates to be used in verifying a signature.
署名証明書属性は、単純な置換および再発行攻撃を防止し、署名の検証に制限された証明書セットを使用できるように設計されています。
SigningCertificateV2 is identified by the OID:
signiveCertificatev2はOIDによって識別されます。
id-aa-signingCertificateV2 OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 47 }
The attribute has the ASN.1 definition:
属性にはasn.1定義があります：
SigningCertificateV2 ::= SEQUENCE {
certs SEQUENCE OF ESSCertIDv2,
policies SEQUENCE OF PolicyInformation OPTIONAL
}
certs contains the list of certificates that are to be used in validating the message. The first certificate identified in the sequence of certificate identifiers MUST be the certificate used to verify the signature. The encoding of the ESSCertIDv2 for this certificate SHOULD include the issuerSerial field. If other constraints ensure that issuerAndSerialNumber will be present in the SignerInfo, the issuerSerial field MAY be omitted. The certificate identified is used during the signature verification process. If the hash of the certificate does not match the certificate used to verify the signature, the signature MUST be considered invalid.
証明書には、メッセージの検証に使用される証明書のリストが含まれています。証明書識別子のシーケンスで識別される最初の証明書は、署名を検証するために使用される証明書でなければなりません。この証明書のESSCERTIDV2のエンコードには、発行担当フィールドを含める必要があります。他の制約がSignerInfoに発行担当者が存在することを保証する場合、発行担当フィールドは省略される場合があります。特定された証明書は、署名検証プロセス中に使用されます。証明書のハッシュが署名を確認するために使用される証明書と一致しない場合、署名は無効と見なされなければなりません。
If more than one certificate is present, subsequent certificates limit the set of certificates that are used during validation. Certificates can be either attribute certificates (limiting authorizations) or public key certificates (limiting path validation). The issuerSerial field (in the ESSCertIDv2 structure) SHOULD be present for these certificates, unless the client who is validating the signature is expected to have easy access to all the certificates required for validation. If only the signing certificate is present in the sequence, there are no restrictions on the set of certificates used in validating the signature.
複数の証明書が存在する場合、その後の証明書は、検証中に使用される証明書のセットを制限します。証明書は、属性証明書（承認の制限）または公開キー証明書（パス検証の制限）のいずれかです。署名を検証しているクライアントが、検証に必要なすべての証明書に簡単にアクセスできると予想されない限り、これらの証明書には発行局フィールド（ESSCERTIDV2構造）が存在する必要があります。署名証明書のみがシーケンスに存在する場合、署名の検証に使用される証明書のセットに制限はありません。
policies contains a sequence of policy information terms that identify those certificate policies that the signer asserts apply to the certificate, and under which the certificate should be relied upon. This value suggests a policy value to be used in the relying party's certification path validation. The definition of PolicyInformation can be found in [RFC3280].
ポリシーには、署名者が主張する証明書に適用される証明書のポリシーを特定する一連のポリシー情報条件が含まれており、その下には証明書が信頼されるべきです。この値は、依存者の認定パス検証で使用されるポリシー値を示唆しています。政策情報の定義は[RFC3280]にあります。
If present, the SigningCertificateV2 attribute MUST be a signed attribute; it MUST NOT be an unsigned attribute. CMS defines SignedAttributes as a SET OF Attribute. A SignerInfo MUST NOT include multiple instances of the SigningCertificateV2 attribute. CMS defines the ASN.1 syntax for the signed attributes to include attrValues SET OF AttributeValue. A SigningCertificateV2 attribute MUST include only a single instance of AttributeValue. There MUST NOT be zero or multiple instances of AttributeValue present in the attrValues SET OF AttributeValue.
存在する場合、signingcertificatev2属性は署名属性でなければなりません。署名されていない属性であってはなりません。CMSは、SigneDattributesを一連の属性として定義します。SignerInfoには、signingCertificatev2属性の複数のインスタンスを含めてはなりません。CMSは、署名された属性のASN.1構文を定義して、属性の属性セットを含むようにします。signingCertificatev2属性には、属性の単一インスタンスのみを含める必要があります。属性の属性セットに存在するゼロまたは複数のインスタンスが存在してはなりません。
Insert the following text as a new section.
次のテキストを新しいセクションとして挿入します。
5.4.1.1 Certificate Identification Version 2
5.4.1.1 証明書識別バージョン2
The best way to identify certificates is an often-discussed issue. The ESSCertIDv2 structure supplies two different fields that are used for this purpose.
証明書を特定する最良の方法は、しばしば議論される問題です。ESSCERTIDV2構造は、この目的に使用される2つの異なるフィールドを提供します。
The hash of the entire certificate allows for a verifier to check that the certificate used in the verification process was the same certificate the signer intended. Hashes are convenient in that they are frequently used by certificate stores as a method of indexing and retrieving certificates as well. The use of the hash is required by this structure since the detection of substituted certificates is based on the fact they would map to different hash values.
証明書全体のハッシュにより、検証者が検証プロセスで使用された証明書が署名者が意図したのと同じ証明書であることを確認することができます。ハッシュは、証明書ストアが証明書のインデックス作成と取得の方法として頻繁に使用されるという点で便利です。代替証明書の検出は、異なるハッシュ値にマッピングされるという事実に基づいているため、ハッシュの使用はこの構造で必要です。
The issuer/serial number pair is the method of identification of certificates used in [RFC3280]. That document imposes a restriction for certificates that the issuer distinguished name must be present. The issuer/serial number pair would therefore normally be sufficient to identify the correct signing certificate. (This assumes the same issuer name is not reused from the set of trust anchors.) The issuer/serial number pair can be stored in the sid field of the SignerInfo object. However, the sid field is not covered by the signature. In the cases where the issuer/serial number pair is not used in the sid or the issuer/serial number pair needs to be signed, it SHOULD be placed in the issuerSerial field of the ESSCertIDv2 structure.
発行者/シリアル番号ペアは、[RFC3280]で使用される証明書を識別する方法です。その文書は、発行者の著名な名前が存在する必要があるという証明書の制限を課しています。したがって、発行者/シリアル番号ペアは通常、正しい署名証明書を識別するのに十分です。（これは、同じ発行者名が信頼アンカーのセットから再利用されないと仮定します。）発行者/シリアル番号ペアは、SignerInfoオブジェクトのSIDフィールドに保存できます。ただし、SIDフィールドは署名でカバーされていません。発行者/シリアル番号ペアがSIDで使用されていない場合、または発行者/シリアル番号ペアに署名する必要がある場合、ESSCERTIDV2構造の発行担当フィールドに配置する必要があります。
Attribute certificates and additional public key certificates containing information do not have an issuer/serial number pair represented anywhere in a SignerInfo object. When an attribute certificate or an additional public key certificate is not included in the SignedData object, it becomes much more difficult to get the correct set of certificates based only on a hash of the certificate. For this reason, these certificates SHOULD be identified by the IssuerSerial object.
属性証明書と情報を含む追加の公開キー証明書には、SignerInfoオブジェクトのどこにでも表される発行者/シリアル番号ペアがありません。属性証明書または追加の公開鍵証明書がSignedDataオブジェクトに含まれていない場合、証明書のハッシュにのみ基づいて正しい証明書セットを取得することがはるかに困難になります。このため、これらの証明書は発行担当オブジェクトによって識別される必要があります。
This document defines a certificate identifier as:
このドキュメントは、証明書識別子を次のように定義しています。
ESSCertIDv2 ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier
DEFAULT {algorithm id-sha256},
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}
Hash ::= OCTET STRING
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serialNumber CertificateSerialNumber
}
The fields of ESSCertIDv2 are defined as follows:
esscertidv2のフィールドは、次のように定義されています。
hashAlgorithm contains the identifier of the algorithm used in computing certHash.
Hashalgorithmには、Certhashの計算に使用されるアルゴリズムの識別子が含まれています。
certHash is computed over the entire DER-encoded certificate (including the signature) using the SHA-1 algorithm.
Certhashは、SHA-1アルゴリズムを使用して、derエンコードされた証明書（署名を含む）全体で計算されます。
issuerSerial holds the identification of the certificate. The issuerSerial would normally be present unless the value can be inferred from other information (e.g., the sid field of the SignerInfo object).
発行担当者は、証明書の識別を保持しています。値を他の情報（例えば、SignerINFOオブジェクトのSIDフィールド）から推測できる場合を除き、発行担当者は通常存在します。
The fields of IssuerSerial are defined as follows:
発行担当者の分野は次のように定義されています。
issuer contains the issuer name of the certificate. For non-attribute certificates, the issuer MUST contain only the issuer name from the certificate encoded in the directoryName choice of GeneralNames. For attribute certificates, the issuer MUST contain the issuer name field from the attribute certificate.
発行者には、証明書の発行者名が含まれています。非属性証明書の場合、発行者は、一般名のdirectoryName選択にエンコードされた証明書の発行者名のみを含める必要があります。属性証明書の場合、発行者は属性証明書から発行者名フィールドを含める必要があります。
serialNumber holds the serial number that uniquely identifies the certificate for the issuer.
SerialNumberは、発行者の証明書を一意に識別するシリアル番号を保持します。
(Note: This section does not present new material. This section contains the original contents of Section 5.4 in [ESS], which are retained with minor changes in this specification to achieve backwards compatibility.)
（注：このセクションには新しい素材は表示されません。このセクションには、[ESS]のセクション5.4の元の内容が含まれています。この仕様には、逆方向の互換性を実現するために保持されます。）
Insert the following text as a new section.
次のテキストを新しいセクションとして挿入します。
5.4.2 Signing Certificate Attribute Definition Version 1
5.4.2 署名証明書属性定義バージョン1
The signing certificate attribute is designed to prevent the simple substitution and re-issue attacks, and to allow for a restricted set of certificates to be used in verifying a signature.
署名証明書属性は、単純な置換および再発行攻撃を防止し、署名の検証に制限された証明書セットを使用できるように設計されています。
The definition of SigningCertificate is
signingcertificateの定義はです
SigningCertificate ::= SEQUENCE {
certs SEQUENCE OF ESSCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL
}
id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 12 }
The first certificate identified in the sequence of certificate identifiers MUST be the certificate used to verify the signature. The encoding of the ESSCertID for this certificate SHOULD include the issuerSerial field. If other constraints ensure that issuerAndSerialNumber will be present in the SignerInfo, the issuerSerial field MAY be omitted. The certificate identified is used during the signature verification process. If the hash of the certificate does not match the certificate used to verify the signature, the signature MUST be considered invalid.
証明書識別子のシーケンスで識別される最初の証明書は、署名を検証するために使用される証明書でなければなりません。この証明書のESSCERTIDのエンコードには、発行担当フィールドを含める必要があります。他の制約がSignerInfoに発行担当者が存在することを保証する場合、発行担当フィールドは省略される場合があります。特定された証明書は、署名検証プロセス中に使用されます。証明書のハッシュが署名を確認するために使用される証明書と一致しない場合、署名は無効と見なされなければなりません。
If more than one certificate is present in the sequence of ESSCertIDs, the certificates after the first one limit the set of certificates that are used during validation. Certificates can be either attribute certificates (limiting authorizations) or public key certificates (limiting path validation). The issuerSerial field (in the ESSCertID structure) SHOULD be present for these certificates, unless the client who is validating the signature is expected to have easy access to all the certificates required for validation. If only the signing certificate is present in the sequence, there are no restrictions on the set of certificates used in validating the signature.
Esscertidsのシーケンスに複数の証明書が存在する場合、最初の1つの後の証明書は、検証中に使用される証明書のセットを制限します。証明書は、属性証明書（承認の制限）または公開キー証明書（パス検証の制限）のいずれかです。署名を検証しているクライアントが、検証に必要なすべての証明書に簡単にアクセスできると予想されない限り、これらの証明書には発行局フィールドが存在する必要があります。署名証明書のみがシーケンスに存在する場合、署名の検証に使用される証明書のセットに制限はありません。
The sequence of policy information terms identifies those certificate policies that the signer asserts apply to the certificate, and under which the certificate should be relied upon. This value suggests a policy value to be used in the relying party's certification path validation.
一連のポリシー情報条件は、署名者が主張する証明書に適用される証明書ポリシーを識別し、その下に証明書が信頼されるべきです。この値は、依存者の認定パス検証で使用されるポリシー値を示唆しています。
If present, the SigningCertificate attribute MUST be a signed attribute; it MUST NOT be an unsigned attribute. Cryptographic Message Syntax (CMS) defines SignedAttributes as a SET OF Attribute. A SignerInfo MUST NOT include multiple instances of the SigningCertificate attribute. CMS defines the ASN.1 syntax for the signed attributes to include attrValues SET OF AttributeValue. A SigningCertificate attribute MUST include only a single instance of AttributeValue. There MUST NOT be zero or multiple instances of AttributeValue present in the attrValues SET OF AttributeValue.
存在する場合、signingcertificate属性は署名属性でなければなりません。署名されていない属性であってはなりません。暗号化メッセージ構文（CMS）は、Signedattributesを一連の属性として定義します。SignerInfoには、signingcertificate属性の複数のインスタンスを含めてはなりません。CMSは、署名された属性のASN.1構文を定義して、属性の属性セットを含むようにします。signingcertificate属性には、属性の単一インスタンスのみを含める必要があります。属性の属性セットに存在するゼロまたは複数のインスタンスが存在してはなりません。
(Note: This section does not present new material. This section contains the original contents of Section 5.4 in [ESS], which are retained with minor changes in this specification to achieve backwards compatibility.)
（注：このセクションには新しい素材は表示されません。このセクションには、[ESS]のセクション5.4の元の内容が含まれています。この仕様には、逆方向の互換性を実現するために保持されます。）
Delete old Section 5.4.1
古いセクション5.4.1を削除します
Insert the following as new text
新しいテキストとして以下を挿入します
5.4.2.1 Certificate Identification Version 1
5.4.2.1 証明書識別バージョン1
Certificates are uniquely identified using the information in the ESSCertID structure. Discussion can be found in Section 5.4.1.1.
証明書は、esscertid構造の情報を使用して一意に識別されます。議論はセクション5.4.1.1に記載されています。
This document defines a certificate identifier as:
このドキュメントは、証明書識別子を次のように定義しています。
ESSCertID ::= SEQUENCE {
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}
The fields of ESSCertID are defined as follows:
Esscertidのフィールドは次のように定義されています。
certHash is computed over the entire DER-encoded certificate (including the signature).
Certhashは、derエンコードされた証明書（署名を含む）全体で計算されます。
issuerSerial holds the identification of the certificate. This field would normally be present unless the value can be inferred from other information (e.g., the sid field of the SignerInfo object).
発行担当者は、証明書の識別を保持しています。このフィールドは、通常、他の情報（SignerinfoオブジェクトのSIDフィールド）から値を推測できない限り存在します。
The fields of IssuerSerial are discussed in Section 5.4.1.1
発行担当者の分野については、セクション5.4.1.1で説明します
This document is designed to address the security issue of a substituted certificate used by the validator. If a different certificate is used by the validator than the signer, the validator may not get the correct result. An example of this would be that the original certificate was revoked and a new certificate with the same public key was issued for a different individual. Since the issuer/ serial number field is not protected, the attacker could replace this and point to the new certificate and validation would be successful.
このドキュメントは、VALIDATORが使用する代替証明書のセキュリティ問題に対処するように設計されています。署名者とは別の証明書がバリーターによって使用されている場合、バリーターは正しい結果を得られない場合があります。この例は、元の証明書が取り消され、同じ公開キーを持つ新しい証明書が別の個人に対して発行されたことです。発行者/シリアル番号フィールドは保護されていないため、攻撃者はこれを置き換え、新しい証明書を指すことができ、検証は成功します。
The attributes defined in this document are to be placed in locations that are protected by the signature. This attribute does not provide any additional security if placed in an unsigned or un-authenticated location.
このドキュメントで定義されている属性は、署名によって保護されている場所に配置されます。この属性は、署名のないまたは無認定の場所に配置された場合、追加のセキュリティを提供しません。
The attributes defined in this document permit a signer to select a hash algorithm to identify a certificate. A poorly selected hash algorithm may provide inadequate protection against certificate substitution or result in denial of service for this protection. By employing the attributes defined in this specification with the same hash algorithm used for message signing, the sender can ensure that these attributes provide commensurate security.
このドキュメントで定義されている属性により、署名者はハッシュアルゴリズムを選択して証明書を識別することができます。選択されていないハッシュアルゴリズムは、証明書の代替に対する不十分な保護を提供するか、この保護のためにサービスの拒否をもたらす可能性があります。この仕様で定義されている属性をメッセージ署名に使用したのと同じハッシュアルゴリズムを使用して使用することにより、送信者はこれらの属性が相応のセキュリティを提供することを保証できます。
Since recipients must support the hash algorithm to verify the signature, selecting the same hash algorithm also increases the likelihood that the hash algorithm is supported in the context of certificate identification. Note that an unsupported hash algorithm for certificate identification does not preclude validating the message but does deny the message recipient protection against certificate substitution.
受信者はハッシュアルゴリズムをサポートして署名を検証する必要があるため、同じハッシュアルゴリズムを選択すると、ハッシュアルゴリズムが証明書識別のコンテキストでサポートされる可能性も増加します。証明書識別のためのサポートされていないハッシュアルゴリズムは、メッセージの検証を排除するのではなく、証明書の代替に対するメッセージ受信者の保護を否定することに注意してください。
To ensure that legacy implementations are provided protection against certificate substitution, clients are permitted to include both ESScertID and ESScertIDv2 in the same message. Since these attributes are generated and evaluated independently, the contents could conceivably be in conflict. Specifically, where a signer has multiple certificates containing the same public key, the two attributes could specify different signing certificates. The result of signature processing may vary depending on which certificate is used to validate the signature.
レガシーの実装が証明書の代替に対して保護されるようにするために、クライアントは同じメッセージにesscertidとesscertidv2の両方を含めることが許可されています。これらの属性は独立して生成および評価されるため、内容はおそらく対立する可能性があります。具体的には、署名者が同じ公開キーを含む複数の証明書を持っている場合、2つの属性は異なる署名証明書を指定できます。署名処理の結果は、署名の検証に使用される証明書によって異なる場合があります。
Recipients that attempt to evaluate both attributes may choose to reject such a message.
両方の属性を評価しようとする受信者は、そのようなメッセージを拒否することを選択できます。
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[ESS] Hoffman、P。、「S/MIMEの強化されたセキュリティサービス」、RFC 2634、1999年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、RFC 2119、BCP 14、1997年3月。
[RFC3280] Housley, R., Ford, W., Polk, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280] Housley、R.、Ford、W.、Polk、W。、およびD. Solo、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 3280、2002年4月。
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[RFC3852] Housley、R。、「暗号化メッセージ構文（CMS）」、RFC 3852、2004年7月。
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF8] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
Replace the ASN.1 module in RFC 2634 with this one.
RFC 2634のASN.1モジュールをこれに置き換えます。
ExtendedSecurityServices-2006
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-ess-2006(30) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
-- Cryptographic Message Syntax (CMS) [RFC3852]
ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier
FROM CryptographicMessageSyntax2004 { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
modules(0) cms-2004(24)}
-- PKIX Certificate and CRL Profile, Section A.1 Explicity Tagged Module
-- 1988 Syntax [RFC3280]
AlgorithmIdentifier, CertificateSerialNumber
FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18) }
-- PKIX Certificate and CRL Profile, Sec A.2 Implicitly Tagged Module,
-- 1988 Syntax [RFC3280]
PolicyInformation, GeneralNames
FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit(19)};
-- Extended Security Services
-- The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1
-- constructs in this module. A valid ASN.1 SEQUENCE can have zero or
-- more entries. The SIZE (1..MAX) construct constrains the SEQUENCE to
-- have at least one entry. MAX indicates the upper bound is
-- unspecified. Implementations are free to choose an upper bound that
-- suits their environment.
-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The contents are formatted as described in [UTF8]
- [UTF8]で説明されているように、内容がフォーマットされます
-- Section 2.7
- セクション2.7
ReceiptRequest ::= SEQUENCE {
signedContentIdentifier ContentIdentifier,
receiptsFrom ReceiptsFrom,
receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames
}
ub-receiptsTo INTEGER ::= 16
id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1}
ContentIdentifier ::= OCTET STRING
id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7}
ReceiptsFrom ::= CHOICE {
allOrFirstTier [0] AllOrFirstTier, -- formerly "allOrNone [0]AllOrNone"
receiptList [1] SEQUENCE OF GeneralNames
}
AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
allReceipts (0),
firstTierRecipients (1)
}
-- Section 2.8
- セクション2.8
Receipt ::= SEQUENCE {
version ESSVersion,
contentType ContentType,
signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING
}
id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1}
ESSVersion ::= INTEGER { v1(1) }
-- Section 2.9
- セクション2.9
ContentHints ::= SEQUENCE {
contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL,
contentType ContentType
}
id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4}
-- Section 2.10
- セクション2.10
MsgSigDigest ::= OCTET STRING
id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5}
-- Section 2.11
- セクション2.11
ContentReference ::= SEQUENCE {
contentType ContentType,
signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING
}
id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 }
-- Section 3.2
- セクション3.2
ESSSecurityLabel ::= SET {
security-policy-identifier SecurityPolicyIdentifier,
security-classification SecurityClassification OPTIONAL,
privacy-mark ESSPrivacyMark OPTIONAL,
security-categories SecurityCategories OPTIONAL
}
id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2}
SecurityPolicyIdentifier ::= OBJECT IDENTIFIER
SecurityClassification ::= INTEGER {
unmarked (0),
unclassified (1),
restricted (2),
confidential (3),
secret (4),
top-secret (5)
}(0..ub-integer-options)
ub-integer-options INTEGER ::= 256
ESSPrivacyMark ::= CHOICE {
pString PrintableString (SIZE (1..ub-privacy-mark-length)),
utf8String UTF8String (SIZE (1..MAX))
}
ub-privacy-mark-length INTEGER ::= 128
SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
SecurityCategory
ub-security-categories INTEGER ::= 64
SecurityCategory ::= SEQUENCE {
type [0] OBJECT IDENTIFIER,
value [1] ANY DEFINED BY type
}
--Note: The aforementioned SecurityCategory syntax produces identical
--hex encodings as the following SecurityCategory syntax that is
--documented in the X.411 specification:
--
--SecurityCategory ::= SEQUENCE {
-- type [0] SECURITY-CATEGORY,
-- value [1] ANY DEFINED BY type }
--
--SECURITY-CATEGORY MACRO ::=
--BEGIN
--TYPE NOTATION ::= type | empty
--VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
--END
-- Section 3.4
- セクション3.4
EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel
id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9}
-- Section 4.4
- セクション4.4
MLExpansionHistory ::= SEQUENCE
SIZE (1..ub-ml-expansion-history) OF MLData
id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3 }
ub-ml-expansion-history INTEGER ::= 64 MLData ::= SEQUENCE {
mailListIdentifier EntityIdentifier,
expansionTime GeneralizedTime,
mlReceiptPolicy MLReceiptPolicy OPTIONAL
}
EntityIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier SubjectKeyIdentifier
}
MLReceiptPolicy ::= CHOICE {
none [0] NULL,
insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames
}
-- Section 5.4
- セクション5.4
SigningCertificate ::= SEQUENCE {
certs SEQUENCE OF ESSCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL
}
id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 12 }
SigningCertificateV2 ::= SEQUENCE {
certs SEQUENCE OF ESSCertIDv2,
policies SEQUENCE OF PolicyInformation OPTIONAL
}
id-aa-signingCertificateV2 OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 47 }
id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 1 }
ESSCertIDv2 ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier
DEFAULT {algorithm id-sha256},
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}
ESSCertID ::= SEQUENCE {
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}
Hash ::= OCTET STRING IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serialNumber CertificateSerialNumber
}
END
終わり
-- of ExtendedSecurityServices-2006
- 拡張セキュリティServices-2006の
Author's Address
著者の連絡先
Jim Schaad Soaring Hawk Consulting PO Box 675 Gold Bar, WA 98251
Jim Schaad Soaring Hawk Consulting Po Box 675 Gold Bar、WA 98251
EMail: jimsch@exmsft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
この文書は、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は、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。