RFC2315 日本語訳
2315 PKCS #7: Cryptographic Message Syntax Version 1.5. B. Kaliski. March 1998. (Format: TXT=69679 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group B. Kaliski Request for Comments: 2315 RSA Laboratories, East Category: Informational March 1998
Kaliskiがコメントのために要求するワーキンググループB.をネットワークでつないでください: 2315のRSA研究所、東カテゴリ: 情報の1998年3月
PKCS #7: Cryptographic Message Syntax
Version 1.5
PKCS#7: 暗号のメッセージ構文バージョン1.5
Status of this Memo
この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)インターネット協会(1998)。 All rights reserved。
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.
このドキュメントは暗号をそれに適用するかもしれないデータのために一般的な構文について説明します、デジタル署名やデジタル封筒のように。 構文は再帰を認めます、例えば、別のものの中で1個の封筒を入れ子にすることができるか、または1回のパーティーが何らかの以前におおわれたディジタルデータに署名することができるように。 それは、また、メッセージの内容と共に認証されるべき署名時間などの任意の属性を許容して、署名に関連しているように副署などの他の属性に備えます。 構文の堕落したケースは証明書と証明書失効リストを広めるための手段を提供します。
1. Scope
1. 範囲
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メッセージに変換できるので、Privacyによって高められたメール(PEM)と互換性があります。 同様に署名しているデータと署名していておおわれたデータcontent typeに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.
このドキュメントは証明書を拠点とするかぎ管理のためにさまざまなアーキテクチャをサポートできます、RFC1422のPrivacyによって高められたメールのために提案されたものなどのように。 発行人がどんな証明書のように「トップレベル」であると考えられるかという建築決定であり、証明書発行人が公認するのがどんな実体に認可されるか、そして、どんな分類名が許容できると考えられるか、そして、証明書発行人がどんな方針に従わなければならないかは(安定したハードウェアだけでサインするか、または特定の形式の識別を提示するために実体を必要とすることなどの)ドキュメントの外に残されます。
Kaliski Informational [Page 1] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998
Kaliskiの情報[1ページ]のRFC2315PKCS#7: 1998年のCrytographicメッセージ構文行進
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文字の(言います)ストリングとして八重奏ストリングをコード化するためのメカニズムか八重奏ストリングを再コード化することによって信頼できるトランスミッションを可能にするための他のテクニックを扱いません。 RFC1421は1つの可能なソリューションをこの問題に勧めます。
2. References
2. 参照
FIPS PUB 46-1 National Bureau of Standards. FIPS PUB 46-1:
Data Encryption Standard. January 1988.
FIPSパブ46-1規格基準局。 FIPSパブ46-1: データ暗号化規格。 1988年1月。
PKCS #1 RSA Laboratories. PKCS #1: RSA Encryption.
Version 1.5, November 1993.
PKCS#1RSA研究所。 PKCS#1: RSA暗号化。 1993年11月のバージョン1.5。
PKCS #6 RSA Laboratories. PKCS #6: Extended-Certificate
Syntax. Version 1.5, November 1993.
PKCS#6つのRSA研究所。 PKCS#6: 拡張証明書構文。 1993年11月のバージョン1.5。
PKCS #9 RSA Laboratories. PKCS #9: Selected Attribute
Types. Version 1.1, November 1993.
PKCS#9つのRSA研究所。 PKCS#9: 属性タイプを選びました。 1993年11月のバージョン1.1。
RFC 1421 Linn, J., "Privacy Enhancement for
Internet Electronic Mail: Part I: Message
Encryption and Authentication Procedures," RFC 1421
February 1993.
RFC1421リン、J.、「インターネット電子メールのためのプライバシー増進:」 部分I: RFC1421 1993年2月の「メッセージ暗号化と認証手順」
RFC 1422 Kent, S., "Privacy Enhancement for
Internet Electronic Mail: Part II: Certificate-
Based Key Management," RFC 1422, February 1993.
RFC1422ケント、S.、「インターネット電子メールのためのプライバシー増進:」 パートII: 「証明書のベースのKey Management」、RFC1422、1993年2月。
RFC 1423 Balenson, D., "Privacy Enhancement for
Internet Electronic Mail: Part III: Algorithms,
Modes, and Identifiers," RFC 1423, February 1993.
RFC1423Balenson、D.、「インターネット電子メールのためのプライバシー増進:」 パートIII: 「アルゴリズム、モード、および識別子」、RFC1423、2月1993日
RFC 1424 Kaliski, B., "Privacy Enhancement for
Internet Electronic Mail: Part IV: Key
Certification and Related Services," RFC 1424,
February 1993.
RFC1424Kaliski、B.、「インターネット電子メールのためのプライバシー増進:」 パートIV: 「主要な証明の、そして、関連のサービス」、RFC1424、1993年2月。
Kaliski Informational [Page 2] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998
Kaliskiの情報[2ページ]のRFC2315PKCS#7: 1998年のCrytographicメッセージ構文行進
RFC 1319 Kaliski, B., "The MD2 Message-Digest
Algorithm," RFC 1319, April 1992.
RFC1319Kaliski、B.、「MD2メッセージダイジェストアルゴリズム」、RFC1319、1992年4月。
RFC 1321 Rivest, R., "The MD5 Message-Digest
Algorithm," RFC 1321, April 1992.
RFC1321Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。
X.208 CCITT. Recommendation X.208: Specification of
Abstract Syntax Notation One (ASN.1). 1988.
X.208CCITT。 推薦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.209CCITT。 推薦X.209: 基本的なコード化の仕様は抽象構文記法1(ASN.1)のために統治されます。 1988.
X.500 CCITT. Recommendation X.500: The Directory--
Overview of Concepts, Models and
Services. 1988.
X.500CCITT。 推薦X.500: ディレクトリ--概念の、そして、モデルの、そして、サービスの概要。 1988.
X.501 CCITT. Recommendation X.501: The Directory--
Models. 1988.
X.501CCITT。 推薦X.501: ディレクトリ--モデル。 1988.
X.509 CCITT. Recommendation X.509: The Directory--
Authentication Framework. 1988.
X.509CCITT。 推薦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.Rivest、A.シャミル、およびL.Adleman。 120-126、1978年公開鍵暗号系デジタル署名を得るためのメソッドとACM、21(2)に関するコミュニケーション:2月。
3. Definitions
3. 定義
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で定義されるような抽象的なSyntax Notation One。
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で定義されるような基本的なEncoding Rules。
Kaliski Informational [Page 3] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998
Kaliskiの情報[3ページ]のRFC2315PKCS#7: 1998年のCrytographicメッセージ構文行進
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は発行人によって署名されます。 このドキュメントで意図するタイプは1定義されたRFC1422です。
DER: Distinguished Encoding Rules for ASN.1, as defined in X.509, Section 8.7.
DER: ASN.1のためのX.509、セクション8.7で定義されるような顕著なEncoding Rules。
DES: Data Encryption Standard, as defined in FIPS PUB 46-1.
デス: FIPS PUB46-1で定義されるようなデータEncryption Standard。
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公開鍵証明書の発行人によってまとめて署名された1セットの属性。 このタイプはPKCS#6で定義されます。
MD2: RSA Data Security, Inc.'s MD2 message-digest algorithm, as defined in RFC 1319.
MD2: RFC1319で定義されるようなRSA Data Security Inc.のMD2メッセージダイジェストアルゴリズム。
md2: The object identifier for MD2, as defined in RFC 1319.
md2: MD2のためのRFC1319で定義されるようなオブジェクト識別子。
MD5: RSA Data Security, Inc.'s MD5 message-digest algorithm, as defined in RFC 1321.
MD5: RFC1321で定義されるようなRSA Data Security Inc.のMD5メッセージダイジェストアルゴリズム。
md5: The object identifier for MD5, as defined in RFC 1321.
md5: MD5のためのRFC1321で定義されるようなオブジェクト識別子。
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: RFCs1421-1424で定義されるようなインターネットのPrivacyによって高められたメール。
Kaliski Informational [Page 4] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998
Kaliskiの情報[4ページ]のRFC2315PKCS#7: 1998年のCrytographicメッセージ構文行進
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: RSA暗号化のためのPKCS#1で定義されるようなオブジェクト識別子。
4. Symbols and abbreviations
4. シンボルと略語
No symbols or abbreviations are defined in this document.
どんなシンボルも略語も本書では定義されません。
5. General overview
5. 概要
The following nine sections specify useful types, general syntax, six content types, and object identifiers.
以下の9つのセクションが6つの役に立つタイプ、一般的な構文、content type、およびオブジェクト識別子を指定します。
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.
構文は多くの異なったcontent typeをサポートするほど一般的です。 このドキュメントは6を定義します: データであると署名されるデータは、データをおおって、データに署名して、おおって、データを読みこなして、データを暗号化しました。 他のcontent typeは将来、加えられるかもしれません。 このドキュメントの外で定義されたcontent typeの使用は、可能ですが、内容を交換するパーティーの間の二国間条約を受けることがあります。
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つのクラスのcontent typeがあります: ベースであって高められます。 基底クラスのcontent typeは暗号の増進なしで「まさしくデータ」を含んでいます。 現在、このクラス、データcontent typeには1つのcontent typeがあります。 高められたクラスにおけるcontent typeはタイプ(ことによると暗号化される)、および他の暗号の増進の内容を含んでいます。 例えば、内容が含むことができる(暗号化されます)おおわれたデータは、データが内容であると署名しました。(それは、データ内容を含むことができます)。 4つの非データcontent typeが高められたクラスになります。 その結果、高められたクラスにおけるcontent typeはカプセル化、用語への「外側」の上昇を満足しているのに与えて(増進を含むもの)、および「内側」の内容(高められるもの)を使います。
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を使用することで高められたcontent typeを準備できるように設計されています。 内容がテープに保存されるか、または別のプロセスから「運ばれる」なら、単一のパス操作は特に役立っています。 しかしながら、単一のパス操作の欠点の1つは単一のパスでコード化するDERを出力するのが難しいということです、様々なコンポーネントの長さがあらかじめ知られていないかもしれないので。 そして、署名されて、以来署名しているデータがDERコード化が必要である、-、おおう、データ、および読みこなされたデータcontent type、データ以外のcontent typeがそれらのcontent typeの1つの内側の内容であるときに、付加的なパスが必要であるかもしれません。
Kaliski Informational [Page 5] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998
Kaliskiの情報[5ページ]のRFC2315PKCS#7: 1998年のCrytographicメッセージ構文行進
6. Useful types
6. 役に立つタイプ
This section defines types that are useful in at least two places in the document.
このセクションはドキュメントの少なくとも2つの場所で役に立つタイプを定義します。
6.1 CertificateRevocationLists
6.1 CertificateRevocationLists
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タイプは1セットの証明書取消しリストを与えます。 セットがセットが関連している証明書が「記載されていた状態で、加熱してください」ということであるかどうか決定できるくらいの情報を含むことを意図しますが、必要とするより多くの証明書取消しリストがあるかもしれないか、またはそこでは、必要とするより少ないかもしれません。
CertificateRevocationLists ::=
SET OF CertificateRevocationList
CertificateRevocationLists:、:= CertificateRevocationListのセット
6.2 ContentEncryptionAlgorithmIdentifier
6.2 ContentEncryptionAlgorithmIdentifier
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
ContentEncryptionAlgorithmIdentifier:、:= AlgorithmIdentifier
6.3 DigestAlgorithmIdentifier
6.3 DigestAlgorithmIdentifier
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
DigestAlgorithmIdentifier:、:= AlgorithmIdentifier
6.4 DigestEncryptionAlgorithmIdentifier
6.4 DigestEncryptionAlgorithmIdentifier
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
DigestEncryptionAlgorithmIdentifierタイプはメッセージダイジェストを暗号化できるダイジェスト暗号化アルゴリズムを特定します。 1つの例がPKCS#1rsaEncryptionです。 ダイジェスト暗号化アルゴリズムは暗号化と復号化操作をサポートします。 暗号化操作はダイジェスト暗号化キーのコントロールの下における別の八重奏.bpストリング(暗号化メッセージダイジェスト)に八重奏ストリング(メッセージダイジェスト)を写像します。 復号化操作は逆です。
Kaliski Informational [Page 6] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998
Kaliskiの情報[6ページ]のRFC2315PKCS#7: 1998年のCrytographicメッセージ構文行進
encryption operation. Context determines which operation is intended.
暗号化操作。 文脈は、どの操作が意図するかを決定します。
DigestEncryptionAlgorithmIdentifier ::=
AlgorithmIdentifier
DigestEncryptionAlgorithmIdentifier:、:= AlgorithmIdentifier
6.5 ExtendedCertificateOrCertificate
6.5 ExtendedCertificateOrCertificate
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
ExtendedCertificateOrCertificate:、:= CHOICE、Certificateを証明してください--、X.509
extendedCertificate [0] IMPLICIT ExtendedCertificate }
extendedCertificate[0]の内在しているExtendedCertificate
6.6 ExtendedCertificatesAndCertificates
6.6 ExtendedCertificatesAndCertificates
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タイプは1セットの拡張証明書とX.509証明書を与えます。 セットが認識された「根」か「トップレベル証明権威」からセットが関連している署名者のすべてまでのチェーンを含むように十分であることを意図しますが、必要とするより多くの証明書があるかもしれないか、またはそこでは、必要とするより少ないかもしれません。
ExtendedCertificatesAndCertificates ::=
SET OF ExtendedCertificateOrCertificate
ExtendedCertificatesAndCertificates:、:= 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.
注意します。 このドキュメントの範囲の外に「チェーン」の正確な意味があります。 このドキュメントのいくつかのアプリケーションが最大の限界をチェーンの長さに課すかもしれません。 他のものはチェーンで証明書の対象と発行人とのある関係を実施するかもしれません。 そのような関係に関する例はRFC1422のPrivacyによって高められたメールのために提案されました。
6.7 IssuerAndSerialNumber
6.7 IssuerAndSerialNumber
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 }
IssuerAndSerialNumber:、:= 系列発行人Name、serialNumber CertificateSerialNumber
Kaliski Informational [Page 7] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998
Kaliskiの情報[7ページ]のRFC2315PKCS#7: 1998年のCrytographicメッセージ構文行進
6.8 KeyEncryptionAlgorithmIdentifier
6.8 KeyEncryptionAlgorithmIdentifier
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#1rsaEncryptionです。 主要な暗号化アルゴリズムは暗号化と復号化操作をサポートします。 暗号化操作は主要な暗号化キーのコントロールの下における別の八重奏ストリング(暗号化されたキー)に八重奏ストリング(キー)を写像します。 復号化操作は暗号化操作の逆です。 文脈は、どの操作が意図するかを決定します。
KeyEncryptionAlgorithmIdentifier ::=
AlgorithmIdentifier
KeyEncryptionAlgorithmIdentifier:、:= AlgorithmIdentifier
6.9 Version
6.9 バージョン
The Version type gives a syntax version number, for compatibility with future revisions of this document.
バージョンタイプはこのドキュメントの今後の改正との互換性の構文バージョン番号を与えます。
Version ::= INTEGER
バージョン:、:= 整数
7. General syntax
7. 一般構文
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:
このドキュメントに応じて実体の間で交換された内容のための一般的な構文はcontent typeを内容に関連づけます。 構文で、ASN.1はContentInfoをタイプするものとします:
ContentInfo ::= SEQUENCE {
contentType ContentType,
content
[0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }
ContentInfo:、:= 系列contentType ContentType、内容[0]EXPLICIT ANY DEFINED BY contentType OPTIONAL
ContentType ::= OBJECT IDENTIFIER
ContentType:、:= オブジェクト識別子
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は内容のタイプを示します。 content typeを定義するのは、オブジェクト識別子です。(その識別子はそれが権威によって割り当てられた整数のユニークなストリングであることを意味します)。 このドキュメントは6つのcontent typeを定義します(セクション14を見てください): データ、signedData、envelopedData、signedAndEnvelopedData、digestedData、およびencryptedData。
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 内容は内容です。 分野は任意です、そして、分野が存在していないなら、他の手段で意図している値を供給しなければなりません。 タイプはcontentTypeのためのオブジェクト識別子と共に定義されます。
Kaliski Informational [Page 8] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998
Kaliskiの情報[8ページ]のRFC2315PKCS#7: 1998年のCrytographicメッセージ構文行進
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. 満足している分野の任意の省略で、例えば、署名が適用される内容の変更も模写なしで「外部の署名」を組み立てるのは可能になります。 外部の署名の場合では、署名しているデータcontent typeに値を含んでいる場合、署名される内容はカプセル化された「内側」のContentInfoから省略されるでしょう。
8. Data content type
8. データcontent type
The data content type is just an octet string. It shall have ASN.1 type Data:
データcontent typeはただ八重奏ストリングです。 それで、ASN.1はDataをタイプするものとします:
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).
データcontent typeがASCIIテキスト・ファイルなどの任意の八重奏ストリングについて言及することを意図します。 解釈はアプリケーションに残されます。 そのようなストリングには少しの内部の構造もある必要はない、(そうするかもしれません; それらがDER encodingsでさえあるかもしれない、)
9. Signed-data content type
9. 署名しているデータcontent type
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.
署名しているデータcontent typeはどんなタイプの内容とゼロのための内容の暗号化されたメッセージダイジェストか、より多くの署名者からも成ります。 署名者のための暗号化されたダイジェストはその署名者のための内容の「デジタル署名」です。 平行ないろいろな署名者はどんなタイプの内容にも署名することができます。 その上、構文は署名者が全く内容にない堕落した場合を過します。 堕落したケースは証明書と証明書失効リストを広めるための手段を提供します。
Kaliski Informational [Page 9] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998
Kaliskiの情報[9ページ]のRFC2315PKCS#7: 1998年のCrytographicメッセージ構文行進
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.
署名しているデータcontent typeの主用途がデータcontent typeの内容に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について説明します、そして、第二部は1署名者あたりの情報タイプSignerInfoについて説明します、そして、3番目と4番目の部品はメッセージ読みこなすのとダイジェスト暗号化プロセスについて説明します。 5番目の部分はPrivacyによって高められたメールとの互換性をまとめます。
Kaliski Informational [Page 10] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998
Kaliskiの情報[10ページ]のRFC2315PKCS#7: 1998年のCrytographicメッセージ構文行進
9.1 SignedData type
9.1 SignedDataはタイプします。
The signed-data content type shall have ASN.1 type SignedData:
署名しているデータcontent typeで、ASN.1はSignedDataをタイプするものとします:
SignedData ::= SEQUENCE {
version Version,
digestAlgorithms DigestAlgorithmIdentifiers,
contentInfo ContentInfo,
certificates
[0] IMPLICIT ExtendedCertificatesAndCertificates
OPTIONAL,
crls
[1] IMPLICIT CertificateRevocationLists OPTIONAL,
signerInfos SignerInfos }
SignedData:、:= 系列バージョンバージョン、digestAlgorithms DigestAlgorithmIdentifiers、contentInfo ContentInfo、証明書[0]IMPLICIT ExtendedCertificatesAndCertificates OPTIONAL、crls[1]IMPLICIT CertificateRevocationLists OPTIONAL signerInfos SignerInfos
DigestAlgorithmIdentifiers ::=
DigestAlgorithmIdentifiers:、:=
SET OF DigestAlgorithmIdentifier
DigestAlgorithmIdentifierのセット
SignerInfos ::= SET OF SignerInfo
SignerInfos:、:= 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 バージョンは構文バージョン番号です。 それはドキュメントのこのバージョンのために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はメッセージダイジェストアルゴリズム識別子の収集です。 ゼロを含んでいて、収集におけるいろいろな要素があるかもしれません。 各要素は内容が、ある署名者のために読みこなされるメッセージダイジェストアルゴリズム(そして、どんな関連パラメタも)を特定します。 収集が署名者のすべてによって順不同に使われた、1パスの署名照合を容易にしたメッセージダイジェストアルゴリズムを記載することを意図します。 メッセージを読みこなすプロセスはセクション9.3で説明されます。
o contentInfo is the content that is signed. It can
have any of the defined content types.
o contentInfoは署名される内容です。 それは定義されたcontent typeのいずれも持つことができます。
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
o 証明書は、1セットのPKCS#6通の拡張証明書とX.509証明書です。 セットがsignerInfos分野に認識された「根」か「トップレベル証明権威」から署名者のすべてまでのチェーンを保管するために十分であることを意図します。 必要とするより多くの証明書があるかもしれません、そして、2以上からのチェーンを含むことができるくらいの独立している証明書があるかもしれません。
Kaliski Informational [Page 11] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998
Kaliskiの情報[11ページ]のRFC2315PKCS#7: 1998年のCrytographicメッセージ構文行進
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).
証明当局を先端で平らにしてください。 また、必要とするより少ない証明書があるかもしれません、署名について確かめる人が必要な証明書(例えば、前の1セットの証明書からの)を入手する代替の手段を持っていると予想されるなら。
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は1セットの証明書失効リストです。 セットが中の証明書がさばく証明書が「記載されていた状態で、加熱してください」ということであるかどうか決定できるくらいの情報を含むことを意図しますが、そのような通信は必要ではありません。 必要とするより多くの証明書失効リストがあるかもしれません、そして、また、必要とするより少ない証明書失効リストがあるかもしれません。
o signerInfos is a collection of per-signer
information. There may be any number of elements in the
collection, including zero.
o signerInfosは1署名者あたりの情報の収集です。 ゼロを含んでいて、収集におけるいろいろな要素があるかもしれません。
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値を処理するのは可能になります。 (単一のパス処理はセクション5で説明されます。)
2. The differences between version 1 SignedData and
version 0 SignedData (defined in PKCS #7, Version 1.4) are
the following:
2. バージョン1SignedDataとバージョン0SignedData(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.
バージョン番号の違いを除いて、バージョン1が評価するようにバージョン0SignedData値は許容できます。 したがって、実装はまるでそれらがバージョン1値であるかのようにどちらかのバージョンのSignedData値を処理できます。 PKCS実装が、唯一のバージョン1がSignedData値であると生成することが提案されますが、どちらかのバージョンのSignedData値を処理するように用意してください。
Kaliski Informational [Page 12] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998
Kaliskiの情報[12ページ]のRFC2315PKCS#7: 1998年のCrytographicメッセージ構文行進
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価値のcontent typeがデータと、ContentInfo価値の内容分野であることはその場合お勧めです。省略されます。
9.2 SignerInfo type
9.2 SignerInfoはタイプします。
Per-signer information is represented in the type SignerInfo:
1署名者あたりの情報はタイプSignerInfoで表されます:
SignerInfo ::= SEQUENCE {
version Version,
issuerAndSerialNumber IssuerAndSerialNumber,
digestAlgorithm DigestAlgorithmIdentifier,
authenticatedAttributes
[0] IMPLICIT Attributes OPTIONAL,
digestEncryptionAlgorithm
DigestEncryptionAlgorithmIdentifier,
encryptedDigest EncryptedDigest,
unauthenticatedAttributes
[1] IMPLICIT Attributes OPTIONAL }
SignerInfo:、:= 系列バージョンバージョン、issuerAndSerialNumber IssuerAndSerialNumber、digestAlgorithm DigestAlgorithmIdentifier、authenticatedAttributes[0] IMPLICIT Attributes OPTIONAL、digestEncryptionAlgorithm DigestEncryptionAlgorithmIdentifier、encryptedDigest EncryptedDigest、unauthenticatedAttributes[1]IMPLICIT Attributes OPTIONAL
EncryptedDigest ::= OCTET STRING
EncryptedDigest:、:= 八重奏ストリング
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 バージョンは構文バージョン番号です。 それはドキュメントのこのバージョンのために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 authenticatedAttributesは署名者によって署名される(すなわち、認証されます)1セットの属性です。 分野は任意ですが、署名されるContentInfo価値のcontent typeがデータでないなら存在していなければなりません。 分野が存在しているなら、最小限で2つの属性を含まなければなりません:
Kaliski Informational [Page 13] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998
Kaliskiの情報[13ページ]のRFC2315PKCS#7: 1998年のCrytographicメッセージ構文行進
1. A PKCS #9 content-type attribute having
as its value the content type of the
ContentInfo value being signed.
1. 値として署名されるContentInfo価値のcontent typeがあるPKCS#9content 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は署名者によって署名されない(すなわち、認証されます)1セットの属性です。 分野は任意です。 副署などのようにここで役に立つかもしれない属性タイプは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価値のcontent typeがデータであり、他の認証された属性が全くないときはいつも、authenticatedAttributes分野が省略されることが勧められます。
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. バージョン1SignerInfoとバージョン0SignerInfo(PKCS#7、バージョン1.4では、定義される)の違いがメッセージダイジェスト暗号化プロセスにあります(セクション9.4を見てください)。 Privacyによって高められたメール署名メソッドにおける変化を反映して、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署名メソッドが退行性であるので、PKCS実装がバージョン1SignedData値だけを受けるように準備されることが提案されます。
Kaliski Informational [Page 14] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998
Kaliskiの情報[14ページ]のRFC2315PKCS#7: 1998年のCrytographicメッセージ構文行進
9.3 Message-digesting process
9.3 メッセージを読みこなすプロセス
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分野が存在しているかどうかによります。 分野が欠けているとき、結果はただ内容のメッセージダイジェストです。 しかしながら、分野が存在しているとき、結果はauthenticatedAttributes分野でcontaintedされたAttributes価値の完全なDERコード化のメッセージダイジェストです。 (明快ために: authenticatedAttributes分野のIMPLICIT[0]タグはAttributes価値の一部ではありません。 Attributes値のタグは、SET OFと、IMPLICIT[0]タグについてというよりむしろSET OFタグのDERコード化であり、Attributes価値の長さとコンテンツ八重奏と共に消化されることになっています。) 分野が存在しているとき、Attributes値が属性として内容のcontent typeとメッセージダイジェストを含まなければならないので、それらの値は結果に間接的に含まれています。
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.
署名される内容がcontent typeデータを持って、authenticatedAttributes分野が欠けていると、まさしくデータ(例えば、ファイルのコンテンツ)の値は読みこなされます。 これには、内容の長さが署名される場合暗号化プロセスの前で知られている必要はない利点があります。 このメソッドはPrivacyによって高められたメールと互換性があります。
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つの異なったメッセージも見つけるのにおいて計算上実行不可能な仮定であるので、長さの八重奏はメッセージダイジェストアルゴリズムの本質によって保護されます。 その上、content typeが唯一識別子八重奏を決定すると仮定して、識別子八重奏は2つの方法の1つでそれとなく保護されます: 認証された属性でのcontent typeの包含、またはcontent typeがデータであることを含意するセクション9.4におけるPEMコンパチブル代替手段の使用で。
Kaliski Informational [Page 15] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998
Kaliskiの情報[15ページ]のRFC2315PKCS#7: 1998年のCrytographicメッセージ構文行進
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 encodings以外に、このドキュメントのいくつかの実装がオブジェクトを蓄えるかもしれないと予想されますが、そのような習慣はメッセージダイジェスト計算に影響しません。
9.4 Digest-encryption process
9.4 ダイジェスト暗号化プロセス
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 }
DigestInfo:、:= 系列digestAlgorithm DigestAlgorithmIdentifier、ダイジェスト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#1rsaEncryptionであるなら、これは、RSA係数の長さが少なくとも328ビットである限り、単滑車で入力を暗号化できることを意味します。ビットは、セキュリティ推薦と妥当であって、一致しています。
Kaliski Informational [Page 16] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998
Kaliskiの情報[16ページ]のRFC2315PKCS#7: 1998年のCrytographicメッセージ構文行進
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. メッセージダイジェストアルゴリズム識別子は、1つのメッセージダイジェストアルゴリズムの感染から生じる損害を制限するためにDigestInfo値に含まれています。 例えば、敵が与えられたMD2メッセージダイジェストでメッセージを見つけることができるだろうと仮定してください。 その敵は、署名者が以前に署名したものと同じMD2メッセージダイジェストでメッセージを見つけて、署名として新しいメッセージに前の署名を示すことによって、署名を偽造できるでしょう。 署名者が以前にMD2を使用する場合にだけ、DigestInfo値がメッセージダイジェストアルゴリズムを含んでいるので、この攻撃は成功するでしょうに。 署名者が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値が、ダイジェスト分野がまさしく内容のメッセージダイジェストかauthenticatedAttributes分野の完全なDERコード化のメッセージダイジェストを含むかどうかを示さないという事実のためにあります。 言い換えれば、敵が認証された属性で署名をまさしく内容にauthenticatedAttributes分野のDERコード化になるように内容を変えて、次に、authenticatedAttributes野原を取り除くことによってあるように見えるものに変えるのは、可能です。 (逆の変換は、可能ですが、内容がありそうもない認証された属性価値のDERコード化であることを必要とします。) このあいまいさは新しい問題ではありません、そして、文脈が一般に誤用を防ぐので、それはかなりのものではありません。 本当に、また、敵が証明書か証明書失効リストで署名をまさしく署名しているデータ内容にあるように見えるものに変えるのも、可能です。
9.5 Compatibility with Privacy-Enhanced Mail
9.5 プライバシーで高められたメールとの互換性
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:
署名されるContentInfo価値のcontent typeがデータであるときに、PEMのミックだけとミック-CLEARプロセスタイプとの互換性は起こります、そして、メッセージダイジェストアルゴリズムは、md2かmd5です、そして、属性が認証されないで、ダイジェスト暗号化アルゴリズムはPKCS#1rsaEncryptionです。 それらのすべての条件のもとでは、ここに製作された暗号化メッセージダイジェストが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と同じです。
Kaliski Informational [Page 17] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998
Kaliskiの情報[17ページ]のRFC2315PKCS#7: 1998年のCrytographicメッセージ構文行進
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(RFC1423で指定されるように)にある状態で暗号化された値は本書では属性が認証されない時と同じです。 PEMのRSA秘密鍵暗号化はPKCS#1rsaEncryptionと同じです。
The other parts of the signed-data content type (certificates, CRLs, algorithm identifiers, etc.) are easily translated to and from their corresponding PEM components.
署名しているデータcontent type(証明書、CRLs、アルゴリズム識別子など)の他の部品は部品と、そして、それらの対応するPEMの部品から容易に翻訳されます。
10. Enveloped-data content type
10. おおわれたデータcontent type
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.
おおわれたデータcontent typeは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.
おおわれたデータcontent typeの主用途がデータ、読みこなされたデータ、または署名しているデータcontent typeの内容に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値に集められます。
Kaliski Informational [Page 18] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998
Kaliskiの情報[18ページ]のRFC2315PKCS#7: 1998年のCrytographicメッセージ構文行進
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について説明します、と第二部が説明する、-、受取人情報は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.
このcontent typeはPrivacyによって高められたメールと互換性がありません(それが定義するいくつかのプロセスが彼らのPEM対応者と互換性がありますが)、Privacyによって高められたメールがいつも単独でデジタル署名、決してどんなデジタル封筒にもかかわるというわけではないので。
10.1 EnvelopedData type
10.1 EnvelopedDataはタイプします。
The enveloped-data content type shall have ASN.1 type EnvelopedData:
おおわれたデータcontent typeで、ASN.1はEnvelopedDataをタイプするものとします:
EnvelopedData ::= SEQUENCE {
version Version,
recipientInfos RecipientInfos,
encryptedContentInfo EncryptedContentInfo }
EnvelopedData:、:= 系列バージョンバージョン、recipientInfos RecipientInfos、encryptedContentInfo EncryptedContentInfo
RecipientInfos ::= SET OF RecipientInfo
RecipientInfos:、:= RecipientInfoのセット
EncryptedContentInfo ::= SEQUENCE {
contentType ContentType,
contentEncryptionAlgorithm
ContentEncryptionAlgorithmIdentifier,
encryptedContent
[0] IMPLICIT EncryptedContent OPTIONAL }
EncryptedContentInfo:、:= 系列contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifierの、そして、[0]の内在しているencryptedContent EncryptedContent任意のcontentType ContentType
EncryptedContent ::= OCTET STRING
EncryptedContent:、:= 八重奏ストリング
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 バージョンは構文バージョン番号です。 それはドキュメントのこのバージョンのために0になるでしょう。
o recipientInfos is a collection of per-recipient
information. There must be at least one element in
the collection.
o recipientInfosは1受取人あたりの情報の収集です。 収集には少なくとも1つの要素があるに違いありません。
o encryptedContentInfo is the encrypted content
information.
o encryptedContentInfoは暗号化された満足している情報です。
Kaliski Informational [Page 19] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998
Kaliskiの情報[19ページ]のRFC2315PKCS#7: 1998年のCrytographicメッセージ構文行進
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値を処理するのは可能になります。 (単一のパス処理はセクション5で説明されます。)
10.2 RecipientInfo type
10.2 RecipientInfoはタイプします。
Per-recipient information is represented in the type RecipientInfo:
1受取人あたりの情報はタイプRecipientInfoで表されます:
RecipientInfo ::= SEQUENCE {
version Version,
issuerAndSerialNumber IssuerAndSerialNumber,
keyEncryptionAlgorithm
RecipientInfo:、:= SEQUENCE、バージョンバージョン、issuerAndSerialNumber IssuerAndSerialNumber、keyEncryptionAlgorithm
KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
KeyEncryptionAlgorithmIdentifier、encryptedKey EncryptedKey
EncryptedKey ::= OCTET STRING
EncryptedKey:、:= 八重奏ストリング
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 バージョンは構文バージョン番号です。 それはドキュメントのこのバージョンのために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は発行人分類名と発行人特有の通し番号で、受取人の証明書(そして、その結果、受取人の分類名と公開鍵)を指定します。
Kaliski Informational [Page 20] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998
Kaliskiの情報[20ページ]のRFC2315PKCS#7: 1998年のCrytographicメッセージ構文行進
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は受取人の公開鍵によって主要な満足している暗号化を暗号化するという結果(以下を見る)です。
10.3 Content-encryption process
10.3 満足している暗号化プロセス
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.
おおわれる内容がcontent typeデータを持っていると、まさしくデータ(例えば、ファイルのコンテンツ)の値は暗号化されています。 これには、内容の長さが暗号化される場合暗号化プロセスの前で知られている必要はない利点があります。 このメソッドはPrivacyによって高められたメールと互換性があります。
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.
識別子八重奏と長さの八重奏は暗号化されていません。 暗号化アルゴリズムによって、長さの八重奏は暗号化プロセスによってそれとなく保護されるかもしれません。 識別子八重奏は全く保護されません、content typeをそれらから取り戻すことができますが、content typeが唯一識別子八重奏を決定すると仮定して。 識別子と長さの八重奏の明白な保護は、署名していておおわれたデータcontent typeが使われるか、または読みこなされたデータとおおわれたデータcontent typeが連続していて適用されるのを必要とします。
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コード化が必要である理由は長さが明確であるか、または無期であるかを示すビットがおおわれたデータcontent typeで何処にも記録されないということです。 八重奏ストリングなどの純真なタイプには、明確な長さのコード化が、より適切であるので、明確な長さのコード化は選ばれています。
Kaliski Informational [Page 21] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998
Kaliskiの情報[21ページ]のRFC2315PKCS#7: 1998年のCrytographicメッセージ構文行進
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--値kを持っている(lモッズk)八重奏すべて、--(lモッズk)で入力を水増しするためになるでしょう。そこでは、こと、lは入力の長さです。 言い換えれば、入力は引きずっている終わりに以下のストリングの1つで水増しされます:
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モッズkがk-1 02 02と等しいならlモッズkであるならlモッズk=0であるならk-2…k k…k kと等しいです。
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のためのメソッドはさらなる研究への未解決の問題です。
10.4 Key-encryption process
10.4 主要な暗号化プロセス
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.
主要な暗号化プロセスへの入力(受取人の主要な暗号化アルゴリズムに供給された値)はまさしく満足している暗号化キーの「値」です。
11. Signed-and-enveloped-data content type
11. 署名していておおわれたデータcontent type
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.
このセクションは署名していておおわれたデータcontent typeを定義します。 簡潔さにおいて、このセクションの多くがセクション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.
署名していておおわれたデータcontent typeはどんなタイプの暗号化された内容、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.
暗号化された内容と受取人にとって、主要な暗号化された満足している暗号化の組み合わせはその受取人のための「デジタル封筒」です。 署名者のための回復している単独で暗号化されたメッセージダイジェストはその署名者のための回復している内容の「デジタル署名」です。 どんなタイプの内容もいろいろな受取人のためにおおって、平行ないろいろな署名者で署名することができます。
Kaliski Informational [Page 22] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998
Kaliskiの情報[22ページ]のRFC2315PKCS#7: 1998年のCrytographicメッセージ構文行進
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.
そして、それが予想される、それ、署名することの主用途、-、-おおわれたデータcontent typeはデータ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番目の暗号化は、最初の暗号化の結果が何らかのブロック・サイズの倍数に水増しされるのを必要とするかもしれません; 議論に関してセクション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値に集められます。
Kaliski Informational [Page 23] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998
Kaliskiの情報[23ページ]のRFC2315PKCS#7: 1998年のCrytographicメッセージ構文行進
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つは受取人の秘密鍵で解読されます、そして、暗号化された内容は回復している満足している暗号化キーで解読されます。 2番目に、各署名者のための二倍暗号化されたメッセージダイジェストは回復している満足している暗号化キーで解読されます、そして、結果は署名者の公開鍵で解読されます、そして、回復しているメッセージダイジェストは独自に計算されたメッセージダイジェストにたとえられます。
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について説明します、そして、第二部はダイジェスト暗号化プロセスについて説明します。 他のタイプとプロセスはセクション9と10と同じです。 3番目の部分はPrivacyによって高められたメールとの互換性をまとめます。
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.
注意します。 署名していておおわれたデータcontent typeは署名しているデータとおおわれたデータcontent typeの連続した組み合わせから生じるものと同様の暗号の増進を提供します。 しかしながら、content typeが認証されるか、または非認証されるのをさせない署名していておおわれたデータ属性以来、または、署名以外の署名者情報、署名しているデータの連続した組み合わせをおおうことを提供しません、そして、一般に、おおわれたデータcontent typeはSignedAndEnvelopedData content typeより望ましいです、意図されるところのPrivacyによって高められたメールにおけるENCRYPTEDプロセスタイプとの互換性であるときに時を除いて。
11.1 SignedAndEnvelopedData type
11.1 SignedAndEnvelopedDataはタイプします。
The signed-and-enveloped-data content type shall have ASN.1 type SignedAndEnvelopedData:
署名していておおわれたデータcontent typeで、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 }
SignedAndEnvelopedData:、:= 系列バージョンバージョン、recipientInfos RecipientInfos、digestAlgorithms DigestAlgorithmIdentifiers、encryptedContentInfo EncryptedContentInfo、証明書[0]IMPLICIT ExtendedCertificatesAndCertificates OPTIONAL、crls[1]IMPLICIT CertificateRevocationLists OPTIONAL signerInfos SignerInfos
Kaliski Informational [Page 24] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998
Kaliskiの情報[24ページ]のRFC2315PKCS#7: 1998年のCrytographicメッセージ構文行進
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 バージョンは構文バージョン番号です。 それはドキュメントのこのバージョンのために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受取人あたりの情報の収集です。 収集には少なくとも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のように暗号化された内容です。 それは定義されたcontent typeのいずれも持つことができます。
o certificates is a set of PKCS #6 extended
certificates and X.509 certificates, as in Section
9.
o 証明書は、セクション9のように1セットのPKCS#6通の拡張証明書とX.509証明書です。
o crls is a set of certificate-revocation lists, as
in Section 9.
o crlsはセクション9のように1セットの証明書失効リストです。
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署名者あたりの情報の収集です。 収集には少なくとも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
2. crls分野がバージョン1に許容されているということですが、バージョン0でバージョン1SignedAndEnvelopedDataとバージョン0SignedAndEnvelopedData(PKCS#7、バージョン1.4では、定義される)の違いはことであるというわけではありません。 バージョン番号の違いを除いて、バージョン1が評価するようにバージョン0SignedAndEnvelopedData値は許容できます。 したがって、実装は処理されることができます。
Kaliski Informational [Page 25] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998
Kaliskiの情報[25ページ]のRFC2315PKCS#7: 1998年のCrytographicメッセージ構文行進
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.
どちらかのバージョンのSignedAndEnvelopedData値、まるでそれらがバージョン1値であるかのように。 PKCS実装が、唯一のバージョン1がSignedAndEnvelopedData値であると生成することが提案されますが、どちらかのバージョンのSignedAndEnvelopedData値を処理するように用意してください。
11.2 Digest-encryption process
11.2 ダイジェスト暗号化プロセス
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番目に、第一歩の結果は満足している暗号化キーで暗号化されます。 2つの間でステップをコード化するDERが全くありません。 第一歩によって出力された「値」は直接第2ステップに入力されます。 (議論に関してセクション10.3を見てください。)
This process is compatible with the ENCRYPTED process type in Privacy-Enhanced Mail.
このプロセスはPrivacyによって高められたメールにおいて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ステップの目的は敵が内容のメッセージダイジェストを回復するのを防ぐことです。 さもなければ、敵が、比較することによって候補コンテンツ(例えば、「はい」か「いいえ」)のリストのどれが実際の内容であるかを決定できるだろう、実際のメッセージダイジェストへのそれらのメッセージダイジェスト。
11.3 Compatibility with Privacy-Enhanced Mail
11.3 プライバシーで高められたメールとの互換性
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:
署名されて、おおわれるContentInfo価値のcontent typeがデータであるときに、PEMのENCRYPTEDプロセスタイプとの互換性は起こります、そして、メッセージダイジェストアルゴリズムは、md2かmd5です、そして、CBCモードで内容暗号化アルゴリズムはDESです、そして、ダイジェスト暗号化アルゴリズムはPKCS#1rsaEncryptionです、そして、主要な暗号化アルゴリズムはPKCS#1rsaEncryptionです。 それらのすべての条件のもとでは、二倍暗号化されたメッセージダイジェストと暗号化された満足している暗号化キーはセクション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#1rsaEncryptionと同じです。
Kaliski Informational [Page 26] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998
Kaliskiの情報[26ページ]のRFC2315PKCS#7: 1998年のCrytographicメッセージ構文行進
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.)
署名していておおわれたデータcontent type(証明書、CRLs、アルゴリズム識別子など)の他の部品は部品と、そして、それらの対応するPEMの部品から容易に翻訳されます。 (CRLsは別々のPEMメッセージで運ばれます。)
12. Digested-data content type
12. 読みこなされたデータcontent type
The digested-data content type consists of content of any type and a message digest of the content.
読みこなされたデータcontent typeはどんなタイプの内容と内容のメッセージダイジェストからも成ります。
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.
読みこなされたデータcontent typeの主用途がデータcontent typeの内容への保全を加えることであり、結果がおおわれたデータ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:
読みこなされたデータcontent typeで、ASN.1はDigestedDataをタイプするものとします:
DigestedData ::= SEQUENCE {
version Version,
digestAlgorithm DigestAlgorithmIdentifier,
contentInfo ContentInfo,
digest Digest }
DigestedData:、:= 系列バージョンバージョン、digestAlgorithm DigestAlgorithmIdentifier、contentInfo ContentInfoは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 バージョンは構文バージョン番号です。 それはドキュメントのこのバージョンのために0になるでしょう。
Kaliski Informational [Page 27] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998
Kaliskiの情報[27ページ]のRFC2315PKCS#7: 1998年のCrytographicメッセージ構文行進
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は読みこなされる内容です。 それは定義されたcontent typeのいずれも持つことができます。
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で説明されます。)
13. Encrypted-data content type
13. 暗号化されたデータcontent type
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.
暗号化されたデータcontent typeはどんなタイプの暗号化された内容からも成ります。 おおわれたデータcontent typeと異なって、暗号化されたデータcontent typeは受取人も暗号化された満足している暗号化キーも持っていません。 他の手段でキーが管理されると思われます。
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.
暗号化されたデータcontent typeの主用途が地方のストレージのためにデータcontent typeの内容を暗号化することであると予想されます、恐らく暗号化キーがパスワードであるところで。
The encrypted-data content type shall have ASN.1 type EncryptedData:
暗号化されたデータcontent typeで、ASN.1はEncryptedDataをタイプするものとします:
EncryptedData ::= SEQUENCE {
version Version,
encryptedContentInfo EncryptedContentInfo }
EncryptedData:、:= 系列バージョンバージョン、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 バージョンは構文バージョン番号です。 それはドキュメントのこのバージョンのために0になるでしょう。
o encryptedContentInfo is the encrypted content
information, as in Section 10.
o encryptedContentInfoはセクション10のように暗号化された満足している情報です。
14. Object identifiers
14. オブジェクト識別子
This document defines seven object identifiers: pkcs-7, data, signedData, envelopedData, signedAndEnvelopedData, digestedData, and encryptedData.
このドキュメントは7つのオブジェクト識別子を定義します: pkcs-7、データ、signedData、envelopedData、signedAndEnvelopedData、digestedData、およびencryptedData。
Kaliski Informational [Page 28] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998
Kaliskiの情報[28ページ]のRFC2315PKCS#7: 1998年のCrytographicメッセージ構文行進
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 }
pkcs-7 OBJECT IDENTIFIER:、:= iso(1)は(2) 米国(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.
そして、オブジェクト識別子データ、signedData、envelopedData、signedAndEnvelopedData、digestedData、encryptedData、それぞれ署名しているデータであって、おおわれたデータであって、署名しているデータを特定してください、-、-おおわれたデータ、読みこなされたデータ、および暗号化されたデータcontent typeは中でセクション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 }
データ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を見てください)。 ASN.1はそのタイプの満足している分野でそれぞれData、SignedData、EnvelopedData、SignedAndEnvelopedData、DigestedData、およびEncryptedDataをタイプするでしょう。(タイプは満足しているタイプ詳細構文いずれもDEFINED BY contentTypeを持っています)。 また、PKCS#9content 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は2月のRSA Data Security Inc.の公開鍵暗号化標準ミーティングと1991年3月に関係者に分配されました。
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はPKCSの1991年6月3日の初期の公共のリリースの一部です。 NIST/OSI ImplementorsのWorkshopがSEC SIG91-22を記録するとき、バージョン1.4は発行されました。
Kaliski Informational [Page 29] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998
Kaliskiの情報[29ページ]のRFC2315PKCS#7: 1998年のCrytographicメッセージ構文行進
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構文は改訂されています。 新しいバージョンはRFC1423の指定されるとしてのPrivacyによって高められたメールとのコンパチブルメッセージダイジェスト暗号化プロセスを含んでいます。
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: 「authenticatedAttributes分野の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: 暗号化されたデータcontent typeは加えられます。 このcontent typeはどんなタイプの暗号化された内容からも成ります。
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 SIG91-22を記録するとき、それは、発行されました)。
Kaliski Informational [Page 30] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998
Kaliskiの情報[30ページ]のRFC2315PKCS#7: 1998年のCrytographicメッセージ構文行進
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研究所の貢献に基づいています、とこのドキュメント必須からのテキストのRSA Data SecurityのInc.のAnyのかなりの使用の分割がこのドキュメントに言及するか、または参照をつけるすべての材料がこれを特定するというRSA Data Security Inc.RSA Data Security Inc.要求を承諾する、「RSA Data Security、Inc.PKCS#7インチ」
Author's Address
作者のアドレス
Burt Kaliski RSA Laboratories East 20 Crosby Drive Bedford, MA 01730
バートKaliski RSA研究所東20のクロズビー・Driveベッドフォード、MA 01730
Phone: (617) 687-7000 EMail: burt@rsa.com
以下に電話をしてください。 (617) 687-7000 メールしてください: burt@rsa.com
Kaliski Informational [Page 31] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998
Kaliskiの情報[31ページ]のRFC2315PKCS#7: 1998年のCrytographicメッセージ構文行進
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Kaliski Informational [Page 32]
Kaliski情報です。[32ページ]
一覧
スポンサーリンク
