[要約] RFC 2315は、PKCS #7と呼ばれる暗号メッセージ構文のバージョン1.5に関する仕様です。このRFCの目的は、デジタル署名や暗号化などのセキュリティ機能を提供するためのメッセージフォーマットを定義することです。
Network Working Group B. Kaliski
Request for Comments: 2315 RSA Laboratories, East
Category: Informational March 1998
PKCS #7: Cryptographic Message Syntax Version 1.5
PKCS＃7：暗号メッセージ構文バージョン1.5
Status of this Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Overview
概観
This document describes a general syntax for data that may have cryptography applied to it, such as digital signatures and digital envelopes. The syntax admits recursion, so that, for example, one envelope can be nested inside another, or one party can sign some previously enveloped digital data. It also allows arbitrary attributes, such as signing time, to be authenticated along with the content of a message, and provides for other attributes such as countersignatures to be associated with a signature. A degenerate case of the syntax provides a means for disseminating certificates and certificate-revocation lists.
このドキュメントでは、デジタル署名やデジタルエンベロープなど、暗号化が適用されているデータの一般的な構文について説明します。構文は再帰を許可するため、たとえば、あるエンベロープを別のエンベロープ内にネストしたり、ある当事者が以前にエンベロープされたデジタルデータに署名したりできます。また、署名時間などの任意の属性をメッセージのコンテンツとともに認証できるようにし、副署名などの他の属性を署名に関連付けることができます。構文の縮退したケースは、証明書と証明書失効リストを広めるための手段を提供します。
This document is compatible with Privacy-Enhanced Mail (PEM) in that signed-data and signed-and-enveloped-data content, constructed in a PEM-compatible mode, can be converted into PEM messages without any cryptographic operations. PEM messages can similarly be converted into the signed-data and signed-and-enveloped data content types.
このドキュメントはPEMと互換性があり、PEM互換モードで構築された署名済みデータおよび署名済みエンベロープデータのコンテンツは、暗号化操作なしでPEMメッセージに変換できます。 PEMメッセージは、同様に、署名付きデータおよび署名済みおよびエンベロープ付きのデータコンテンツタイプに変換できます。
This document can support a variety of architectures for certificate-based key management, such as the one proposed for Privacy-Enhanced Mail in RFC 1422. Architectural decisions such as what certificate issuers are considered "top-level," what entities certificate issuers are authorized to certify, what distinguished names are considered acceptable, and what policies certificate issuers must follow (such as signing only with secure hardware, or requiring entities to present specific forms of identification) are left outside the document.
このドキュメントは、RFC 1422でプライバシー強化メール用に提案されたものなど、証明書ベースの鍵管理のためのさまざまなアーキテクチャをサポートできます。どの証明書発行者が「トップレベル」と見なされるか、どのエンティティ証明書発行者が許可されるかなどのアーキテクチャ上の決定認定するために、どの識別名が受け入れ可能と見なされるか、および証明書発行者が従わなければならないポリシー（安全なハードウェアでのみ署名する、エンティティに特定の形式のIDを提示するよう要求するなど）は、ドキュメントの外側に残します。
The values produced according to this document are intended to be BER-encoded, which means that the values would typically be represented as octet strings. While many systems are capable of transmitting arbitrary octet strings reliably, it is well known that many electronic-mail systems are not. This document does not address mechanisms for encoding octet strings as (say) strings of ASCII characters or other techniques for enabling reliable transmission by re-encoding the octet string. RFC 1421 suggests one possible solution to this problem.
このドキュメントに従って生成された値は、BERエンコードされることを意図しています。つまり、値は通常オクテット文字列として表されます。多くのシステムは任意のオクテット文字列を確実に送信できますが、多くの電子メールシステムはそうではないことはよく知られています。このドキュメントでは、オクテット文字列を（たとえば）ASCII文字列としてエンコードするメカニズムや、オクテット文字列を再エンコードして信頼性の高い伝送を可能にするその他の手法については触れていません。 RFC 1421は、この問題に対する1つの可能な解決策を提案しています。
FIPS PUB 46-1 National Bureau of Standards. FIPS PUB 46-1: Data Encryption Standard. January 1988.
FIPS PUB 46-1国立標準局。 FIPS PUB 46-1：データ暗号化規格。 1988年1月。
PKCS #1 RSA Laboratories. PKCS #1: RSA Encryption. Version 1.5, November 1993.
PKCS＃1 RSA Laboratories。 PKCS＃1：RSA暗号化。バージョン1.5、1993年11月。
PKCS #6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax. Version 1.5, November 1993.
PKCS＃6 RSA Laboratories。 PKCS＃6：拡張証明書構文。バージョン1.5、1993年11月。
PKCS #9 RSA Laboratories. PKCS #9: Selected Attribute Types. Version 1.1, November 1993.
PKCS＃9 RSA Laboratories。 PKCS＃9：選択された属性タイプ。バージョン1.1、1993年11月。
RFC 1421 Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures," RFC 1421 February 1993.
RFC 1421 Linn、J.、「インターネット電子メールのプライバシー強化：パートI：メッセージの暗号化と認証手順」、RFC 1421、1993年2月。
RFC 1422 Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management," RFC 1422, February 1993.
RFC 1422 Kent、S.、「インターネット電子メールのプライバシー強化：パートII：証明書ベースのキー管理」、RFC 1422、1993年2月。
RFC 1423 Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers," RFC 1423, February 1993.
RFC 1423 Balenson、D。、「インターネット電子メールのプライバシー強化：パートIII：アルゴリズム、モード、および識別子」、RFC 1423、1993年2月。
RFC 1424 Kaliski, B., "Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services," RFC 1424, February 1993.
RFC 1424 Kaliski、B.、「インターネット電子メールのプライバシー強化：パートIV：主要な認証および関連サービス」、RFC 1424、1993年2月。
RFC 1319 Kaliski, B., "The MD2 Message-Digest Algorithm," RFC 1319, April 1992.
RFC 1319 Kaliski、B。、「The MD2 Message-Digest Algorithm」、RFC 1319、1992年4月。
RFC 1321 Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321, April 1992.
RFC 1321 Rivest、R。、「The MD5 Message-Digest Algorithm」、RFC 1321、1992年4月。
X.208 CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988.
X.208 CCITT。勧告X.208：抽象構文記法1（ASN.1）の仕様。 1988。
X.209 CCITT. Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988.
X.209 CCITT。推奨事項X.209：抽象構文記法1（ASN.1）の基本的なエンコーディングルールの仕様。 1988。
X.500 CCITT. Recommendation X.500: The Directory-- Overview of Concepts, Models and Services. 1988.
X.500 CCITT。推奨事項X.500：ディレクトリ-概念、モデル、およびサービスの概要。 1988。
X.501 CCITT. Recommendation X.501: The Directory-- Models. 1988.
X.501 CCITT。推奨事項X.501：ディレクトリ-モデル。 1988。
X.509 CCITT. Recommendation X.509: The Directory-- Authentication Framework. 1988.
X.509 CCITT。推奨事項X.509：ディレクトリ-認証フレームワーク。 1988。
[NIST91] NIST. Special Publication 500-202: Stable Implementation Agreements for Open Systems Interconnection Protocols. Version 5, Edition 1, Part 12. December 1991.
[NIST91] NIST。特別刊行物500-202：オープンシステム相互接続プロトコルの安定した実装契約。バージョン5、エディション1、パート12。1991年12月。
[RSA78] R.L. Rivest, A. Shamir, and L. Adleman. A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM, 21(2):120-126, February 1978.
[RSA78] R.L.リベスト、A。シャミール、およびL.アドルマン。デジタル署名と公開鍵暗号システムを取得する方法。 ACMの通信、21（2）：120-126、1978年2月。
For the purposes of this document, the following definitions apply.
このドキュメントでは、次の定義が適用されます。
AlgorithmIdentifier: A type that identifies an algorithm (by object identifier) and associated parameters. This type is defined in X.509.
AlgorithmIdentifier：（オブジェクト識別子によって）アルゴリズムと関連するパラメーターを識別するタイプ。このタイプはX.509で定義されています。
ASN.1: Abstract Syntax Notation One, as defined in X.208.
ASN.1：X.208で定義されている抽象構文記法1。
Attribute: A type that contains an attribute type (specified by object identifier) and one or more attribute values. This type is defined in X.501.
属性：（オブジェクト識別子で指定された）属性タイプと1つ以上の属性値を含むタイプ。このタイプはX.501で定義されています。
BER: Basic Encoding Rules, as defined in X.209.
BER：X.209で定義されている基本的なエンコーディングルール。
Certificate: A type that binds an entity's distinguished name to a public key with a digital signature. This type is defined in X.509. This type also contains the distinguished name of the certificate issuer (the signer), an issuer-specific serial number, the issuer's signature algorithm identifier, and a validity period.
証明書：エンティティの識別名をデジタル署名付きの公開鍵にバインドするタイプ。このタイプはX.509で定義されています。このタイプには、証明書の発行者（署名者）の識別名、発行者固有のシリアル番号、発行者の署名アルゴリズム識別子、および有効期間も含まれています。
CertificateSerialNumber: A type that uniquely identifies a certificate (and thereby an entity and a public key) among those signed by a particular certificate issuer. This type is defined in X.509.
CertificateSerialNumber：特定の証明書発行者によって署名された証明書の中で証明書（およびエンティティと公開鍵）を一意に識別するタイプ。このタイプはX.509で定義されています。
CertificateRevocationList: A type that contains information about certificates whose validity an issuer has prematurely revoked. The information consists of an issuer name, the time of issue, the next scheduled time of issue, and a list of certificate serial numbers and their associated revocation times. The CRL is signed by the issuer. The type intended by this document is the one defined RFC 1422.
CertificateRevocationList：発行者が早期に取り消した有効性の証明書に関する情報を含むタイプ。この情報は、発行者名、発行時刻、次に予定されている発行時刻、証明書のシリアル番号とそれに関連付けられている失効時刻のリストで構成されています。 CRLは発行者によって署名されています。このドキュメントで意図されているタイプは、RFC 1422で定義されたタイプです。
DER: Distinguished Encoding Rules for ASN.1, as defined in X.509, Section 8.7.
DER：X.509のセクション8.7で定義されているASN.1のDistinguished Encoding Rules。
DES: Data Encryption Standard, as defined in FIPS PUB 46-1.
DES：FIPS PUB 46-1で定義されているデータ暗号化規格。
desCBC: The object identifier for DES in cipher-block chaining (CBC) mode, as defined in [NIST91].
desCBC：暗号ブロック連鎖（CBC）モードのDESのオブジェクト識別子。[NIST91]で定義されています。
ExtendedCertificate: A type that consists of an X.509 public-key certificate and a set of attributes, collectively signed by the issuer of the X.509 public-key certificate. This type is defined in PKCS #6.
ExtendedCertificate：X.509公開鍵証明書と一連の属性で構成されるタイプで、X.509公開鍵証明書の発行者によってまとめて署名されます。このタイプはPKCS＃6で定義されています。
MD2: RSA Data Security, Inc.'s MD2 message-digest algorithm, as defined in RFC 1319.
MD2：RFC 1319で定義されている、RSA Data Security、Inc.のMD2メッセージダイジェストアルゴリズム。
md2: The object identifier for MD2, as defined in RFC 1319.
md2：RFC 1319で定義されているMD2のオブジェクト識別子。
MD5: RSA Data Security, Inc.'s MD5 message-digest algorithm, as defined in RFC 1321.
MD5：RFC 1321で定義されている、RSA Data Security、Inc.のMD5メッセージダイジェストアルゴリズム。
md5: The object identifier for MD5, as defined in RFC 1321.
md5：RFC 1321で定義されているMD5のオブジェクト識別子。
Name: A type that uniquely identifies or "distinguishes" objects in an X.500 directory. This type is defined in X.501. In an X.509 certificate, the type identifies the certificate issuer and the entity whose public key is certified.
名前：X.500ディレクトリー内のオブジェクトを一意的に識別または「区別」するタイプ。このタイプはX.501で定義されています。 X.509証明書では、タイプは証明書の発行者と公開鍵が認証されているエンティティを識別します。
PEM: Internet Privacy-Enhanced Mail, as defined in RFCs 1421-1424.
PEM：RFC 1421-1424で定義されているInternet Privacy-Enhanced Mail。
RSA: The RSA public-key cryptosystem, as defined in [RSA78].
RSA：[RSA78]で定義されているRSA公開鍵暗号システム。
rsaEncryption: The object identifier for RSA encryption, as defined in PKCS #1.
rsaEncryption：PKCS＃1で定義されている、RSA暗号化のオブジェクト識別子。
No symbols or abbreviations are defined in this document.
このドキュメントでは、記号や略語は定義されていません。
The following nine sections specify useful types, general syntax, six content types, and object identifiers.
次の9つのセクションでは、有用なタイプ、一般的な構文、6つのコンテンツタイプ、およびオブジェクト識別子を指定します。
The syntax is general enough to support many different content types. This document defines six: data, signed data, enveloped data, signed-and-enveloped data, digested data, and encrypted data. Other content types may be added in the future. The use of content types defined outside this document is possible, but is subject to bilateral agreement between parties exchanging content.
構文は、多くの異なるコンテンツタイプをサポートするのに十分一般的です。このドキュメントでは、データ、署名データ、エンベロープデータ、署名およびエンベロープデータ、ダイジェストデータ、暗号化データの6つを定義しています。他のコンテンツタイプは将来追加される可能性があります。このドキュメントの外部で定義されているコンテンツタイプの使用は可能ですが、コンテンツを交換する当事者間の二国間合意の対象となります。
This document exports one type, ContentInfo, as well as the various object identifiers.
このドキュメントは、1つのタイプContentInfoとさまざまなオブジェクト識別子をエクスポートします。
There are two classes of content types: base and enhanced. Content types in the base class contain "just data," with no cryptographic enhancements. Presently, one content type is in this class, the data content type. Content types in the enhanced class contain content of some type (possibly encrypted), and other cryptographic enhancements. For example, enveloped-data content can contain (encrypted) signed-data content, which can contain data content. The four non-data content types fall into the enhanced class. The content types in the enhanced class thus employ encapsulation, giving rise to the terms "outer" content (the one containing the enhancements) and "inner" content (the one being enhanced).
コンテンツタイプには、基本と拡張の2つのクラスがあります。基本クラスのコンテンツタイプには「単なるデータ」が含まれており、暗号化機能は強化されていません。現在、1つのコンテンツタイプがこのクラスにあります。データコンテンツタイプです。拡張クラスのコンテンツタイプには、何らかのタイプのコンテンツ（暗号化されている可能性があります）とその他の暗号化拡張機能が含まれています。たとえば、エンベロープデータコンテンツには、（暗号化された）署名付きデータコンテンツを含めることができ、データコンテンツを含めることができます。データ以外の4つのコンテンツタイプは、拡張クラスに分類されます。したがって、拡張クラスのコンテンツタイプはカプセル化を採用し、「外部」コンテンツ（拡張を含むコンテンツ）と「内部」コンテンツ（拡張されるコンテンツ）を生み出します。
The document is designed such that the enhanced content types can be prepared in a single pass using indefinite-length BER encoding, and processed in a single pass in any BER encoding. Single-pass operation is especially helpful if content is stored on tapes, or is "piped" from another process. One of the drawbacks of single-pass operation, however, is that it is difficult to output a DER encoding in a single pass, since the lengths of the various components may not be known in advance. Since DER encoding is required by the signed-data, signed-and-enveloped data, and digested-data content types, an extra pass may be necessary when a content type other than data is the inner content of one of those content types.
このドキュメントは、拡張コンテンツタイプが不定長BERエンコーディングを使用してシングルパスで準備され、任意のBERエンコーディングのシングルパスで処理されるように設計されています。シングルパス操作は、コンテンツがテープに保存されている場合、または別のプロセスから「パイプ」されている場合に特に役立ちます。ただし、シングルパス操作の欠点の1つは、さまざまなコンポーネントの長さが事前にわからない場合があるため、シングルパスでDERエンコーディングを出力することが難しいことです。 DERエンコードは、署名データ、署名およびエンベロープデータ、およびダイジェストデータのコンテンツタイプで必要とされるため、データ以外のコンテンツタイプがこれらのコンテンツタイプのいずれかの内部コンテンツである場合、追加のパスが必要になる場合があります。
This section defines types that are useful in at least two places in the document.
このセクションでは、ドキュメントの少なくとも2つの場所で役立つタイプを定義します。
The CertificateRevocationLists type gives a set of certificate-revocation lists. It is intended that the set contain information sufficient to determine whether the certificates with which the set is associated are "hot listed," but there may be more certificate-revocation lists than necessary, or there may be fewer than necessary.
CertificateRevocationListsタイプは、証明書失効リストのセットを提供します。セットには、セットが関連付けられている証明書が「ホットリスト」であるかどうかを判断するのに十分な情報が含まれていますが、証明書失効リストが必要以上にある場合や、必要以上に少ない場合があります。
CertificateRevocationLists ::=
SET OF CertificateRevocationList
The ContentEncryptionAlgorithmIdentifier type identifies a content-encryption algorithm such as DES. A content-encryption algorithm supports encryption and decryption operations. The encryption operation maps an octet string (the message) to another octet string (the ciphertext) under control of a content-encryption key. The decryption operation is the inverse of the encryption operation. Context determines which operation is intended.
ContentEncryptionAlgorithmIdentifierタイプは、DESなどのコンテンツ暗号化アルゴリズムを識別します。コンテンツ暗号化アルゴリズムは、暗号化および復号化操作をサポートします。暗号化操作は、コンテンツ暗号化キーの制御下で、オクテット文字列（メッセージ）を別のオクテット文字列（暗号文）にマッピングします。復号化操作は、暗号化操作の逆です。コンテキストは、意図する操作を決定します。
ContentEncryptionAlgorithmIdentifier ::=
AlgorithmIdentifier
The DigestAlgorithmIdentifier type identifies a message-digest algorithm. Examples include MD2 and MD5. A message-digest algorithm maps an octet string (the message) to another octet string (the message digest).
DigestAlgorithmIdentifierタイプは、メッセージダイジェストアルゴリズムを識別します。例には、MD2およびMD5が含まれます。メッセージダイジェストアルゴリズムは、オクテット文字列（メッセージ）を別のオクテット文字列（メッセージダイジェスト）にマッピングします。
DigestAlgorithmIdentifier ::= AlgorithmIdentifier
The DigestEncryptionAlgorithmIdentifier type identifies a digest-encryption algorithm under which a message digest can be encrypted. One example is PKCS #1's rsaEncryption. A digest-encryption algorithm supports encryption and decryption operations. The encryption operation maps an octet string (the message digest) to another octet .bp string (the encrypted message digest) under control of a digest-encryption key. The decryption operation is the inverse of the encryption operation. Context determines which operation is intended.
DigestEncryptionAlgorithmIdentifierタイプは、メッセージダイジェストを暗号化できるダイジェスト暗号化アルゴリズムを識別します。 1つの例は、PKCS＃1のrsaEncryptionです。ダイジェスト暗号化アルゴリズムは、暗号化および復号化操作をサポートします。暗号化操作では、ダイジェスト暗号化キーの制御下で、オクテット文字列（メッセージダイジェスト）を別のオクテット.bp文字列（暗号化されたメッセージダイジェスト）にマッピングします。復号化操作は、暗号化操作の逆です。コンテキストは、意図する操作を決定します。
DigestEncryptionAlgorithmIdentifier ::=
AlgorithmIdentifier
The ExtendedCertificateOrCertificate type gives either a PKCS #6 extended certificate or an X.509 certificate. This type follows the syntax recommended in Section 6 of PKCS #6:
ExtendedCertificateOrCertificateタイプは、PKCS＃6拡張証明書またはX.509証明書を提供します。このタイプは、PKCS＃6のセクション6で推奨されている構文に従います。
ExtendedCertificateOrCertificate ::= CHOICE {
certificate Certificate, -- X.509
extendedCertificate [0] IMPLICIT ExtendedCertificate }
extendedCertificate [0] IMPLICIT ExtendedCertificate}
The ExtendedCertificatesAndCertificates type gives a set of extended certificates and X.509 certificates. It is intended that the set be sufficient to contain chains from a recognized "root" or "top-level certification authority" to all of the signers with which the set is associated, but there may be more certificates than necessary, or there may be fewer than necessary.
ExtendedCertificatesAndCertificatesタイプは、拡張証明書とX.509証明書のセットを提供します。セットは、認識された「ルート」または「トップレベルの認証局」から、セットが関連付けられているすべての署名者へのチェーンを含めるのに十分であることが意図されていますが、必要以上の証明書が存在するか、または必要より少ない。
ExtendedCertificatesAndCertificates ::=
SET OF ExtendedCertificateOrCertificate
Note. The precise meaning of a "chain" is outside the scope of this document. Some applications of this document may impose upper limits on the length of a chain; others may enforce certain relationships between the subjects and issuers of certificates in a chain. An example of such relationships has been proposed for Privacy-Enhanced Mail in RFC 1422.
注意。 「チェーン」の正確な意味は、このドキュメントの範囲外です。このドキュメントの一部のアプリケーションでは、チェーンの長さに上限を課す場合があります。チェーン内の証明書のサブジェクトと発行者の間の特定の関係を強制するものもあります。このような関係の例は、RFC 1422のプライバシー強化メールに提案されています。
The IssuerAndSerialNumber type identifies a certificate (and thereby an entity and a public key) by the distinguished name of the certificate issuer and an issuer-specific certificate serial number.
IssuerAndSerialNumberタイプは、証明書の発行者の識別名と発行者固有の証明書のシリアル番号によって証明書（およびエンティティと公開鍵）を識別します。
IssuerAndSerialNumber ::= SEQUENCE {
issuer Name,
serialNumber CertificateSerialNumber }
The KeyEncryptionAlgorithmIdentifier type identifies a key-encryption algorithm under which a content-encryption key can be encrypted. One example is PKCS #1's rsaEncryption. A key-encryption algorithm supports encryption and decryption operations. The encryption operation maps an octet string (the key) to another octet string (the encrypted key) under control of a key-encryption key. The decryption operation is the inverse of the encryption operation. Context determines which operation is intended.
KeyEncryptionAlgorithmIdentifierタイプは、コンテンツ暗号化キーを暗号化できるキー暗号化アルゴリズムを識別します。 1つの例は、PKCS＃1のrsaEncryptionです。鍵暗号化アルゴリズムは、暗号化および復号化操作をサポートします。暗号化操作は、キー暗号化キーの制御下で、オクテット文字列（キー）を別のオクテット文字列（暗号化キー）にマッピングします。復号化操作は、暗号化操作の逆です。コンテキストは、意図する操作を決定します。
KeyEncryptionAlgorithmIdentifier ::=
AlgorithmIdentifier
The Version type gives a syntax version number, for compatibility with future revisions of this document.
バージョンタイプは、このドキュメントの将来のリビジョンとの互換性のために、構文のバージョン番号を提供します。
Version ::= INTEGER
The general syntax for content exchanged between entities according to this document associates a content type with content. The syntax shall have ASN.1 type ContentInfo:
このドキュメントに従ってエンティティ間で交換されるコンテンツの一般的な構文は、コンテンツタイプをコンテンツに関連付けます。構文は、ASN.1タイプContentInfoを持つ必要があります。
ContentInfo ::= SEQUENCE {
contentType ContentType,
content
[0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }
ContentType ::= OBJECT IDENTIFIER
The fields of type ContentInfo have the following meanings:
タイプContentInfoのフィールドには次の意味があります。
o contentType indicates the type of content. It is an object identifier, which means it is a unique string of integers assigned by the authority that defines the content type. This document defines six content types (see Section 14): data, signedData, envelopedData, signedAndEnvelopedData, digestedData, and encryptedData.
o contentTypeは、コンテンツのタイプを示します。これはオブジェクト識別子です。つまり、コンテンツタイプを定義する機関によって割り当てられた整数の一意の文字列です。このドキュメントでは、データ、signedData、envelopedData、signedAndEnvelopedData、digestedData、およびencryptedDataの6つのコンテンツタイプ（セクション14を参照）を定義しています。
o content is the content. The field is optional, and if the field is not present, its intended value must be supplied by other means. Its type is defined along with the object identifier for contentType.
o contentはコンテンツです。このフィールドはオプションであり、フィールドが存在しない場合は、その意図された値を他の方法で提供する必要があります。そのタイプは、contentTypeのオブジェクト識別子とともに定義されます。
Notes.
ノート。
1. The methods below assume that the type of content can be determined uniquely by contentType, so the type defined along with the object identifier should not be a CHOICE type.
1. 以下のメソッドは、コンテンツのタイプがcontentTypeによって一意に決定できると想定しているため、オブジェクト識別子とともに定義されるタイプはCHOICEタイプであってはなりません。
2. When a ContentInfo value is the inner content of signed-data, signed-and-enveloped-data, or digested-data content, a message-digest algorithm is applied to the contents octets of the DER encoding of the content field. When a ContentInfo value is the inner content of enveloped-data or signed-and-enveloped-data content, a content-encryption algorithm is applied to the contents octets of a definite-length BER encoding of the content field.
2. ContentInfo値が署名済みデータ、署名済みおよびエンベロープデータ、またはダイジェストデータのコンテンツの内部コンテンツである場合、メッセージダイジェストアルゴリズムがコンテンツフィールドのDERエンコーディングのコンテンツオクテットに適用されます。 ContentInfo値がエンベロープデータまたは署名およびエンベロープデータのコンテンツの内部コンテンツである場合、コンテンツ暗号化アルゴリズムが、コンテンツフィールドの固定長BERエンコードのコンテンツオクテットに適用されます。
3. The optional omission of the content field makes it possible to construct "external signatures," for example, without modification to or replication of the content to which the signatures apply. In the case of external signatures, the content being signed would be omitted from the "inner" encapsulated ContentInfo value included in the signed-data content type.
3. コンテンツフィールドを省略しても、たとえば、署名が適用されるコンテンツを変更したり複製したりすることなく、「外部署名」を作成できます。外部署名の場合、署名されるコンテンツは、signed-dataコンテンツタイプに含まれる「内部」のカプセル化されたContentInfo値から省略されます。
The data content type is just an octet string. It shall have ASN.1 type Data:
データコンテンツタイプは、オクテット文字列です。 ASN.1タイプのデータを持つ必要があります。
Data ::= OCTET STRING
The data content type is intended to refer to arbitrary octet strings, such as ASCII text files; the interpretation is left to the application. Such strings need not have any internal structure (although they may; they could even be DER encodings).
データコンテンツタイプは、ASCIIテキストファイルなどの任意のオクテット文字列を参照することを目的としています。解釈はアプリケーションに委ねられます。このような文字列は、内部構造を持つ必要はありません（ただし、そうである可能性があります。これらはDERエンコーディングでさえあります）。
The signed-data content type consists of content of any type and encrypted message digests of the content for zero or more signers. The encrypted digest for a signer is a "digital signature" on the content for that signer. Any type of content can be signed by any number of signers in parallel. Furthermore, the syntax has a degenerate case in which there are no signers on the content. The degenerate case provides a means for disseminating certificates and certificate-revocation lists.
署名付きデータコンテンツタイプは、任意のタイプのコンテンツと、0人以上の署名者のコンテンツの暗号化されたメッセージダイジェストで構成されます。署名者の暗号化されたダイジェストは、その署名者のコンテンツの「デジタル署名」です。任意のタイプのコンテンツに、任意の数の署名者が並行して署名できます。さらに、構文には、コンテンツに署名者がいない退化したケースがあります。縮退したケースは、証明書と証明書失効リストを広めるための手段を提供します。
It is expected that the typical application of the signed-data content type will be to represent one signer's digital signature on content of the data content type. Another typical application will be to disseminate certificates and certificate-revocation lists.
署名付きデータコンテンツタイプの一般的な用途は、データコンテンツタイプのコンテンツに対する1人の署名者のデジタル署名を表すことです。もう1つの典型的なアプリケーションは、証明書と証明書失効リストの配布です。
The process by which signed data is constructed involves the following steps:
署名付きデータを作成するプロセスには、次の手順が含まれます。
1. For each signer, a message digest is computed on the content with a signer-specific message-digest algorithm. (If two signers employ the same message-digest algorithm, then the message digest need be computed for only one of them.) If the signer is authenticating any information other than the content (see Section 9.2), the message digest of the content and the other information are digested with the signer's message digest algorithm, and the result becomes the "message digest."
1. 署名者ごとに、署名者固有のメッセージダイジェストアルゴリズムを使用して、コンテンツに対してメッセージダイジェストが計算されます。 （2人の署名者が同じメッセージダイジェストアルゴリズムを採用している場合、メッセージダイジェストはそのうちの1つについてのみ計算する必要があります。）署名者がコンテンツ以外の情報を認証している場合（セクション9.2を参照）、コンテンツのメッセージダイジェストとその他の情報は署名者のメッセージダイジェストアルゴリズムでダイジェストされ、結果は「メッセージダイジェスト」になります。
2. For each signer, the message digest and associated information are encrypted with the signer's private key.
2. 署名者ごとに、メッセージダイジェストと関連情報が署名者の秘密鍵で暗号化されます。
3. For each signer, the encrypted message digest and other signer-specific information are collected into a SignerInfo value, defined in Section 9.2. Certificates and certificate-revocation lists for each signer, and those not corresponding to any signer, are collected in this step.
3. 署名者ごとに、暗号化されたメッセージダイジェストとその他の署名者固有の情報が、セクション9.2で定義されているSignerInfo値に収集されます。各署名者の証明書と証明書失効リスト、およびどの署名者にも対応しないものは、このステップで収集されます。
4. The message-digest algorithms for all the signers and the SignerInfo values for all the signers are collected together with the content into a SignedData value, defined in Section 9.1.
4. すべての署名者のメッセージダイジェストアルゴリズムとすべての署名者のSignerInfo値は、コンテンツとともに、セクション9.1で定義されているSignedData値に収集されます。
A recipient verifies the signatures by decrypting the encrypted message digest for each signer with the signer's public key, then comparing the recovered message digest to an independently computed message digest. The signer's public key is either contained in a certificate included in the signer information, or is referenced by an issuer distinguished name and an issuer-specific serial number that uniquely identify the certificate for the public key.
受信者は、署名者の公開鍵を使用して各署名者の暗号化されたメッセージダイジェストを復号化し、復元されたメッセージダイジェストを個別に計算されたメッセージダイジェストと比較して、署名を検証します。署名者の公開鍵は、署名者情報に含まれる証明書に含まれるか、公開鍵の証明書を一意に識別する発行者識別名と発行者固有のシリアル番号によって参照されます。
This section is divided into five parts. The first part describes the top-level type SignedData, the second part describes the per-signer information type SignerInfo, and the third and fourth parts describe the message-digesting and digest-encryption processes. The fifth part summarizes compatibility with Privacy-Enhanced Mail.
このセクションは5つのパートに分かれています。最初の部分はトップレベルのタイプSignedDataを説明し、2番目の部分は署名者ごとの情報タイプSignerInfoを説明し、3番目と4番目の部分はメッセージ消化プロセスとダイジェスト暗号化プロセスを説明します。 5番目の部分では、プライバシー強化メールとの互換性を要約しています。
The signed-data content type shall have ASN.1 type SignedData:
署名済みデータのコンテンツタイプは、ASN.1タイプSignedDataを持つ必要があります。
SignedData ::= SEQUENCE {
version Version,
digestAlgorithms DigestAlgorithmIdentifiers,
contentInfo ContentInfo,
certificates
[0] IMPLICIT ExtendedCertificatesAndCertificates
OPTIONAL,
crls
[1] IMPLICIT CertificateRevocationLists OPTIONAL,
signerInfos SignerInfos }
DigestAlgorithmIdentifiers ::=
SET OF DigestAlgorithmIdentifier
SET OF DigestAlgorithmIdentifier
SignerInfos ::= SET OF SignerInfo
The fields of type SignedData have the following meanings:
タイプSignedDataのフィールドには次の意味があります。
o version is the syntax version number. It shall be 1 for this version of the document.
o versionは構文のバージョン番号です。このバージョンのドキュメントでは1になります。
o digestAlgorithms is a collection of message-digest algorithm identifiers. There may be any number of elements in the collection, including zero. Each element identifies the message-digest algorithm (and any associated parameters) under which the content is digested for a some signer. The collection is intended to list the message-digest algorithms employed by all of the signers, in any order, to facilitate one-pass signature verification. The message-digesting process is described in Section 9.3.
o digestAlgorithmsは、メッセージダイジェストアルゴリズム識別子のコレクションです。コレクションには、0を含む任意の数の要素が含まれる場合があります。各要素は、一部の署名者のためにコンテンツがダイジェストされるメッセージダイジェストアルゴリズム（および関連するパラメーター）を識別します。このコレクションは、すべての署名者が使用するメッセージダイジェストアルゴリズムを任意の順序でリストして、ワンパス署名検証を容易にすることを目的としています。メッセージダイジェストプロセスについては、セクション9.3で説明します。
o contentInfo is the content that is signed. It can have any of the defined content types.
o contentInfoは、署名されたコンテンツです。定義されたコンテンツタイプのいずれかを持つことができます。
o certificates is a set of PKCS #6 extended certificates and X.509 certificates. It is intended that the set be sufficient to contain chains from a recognized "root" or "top-level certification authority" to all of the signers in the signerInfos field. There may be more certificates than necessary, and there may be certificates sufficient to contain chains from two or more independent top-level certification authorities. There may also be fewer certificates than necessary, if it is expected that those verifying the signatures have an alternate means of obtaining necessary certificates (e.g., from a previous set of certificates).
o証明書は、PKCS＃6拡張証明書とX.509証明書のセットです。このセットは、認識された「ルート」または「トップレベルの証明機関」からすべての署名者へのチェーンをsignerInfosフィールドに含めるのに十分であることを意図しています。必要以上の証明書が存在する可能性があり、2つ以上の独立したトップレベルの証明機関からのチェーンを含めるのに十分な証明書が存在する可能性があります。署名を検証する人が必要な証明書を取得する別の手段を持っていることが予想される場合（たとえば、以前の証明書のセットから）、証明書が必要よりも少ない場合もあります。
o crls is a set of certificate-revocation lists. It is intended that the set contain information sufficient to determine whether or not the certificates in the certificates field are "hot listed," but such correspondence is not necessary. There may be more certificate-revocation lists than necessary, and there may also be fewer certificate-revocation lists than necessary.
o crlsは、証明書失効リストのセットです。セットには、証明書フィールドの証明書が「ホットリスト」であるかどうかを判断するのに十分な情報が含まれていますが、このような対応は必要ありません。必要以上に多くの証明書失効リストが存在する可能性があり、必要以上に少ない証明書失効リストも存在する可能性があります。
o signerInfos is a collection of per-signer information. There may be any number of elements in the collection, including zero.
o signerInfosは、署名者ごとの情報のコレクションです。コレクションには、0を含む任意の数の要素が含まれる場合があります。
Notes.
ノート。
1. The fact that the digestAlgorithms field comes before the contentInfo field and the signerInfos field comes after it makes it possible to process a SignedData value in a single pass. (Single-pass processing is described in Section 5.)
1. digestAlgorithmsフィールドがcontentInfoフィールドの前にあり、signerInfosフィールドが後にあるので、SignedData値を1回のパスで処理できます。 （シングルパス処理については、セクション5で説明します。）
2. The differences between version 1 SignedData and version 0 SignedData (defined in PKCS #7, Version 1.4) are the following:
2. バージョン1 SignedDataとバージョン0 SignedData（PKCS＃7、バージョン1.4で定義）の違いは次のとおりです。
o the digestAlgorithms and signerInfos fields may contain zero elements in version 1, but not in version 0
o digestAlgorithmsおよびsignerInfosフィールドには、バージョン1ではゼロ要素が含まれる場合がありますが、バージョン0では含まれません。
o the crls field is allowed in version 1, but not in version 0
o crlsフィールドはバージョン1では許可されていますが、バージョン0では許可されていません
Except for the difference in version number, version 0 SignedData values are acceptable as version 1 values. An implementation can therefore process SignedData values of either version as though they were version 1 values. It is suggested that PKCS implementations generate only version 1 SignedData values, but be prepared to process SignedData values of either version.
バージョン番号の違いを除いて、バージョン0のSignedData値はバージョン1の値として受け入れられます。したがって、実装は、どちらのバージョンのSignedData値も、バージョン1の値であるかのように処理できます。 PKCS実装はバージョン1のSignedData値のみを生成することをお勧めしますが、どちらのバージョンのSignedData値も処理できるように準備しておく必要があります。
3. In the degenerate case where there are no signers on the content, the ContentInfo value being "signed" is irrelevant. It is recommended in that case that the content type of the ContentInfo value being "signed" be data, and the content field of the ContentInfo value be omitted.
3. コンテンツに署名者がいない縮退したケースでは、「署名」されているContentInfo値は関係ありません。その場合、「署名」されるContentInfo値のコンテンツタイプはデータであり、ContentInfo値のコンテンツフィールドは省略されることをお勧めします。
Per-signer information is represented in the type SignerInfo:
署名者ごとの情報は、SignerInfoタイプで表されます。
SignerInfo ::= SEQUENCE {
version Version,
issuerAndSerialNumber IssuerAndSerialNumber,
digestAlgorithm DigestAlgorithmIdentifier,
authenticatedAttributes
[0] IMPLICIT Attributes OPTIONAL,
digestEncryptionAlgorithm
DigestEncryptionAlgorithmIdentifier,
encryptedDigest EncryptedDigest,
unauthenticatedAttributes
[1] IMPLICIT Attributes OPTIONAL }
EncryptedDigest ::= OCTET STRING
The fields of type SignerInfo have the following meanings:
タイプSignerInfoのフィールドには、次の意味があります。
o version is the syntax version number. It shall be 1 for this version of the document.
o versionは構文のバージョン番号です。このバージョンのドキュメントでは1になります。
o issuerAndSerialNumber specifies the signer's certificate (and thereby the signer's distinguished name and public key) by issuer distinguished name and issuer-specific serial number.
o issuerAndSerialNumberは、発行者の識別名と発行者固有のシリアル番号によって、署名者の証明書（したがって、署名者の識別名と公開鍵）を指定します。
o digestAlgorithm identifies the message-digest algorithm (and any associated parameters) under which the content and authenticated attributes (if present) are digested. It should be among those in the digestAlgorithms field of the superior SignerInfo value. The message-digesting process is described in Section 9.3.
o digestAlgorithmは、コンテンツと認証された属性（存在する場合）がダイジェストされるメッセージダイジェストアルゴリズム（および関連するパラメーター）を識別します。これは、上位のSignerInfo値のdigestAlgorithmsフィールドに含まれているはずです。メッセージダイジェストプロセスについては、セクション9.3で説明します。
o authenticatedAttributes is a set of attributes that are signed (i.e., authenticated) by the signer. The field is optional, but it must be present if the content type of the ContentInfo value being signed is not data. If the field is present, it must contain, at a minimum, two attributes:
o authenticationAttributesは、署名者によって署名された（つまり、認証された）属性のセットです。このフィールドはオプションですが、署名されるContentInfo値のコンテンツタイプがデータでない場合は、存在する必要があります。フィールドが存在する場合、少なくとも2つの属性が含まれている必要があります。
1. A PKCS #9 content-type attribute having as its value the content type of the ContentInfo value being signed.
1. 署名されるContentInfo値のコンテンツタイプを値として持つPKCS＃9 content-type属性。
2. A PKCS #9 message-digest attribute, having as its value the message digest of the content (see below).
2. コンテンツのメッセージダイジェストを値として持つPKCS＃9メッセージダイジェスト属性（以下を参照）。
Other attribute types that might be useful here, such as signing time, are also defined in PKCS #9.
署名時刻など、ここで役立つ他の属性タイプもPKCS＃9で定義されています。
o digestEncryptionAlgorithm identifies the digest-encryption algorithm (and any associated parameters) under which the message digest and associated information are encrypted with the signer's private key. The digest-encryption process is described in Section 9.4.
o digestEncryptionAlgorithmは、メッセージダイジェストと関連情報が署名者の秘密鍵で暗号化されるダイジェスト暗号化アルゴリズム（および関連するパラメーター）を識別します。ダイジェスト暗号化プロセスについては、セクション9.4で説明しています。
o encryptedDigest is the result of encrypting the message digest and associated information with the signer's private key.
o encryptedDigestは、メッセージダイジェストと関連情報を署名者の秘密鍵で暗号化した結果です。
o unauthenticatedAttributes is a set of attributes that are not signed (i.e., authenticated) by the signer. The field is optional. Attribute types that might be useful here, such as countersignatures, are defined in PKCS #9.
o unauthenticatedAttributesは、署名者によって署名されていない（つまり、認証されていない）属性のセットです。このフィールドはオプションです。副署名など、ここで役立つ可能性のある属性タイプは、PKCS＃9で定義されています。
Notes.
ノート。
1. It is recommended in the interest of PEM compatibility that the authenticatedAttributes field be omitted whenever the content type of the ContentInfo value being signed is data and there are no other authenticated attributes.
1. PEMの互換性のために、署名されるContentInfo値のコンテンツタイプがデータであり、他の認証された属性がない場合は常に、authenticationAttributesフィールドを省略することをお勧めします。
2. The difference between version 1 SignerInfo and version 0 SignerInfo (defined in PKCS #7, Version 1.4) is in the message-digest encryption process (see Section 9.4). Only the PEM-compatible processes are different, reflecting changes in Privacy-Enhanced Mail signature methods. There is no difference in the non-PEM-compatible message-digest encryption process.
2. バージョン1のSignerInfoとバージョン0のSignerInfo（PKCS＃7、バージョン1.4で定義）の違いは、メッセージダイジェスト暗号化プロセスにあります（セクション9.4を参照）。プライバシーが強化されたメールの署名方法の変更を反映して、PEM互換プロセスのみが異なります。非PEM互換のメッセージダイジェスト暗号化プロセスに違いはありません。
It is suggested that PKCS implementations generate only version 1 SignedData values. Since the PEM signature method with which version 0 is compatible is obsolescent, it is suggested that PKCS implementations be prepared to receive only version 1 SignedData values.
PKCS実装はバージョン1のSignedData値のみを生成することをお勧めします。バージョン0と互換性のあるPEM署名方式は廃止されているため、バージョン1のSignedData値のみを受け取るようにPKCS実装を準備することをお勧めします。
The message-digesting process computes a message digest on either the content being signed or the content together with the signer's authenticated attributes. In either case, the initial input to the message-digesting process is the "value" of the content being signed. Specifically, the initial input is the contents octets of the DER encoding of the content field of the ContentInfo value to which the signing process is applied. Only the contents octets of the DER encoding of that field are digested, not the identifier octets or the length octets.
メッセージダイジェストプロセスは、署名されているコンテンツ、または署名者の認証された属性と一緒にコンテンツのいずれかでメッセージダイジェストを計算します。どちらの場合でも、メッセージダイジェストプロセスへの最初の入力は、署名されるコンテンツの「価値」です。具体的には、初期入力は、署名プロセスが適用されるContentInfo値のコンテンツフィールドのDERエンコーディングのコンテンツオクテットです。そのフィールドのDERエンコードのコンテンツオクテットのみがダイジェストされ、識別子オクテットや長さオクテットはダイジェストされません。
The result of the message-digesting process (which is called, informally, the "message digest") depends on whether the authenticatedAttributes field is present. When the field is absent, the result is just the message digest of the content. When the field is present, however, the result is the message digest of the complete DER encoding of the Attributes value containted in the authenticatedAttributes field. (For clarity: The IMPLICIT [0] tag in the authenticatedAttributes field is not part of the Attributes value. The Attributes value's tag is SET OF, and the DER encoding of the SET OF tag, rather than of the IMPLICIT [0] tag, is to be digested along with the length and contents octets of the Attributes value.) Since the Attributes value, when the field is present, must contain as attributes the content type and the message digest of the content, those values are indirectly included in the result.
メッセージダイジェストプロセス（非公式には「メッセージダイジェスト」と呼ばれます）の結果は、authenticatedAttributesフィールドが存在するかどうかによって異なります。フィールドが存在しない場合、結果はコンテンツのメッセージダイジェストのみです。ただし、フィールドが存在する場合、結果は、authenticationAttributesフィールドに含まれる属性値の完全なDERエンコードのメッセージダイジェストになります。 （明確にするために、authenticationAttributesフィールドのIMPLICIT [0]タグは、Attributes値の一部ではありません。Attributes値のタグはSET OFであり、IMPLICIT [0]タグではなく、SET OFタグのDERエンコードです属性値の長さと内容のオクテットとともにダイジェストされます。）属性値は、フィールドが存在する場合、属性としてコンテンツのコンテンツタイプとメッセージダイジェストを含む必要があるため、これらの値は間接的に結果。
When the content being signed has content type data and the authenticatedAttributes field is absent, then just the value of the data (e.g., the contents of a file) is digested. This has the advantage that the length of the content being signed need not be known in advance of the encryption process. This method is compatible with Privacy-Enhanced Mail.
署名されるコンテンツにコンテンツタイプデータがあり、authenticationAttributesフィールドが存在しない場合、データの値（たとえば、ファイルのコンテンツ）のみがダイジェストされます。これには、署名されるコンテンツの長さが暗号化プロセスの前に既知である必要がないという利点があります。この方法は、プライバシー強化メールと互換性があります。
Although the identifier octets and the length octets are not digested, they are still protected by other means. The length octets are protected by the nature of the message-digest algorithm since it is by assumption computationally infeasible to find any two distinct messages of any length that have the same message digest. Furthermore, assuming that the content type uniquely determines the identifier octets, the identifier octets are protected implicitly in one of two ways: either by the inclusion of the content type in the authenticated attributes, or by the use of the PEM-compatible alternative in Section 9.4 which implies that the content type is data.
識別子のオクテットと長さのオクテットはダイジェストされていませんが、他の方法で保護されています。同じメッセージダイジェストを持つ任意の長さの2つの異なるメッセージを見つけることは計算上不可能であるため、長さオクテットはメッセージダイジェストアルゴリズムの性質によって保護されています。さらに、コンテンツタイプが識別子オクテットを一意に決定すると仮定すると、識別子オクテットは、2つの方法の1つで暗黙的に保護されます。認証された属性にコンテンツタイプを含めるか、セクションのPEM互換の代替手段を使用します。これは、コンテンツタイプがデータであることを意味します。
Note. The fact that the message digest is computed on part of a DER encoding does not mean that DER is the required method of representing that part for data transfer. Indeed, it is expected that some implementations of this document may store objects in other than their DER encodings, but such practices do not affect message-digest computation.
注意。メッセージダイジェストがDERエンコーディングの一部で計算されるという事実は、DERがデータ転送のためにその部分を表すために必要な方法であることを意味しません。実際、このドキュメントの実装によっては、オブジェクトをDERエンコーディング以外で格納することが予想されますが、そのような方法はメッセージダイジェストの計算には影響しません。
The input to the digest-encryption process--the value supplied to the signer's digest-encryption algorithm--includes the result of the message-digesting process (informally, the "message digest") and the digest algorithm identifier (or object identifier). The result of the digest-encryption process is the encryption with the signer's private key of the BER encoding of a value of type DigestInfo:
ダイジェスト暗号化プロセスへの入力（署名者のダイジェスト暗号化アルゴリズムに提供される値）には、メッセージダイジェストプロセスの結果（非公式には「メッセージダイジェスト」）とダイジェストアルゴリズム識別子（またはオブジェクト識別子）が含まれます。 。ダイジェスト暗号化プロセスの結果は、タイプDigestInfoの値のBERエンコードの署名者の秘密鍵による暗号化です。
DigestInfo ::= SEQUENCE {
digestAlgorithm DigestAlgorithmIdentifier,
digest Digest }
Digest ::= OCTET STRING
The fields of type DigestInfo have the following meanings:
タイプDigestInfoのフィールドには次の意味があります。
o digestAlgorithm identifies the message-digest algorithm (and any associated parameters) under which the content and authenticated attributes are digested. It should be the same as the digestAlgorithm field of the superior SignerInfo value.
o digestAlgorithmは、コンテンツと認証された属性がダイジェストされるメッセージダイジェストアルゴリズム（および関連するパラメーター）を識別します。これは、上位のSignerInfo値のdigestAlgorithmフィールドと同じである必要があります。
o digest is the result of the message-digesting process.
o ダイジェストは、メッセージダイジェストプロセスの結果です。
Notes.
ノート。
1. The only difference between the signature process defined here and the signature algorithms defined in PKCS #1 is that signatures there are represented as bit strings, for consistency with the X.509 SIGNED macro. Here, encrypted message digests are octet strings.
1. ここで定義されている署名プロセスとPKCS＃1で定義されている署名アルゴリズムの唯一の違いは、X.509 SIGNEDマクロとの整合性を保つために、署名がビット文字列として表されることです。ここでは、暗号化されたメッセージダイジェストはオクテット文字列です。
2. The input to the encryption process typically will have 30 or fewer octets. If digestEncryptionAlgorithm is PKCS #1's rsaEncryption, then this means that the input can be encrypted in a single block as long as the length of the RSA modulus is at least 328 bits, which is reasonable and consistent with security recommendations.
2. 暗号化プロセスへの入力は、通常30オクテット以下になります。 digestEncryptionAlgorithmがPKCS＃1のrsaEncryptionである場合、これは、RSAモジュラスの長さが328ビット以上である限り、単一ブロックで入力を暗号化できることを意味します。これは妥当であり、セキュリティの推奨事項と一致しています。
3. A message-digest algorithm identifier is included in the DigestInfo value to limit the damage resulting from the compromise of one message-digest algorithm. For instance, suppose an adversary were able to find messages with a given MD2 message digest. That adversary could then forge a signature by finding a message with the same MD2 message digest as one that a signer previously signed, and presenting the previous signature as the signature on the new message. This attack would succeed only if the signer previously used MD2, since the DigestInfo value contains the message-digest algorithm. If a signer never trusted the MD2 algorithm and always used MD5, then the compromise of MD2 would not affect the signer. If the DigestInfo value contained only the message digest, however, the compromise of MD2 would affect signers that use any message-digest algorithm.
3. メッセージダイジェストアルゴリズムの識別子がDigestInfo値に含まれているため、1つのメッセージダイジェストアルゴリズムの侵害による被害を制限できます。たとえば、攻撃者が特定のMD2メッセージダイジェストを持つメッセージを見つけられたとします。次に、その攻撃者は、署名者が以前に署名したものと同じMD2メッセージダイジェストを持つメッセージを見つけ、以前の署名を新しいメッセージの署名として提示することにより、署名を偽造できます。 DigestInfo値にはメッセージダイジェストアルゴリズムが含まれているため、この攻撃は、署名者が以前にMD2を使用した場合にのみ成功します。署名者がMD2アルゴリズムを信頼せず、常にMD5を使用した場合、MD2の侵害は署名者に影響しません。ただし、DigestInfo値にメッセージダイジェストのみが含まれている場合、MD2の侵害により、任意のメッセージダイジェストアルゴリズムを使用する署名者が影響を受けます。
4. There is potential for ambiguity due to the fact that the DigestInfo value does not indicate whether the digest field contains just the message digest of the content or the message digest of the complete DER encoding of the authenticatedAttributes field. In other words, it is possible for an adversary to transform a signature on authenticated attributes to one that appears to be just on content by changing the content to be the DER encoding of the authenticatedAttributes field, and then removing the authenticatedAttributes field. (The reverse transformation is possible, but requires that the content be the DER encoding of an authenticated attributes value, which is unlikely.) This ambiguity is not a new problem, nor is it a significant one, as context will generally prevent misuse. Indeed, it is also possible for an adversary to transform a signature on a certificate or certificate-revocation list to one that appears to be just on signed-data content.
4. DigestInfo値は、ダイジェストフィールドにコンテンツのメッセージダイジェストのみが含まれているか、authenticationAttributesフィールドの完全なDERエンコーディングのメッセージダイジェストが含まれているかを示していないため、あいまいになる可能性があります。つまり、攻撃者は、コンテンツをauthenticationAttributesフィールドのDERエンコーディングに変更し、authenticationAttributesフィールドを削除することにより、認証された属性の署名を、コンテンツ上にあるように見えるものに変換することができます。 （逆変換は可能ですが、コンテンツが認証された属性値のDERエンコードである必要があります。これはほとんどありません。）このあいまいさは新しい問題ではなく、重大な問題でもありません。コンテキストが一般的に誤用を防ぐためです。実際、攻撃者が証明書または証明書失効リストの署名を、署名されたデータのコンテンツのみにあるように見えるものに変換することも可能です。
Compatibility with the MIC-ONLY and MIC-CLEAR process types in PEM occurs when the content type of the ContentInfo value being signed is data, there are no authenticated attributes, the message-digest algorithm is md2 or md5, and the digest-encryption algorithm is PKCS #1's rsaEncryption. Under all those conditions, the encrypted message digest produced here matches the one produced in PEM because:
PEMのMIC-ONLYおよびMIC-CLEARプロセスタイプとの互換性は、署名されるContentInfo値のコンテンツタイプがデータであり、認証された属性がなく、メッセージダイジェストアルゴリズムがmd2またはmd5であり、ダイジェスト暗号化アルゴリズムである場合に発生します。 PKCS＃1のrsaEncryptionです。これらすべての条件の下で、ここで生成される暗号化されたメッセージダイジェストは、PEMで生成されるものと一致します。
1. The value input to the message-digest algorithm in PEM is the same as in this document when there are no authenticated attributes. MD2 and MD5 in PEM are the same as md2 and md5.
1. PEMのメッセージダイジェストアルゴリズムに入力される値は、認証された属性がない場合、このドキュメントと同じです。 PEMのMD2およびMD5は、md2およびmd5と同じです。
2. The value encrypted with the signer's private key in PEM (as specified in RFC 1423) is the same as in this document when there are no authenticated attributes. RSA private-key encryption in PEM is the same as PKCS #1's rsaEncryption.
2. PEMの署名者の秘密鍵で暗号化された値（RFC 1423で指定）は、認証された属性がない場合、このドキュメントと同じです。 PEMでのRSA秘密鍵暗号化は、PKCS＃1のrsaEncryptionと同じです。
The other parts of the signed-data content type (certificates, CRLs, algorithm identifiers, etc.) are easily translated to and from their corresponding PEM components.
署名付きデータコンテンツタイプの他の部分（証明書、CRL、アルゴリズム識別子など）は、対応するPEMコンポーネントとの間で簡単に変換されます。
The enveloped-data content type consists of encrypted content of any type and encrypted content-encryption keys for one or more recipients. The combination of encrypted content and encrypted content-encryption key for a recipient is a "digital envelope" for that recipient. Any type of content can be enveloped for any number of recipients in parallel.
エンベロープデータコンテンツタイプは、任意のタイプの暗号化コンテンツと1人以上の受信者用の暗号化コンテンツ暗号化キーで構成されます。受信者の暗号化されたコンテンツと暗号化されたコンテンツ暗号化キーの組み合わせは、その受信者の「デジタルエンベロープ」です。任意のタイプのコンテンツを、任意の数の受信者に対して同時にエンベロープできます。
It is expected that the typical application of the enveloped-data content type will be to represent one or more recipients' digital envelopes on content of the data, digested-data, or signed-data content types.
エンベロープデータコンテンツタイプの一般的な用途は、データ、ダイジェストデータ、または署名データコンテンツタイプのコンテンツで1人以上の受信者のデジタルエンベロープを表すことです。
The process by which enveloped data is constructed involves the following steps:
エンベロープデータが構築されるプロセスには、次の手順が含まれます。
1. A content-encryption key for a particular content-encryption algorithm is generated at random.
1. 特定のコンテンツ暗号化アルゴリズムのコンテンツ暗号化キーはランダムに生成されます。
2. For each recipient, the content-encryption key is encrypted with the recipient's public key.
2. 受信者ごとに、コンテンツ暗号化キーは受信者の公開キーで暗号化されます。
3. For each recipient, the encrypted content-encryption key and other recipient-specific information are collected into a RecipientInfo value, defined in Section 10.2.
3. 受信者ごとに、暗号化されたコンテンツ暗号化キーとその他の受信者固有の情報が、セクション10.2で定義されているRecipientInfo値に収集されます。
4. The content is encrypted with the content-encryption key. (Content encryption may require that the content be padded to a multiple of some block size; see Section 10.3 for discussion.)
4. コンテンツはコンテンツ暗号化キーで暗号化されます。 （コンテンツの暗号化では、コンテンツをいくつかのブロックサイズの倍数に埋め込む必要がある場合があります。詳細については、セクション10.3を参照してください。）
5. The RecipientInfo values for all the recipients are collected together with the encrypted content into a EnvelopedData value, defined in Section 10.1.
5. すべての受信者のRecipientInfo値は、暗号化されたコンテンツとともに、10.1で定義されているEnvelopedData値に収集されます。
A recipient opens the envelope by decrypting the one of the encrypted content-encryption keys with the recipient's private key and decrypting the encrypted content with the recovered content-encryption key. The recipient's private key is referenced by an issuer distinguished name and an issuer-specific serial number that uniquely identify the certificate for the corresponding public key.
受信者は、暗号化されたコンテンツ暗号化キーの1つを受信者の秘密キーで復号化し、暗号化されたコンテンツを復元されたコンテンツ暗号化キーで復号化して、エンベロープを開きます。受信者の秘密鍵は、発行者の識別名と、対応する公開鍵の証明書を一意に識別する発行者固有のシリアル番号によって参照されます。
This section is divided into four parts. The first part describes the top-level type EnvelopedData, the second part describes the per-recipient information type RecipientInfo, and the third and fourth parts describe the content-encryption and key-encryption processes.
このセクションは4つのパートに分かれています。最初の部分はトップレベルタイプのEnvelopedDataを説明し、2番目の部分は受信者ごとの情報タイプRecipientInfoを説明し、3番目と4番目の部分はコンテンツの暗号化とキー暗号化のプロセスを説明します。
This content type is not compatible with Privacy-Enhanced Mail (although some processes it defines are compatible with their PEM counterparts), since Privacy-Enhanced Mail always involves digital signatures, never digital envelopes alone.
プライバシー強化メールには常にデジタル署名が含まれ、デジタル封筒だけが含まれるわけではないため、このコンテンツタイプはプライバシー強化メールと互換性がありません（ただし、定義されている一部のプロセスは対応するPEMと互換性があります）。
The enveloped-data content type shall have ASN.1 type EnvelopedData:
エンベロープデータコンテンツタイプは、ASN.1タイプEnvelopedDataを持つ必要があります。
EnvelopedData ::= SEQUENCE {
version Version,
recipientInfos RecipientInfos,
encryptedContentInfo EncryptedContentInfo }
RecipientInfos ::= SET OF RecipientInfo
EncryptedContentInfo ::= SEQUENCE {
contentType ContentType,
contentEncryptionAlgorithm
ContentEncryptionAlgorithmIdentifier,
encryptedContent
[0] IMPLICIT EncryptedContent OPTIONAL }
EncryptedContent ::= OCTET STRING
The fields of type EnvelopedData have the following meanings:
EnvelopedData型のフィールドには次の意味があります。
o version is the syntax version number. It shall be 0 for this version of the document.
o versionは構文のバージョン番号です。このバージョンのドキュメントでは0になります。
o recipientInfos is a collection of per-recipient information. There must be at least one element in the collection.
o recipientInfosは、受信者ごとの情報のコレクションです。コレクションには少なくとも1つの要素が必要です。
o encryptedContentInfo is the encrypted content information.
o encryptedContentInfoは、暗号化されたコンテンツ情報です。
The fields of type EncryptedContentInfo have the following meanings:
タイプEncryptedContentInfoのフィールドには次の意味があります。
o contentType indicates the type of content.
o contentTypeは、コンテンツのタイプを示します。
o contentEncryptionAlgorithm identifies the content-encryption algorithm (and any associated parameters) under which the content is encrypted. The content-encryption process is described in Section 10.3. This algorithm is the same for all recipients.
o contentEncryptionAlgorithmは、コンテンツが暗号化されるコンテンツ暗号化アルゴリズム（および関連するパラメーター）を識別します。コンテンツの暗号化プロセスについては、10.3項で説明しています。このアルゴリズムは、すべての受信者に共通です。
o encryptedContent is the result of encrypting the content. The field is optional, and if the field is not present, its intended value must be supplied by other means.
o encryptedContentは、コンテンツを暗号化した結果です。このフィールドはオプションであり、フィールドが存在しない場合は、その意図された値を他の方法で提供する必要があります。
Note. The fact that the recipientInfos field comes before the encryptedContentInfo field makes it possible to process an EnvelopedData value in a single pass. (Single-pass processing is described in Section 5.)
注意。 recipientInfosフィールドがencryptedContentInfoフィールドの前にあるという事実により、EnvelopedData値を1回のパスで処理できます。 （シングルパス処理については、セクション5で説明します。）
Per-recipient information is represented in the type RecipientInfo:
受信者ごとの情報は、RecipientInfoタイプで表されます。
RecipientInfo ::= SEQUENCE {
version Version,
issuerAndSerialNumber IssuerAndSerialNumber,
keyEncryptionAlgorithm
KeyEncryptionAlgorithmIdentifier, encryptedKey EncryptedKey }
KeyEncryptionAlgorithmIdentifier、encryptedKey EncryptedKey}
EncryptedKey ::= OCTET STRING
The fields of type RecipientInfo have the following meanings:
タイプRecipientInfoのフィールドには、次の意味があります。
o version is the syntax version number. It shall be 0 for this version of the document.
o versionは構文のバージョン番号です。このバージョンのドキュメントでは0になります。
o issuerAndSerialNumber specifies the recipient's certificate (and thereby the recipient's distinguished name and public key) by issuer distinguished name and issuer-specific serial number.
o issuerAndSerialNumberは、発行者の識別名と発行者固有のシリアル番号によって、受信者の証明書（および受信者の識別名と公開鍵）を指定します。
o keyEncryptionAlgorithm identifies the key-encryption algorithm (and any associated parameters) under which the content-encryption key is encrypted with the recipient's public key. The key-encryption process is described in Section 10.4.
o keyEncryptionAlgorithmは、コンテンツ暗号化キーが受信者の公開キーで暗号化されるキー暗号化アルゴリズム（および関連するパラメーター）を識別します。鍵暗号化プロセスについては、10.4項を参照してください。
o encryptedKey is the result of encrypting the content-encryption key with the recipient's public key (see below).
o encryptedKeyは、コンテンツ暗号化キーを受信者の公開キーで暗号化した結果です（以下を参照）。
The input to the content-encryption process is the "value" of the content being enveloped. Specifically, the input is the contents octets of a definite-length BER encoding of the content field of the ContentInfo value to which the enveloping process is applied. Only the contents octets of the BER encoding are encrypted, not the identifier octets or length octets; those other octets are not represented at all.
コンテンツ暗号化プロセスへの入力は、エンベロープされるコンテンツの「価値」です。具体的には、入力は、エンベロープ処理が適用されるContentInfo値のコンテンツフィールドの固定長BERエンコードのコンテンツオクテットです。暗号化されるのはBERエンコードのコンテンツオクテットのみで、識別子オクテットや長さオクテットは暗号化されません。それらの他のオクテットはまったく表されません。
When the content being enveloped has content type data, then just the value of the data (e.g., the contents of a file) is encrypted. This has the advantage that the length of the content being encrypted need not be known in advance of the encryption process. This method is compatible with Privacy-Enhanced Mail.
エンベロープされるコンテンツにコンテンツタイプのデータがある場合、データの値（たとえば、ファイルのコンテンツ）のみが暗号化されます。これには、暗号化されるコンテンツの長さが暗号化プロセスの前に既知である必要がないという利点があります。この方法は、プライバシー強化メールと互換性があります。
The identifier octets and the length octets are not encrypted. The length octets may be protected implicitly by the encryption process, depending on the encryption algorithm. The identifier octets are not protected at all, although they can be recovered from the content type, assuming that the content type uniquely determines the identifier octets. Explicit protection of the identifier and length octets requires that the signed-and-enveloped-data content type be employed, or that the digested-data and enveloped-data content types be applied in succession.
識別子オクテットと長さオクテットは暗号化されていません。暗号化アルゴリズムによっては、長さのオクテットが暗号化プロセスによって暗黙的に保護される場合があります。識別子オクテットはまったく保護されていませんが、コンテンツタイプが一意に識別子オクテットを決定すると想定して、コンテンツタイプから回復できます。識別子と長さのオクテットを明示的に保護するには、signed-and-enveloped-dataコンテンツタイプを使用するか、digested-dataコンテンツタイプとエンベロープデータタイプのコンテンツタイプを続けて適用する必要があります。
Notes.
ノート。
1. The reason that a definite-length BER encoding is required is that the bit indicating whether the length is definite or indefinite is not recorded anywhere in the enveloped-data content type. Definite-length encoding is more appropriate for simple types such as octet strings, so definite-length encoding is chosen.
1. 明確な長さのBERエンコードが必要な理由は、長さが明確か不明確かを示すビットが、エンベロープデータコンテンツタイプのどこにも記録されていないためです。固定長エンコーディングは、オクテット文字列などの単純なタイプに適しているため、固定長エンコーディングが選択されます。
2. Some content-encryption algorithms assume the input length is a multiple of k octets, where k > 1, and let the application define a method for handling inputs whose lengths are not a multiple of k octets. For such algorithms, the method shall be to pad the input at the trailing end with k - (l mod k) octets all having value k - (l mod k), where l is the length of the input. In other words, the input is padded at the trailing end with one of the following strings:
2. 一部のコンテンツ暗号化アルゴリズムは、入力の長さがkオクテットの倍数であると想定し（k> 1）、アプリケーションに、長さがkオクテットの倍数ではない入力を処理するメソッドを定義させます。このようなアルゴリズムの場合、メソッドは、すべてk-（l mod k）の値を持つk-（l mod k）オクテットで後端の入力をパディングする必要があります。ここで、lは入力の長さです。つまり、入力の末尾に次の文字列のいずれかが埋め込まれます。
01 -- if l mod k = k-1 02 02 -- if l mod k = k-2 . . . k k ... k k -- if l mod k = 0
01-l mod k = k-1の場合02 02-l mod k = k-2の場合。 。 k k ... k k-l mod k = 0の場合
The padding can be removed unambiguously since all input is padded and no padding string is a suffix of another. This padding method is well-defined if and only if k < 256; methods for larger k are an open issue for further study.
すべての入力はパディングされ、パディング文字列は別のサフィックスではないため、パディングは明確に削除できます。このパディング方法は、k <256の場合にのみ明確に定義されます。より大きなkの方法は、今後の検討課題です。
The input to the key-encryption process--the value supplied to the recipient's key-encryption algorithm--is just the "value" of the content-encryption key.
キー暗号化プロセスへの入力（受信者のキー暗号化アルゴリズムに提供される値）は、コンテンツ暗号化キーの単なる「値」です。
This section defines the signed-and-enveloped-data content type. For brevity, much of this section is expressed in terms of material in Sections 9 and 10.
このセクションでは、署名およびエンベロープデータのコンテンツタイプを定義します。簡潔にするために、このセクションの多くはセクション9および10の資料で表現されています。
The signed-and-enveloped-data content type consists of encrypted content of any type, encrypted content-encryption keys for one or more recipients, and doubly encrypted message digests for one or more signers. The "double encryption" consists of an encryption with a signer's private key followed by an encryption with the content-encryption key.
署名およびエンベロープデータコンテンツタイプは、任意のタイプの暗号化されたコンテンツ、1人以上の受信者用の暗号化されたコンテンツ暗号化キー、および1人以上の署名者用の二重に暗号化されたメッセージダイジェストで構成されます。 「二重暗号化」は、署名者の秘密鍵による暗号化と、それに続くコンテンツ暗号化鍵による暗号化で構成されます。
The combination of encrypted content and encrypted content-encryption key for a recipient is a "digital envelope" for that recipient. The recovered singly encrypted message digest for a signer is a "digital signature" on the recovered content for that signer. Any type of content can be enveloped for any number of recipients and signed by any number of signers in parallel.
受信者の暗号化されたコンテンツと暗号化されたコンテンツ暗号化キーの組み合わせは、その受信者の「デジタルエンベロープ」です。署名者の復元された単一暗号化メッセージダイジェストは、その署名者の復元されたコンテンツの「デジタル署名」です。任意のタイプのコンテンツを任意の数の受信者用にエンベロープし、任意の数の署名者が並行して署名できます。
It is expected that the typical application of the signed-and-enveloped-data content type will be to represent one signer's digital signature and one or more recipients' digital envelopes on content of the data content type.
署名およびエンベロープデータコンテンツタイプの一般的な用途は、データコンテンツタイプのコンテンツで1人の署名者のデジタル署名と1人以上の受信者のデジタルエンベロープを表すことです。
The process by which signed-and-enveloped data is constructed involves the following steps:
署名およびエンベロープされたデータが構築されるプロセスには、以下のステップが含まれます。
1. A content-encryption key for a particular content-encryption algorithm is generated at random.
1. 特定のコンテンツ暗号化アルゴリズムのコンテンツ暗号化キーはランダムに生成されます。
2. For each recipient, the content-encryption key is encrypted with the recipient's public key.
2. 受信者ごとに、コンテンツ暗号化キーは受信者の公開キーで暗号化されます。
3. For each recipient, the encrypted content-encryption key and other recipient-specific information are collected into a RecipientInfo value, defined in Section 10.2.
3. 受信者ごとに、暗号化されたコンテンツ暗号化キーとその他の受信者固有の情報が、セクション10.2で定義されているRecipientInfo値に収集されます。
4. For each signer, a message digest is computed on the content with a signer-specific message-digest algorithm. (If two signers employ the same message-digest algorithm, then the message digest need be computed for only one of them.)
4. 署名者ごとに、署名者固有のメッセージダイジェストアルゴリズムを使用して、コンテンツに対してメッセージダイジェストが計算されます。 （2人の署名者が同じメッセージダイジェストアルゴリズムを使用している場合、メッセージダイジェストを計算する必要があるのはそのうちの1人だけです。）
5. For each signer, the message digest and associated information are encrypted with the signer's private key, and the result is encrypted with the content-encryption key. (The second encryption may require that the result of the first encryption be padded to a multiple of some block size; see Section 10.3 for discussion.)
5. 署名者ごとに、メッセージダイジェストと関連情報は署名者の秘密鍵で暗号化され、結果はコンテンツ暗号化鍵で暗号化されます。 （2番目の暗号化では、1番目の暗号化の結果をいくつかのブロックサイズの倍数に埋め込む必要がある場合があります。詳細については、セクション10.3を参照してください。）
6. For each signer, the doubly encrypted message digest and other signer-specific information are collected into a SignerInfo value, defined in Section 9.2.
6. 署名者ごとに、二重に暗号化されたメッセージダイジェストとその他の署名者固有の情報が、セクション9.2で定義されているSignerInfo値に収集されます。
7. The content is encrypted with the content-encryption key. (See Section 10.3 for discussion.)
7. コンテンツはコンテンツ暗号化キーで暗号化されます。 （議論についてはセクション10.3を参照してください。）
8. The message-digest algorithms for all the signers, the SignerInfo values for all the signers and the RecipientInfo values for all the recipients are collected together with the encrypted content into a SignedAndEnvelopedData value, defined in Section 11.1.
8. すべての署名者のメッセージダイジェストアルゴリズム、すべての署名者のSignerInfo値、およびすべての受信者のRecipientInfo値は、暗号化されたコンテンツとともに、セクション11.1で定義されているSignedAndEnvelopedData値に収集されます。
A recipient opens the envelope and verifies the signatures in two steps. First, the one of the encrypted content-encryption keys is decrypted with the recipient's private key, and the encrypted content is decrypted with the recovered content-encryption key. Second, the doubly encrypted message digest for each signer is decrypted with the recovered content-encryption key, the result is decrypted with the signer's public key, and the recovered message digest is compared to an independently computed message digest.
受信者はエンベロープを開き、2つのステップで署名を検証します。最初に、暗号化されたコンテンツ暗号化キーの1つが受信者の秘密キーで復号化され、暗号化されたコンテンツが復元されたコンテンツ暗号化キーで復号化されます。次に、各署名者の二重に暗号化されたメッセージダイジェストが復元されたコンテンツ暗号化キーで復号化され、その結果が署名者の公開キーで復号化され、復元されたメッセージダイジェストが個別に計算されたメッセージダイジェストと比較されます。
Recipient private keys and signer public keys are contained or referenced as discussed in Sections 9 and 10.
セクション9および10で説明されているように、受信者の秘密キーと署名者の公開キーが含まれている、または参照されている。
This section is divided into three parts. The first part describes the top-level type SignedAndEnvelopedData and the second part describes the digest-encryption process. Other types and processes are the same as in Sections 9 and 10. The third part summarizes compatibility with Privacy-Enhanced Mail.
このセクションは3つの部分に分かれています。最初の部分はトップレベルのタイプSignedAndEnvelopedDataを説明し、2番目の部分はダイジェスト暗号化プロセスを説明します。その他のタイプとプロセスは、セクション9および10と同じです。3番目の部分では、プライバシー強化メールとの互換性を要約しています。
Note. The signed-and-enveloped-data content type provides cryptographic enhancements similar to those resulting from the sequential combination of signed-data and enveloped-data content types. However, since the signed-and-enveloped-data content type does not have authenticated or unauthenticated attributes, nor does it provide enveloping of signer information other than the signature, the sequential combination of signed-data and enveloped-data content types is generally preferable to the SignedAndEnvelopedData content type, except when compatibility with the ENCRYPTED process type in Privacy-Enhanced Mail in intended.
注意。署名およびエンベロープデータコンテンツタイプは、署名データコンテンツタイプとエンベロープデータコンテンツタイプの順次的な組み合わせから生じるものと同様の暗号化機能強化を提供します。ただし、signed-and-enveloped-dataコンテンツタイプには、認証または非認証の属性がなく、署名以外の署名者情報のエンベロープも提供されないため、通常は、signed-dataとエンベロープデータのコンテンツタイプの連続した組み合わせが望ましいSignedAndEnvelopedDataコンテンツタイプに変更します。ただし、プライバシーが強化されたメールのENCRYPTEDプロセスタイプとの互換性が意図されている場合を除きます。
The signed-and-enveloped-data content type shall have ASN.1 type SignedAndEnvelopedData:
signed-and-enveloped-dataコンテンツタイプは、ASN.1タイプSignedAndEnvelopedDataを持つ必要があります。
SignedAndEnvelopedData ::= SEQUENCE {
version Version,
recipientInfos RecipientInfos,
digestAlgorithms DigestAlgorithmIdentifiers,
encryptedContentInfo EncryptedContentInfo,
certificates
[0] IMPLICIT ExtendedCertificatesAndCertificates
OPTIONAL,
crls
[1] IMPLICIT CertificateRevocationLists OPTIONAL,
signerInfos SignerInfos }
The fields of type SignedAndEnvelopedData have the following meanings:
タイプSignedAndEnvelopedDataのフィールドには、次の意味があります。
o version is the syntax version number. It shall be 1 for this version of the document.
o versionは構文のバージョン番号です。このバージョンのドキュメントでは1になります。
o recipientInfos is a collection of per-recipient information, as in Section 10. There must be at least one element in the collection.
o recipientInfosは、セクション10と同様に、受信者ごとの情報のコレクションです。コレクションには少なくとも1つの要素が必要です。
o digestAlgorithms is a collection of message-digest algorithm identifiers, as in Section 9. The message-digesting process is the same as in Section 9 in the case when there are no authenticated attributes.
o digestAlgorithmsは、セクション9と同様に、メッセージダイジェストアルゴリズム識別子のコレクションです。メッセージダイジェストプロセスは、認証された属性がない場合のセクション9と同じです。
o encryptedContentInfo is the encrypted content, as in Section 10. It can have any of the defined content types.
o encryptedContentInfoは、セクション10と同様に暗号化されたコンテンツです。定義されたコンテンツタイプのいずれかを持つことができます。
o certificates is a set of PKCS #6 extended certificates and X.509 certificates, as in Section 9.
o 証明書は、セクション9にあるように、PKCS＃6拡張証明書とX.509証明書のセットです。
o crls is a set of certificate-revocation lists, as in Section 9.
o crlsは、セクション9にあるように、証明書失効リストのセットです。
o signerInfos is a collection of per-signer information. There must be at least one element in the collection. SignerInfo values have the same meaning as in Section 9 with the exception of the encryptedDigest field (see below).
o signerInfosは、署名者ごとの情報のコレクションです。コレクションには少なくとも1つの要素が必要です。 SignerInfo値は、encryptedDigestフィールドを除いて、セクション9と同じ意味を持ちます（以下を参照）。
Notes.
ノート。
1. The fact that the recipientInfos and digestAlgorithms fields come before the contentInfo field and the signerInfos field comes after it makes it possible to process a SignedAndEnvelopedData value in a single pass. (Single-pass processing is described in Section 5.)
1. recipientInfosフィールドとdigestAlgorithmsフィールドがcontentInfoフィールドの前にあり、signerInfosフィールドが後にあるという事実により、SignedAndEnvelopedData値を単一のパスで処理することが可能になります。 （シングルパス処理については、セクション5で説明します。）
2. The difference between version 1 SignedAndEnvelopedData and version 0 SignedAndEnvelopedData (defined in PKCS #7, Version 1.4) is that the crls field is allowed in version 1, but not in version 0. Except for the difference in version number, version 0 SignedAndEnvelopedData values are acceptable as version 1 values. An implementation can therefore process SignedAndEnvelopedData values of either version as though they were version 1 values. It is suggested that PKCS implementations generate only version 1 SignedAndEnvelopedData values, but be prepared to process SignedAndEnvelopedData values of either version.
2.バージョン1のSignedAndEnvelopedDataとバージョン0のSignedAndEnvelopedData（PKCS＃7、バージョン1.4で定義）の違いは、バージョン1ではcrlsフィールドが許可されているが、バージョン0では許可されていないことです。バージョン番号、バージョン0の違いを除いて、SignedAndEnvelopedData値はバージョン1の値として受け入れられます。したがって、実装は、どちらかのバージョンのSignedAndEnvelopedData値を、バージョン1の値であるかのように処理できます。 PKCS実装はバージョン1のSignedAndEnvelopedData値のみを生成することをお勧めしますが、いずれかのバージョンのSignedAndEnvelopedData値を処理する準備をする必要があります。
The input to the digest-encryption process is the same as in Section 9, but the process itself is different. Specifically, the process involves two steps. First, the input to the process is supplied to the signer's digest-encryption algorithm, as in Section 9. Second, the result of the first step is encrypted with the content-encryption key. There is no DER encoding between the two steps; the "value" output by the first step is input directly to the second step. (See Section 10.3 for discussion.)
ダイジェスト暗号化プロセスへの入力は、セクション9と同じですが、プロセス自体が異なります。具体的には、プロセスには2つのステップが含まれます。最初に、セクション9のように、プロセスへの入力が署名者のダイジェスト暗号化アルゴリズムに提供されます。次に、最初のステップの結果がコンテンツ暗号化キーで暗号化されます。 2つのステップの間にDERエンコードはありません。最初のステップで出力された「値」は、2番目のステップに直接入力されます。 （議論についてはセクション10.3を参照してください。）
This process is compatible with the ENCRYPTED process type in Privacy-Enhanced Mail.
このプロセスは、プライバシー強化メールのENCRYPTEDプロセスタイプと互換性があります。
Note. The purpose of the second step is to prevent an adversary from recovering the message digest of the content. Otherwise, an adversary would be able to determine which of a list of candidate contents (e.g., "Yes" or "No") is the actual content by comparing the their message digests to the actual message digest.
注意。 2番目のステップの目的は、攻撃者がコンテンツのメッセージダイジェストを回復できないようにすることです。そうでない場合、攻撃者は、メッセージダイジェストを実際のメッセージダイジェストと比較することにより、候補コンテンツのリスト（たとえば、「はい」または「いいえ」）が実際のコンテンツであるかどうかを判別できます。
Compatibility with the ENCRYPTED process type of PEM occurs when the content type of the ContentInfo value being signed and enveloped is data, the message-digest algorithm is md2 or md5, the content-encryption algorithm is DES in CBC mode, the digest-encryption algorithm is PKCS #1's rsaEncryption, and the key-encryption algorithm is PKCS #1's rsaEncryption. Under all those conditions, the doubly encrypted message digest and the encrypted content encryption key match the ones produced in PEM because of reasons similar to those given in Section 9.5, as well as the following:
PEMのENCRYPTEDプロセスタイプとの互換性は、署名およびエンベロープされるContentInfo値のコンテンツタイプがデータ、メッセージダイジェストアルゴリズムがmd2またはmd5、コンテンツ暗号化アルゴリズムがCBCモードのDES、ダイジェスト暗号化アルゴリズムの場合に発生します。 PKCS＃1のrsaEncryptionであり、鍵暗号化アルゴリズムはPKCS＃1のrsaEncryptionです。これらのすべての条件下で、二重に暗号化されたメッセージダイジェストと暗号化されたコンテンツ暗号化キーは、セクション9.5と同様の理由により、PEMで生成されたものと一致します。
1. The value input to the content-encryption algorithm in PEM is the same as in this document. DES in CBC mode is the same as desCBC.
1. PEMのコンテンツ暗号化アルゴリズムに入力される値は、このドキュメントと同じです。 CBCモードのDESは、desCBCと同じです。
2. The value input to the key-encryption algorithm in PEM is the same as in this document (see Section 10.4). RSA public-key encryption in PEM is the same as PKCS #1's rsaEncryption.
2. PEMのキー暗号化アルゴリズムに入力される値は、このドキュメントと同じです（セクション10.4を参照）。 PEMのRSA公開鍵暗号化は、PKCS＃1のrsaEncryptionと同じです。
3. The double-encryption process applied to the message digest in this document and in PEM are the same.
3. このドキュメントとPEMのメッセージダイジェストに適用される二重暗号化プロセスは同じです。
The other parts of the signed-and-enveloped-data content type (certificates, CRLs, algorithm identifiers, etc.) are easily translated to and from their corresponding PEM components. (CRLs are carried in a separate PEM message.)
署名およびエンベロープデータのコンテンツタイプの他の部分（証明書、CRL、アルゴリズム識別子など）は、対応するPEMコンポーネントとの間で簡単に変換されます。 （CRLは別のPEMメッセージで伝達されます。）
The digested-data content type consists of content of any type and a message digest of the content.
ダイジェストデータコンテンツタイプは、任意のタイプのコンテンツとコンテンツのメッセージダイジェストで構成されます。
It is expected that the typical application of the digested-data content type will be to add integrity to content of the data content type, and that the result would become the content input to the enveloped-data content type.
ダイジェストデータコンテンツタイプの一般的な用途は、データコンテンツタイプのコンテンツに整合性を追加することであり、その結果は、エンベロープデータコンテンツタイプへのコンテンツ入力になることが予想されます。
The process by which digested-data is constructed involves the following steps:
ダイジェストデータを構築するプロセスには、次の手順が含まれます。
1. A message digest is computed on the content with a message-digest algorithm.
1. メッセージダイジェストは、メッセージダイジェストアルゴリズムを使用してコンテンツに対して計算されます。
2. The message-digest algorithm and the message digest are collected together with the content into a DigestedData value.
2. メッセージダイジェストアルゴリズムとメッセージダイジェストは、コンテンツとともにDigestedData値に収集されます。
A recipient verifies the message digest by comparing the message digest to an independently computed message digest.
受信者は、メッセージダイジェストを個別に計算されたメッセージダイジェストと比較することにより、メッセージダイジェストを検証します。
The digested-data content type shall have ASN.1 type DigestedData:
ダイジェストデータコンテンツタイプは、ASN.1タイプのDigestedDataを持つ必要があります。
DigestedData ::= SEQUENCE {
version Version,
digestAlgorithm DigestAlgorithmIdentifier,
contentInfo ContentInfo,
digest Digest }
Digest ::= OCTET STRING
The fields of type DigestedData have the following meanings:
タイプDigestedDataのフィールドには次の意味があります。
o version is the syntax version number. It shall be 0 for this version of the document.
o versionは構文のバージョン番号です。このバージョンのドキュメントでは0になります。
o digestAlgorithm identifies the message-digest algorithm (and any associated parameters) under which the content is digested. (The message-digesting process is the same as in Section 9 in the case when there are no authenticated attributes.)
o digestAlgorithmは、コンテンツがダイジェストされるメッセージダイジェストアルゴリズム（および関連するパラメーター）を識別します。 （メッセージダイジェストプロセスは、認証された属性がない場合のセクション9と同じです。）
o contentInfo is the content that is digested. It can have any of the defined content types.
o contentInfoは、ダイジェストされるコンテンツです。定義されたコンテンツタイプのいずれかを持つことができます。
o digest is the result of the message-digesting process.
o ダイジェストは、メッセージダイジェストプロセスの結果です。
Note. The fact that the digestAlgorithm field comes before the contentInfo field and the digest field comes after it makes it possible to process a DigestedData value in a single pass. (Single-pass processing is described in Section 5.)
注意。 digestAlgorithmフィールドがcontentInfoフィールドの前にあり、ダイジェストフィールドが後にあるという事実により、単一のパスでDigestedData値を処理できます。 （シングルパス処理については、セクション5で説明します。）
The encrypted-data content type consists of encrypted content of any type. Unlike the enveloped-data content type, the encrypted-data content type has neither recipients nor encrypted content-encryption keys. Keys are assumed to be managed by other means.
暗号化されたデータのコンテンツタイプは、任意のタイプの暗号化されたコンテンツで構成されます。エンベロープデータコンテンツタイプとは異なり、暗号化データコンテンツタイプには、受信者も暗号化コンテンツ暗号化キーもありません。鍵は他の方法で管理されることを前提としています。
It is expected that the typical application of the encrypted-data content type will be to encrypt content of the data content type for local storage, perhaps where the encryption key is a password.
暗号化データコンテンツタイプの一般的なアプリケーションは、ローカルストレージのデータコンテンツタイプのコンテンツを暗号化することです。
The encrypted-data content type shall have ASN.1 type EncryptedData:
暗号化されたデータのコンテンツタイプは、ASN.1タイプのEncryptedDataを持つ必要があります。
EncryptedData ::= SEQUENCE {
version Version,
encryptedContentInfo EncryptedContentInfo }
The fields of type EncryptedData have the following meanings:
タイプEncryptedDataのフィールドには次の意味があります。
o version is the syntax version number. It shall be 0 for this version of the document.
o versionは構文のバージョン番号です。このバージョンのドキュメントでは0になります。
o encryptedContentInfo is the encrypted content information, as in Section 10.
o encryptedContentInfoは、セクション10と同様に、暗号化されたコンテンツ情報です。
This document defines seven object identifiers: pkcs-7, data, signedData, envelopedData, signedAndEnvelopedData, digestedData, and encryptedData.
このドキュメントでは、7つのオブジェクト識別子（pkcs-7、data、signedData、envelopedData、signedAndEnvelopedData、digestedData、encryptedData）を定義しています。
The object identifier pkcs-7 identifies this document.
オブジェクト識別子pkcs-7はこのドキュメントを識別します。
pkcs-7 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) US(840) rsadsi(113549)
pkcs(1) 7 }
The object identifiers data, signedData, envelopedData, signedAndEnvelopedData, digestedData, and encryptedData, identify, respectively, the data, signed-data, enveloped-data, signed-and-enveloped-data, digested-data, and encrypted-data content types defined in Sections 8-13.
オブジェクト識別子data、signedData、envelopedData、signedAndEnvelopedData、digestedData、およびencryptedDataは、それぞれ、定義されたデータ、signed-data、enveloped-data、signed-and-enveloped-data、digested-data、およびencrypted-dataコンテンツタイプを識別します。セクション8-13。
data OBJECT IDENTIFIER ::= { pkcs-7 1 }
signedData OBJECT IDENTIFIER ::= { pkcs-7 2 }
envelopedData OBJECT IDENTIFIER ::= { pkcs-7 3 }
signedAndEnvelopedData OBJECT IDENTIFIER ::=
{ pkcs-7 4 }
digestedData OBJECT IDENTIFIER ::= { pkcs-7 5 }
encryptedData OBJECT IDENTIFIER ::= { pkcs-7 6 }
These object identifiers are intended to be used in the contentType field of a value of type ContentInfo (see Section 5). The content field of that type, which has the content-type-specific syntax ANY DEFINED BY contentType, would have ASN.1 type Data, SignedData, EnvelopedData, SignedAndEnvelopedData, DigestedData, and EncryptedData, respectively. These object identifiers are also intended to be used in a PKCS #9 content-type attribute.
これらのオブジェクト識別子は、タイプContentInfoの値のcontentTypeフィールドで使用するためのものです（セクション5を参照）。コンテンツタイプ固有の構文ANY DEFINED BY contentTypeを持つそのタイプのコンテンツフィールドは、それぞれASN.1タイプのデータ、SignedData、EnvelopedData、SignedAndEnvelopedData、DigestedData、およびEncryptedDataを持ちます。これらのオブジェクト識別子は、PKCS＃9 content-type属性で使用することも目的としています。
Security Considerations
セキュリティに関する考慮事項
Security issues are discussed throughout this memo.
セキュリティの問題は、このメモ全体で議論されています。
Revision history
改訂履歴
Versions 1.0-1.3
バージョン1.0-1.3
Versions 1.0-1.3 were distributed to participants in RSA Data Security, Inc.'s Public-Key Cryptography Standards meetings in February and March 1991.
バージョン1.0〜1.3は、1991年2月と3月にRSA Data Security、Inc.の公開鍵暗号規格会議の参加者に配布されました。
Version 1.4
バージョン1.4
Version 1.4 is part of the June 3, 1991 initial public release of PKCS. Version 1.4 was published as NIST/OSI Implementors' Workshop document SEC-SIG-91-22.
バージョン1.4は、1991年6月3日のPKCSの最初のパブリックリリースの一部です。バージョン1.4は、NIST / OSI実装者向けワークショップドキュメントSEC-SIG-91-22として公開されました。
Version 1.5
バージョン1.5
Version 1.5 incorporates several editorial changes, including updates to the references and the addition of a revision history. The following substantive changes were made:
バージョン1.5には、参照の更新や改訂履歴の追加など、いくつかの編集上の変更が組み込まれています。次の実質的な変更が行われました。
o Section 6: CertificateRevocationLists type is added.
o セクション6：CertificateRevocationListsタイプが追加されました。
o Section 9.1: SignedData syntax is revised. The new version allows for the dissemination of certificate-revocation lists along with signatures. It also allows for the dissemination of certificates and certificate-revocation lists alone, without any signatures.
o セクション9.1：SignedData構文が改訂されました。新しいバージョンでは、署名と共に証明書失効リストを配布できます。また、署名なしで、証明書と証明書失効リストのみを配布することもできます。
o Section 9.2: SignerInfo syntax is revised. The new version includes a message-digest encryption process compatible with Privacy-Enhanced Mail as specified in RFC 1423.
o セクション9.2：SignerInfo構文が修正されました。新しいバージョンには、RFC 1423で指定されているプライバシー強化メールと互換性のあるメッセージダイジェスト暗号化プロセスが含まれています。
o Section 9.3: Meaning of "the DER encoding of the authenticatedAttributes field" is clarified as "the DER encoding of the Attributes value."
o セクション9.3：「authenticationAttributesフィールドのDERエンコーディング」の意味は、「Attributes値のDERエンコーディング」として明確化されています。
o Section 10.3: Padding method for content-encryption algorithms is described.
o セクション10.3：コンテンツ暗号化アルゴリズムのパディング方法について説明します。
o Section 11.1: SignedAndEnvelopedData syntax is revised. The new version allows for the dissemination of certificate-revocation lists.
o セクション11.1：SignedAndEnvelopedData構文が改訂されました。新しいバージョンでは、証明書失効リストの配布が可能です。
o Section 13: Encrypted-data content type is added. This content type consists of encrypted content of any type.
o セクション13：暗号化されたデータのコンテンツタイプが追加されます。このコンテンツタイプは、任意のタイプの暗号化されたコンテンツで構成されています。
o Section 14: encryptedData object identifier is added.
o セクション14：encryptedDataオブジェクト識別子が追加されました。
Supersedes June 3, 1991 version, which was also published as NIST/OSI Implementors' Workshop document SEC-SIG-91-22.
1991年6月3日バージョンに取って代わり、NIST / OSI Implementors 'WorkshopドキュメントSEC-SIG-91-22としても発行されました。
Acknowledgements
謝辞
This document is based on a contribution of RSA Laboratories, a division of RSA Data Security, Inc. Any substantial use of the text from this document must acknowledge RSA Data Security, Inc. RSA Data Security, Inc. requests that all material mentioning or referencing this document identify this as "RSA Data Security, Inc. PKCS #7".
このドキュメントは、RSA Data Security、Incの一部門であるRSA Laboratoriesの寄稿に基づいています。このドキュメントのテキストを実質的に使用する場合は、RSA Data Security、Inc.に同意する必要があります。RSAData Security、Inc.は、すべての資料について言及または参照することを要求します。このドキュメントでは、これを「RSA Data Security、Inc. PKCS＃7」として識別します。
Author's Address
著者のアドレス
Burt Kaliski RSA Laboratories East 20 Crosby Drive Bedford, MA 01730
Burt Kaliski RSA Laboratories East 20 Crosby Drive Bedford、MA 01730
Phone: (617) 687-7000 EMail: burt@rsa.com
電話：（617）687-7000メール：burt@rsa.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。