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
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.
このドキュメントは、更新された構造を使用して新しい属性SigningCertificateV2、一緒に構造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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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を更新し、改訂されたセクションには、以下の構造を持っています。
In addition, the ASN.1 module in Appendix A is replaced.
また、付録AのASN.1モジュールが交換されます。
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.
二つの異なる属性が原因オリジナルデザインの欠陥には、このために存在します。二つの属性間の唯一の実質的な違いはSigningCertificateは、SHA-1ハッシュアルゴリズムの使用を強制しながら、SigningCertificateV2は、ハッシュアルゴリズムの俊敏性を可能にすることです。 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属性が使用されなければなりません。 SigningCertificateV2属性は、SHA-1以外の任意のアルゴリズムが使用されている場合に使用されなければならないとSHA-1には使用しないでください。アプリケーションがあれば、それらは、2つの異なる証明書（すなわち、衝突の可能性が十分に低い）とを区別することがSHA-1を考慮するとして両方の属性を認識するべきです。両方の属性が単一のメッセージに存在する場合、それらは独立して評価されます。
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.署名検証に失敗し、ハッシュが一致しない場合：この場合には、署名が変更されたこと、または間違った証明書が使用されていることのいずれかであり得ます。アプリケーションは、属性内のハッシュ値と一致した別の証明書の検索をしようと、署名の検証を再試行する新しい証明書を使用する必要があります。
3. Insert New 'Signing Certificate Attribute Definition Version 2'
3.新規挿入「署名証明書属性定義バージョン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:
SigningCertificateV2は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のエンコーディングはissuerSerialフィールドを含むべきです。他の制約がissuerAndSerialNumberがのSignerInfoで存在するであろうことを確実にした場合、issuerSerialフィールドは省略されるかもしれません。同定された証明書は、署名検証処理の間に使用されます。証明書のハッシュが署名を検証するために使用される証明書と一致しない場合は、署名が無効であると見なされなければなりません。
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構造の）issuerSerialフィールドは、これらの証明書のために存在しなければなりません。唯一の署名証明書は、配列中に存在する場合は、署名の検証に使用する証明書のセットに制限はありません。
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].
ポリシーは、署名者が証明書に適用されるアサートし、その下に、証明書が依拠する必要があり、それらの証明書ポリシーを識別するポリシー情報項目のシーケンスが含まれています。この値は、証明書利用者の証明書パスの検証に使用されるポリシーの値を示唆しています。 PolicyInformationの定義は、[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はAttributeValueの一連のattrValuesを含めるために署名した属性のASN.1構文を定義します。 SigningCertificateV2属性はAttributeValueのの単一のインスタンスだけを含まなければなりません。 AttributeValueのOF attrValuesセットに存在するAttributeValueのゼロか複数のインスタンスがあってはなりません。
Insert the following text as a new section.
新しいセクションとして次のテキストを挿入します。
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構造のissuerSerialフィールドに置かれるべきです。
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オブジェクトに含まれていない場合には、それだけで、証明書のハッシュに基づいて証明書の正しいセットを取得するためにはるかに困難になります。このため、これらの証明書はIssuerSerialオブジェクトによって特定されるべきです。
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).
issuerSerialは、証明書の識別情報を保持しています。値は、他の情報（例えば、のSignerInfoオブジェクトのSIDフィールド）から推測することができない限りissuerSerialは、通常存在するであろう。
The fields of IssuerSerial are defined as follows:
次のようにIssuerSerialのフィールドが定義されています。
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.
発行者は、証明書の発行者名が含まれています。非属性証明書については、発行者はGeneralNamesのdirectoryNameでの選択でエンコードされた証明書からのみ発行者名を含まなければなりません。属性証明書については、発行者は、属性証明書から発行者名フィールドを含まなければなりません。
serialNumber holds the serial number that uniquely identifies the certificate for the issuer.
serialNumberを一意に発行者の証明書を識別するシリアル番号を保持しています。
5. Insert New 'Signing Certificate Attribute Definition Version 1'
5.新規挿入「署名証明書属性定義バージョン1」
(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.
新しいセクションとして次のテキストを挿入します。
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のエンコーディングはissuerSerialフィールドを含むべきです。他の制約がissuerAndSerialNumberがのSignerInfoで存在するであろうことを確実にした場合、issuerSerialフィールドは省略されるかもしれません。同定された証明書は、署名検証処理の間に使用されます。証明書のハッシュが署名を検証するために使用される証明書と一致しない場合は、署名が無効であると見なされなければなりません。
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の配列中に存在する場合、最初のものの後の証明書は、検証中に使用される証明書のセットを制限します。証明書は、属性証明書（権限を制限する）、または公開鍵証明書（パス検証を制限する）のいずれかになります。署名を検証しているクライアントは、検証のために必要なすべての証明書への容易なアクセスを持つことが期待されていない限り（ESSCertID構造の）issuerSerialフィールドは、これらの証明書のために存在しなければなりません。唯一の署名証明書は、配列中に存在する場合は、署名の検証に使用する証明書のセットに制限はありません。
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はAttributeValueの一連のattrValuesを含めるために署名した属性のASN.1構文を定義します。 SigningCertificate属性はAttributeValueのの単一のインスタンスだけを含まなければなりません。 AttributeValueのOF attrValuesセットに存在するAttributeValueのゼロか複数のインスタンスがあってはなりません。
(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
次のように新しいテキストを挿入
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).
issuerSerialは、証明書の識別情報を保持しています。値は、他の情報（例えば、のSignerInfoオブジェクトのSIDフィールド）から推論することができる限り、このフィールドは、通常存在するであろう。
The fields of IssuerSerial are discussed in Section 5.4.1.1
IssuerSerialのフィールドは、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.
このドキュメントは、バリデータによって使用される置換証明書のセキュリティ上の問題に対処するために設計されています。別の証明書が署名者よりもバリデータによって使用されている場合、バリデータは正しい結果を得ることはできません。この例では、元の証明書が取り消されたと同じ公開鍵を持つ新しい証明書が異なる個々のために発行されたことになります。発行者/シリアル番号フィールドが保護されていないので、攻撃者は、新しい証明書には、このポイントを置き換えることができ、検証が成功するでしょう。
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]ホフマン、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、フォード、W.、ポーク、W.、およびD.ソロ、 "インターネット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.、 "UTF8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
Appendix A. ASN.1 Module
付録A. ASN.1モジュール
Replace the ASN.1 module in RFC 2634 with this one.
この1と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)};
- PKIX証明書およびCRLプロファイル、秒A.2暗黙的にタグ付けモジュール、 - 1988構文[RFC3280] PolicyInformation、PKIX1Implicit88 FROM GeneralNames {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5 ）機構（5）PKIX（7）ID-MOD（0）ID-pkix1-暗黙（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.
- 拡張セキュリティサービス - このモジュール中の構築 - いくつかのASN.1に表示されて構築物「のシーケンスSIZE（1..MAX）」。複数のエントリ - 有効なASN.1シーケンスがゼロかを持つことができます。 SIZE（1..MAX）構築物にSEQUENCEを拘束 - 少なくとも1つのエントリを有しています。未指定 - MAXは上限があることを示します。自分の環境に合っ - 実装はという上限を自由に選択できます。
-- 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
- 拡張セキュリティサービス-2006の
Author's Address
著者のアドレス
Jim Schaad Soaring Hawk Consulting PO Box 675 Gold Bar, WA 98251
ジムSchaad高騰ホークコンサルティング私書箱675ゴールドバー、WA 98251
EMail: jimsch@exmsft.com
メールアドレス：jimsch@exmsft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。