[要約] RFC 7191は、Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Typesに関する文書です。このRFCの目的は、鍵パッケージの受領確認とエラー報告のためのフォーマットを定義することにあります。これにより、鍵の配布や管理のプロセスがより信頼性と透明性を持ち、効率的に行われるようになります。利用場面としては、セキュリティが重要視される通信での鍵の交換や更新時にこのフォーマットが使用されます。関連するRFCには、CMSを定義するRFC 5652や、他の鍵管理関連のRFCがあります。
Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 7191 Vigil Security
Category: Standards Track April 2014
ISSN: 2070-1721
Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types
暗号化メッセージ構文（CMS）キーパッケージの受信とエラーコンテンツタイプ
Abstract
概要
This document defines the syntax for two Cryptographic Message Syntax (CMS) content types: one for key package receipts and another for key package errors. The key package receipt content type is used to confirm receipt of an identified key package or collection of key packages. The key package error content type is used to indicate an error occurred during the processing of a key package. CMS can be used to digitally sign, digest, authenticate, or encrypt these content types.
このドキュメントでは、2つの暗号化メッセージ構文（CMS）コンテンツタイプの構文を定義します。1つはキーパッケージの受信用、もう1つはキーパッケージのエラー用です。キーパッケージの受信コンテンツタイプは、識別されたキーパッケージまたはキーパッケージのコレクションの受信を確認するために使用されます。キーパッケージのエラーコンテンツタイプは、キーパッケージの処理中に発生したエラーを示すために使用されます。 CMSは、これらのコンテンツタイプのデジタル署名、ダイジェスト、認証、または暗号化に使用できます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7191.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7191で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Requirements Terminology ...................................2
1.2. ASN.1 Syntax Notation ......................................2
1.3. Processing Key Package Receipt Requests ....................3
1.4. Processing Key Packages with Errors ........................3
2. SIR Entity Name .................................................3
3. Key Package Identifier and Receipt Request Attribute ............4
4. Key Package Receipt CMS Content Type ............................6
5. Key Package Error CMS Content Type ..............................8
6. Protecting the KeyPackageReceipt and KeyPackageError ...........17
7. Using the application/cms Media Type ...........................17
8. IANA Considerations ............................................17
9. Security Considerations ........................................17
10. Acknowledgements ..............................................18
11. References ....................................................18
11.1. Normative References .....................................18
11.2. Informative References ...................................20
Appendix A. ASN.1 Module ..........................................21
This document defines the syntax for two Cryptographic Message Syntax (CMS) [RFC5652] content types: one for key package receipts and another for key package errors. The key package receipt content type is used to confirm receipt of an identified key package or collection of key packages. The key package error content type is used to indicate an error occurred during the processing of a key package. CMS can be used to digitally sign, digest, authenticate, or encrypt these content types.
このドキュメントでは、2つの暗号化メッセージ構文（CMS）[RFC5652]コンテンツタイプの構文を定義します。1つはキーパッケージの受信用、もう1つはキーパッケージのエラー用です。キーパッケージの受信コンテンツタイプは、識別されたキーパッケージまたはキーパッケージのコレクションの受信を確認するために使用されます。キーパッケージのエラーコンテンツタイプは、キーパッケージの処理中に発生したエラーを示すために使用されます。 CMSは、これらのコンテンツタイプのデジタル署名、ダイジェスト、認証、または暗号化に使用できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The content types defined herein use ASN.1 ([X.680], [X.681], [X.682], and [X.683]).
ここで定義されているコンテンツタイプは、ASN.1（[X.680]、[X.681]、[X.682]、および[X.683]）を使用します。
The CONTENT-TYPE definition was updated to the 2008 version of ASN.1 by [RFC6268]; however, none of the new 2008 ASN.1 tokens are used in this specification, which allows compilers that only support the 2002 version of ASN.1 to compile the module in Appendix A.
CONTENT-TYPE定義は、[RFC6268]によって2008バージョンのASN.1に更新されました。ただし、この仕様では新しい2008 ASN.1トークンは使用されないため、ASN.1の2002バージョンのみをサポートするコンパイラは、付録Aのモジュールをコンパイルできます。
The key package or collection of key packages [RFC4073] [RFC5958] [RFC6031] [RFC6032] for which the receipt is being generated MUST be signed, and the key package MUST include the key-package-identifier-and-receipt-request attribute specified in Section 3.
キーパッケージまたはキーパッケージのコレクション[RFC4073] [RFC5958] [RFC6031] [RFC6032]のレシートが生成されている必要があり、キーパッケージにはkey-package-identifier-and-receipt-request属性が含まれている必要がありますセクション3で指定。
The key package or collection of key packages [RFC4073] [RFC5958] [RFC6031] [RFC6032] for which the error is being generated might be signed. The key package can be identified by a key-package-identifier-and-receipt-request attribute specified in Section 3.
エラーが生成されているキーパッケージまたはキーパッケージのコレクション[RFC4073] [RFC5958] [RFC6031] [RFC6032]は署名されている可能性があります。鍵パッケージは、セクション3で指定されたkey-package-identifier-and-receipt-request属性によって識別できます。
Within a key distribution system, the source, intermediary, and receiver entities are identified by a Source Intermediary Recipient (SIR) entity name. The syntax for the SIR entity name does not impose any particular structure, and it accommodates straightforward registration of additional SIR entity name types.
鍵配布システム内では、ソース、中間、および受信者エンティティは、ソース中間受信者（SIR）エンティティ名によって識別されます。 SIRエンティティ名の構文は、特定の構造を課すものではなく、追加のSIRエンティティ名タイプの簡単な登録に対応しています。
The inclusion of the nameType object identifier ensures that two identifiers of different types that happen to contain the same values are not interpreted as equivalent. Additional SIR entity name types are expected to be registered that represent different granularities. For example, one SIR entity name type might represent the receiver organization, and at a finer granularity, another SIR entity name type might identify a specific device, perhaps using a manufacturer identifier and serial number. The use of an object identifier avoids the need for a central registry of SIR entity name types.
nameTypeオブジェクト識別子を含めることにより、たまたま同じ値を含む異なるタイプの2つの識別子が同等のものとして解釈されないようにします。異なる粒度を表す追加のSIRエンティティ名タイプが登録されることが期待されます。たとえば、1つのSIRエンティティ名タイプは受信側の組織を表し、より細かい粒度で、別のSIRエンティティ名タイプは、おそらく製造元の識別子とシリアル番号を使用して、特定のデバイスを識別することができます。オブジェクト識別子を使用すると、SIRエンティティ名タイプの中央レジストリの必要がなくなります。
The nameValue is an OCTET STRING, which allows the canonical form of any name to be carried. Two names of the same type are considered equal if the octet strings are the same length and contain the same string of octets.
nameValueはOCTET STRINGであり、これにより任意の名前の正規形を運ぶことができます。同じタイプの2つの名前は、オクテット文字列が同じ長さで、同じオクテット文字列を含む場合、等しいと見なされます。
SIREntityNames and SIREntityName have the following syntax:
SIREntityNamesおよびSIREntityNameの構文は次のとおりです。
SIREntityNames ::= SEQUENCE SIZE (1..MAX) OF SIREntityName
SIR-ENTITY-NAME ::= CLASS {
&sIRENType OBJECT IDENTIFIER UNIQUE,
&SIRENValue
} WITH SYNTAX {
SYNTAX &SIRENValue IDENTIFIED BY &sIRENType }
SIREntityName ::= SEQUENCE {
sirenType SIR-ENTITY-NAME.&sIRENType({SIREntityNameTypes}),
sirenValue OCTET STRING (CONTAINING
SIR-ENTITY-NAME.&SIRENValue(
{SIREntityNameTypes}{@sirenType}) ) }
This document defines one SIR entity name type: the DN type. The DN type uses a nameType of id-dn and a nameValue of a Distinguished Name (DN). The nameValue OCTET STRING carries an ASN.1 encoded Name as specified in [RFC5280]. Note that other documents may define additional types.
このドキュメントでは、DNタイプという1つのSIRエンティティ名タイプを定義しています。 DNタイプは、id-dnのnameTypeと識別名（DN）のnameValueを使用します。 nameValue OCTET STRINGは、[RFC5280]で指定されているASN.1エンコードされた名前を保持します。他のドキュメントでは追加のタイプが定義されている場合があることに注意してください。
SIREntityNameTypes SIR-ENTITY-NAME ::= {
siren-dn,
... -- Expect additional SIR Entity Name types -- }
siren-dn SIR-ENTITY-NAME ::= {
SYNTAX DistinguishedName
IDENTIFIED BY id-dn }
id-dn OBJECT IDENTIFIER ::= {
joint-iso-ccitt(2) country(16) us(840) organization(1)
gov(101) dod(2) infosec(1) sir-name-types(16) 0 }
The key-package-identifier-and-receipt-request attribute, as its name implies, allows the originator to identify the key package and, optionally, request receipts. This attribute can appear as a signed, authenticated, and content attribute. Signed attributes are carried in the CMS Signed-data content type described in Section 5 of [RFC5652]. Authenticated attributes are carried in the CMS Authenticated-data content type described in Section 9 of [RFC5652] or in the CMS Authenticated-enveloped-data content type described in Section 2 of [RFC5083]. Content attributes are carried in the Content-with-attributes content type described in Section 3 of [RFC4073].
key-package-identifier-and-receipt-request属性は、その名前が示すように、発信者がキーパッケージを識別し、オプションで領収書を要求できるようにします。この属性は、署名済み、認証済み、およびコンテンツの属性として表示できます。署名付き属性は、[RFC5652]のセクション5で説明されているCMS署名付きデータコンテンツタイプで伝達されます。認証済みの属性は、[RFC5652]のセクション9で説明されているCMS Authenticated-dataコンテンツタイプ、または[RFC5083]のセクション2で説明されているCMS Authenticated-enveloped-dataコンテンツタイプで伝達されます。コンテンツ属性は、[RFC4073]のセクション3で説明されているContent-with-attributesコンテンツタイプで伝達されます。
The key-package-identifier-and-receipt-request attribute has the following syntax:
key-package-identifier-and-receipt-request属性の構文は次のとおりです。
aa-keyPackageIdentifierAndReceiptRequest ATTRIBUTE ::= {
TYPE KeyPkgIdentifierAndReceiptReq
IDENTIFIED BY id-aa-KP-keyPkgIdAndReceiptReq }
id-aa-KP-keyPkgIdAndReceiptReq OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1)
gov(101) dod(2) infosec(1) attributes(5) 65 }
KeyPkgIdentifierAndReceiptReq ::= SEQUENCE {
pkgID KeyPkgID,
receiptReq KeyPkgReceiptReq OPTIONAL }
KeyPkgID ::= OCTET STRING
KeyPkgReceiptReq ::= SEQUENCE {
encryptReceipt BOOLEAN DEFAULT FALSE,
receiptsFrom [0] SIREntityNames OPTIONAL,
receiptsTo SIREntityNames }
Even though the ATTRIBUTE syntax is defined as a SET OF AttributeValue, a key-package-identifier-and-receipt-request attribute MUST have a single attribute value; zero or multiple instances of AttributeValue are not permitted.
ATTRIBUTE構文はSET OF AttributeValueとして定義されていますが、key-package-identifier-and-receipt-request属性は単一の属性値を持つ必要があります。ゼロまたは複数のAttributeValueのインスタンスは許可されていません。
The fields in the key-package-identifier-and-receipt-request attribute have the following semantics:
key-package-identifier-and-receipt-request属性のフィールドには、次のセマンティクスがあります。
o pkgID contains an octet string, and this syntax does not impose any particular structure on the identifier.
o pkgIDにはオクテット文字列が含まれており、この構文は識別子に特定の構造を課しません。
o receiptReq is OPTIONAL, and when it is present, it includes an encryption receipt flag, an OPTIONAL indication of which receivers should generate receipts, and an indication of where the receipts are to be sent.
o receiveReqはオプションであり、存在する場合は、暗号化受信フラグ、どの受信者が受信を生成するかを示すオプションの指示、および受信の送信先の指示が含まれます。
* The encryption receipt flag indicates whether the key package originator wants the receipt to be encrypted. If the boolean is set, then the receipt SHOULD be encrypted.
* 暗号化レシートフラグは、キーパッケージの作成者がレシートの暗号化を希望するかどうかを示します。ブール値が設定されている場合は、レシートを暗号化する必要があります（SHOULD）。
* The OPTIONAL ReceiptsFrom field provides an indication of which receivers SHOULD generate receipts. When the ReceiptsFrom field is absent, all receivers of the key package are expected to return receipts. When the ReceiptsFrom field is present, a list of SIR entity names indicates which receivers of the key package are requested to return receipts.
* OPTIONAL ReceiptsFromフィールドは、どの受信者が受信を生成する必要があるかを示します。 ReceiptsFromフィールドが存在しない場合、キーパッケージのすべての受信者が領収書を返すことが期待されます。 ReceiptsFromフィールドが存在する場合、SIRエンティティ名のリストは、キーパッケージのどの受信者が領収書を返すように要求されているかを示します。
In this case, the receiver SHOULD return a receipt only if their SIR entity name appears on the list.
この場合、受信者は、SIRエンティティ名がリストに表示されている場合にのみ、領収書を返す必要があります（SHOULD）。
* The receipt request does not include any key management information; however, the list of SIR entity names in the receiptsTo field can be used to select symmetric or asymmetric keying material for the receipt receivers.
* 受領要求には、鍵管理情報は含まれていません。ただし、receiptsToフィールドのSIRエンティティ名のリストを使用して、レシートレシーバーの対称または非対称キーイングマテリアルを選択できます。
A receiver SHOULD ignore the nameValue associated with any unrecognized nameType in either the receiptsFrom field or the receiptsTo field.
受信者は、receiptsFromフィールドまたはReceimentsToフィールドのいずれかで認識されないnameTypeに関連付けられたnameValueを無視する必要があります（SHOULD）。
When the key-package-identifier-and-receipt-request attribute appears in more than one location in the overall key package, each occurrence is evaluated independently. That is, the receiver may generate more than one receipt for a single key package. However, the time at which the receipts are sent will depend on policies that are beyond the scope of this document.
key-package-identifier-and-receipt-request属性がキーパッケージ全体の複数の場所にある場合、各オカレンスは個別に評価されます。つまり、受信者は、単一のキーパッケージに対して複数のレシートを生成できます。ただし、レシートが送信される時間は、このドキュメントの範囲外のポリシーによって異なります。
The key package receipt content type is used to confirm receipt of an identified key package or collection of key packages. This content type MUST be encoded using the Distinguished Encoding Rules (DER) [X.690].
キーパッケージの受信コンテンツタイプは、識別されたキーパッケージまたはキーパッケージのコレクションの受信を確認するために使用されます。このコンテンツタイプは、Distinguished Encoding Rules（DER）[X.690]を使用してエンコードする必要があります。
The key package receipt content type has the following syntax:
主要なパッケージ受領コンテンツタイプの構文は次のとおりです。
ct-key-package-receipt CONTENT-TYPE ::= {
TYPE KeyPackageReceipt
IDENTIFIED BY id-ct-KP-keyPackageReceipt }
id-ct-KP-keyPackageReceipt OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1)
gov(101) dod(2) infosec(1) formats(2)
key-package-content-types(78) 3 }
KeyPackageReceipt ::= SEQUENCE {
version KeyPkgVersion DEFAULT v2,
receiptOf KeyPkgIdentifier,
receivedBy SIREntityName }
-- Revised definition of KeyPkgVersion from [RFC6031]
KeyPkgVersion ::= INTEGER { v1(1), v2(2) } (1 .. 65535)
KeyPkgIdentifier ::= CHOICE {
pkgID KeyPkgID,
attribute SingleAttribute {{ KeyPkgIdentifiers }} }
KeyPkgID ::= OCTET STRING
KeyPkgIdentifiers ATTRIBUTE ::= { ... }
The KeyPackageReceipt fields are used as follows:
KeyPackageReceiptフィールドは次のように使用されます。
o version identifies version of the key package receipt content. For this version of the specification, the default value, v2, MUST be used. Note that v1 was defined in an earlier version, but the use of v1 is deprecated.
o versionは、主要なパッケージ受領コンテンツのバージョンを識別します。このバージョンの仕様では、デフォルト値のv2を使用する必要があります。 v1は以前のバージョンで定義されていましたが、v1の使用は推奨されていません。
o receiptOf offers two alternatives for identifying the key package for which the receipt is being generated. The first alternative, pkgID, MUST be supported, and pkgID provides the key package identifier of the key package or collection of key packages for which this receipt is being generated. This key package identifier value MUST exactly match the key package identifier value of the key-package-identifier-and-receipt-request attribute in the received key package or collection. The key-package-identifier-and-receipt-request attribute is described Section 3. The second alternative allows alternate attributes to be used to define the identifier.
o receiveOfは、レシートが生成される対象のキーパッケージを識別するための2つの選択肢を提供します。最初の代替であるpkgIDはサポートされなければなりません（MUST）。pkgIDは、この領収書が生成される対象のキーパッケージまたはキーパッケージのコレクションのキーパッケージ識別子を提供します。このキーパッケージ識別子の値は、受信したキーパッケージまたはコレクションのkey-package-identifier-and-receipt-request属性のキーパッケージ識別子の値と正確に一致する必要があります。 key-package-identifier-and-receipt-request属性については、セクション3で説明します。2番目の代替方法では、代替属性を使用して識別子を定義できます。
o receivedBy identifies the entity that received the key package. The entity is named by an SIR entity name as specified in Section 2.
o receivedByは、鍵パッケージを受け取ったエンティティーを識別します。エンティティは、セクション2で指定されているSIRエンティティ名で命名されます。
Key package receipts MUST be encapsulated in a CMS SignedData content type to carry the signature of the entity that is confirming receipt of the identified key package or collection of key packages. Key package receipts MAY be encrypted by encapsulating them in the CMS EncryptedData content type, the CMS EnvelopedData content type, or the AuthEnvelopedData content type. When the key package receipt is signed and encrypted, it MUST be signed prior to being encrypted.
識別されたキーパッケージまたはキーパッケージのコレクションの受信を確認するエンティティの署名を運ぶには、キーパッケージの受信をCMS SignedDataコンテンツタイプにカプセル化する必要があります。キーパッケージの領収書は、CMS EncryptedDataコンテンツタイプ、CMS EnvelopedDataコンテンツタイプ、またはAuthEnvelopedDataコンテンツタイプでカプセル化することにより暗号化できます。鍵パッケージの受領書が署名および暗号化されている場合は、暗号化する前に署名する必要があります。
Note that delivery assurance is the responsibility of the protocol that is used to transport and track key packages. The key package receipt content type can be used in conjunction with that protocol as part of an overall delivery assurance solution.
配信保証は、主要なパッケージの転送と追跡に使用されるプロトコルの責任であることに注意してください。主要なパッケージ受領コンテンツタイプは、そのプロトコルと組み合わせて、全体的な配信保証ソリューションの一部として使用できます。
Because the receipts are signed, all recipients that generate key package receipts MUST have a private signature key to sign the receipt as well as store their own certificate or have a means of obtaining the key identifier of their public key. If memory is a concern, the public key identifier can be computed from the public key.
領収書は署名されているため、鍵パッケージの領収書を生成するすべての受信者は、領収書に署名するための秘密署名鍵を持ち、独自の証明書を格納するか、公開鍵の鍵識別子を取得する手段を持っている必要があります。メモリが問題になる場合は、公開鍵から公開鍵識別子を計算できます。
If the receipt signer has access to a real-time clock, then the binary-signing-time [RFC6019] signed attribute SHOULD be included in the key package receipt to provide the date and time when it was generated.
レシート署名者がリアルタイムクロックにアクセスできる場合、バイナリ署名時間[RFC6019]の署名済み属性をキーパッケージレシートに含めて、生成された日時を提供する必要があります（SHOULD）。
The key package error content type provides an indication of the reason for rejection of a key package or collection of key packages. This content type MUST be encoded using the Distinguished Encoding Rules (DER) [X.690].
キーパッケージのエラーコンテンツタイプは、キーパッケージの拒否またはキーパッケージのコレクションの理由を示します。このコンテンツタイプは、Distinguished Encoding Rules（DER）[X.690]を使用してエンコードする必要があります。
The key package error content type has the following syntax:
キーパッケージのエラーコンテンツタイプの構文は次のとおりです。
ct-key-package-error CONTENT-TYPE ::= {
TYPE KeyPackageError IDENTIFIED BY id-ct-KP-keyPackageError }
id-ct-KP-keyPackageError OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1)
gov(101) dod(2) infosec(1) formats(2)
key-package-content-types(78) 6 }
KeyPackageError ::= SEQUENCE {
version KeyPkgVersion DEFAULT v2,
errorOf [0] KeyPkgIdentifier OPTIONAL,
errorBy SIREntityName,
errorCode ErrorCodeChoice }
KeyPkgVersion ::= INTEGER { v1(1), v2(2) } (1 .. 65535)
KeyPkgIdentifier ::= CHOICE {
pkgID KeyPkgID,
attribute SingleAttribute {{ KeyPkgIdentifiers }} }
KeyPkgID ::= OCTET STRING
KeyPkgIdentifiers ATTRIBUTE ::= { ... }
ErrorCodeChoice ::= CHOICE {
enum EnumeratedErrorCode,
oid OBJECT IDENTIFIER }
EnumeratedErrorCode ::= ENUMERATED {
decodeFailure (1),
badContentInfo (2),
badSignedData (3),
badEncapContent (4),
badCertificate (5),
badSignerInfo (6),
badSignedAttrs (7),
badUnsignedAttrs (8),
missingContent (9),
noTrustAnchor (10),
notAuthorized (11),
badDigestAlgorithm (12),
badSignatureAlgorithm (13),
unsupportedKeySize (14),
unsupportedParameters (15),
signatureFailure (16),
insufficientMemory (17),
incorrectTarget (23),
missingSignature (29),
resourcesBusy (30),
versionNumberMismatch (31),
revokedCertificate (33),
-- Error codes with values <= 33 are aligned with [RFC5934]
-値が33以下のエラーコードは[RFC5934]に揃えられます
ambiguousDecrypt (60), noDecryptKey (61), badEncryptedData (62), badEnvelopedData (63), badAuthenticatedData (64), badAuthEnvelopedData (65), badKeyAgreeRecipientInfo (66), badKEKRecipientInfo (67), badEncryptContent (68), badEncryptAlgorithm (69), missingCiphertext (70), decryptFailure (71), badMACAlgorithm (72), badAuthAttrs (73), badUnauthAttrs (74), invalidMAC (75), mismatchedDigestAlg (76), missingCertificate (77), tooManySigners (78), missingSignedAttributes (79), derEncodingNotUsed (80), missingContentHints (81), invalidAttributeLocation (82), badMessageDigest (83), badKeyPackage (84), badAttributes (85), attributeComparisonFailure (86), unsupportedSymmetricKeyPackage (87), unsupportedAsymmetricKeyPackage (88), constraintViolation (89), ambiguousDefaultValue (90), noMatchingRecipientInfo (91), unsupportedKeyWrapAlgorithm (92), badKeyTransRecipientInfo (93), other (127), ... -- Expect additional error codes -- }
ambiguousDecrypt（60）、noDecryptKey（61）、badEncryptedData（62）、badEnvelopedData（63）、badAuthenticatedData（64）、badAuthEnvelopedData（65）、badKeyAgreeRecipientInfo（66）、badKEKRecipientInfo（67）、badEncryptContent（68）、badEncryptAlgorithm（69） missingCiphertext（70）、decryptFailure（71）、badMACAlgorithm（72）、badAuthAttrs（73）、badUnauthAttrs（74）、invalidMAC（75）、mismatchedDigestAlg（76）、missingCertificate（77）、tooManySigners（78）、missingSignedAttributes（79）、 derEncodingNotUsed（80）、missingContentHints（81）、invalidAttributeLocation（82）、badMessageDigest（83）、badKeyPackage（84）、badAttributes（85）、attributeComparisonFailure（86）、unsupportedSymmetricKeyPackage（87）、unsupportedAsymmetricKeyPackage（88）、constraintViolation（89）、 ambiguousDefaultValue（90）、noMatchingRecipientInfo（91）、unsupportedKeyWrapAlgorithm（92）、badKeyTransRecipientInfo（93）、その他（127）、...-追加のエラーコードが予想される-}
The KeyPackageError fields are used as follows:
KeyPackageErrorフィールドは次のように使用されます。
o version identifies version of the key package error content structure. For this version of the specification, the default value, v2, MUST be used. Note that v1 was defined in an earlier version, but the use of v1 is deprecated.
o versionは、キーパッケージのエラーコンテンツ構造のバージョンを識別します。このバージョンの仕様では、デフォルト値のv2を使用する必要があります。 v1は以前のバージョンで定義されていましたが、v1の使用は推奨されていません。
o errorOf is OPTIONAL, and it provides the identifier of the keying material for which this error is being generated. This is omitted if the receiver or intermediary cannot parse the received data to determine the package identifier. Also, encryption may prevent an intermediary from obtaining any of the identifiers. Two alternatives for identifying the keying material are possible; see KeyPkgIdentifier as described in Section 4. The value MUST exactly match the value of the key-package-identifier-and-receipt-request attribute in the received key package or collection. The key-package-identifier-and-receipt-request attribute is described in Section 3.
o errorOfはオプションであり、これにより、このエラーが生成されているキー情報の識別子が提供されます。これは、受信者または仲介者が受信したデータを解析してパッケージ識別子を決定できない場合は省略されます。また、暗号化により、仲介者が識別子を取得できない場合があります。鍵素材を識別するための2つの代替案が可能です。セクション4で説明されているKeyPkgIdentifierを参照してください。値は、受信したキーパッケージまたはコレクションのkey-package-identifier-and-receipt-request属性の値と正確に一致する必要があります。 key-package-identifier-and-receipt-request属性については、セクション3で説明します。
o errorBy identifies the entity that received the key package. The entity is named by an SIR entity name as specified in Section 2.
o errorByは、キーパッケージを受け取ったエンティティを識別します。エンティティは、セクション2で指定されているSIRエンティティ名で命名されます。
o errorCode contains a code that indicates the reason for the error. It contains either an enumerated error code from the list below or an extended error code represented by an object identifier. The enumerated error code alternative MUST be supported. The object identifier error code MAY be supported.
o errorCodeには、エラーの理由を示すコードが含まれています。以下のリストから列挙されたエラーコード、またはオブジェクト識別子で表される拡張エラーコードのいずれかが含まれます。列挙されたエラーコードの代替がサポートされている必要があります。オブジェクト識別子のエラーコードがサポートされる場合があります。
* decodeFailure is used to indicate that the key package intermediary or receiver was unable to successfully decode the provided package. The specified content type and the provided content do not match.
* decodeFailureは、キーパッケージの仲介者または受信者が提供されたパッケージを正常にデコードできなかったことを示すために使用されます。指定されたコンテンツタイプと提供されたコンテンツが一致しません。
* badContentInfo is used to indicate that the ContentInfo syntax is invalid or that the contentType carried within the ContentInfo is unknown or unsupported.
* badContentInfoは、ContentInfo構文が無効であること、またはContentInfo内で運ばれるcontentTypeが不明またはサポートされていないことを示すために使用されます。
* badSignedData is used to indicate that the SignedData syntax is invalid, the version is unknown or unsupported, or more than one entry is present in digestAlgorithms.
* badSignedDataは、SignedData構文が無効であること、バージョンが不明またはサポートされていないこと、またはdigestAlgorithmsに複数のエントリが存在することを示すために使用されます。
* badEncapContent is used to indicate that the EncapsulatedContentInfo syntax is invalid within a SignedData or an AuthenticatedData or the EncryptedContentInfo syntax is invalid within an AuthEnvelopedData.
* badEncapContentは、SignedDataまたはAuthenticatedData内のEncapsulatedContentInfo構文が無効であるか、AuthEnvelopedData内のEncryptedContentInfo構文が無効であることを示すために使用されます。
* badCertificate is used to indicate that the syntax for one or more certificates in CertificateSet or elsewhere is invalid or unsupported.
* badCertificateは、CertificateSetまたはその他の場所にある1つ以上の証明書の構文が無効またはサポートされていないことを示すために使用されます。
* badSignerInfo is used to indicate that the SignerInfo syntax is invalid or the version is unknown or unsupported.
* badSignerInfoは、SignerInfo構文が無効であるか、バージョンが不明またはサポートされていないことを示すために使用されます。
* badSignedAttrs is used to indicate that the signedAttrs syntax within SignerInfo is invalid.
* badSignedAttrsは、SignerInfo内のsignedAttrs構文が無効であることを示すために使用されます。
* badUnsignedAttrs is used to indicate that the unsignedAttrs within SignerInfo contains one or more attributes. Since unrecognized attributes are ignored, this error code is used when the object identifier for the attribute is recognized, but the value is malformed or internally inconsistent. In addition, this error code can be used when policy prohibits an implementation from supporting unsigned attributes.
* badUnsignedAttrsは、SignerInfo内のunsignedAttrsに1つ以上の属性が含まれていることを示すために使用されます。認識されない属性は無視されるため、このエラーコードは、属性のオブジェクト識別子は認識されるが、値の形式が正しくないか、内部的に矛盾している場合に使用されます。さらに、このエラーコードは、ポリシーによって実装が符号なし属性をサポートすることが禁止されている場合に使用できます。
* missingContent is used to indicate that the optional eContent is missing in EncapsulatedContentInfo, which is required when including an asymmetric key package, a symmetric key package, and an encrypted key package. This error can be generated due to problems located in SignedData or AuthenticatedData.
* missingContentは、オプションのeContentがEncapsulatedContentInfoにないことを示すために使用されます。これは、非対称キーパッケージ、対称キーパッケージ、および暗号化キーパッケージを含めるときに必要です。このエラーは、SignedDataまたはAuthenticatedDataにある問題が原因で発生する可能性があります。
Note that CMS EncapsulatedContentInfo eContent field is optional [RFC5652]; however, [RFC5958], [RFC6031], and [RFC6032] require that the eContent be present.
CMS EncapsulatedContentInfo eContentフィールドはオプションであることに注意してください[RFC5652]。ただし、[RFC5958]、[RFC6031]、および[RFC6032]では、eContentが存在する必要があります。
* noTrustAnchor is used to indicate that the subjectKeyIdentifier does not identify the public key of a trust anchor or a certification path that terminates with an installed trust anchor.
* noTrustAnchorは、subjectKeyIdentifierがトラストアンカーの公開鍵、またはインストールされているトラストアンカーで終了する証明書パスを識別しないことを示すために使用されます。
* notAuthorized is used to indicate that the sid within SignerInfo leads to an installed trust anchor, but that trust anchor is not an authorized signer for the received content type.
* notAuthorizedは、SignerInfo内のsidがインストールされたトラストアンカーにつながるが、そのトラストアンカーは受信したコンテンツタイプの承認された署名者ではないことを示すために使用されます。
* badDigestAlgorithm is used to indicate that the digestAlgorithm in either SignerInfo, SignedData, or AuthenticatedData is unknown or unsupported.
* badDigestAlgorithmは、SignerInfo、SignedData、またはAuthenticatedDataのいずれかのdigestAlgorithmが不明またはサポートされていないことを示すために使用されます。
* badSignatureAlgorithm is used to indicate that the signatureAlgorithm in SignerInfo is unknown or unsupported.
* badSignatureAlgorithmは、SignerInfoのsignatureAlgorithmが不明またはサポートされていないことを示すために使用されます。
* unsupportedKeySize is used to indicate that the signatureAlgorithm in SignerInfo is known and supported, but the digital signature could not be validated because an unsupported key size was employed by the signer. Alternatively, the algorithm used in EnvelopedData, AuthenticatedData, or AuthEnvelopedData to generate the key-encryption key is known and supported, but an unsupported key size was employed by the originator.
* unsupportedKeySizeは、SignerInfoのsignatureAlgorithmが既知でありサポートされていることを示すために使用されますが、サポートされていないキーサイズが署名者によって使用されたため、デジタル署名を検証できませんでした。または、キー暗号化キーを生成するためにEnvelopedData、AuthenticatedData、またはAuthEnvelopedDataで使用されるアルゴリズムは既知でありサポートされていますが、サポートされていないキーサイズが発信者によって使用されました。
* unsupportedParameters is used to indicate that the signatureAlgorithm in SignerInfo is known, but the digital signature could not be validated because unsupported parameters were employed by the signer. Alternatively, the algorithm used in EnvelopedData, AuthenticatedData, or AuthEnvelopedData to generate the key-encryption key is known and supported, but unsupported parameters were employed by the originator.
* unsupportedParametersは、SignerInfoのsignatureAlgorithmが既知であることを示すために使用されますが、サポートされていないパラメーターが署名者によって使用されたため、デジタル署名を検証できませんでした。または、鍵暗号化鍵を生成するためにEnvelopedData、AuthenticatedData、またはAuthEnvelopedDataで使用されるアルゴリズムは既知であり、サポートされていますが、サポートされていないパラメーターが発信元によって使用されました。
* signatureFailure is used to indicate that the signatureAlgorithm in SignerInfo is known and supported, but the digital signature in the signature field within SignerInfo could not be validated.
* signatureFailureは、SignerInfoのsignatureAlgorithmが既知でありサポートされているが、SignerInfo内の署名フィールドのデジタル署名を検証できなかったことを示すために使用されます。
* insufficientMemory indicates that the key package could not be processed because the intermediary or receiver did not have sufficient memory to store the keying material.
* 不十分なメモリは、仲介者または受信者がキー情報を格納するための十分なメモリを持っていなかったため、キーパッケージを処理できなかったことを示します。
* incorrectTarget indicates that a receiver is not the intended recipient.
* correctTargetは、受信者が意図された受信者ではないことを示します。
* missingSignature indicates that the receiver requires the key package to be signed or authenticated with a Message Authentication Code (MAC), but the received key package was not signed or authenticated.
* missingSignatureは、受信者がメッセージパッケージをメッセージ認証コード（MAC）で署名または認証する必要があるが、受信したキーパッケージが署名または認証されていないことを示します。
* resourcesBusy indicates that the resources necessary to process the key package are not available at the present time, but the resources might be available at some point in the future.
* resourcesBusyは、キーパッケージを処理するために必要なリソースが現時点で利用できないことを示しますが、リソースは将来のある時点で利用可能になる可能性があります。
* versionNumberMismatch indicates that the version number in a received key package is not acceptable.
* versionNumberMismatchは、受け取った鍵パッケージのバージョン番号が受け入れられないことを示します。
* revokedCertificate indicates that one or more of the certificates needed to properly process the key package has been revoked.
* revokedCertificateは、鍵パッケージを適切に処理するために必要な1つ以上の証明書が取り消されたことを示します。
* ambiguousDecrypt indicates that the EncryptedData content type was used, and the key package receiver could not determine the appropriate keying material to perform the decryption.
* ambiguousDecryptは、EncryptedDataコンテンツタイプが使用され、キーパッケージレシーバーが復号化を実行するための適切なキー情報を判別できなかったことを示します。
* noDecryptKey indicates that the receiver does not have the key named in the content-decryption-key-identifier attribute (see [RFC6032]).
* noDecryptKeyは、受信者がcontent-decryption-key-identifier属性で指定されたキーを持っていないことを示します（[RFC6032]を参照）。
* badEncryptedData indicates that the EncryptedData syntax is invalid or the version is unknown or unsupported.
* badEncryptedDataは、EncryptedData構文が無効であるか、バージョンが不明またはサポートされていないことを示します。
* badEnvelopedData indicates that the EnvelopedData syntax is invalid or the version is unknown or unsupported.
* badEnvelopedDataは、EnvelopedData構文が無効であるか、バージョンが不明またはサポートされていないことを示します。
* badAuthenticatedData indicates that the AuthenticatedData syntax is invalid or the version is unknown or unsupported.
* badAuthenticatedDataは、AuthenticatedData構文が無効であるか、バージョンが不明またはサポートされていないことを示します。
* badAuthEnvelopedData indicates that the AuthEnvelopedData syntax is invalid or the version is unknown or unsupported.
* badAuthEnvelopedDataは、AuthEnvelopedData構文が無効であるか、バージョンが不明またはサポートされていないことを示します。
* badKeyAgreeRecipientInfo indicates that the KeyAgreeRecipientInfo syntax is invalid or the version is unknown or unsupported.
* badKeyAgreeRecipientInfoは、KeyAgreeRecipientInfo構文が無効であるか、バージョンが不明またはサポートされていないことを示します。
* badKEKRecipientInfo indicates that the KEKRecipientInfo syntax is invalid or the version is unknown or unsupported.
* badKEKRecipientInfoは、KEKRecipientInfo構文が無効であるか、バージョンが不明またはサポートされていないことを示します。
* badEncryptContent indicates that the EncryptedContentInfo syntax is invalid, or that the content type carried within the contentType is unknown or unsupported.
* badEncryptContentは、EncryptedContentInfo構文が無効であること、またはcontentType内で運ばれるコンテンツタイプが不明またはサポートされていないことを示します。
* badEncryptAlgorithm indicates that the encryption algorithm identified by contentEncryptionAlgorithm in EncryptedContentInfo is unknown or unsupported. This can result from EncryptedData, EnvelopedData, or AuthEnvelopedData.
* badEncryptAlgorithmは、EncryptedContentInfoのcontentEncryptionAlgorithmによって識別される暗号化アルゴリズムが不明またはサポートされていないことを示します。これは、EncryptedData、EnvelopedData、またはAuthEnvelopedDataが原因で発生する可能性があります。
* missingCiphertext indicates that the optional encryptedContent is missing in EncryptedContentInfo, which is required when including an asymmetric key package, a symmetric key package, and an encrypted key package.
* missingCiphertextは、オプションのencryptedContentがEncryptedContentInfoにないことを示します。これは、非対称鍵パッケージ、対称鍵パッケージ、および暗号化鍵パッケージを含めるときに必要です。
* decryptFailure indicates that the encryptedContent in EncryptedContentInfo did not decrypt properly.
* decodeFailureは、EncryptedContentInfoのencryptedContentが適切に復号化されなかったことを示します。
* badMACAlgorithm indicates that the MAC algorithm identified by MessageAuthenticationCodeAlgorithm in AuthenticatedData is unknown or unsupported.
* badMACAlgorithmは、AuthenticatedDataのMessageAuthenticationCodeAlgorithmによって識別されたMACアルゴリズムが不明またはサポートされていないことを示します。
* badAuthAttrs is used to indicate that the authAttrs syntax within AuthenticatedData or AuthEnvelopedData is invalid. Since unrecognized attributes are ignored, this error code is used when the object identifier for the attribute is recognized, but the value is malformed or internally inconsistent.
* badAuthAttrsは、AuthenticatedDataまたはAuthEnvelopedData内のauthAttrs構文が無効であることを示すために使用されます。認識されない属性は無視されるため、このエラーコードは、属性のオブジェクト識別子は認識されるが、値の形式が正しくないか、内部的に矛盾している場合に使用されます。
* badUnauthAttrs is used to indicate that the unauthAttrs syntax within AuthenticatedData or AuthEnvelopedData is invalid. Since unrecognized attributes are ignored, this error code is used when the object identifier for the attribute is recognized, but the value is malformed or internally inconsistent.
* badUnauthAttrsは、AuthenticatedDataまたはAuthEnvelopedData内のunauthAttrs構文が無効であることを示すために使用されます。認識されない属性は無視されるため、このエラーコードは、属性のオブジェクト識別子は認識されるが、値の形式が正しくないか、内部的に矛盾している場合に使用されます。
* invalidMAC is used to indicate that the message authentication code value within AuthenticatedData or AuthEnvelopedData did not validate properly.
* invalidMACは、AuthenticatedDataまたはAuthEnvelopedData内のメッセージ認証コード値が適切に検証されなかったことを示すために使用されます。
* mismatchedDigestAlg is used to indicate that the digest algorithm in digestAlgorithms field within SignedData does not match the digest algorithm used in the signature algorithm.
* MismatchedDigestAlgは、SignedData内のdigestAlgorithmsフィールドのダイジェストアルゴリズムが、署名アルゴリズムで使用されるダイジェストアルゴリズムと一致しないことを示すために使用されます。
* missingCertificate indicates that a signature could not be verified using a trust anchor or a certificate from the certificates field within SignedData. Similarly, this error code can indicate that a needed certificate is missing when processing EnvelopedData, AuthEnvelopedData, or AuthenticatedData.
* missingCertificateは、トラストアンカーまたはSignedData内の証明書フィールドの証明書を使用して署名を検証できなかったことを示します。同様に、このエラーコードは、EnvelopedData、AuthEnvelopedData、またはAuthenticatedDataの処理時に必要な証明書が欠落していることを示している可能性があります。
* tooManySigners indicates that a SignedData content contained more than one SignerInfo for a content type that requires only one signer.
* tooManySignersは、SignedDataコンテンツに、1つの署名者のみを必要とするコンテンツタイプの複数のSignerInfoが含まれていることを示します。
* missingSignedAttributes indicates that a SignedInfo within a SignedData content did not contain any signed attributes; at a minimum, the content-type and message-digest must be present, as per [RFC5652]. Similarly, this error code can indicate that required authenticated attributes are missing when processing AuthEnvelopedData or AuthenticatedData.
* missingSignedAttributesは、SignedDataコンテンツ内のSignedInfoに署名された属性が含まれていなかったことを示します。 [RFC5652]のように、少なくともコンテンツタイプとメッセージダイジェストが存在している必要があります。同様に、このエラーコードは、AuthEnvelopedDataまたはAuthenticatedDataの処理時に、必要な認証済み属性が欠落していることを示している可能性があります。
* derEncodingNotUsed indicates that the content contained BER encoding, or some other encoding, where DER encoding was required.
* derEncodingNotUsedは、コンテンツにBERエンコード、またはDERエンコードが必要なその他のエンコードが含まれていたことを示します。
* missingContentHints indicates that a SignedData content encapsulates a content other than a key package or an encrypted key package; however, the content-hints attribute [RFC2634] is not included. Similarly, this error code can indicate that the content-hints attribute was missing when processing AuthEnvelopedData or AuthenticatedData.
* missingContentHintsは、SignedDataコンテンツがキーパッケージまたは暗号化されたキーパッケージ以外のコンテンツをカプセル化することを示します。ただし、content-hints属性[RFC2634]は含まれていません。同様に、このエラーコードは、AuthEnvelopedDataまたはAuthenticatedDataの処理時にcontent-hints属性が欠落していたことを示している可能性があります。
* invalidAttributeLocation indicates that an attribute appeared in an unacceptable location.
* invalidAttributeLocationは、属性が許容できない場所に表示されたことを示します。
* badMessageDigest indicates that the value of the message-digest attribute [RFC5652] did not match the calculated value.
* badMessageDigestは、メッセージダイジェスト属性[RFC5652]の値が計算値と一致しなかったことを示します。
* badKeyPackage indicates that the SymmetricKeyPackage [RFC6031] or AsymmetricKeyPackage [RFC5958] syntax is invalid or that the version is unknown.
* badKeyPackageは、SymmetricKeyPackage [RFC6031]またはAsymmetricKeyPackage [RFC5958]構文が無効であること、またはバージョンが不明であることを示します。
* badAttributes indicates that an attribute collection either contained multiple instances of the same attribute type that allows only one instance or contained an attribute instance with multiple values in an attribute that allows only one value.
* badAttributesは、属性コレクションに、1つのインスタンスのみを許可する同じ属性タイプの複数のインスタンスが含まれているか、1つの値のみを許可する属性に複数の値を持つ属性インスタンスが含まれていることを示します。
* attributeComparisonFailure indicates that multiple instances of an attribute failed the comparison rules for the type of attribute.
* attributeComparisonFailureは、属性の複数のインスタンスが属性のタイプの比較ルールに失敗したことを示します。
* unsupportedSymmetricKeyPackage indicates that the implementation does not support symmetric key packages [RFC6031].
* unsupportedSymmetricKeyPackageは、実装が対称鍵パッケージをサポートしていないことを示します[RFC6031]。
* unsupportedAsymmetricKeyPackage indicates that the implementation does not support asymmetric key packages [RFC5958].
* unsupportedAsymmetricKeyPackageは、実装が非対称キーパッケージをサポートしていないことを示します[RFC5958]。
* constraintViolation indicates that one or more of the attributes has a value that is not in the authorized set of values for the signer [RFC6010]. That is, the value is in conflict with the constraints imposed on the signer.
* constraintViolationは、1つ以上の属性に、署名者の許可された値のセット[RFC6010]にない値があることを示します。つまり、値は署名者に課せられた制約と矛盾しています。
* ambiguousDefaultValue indicates that one or more of the attributes that is part of the signer's constraints is omitted from the key package, and the constraint permits more than one value; therefore, the appropriate default value for that attribute or attribute cannot be determined.
* ambiguousDefaultValueは、署名者の制約の一部である1つ以上の属性がキーパッケージから省略され、制約が複数の値を許可することを示します。したがって、その属性または属性の適切なデフォルト値を決定できません。
* noMatchingRecipientInfo indicates that a recipientInfo could not be found for the recipient. This can result from a ktri or kari found in EncryptedData, EnvelopedData, or AuthEnvelopedData.
* noMatchingRecipientInfoは、受信者の受信者情報が見つからなかったことを示します。これは、EncryptedData、EnvelopedData、またはAuthEnvelopedDataにあるktriまたはkariが原因である可能性があります。
* unsupportedKeyWrapAlgorithm indicates that the key wrap algorithm is not supported.
* unsupportedKeyWrapAlgorithmは、キーラップアルゴリズムがサポートされていないことを示します。
* badKeyTransRecipientInfo indicates that the KeyTransRecipientInfo syntax is invalid or the version is unknown or unsupported.
* badKeyTransRecipientInfoは、KeyTransRecipientInfo構文が無効であるか、バージョンが不明またはサポートされていないことを示します。
* other indicates that the key package could not be processed, but the reason is not covered by any of the assigned status codes. Use of this status code SHOULD be avoided.
* その他は、キーパッケージを処理できなかったが、その理由は割り当てられたステータスコードのいずれにも該当しないことを示します。このステータスコードの使用は避けてください。
The key package error content type MUST be signed if the entity generating it is capable of signing it. For example, a device will be incapable of signing when it is in early stages of deployment and it has not been configured with a private signing key or a device has an internal error that prevents use of its private signing key. When it is signed, the key package error MUST be encapsulated in a CMS SignedData content type to carry the signature of the party that is indicating an error. When it is encrypted, the key package error MUST be encapsulated in a CMS EnvelopedData content type, a CMS EncryptedData content type, or a CMS AuthEnvelopedData content type. When a key package error is signed and encrypted, it MUST be signed prior to being encrypted.
キーパッケージのエラーコンテンツタイプは、それを生成するエンティティが署名できる場合に署名する必要があります。たとえば、デバイスが展開の初期段階にあり、秘密署名キーで構成されていない場合、またはデバイスに内部エラーがあり、秘密署名キーを使用できない場合、デバイスは署名できなくなります。署名されている場合、キーパッケージエラーはCMS SignedDataコンテンツタイプにカプセル化して、エラーを示しているパーティの署名を伝える必要があります。暗号化される場合、キーパッケージエラーは、CMS EnvelopedDataコンテンツタイプ、CMS EncryptedDataコンテンツタイプ、またはCMS AuthEnvelopedDataコンテンツタイプにカプセル化する必要があります。鍵パッケージのエラーが署名および暗号化されている場合、暗号化する前に署名する必要があります。
All devices that generate signed key package error reports MUST store their own certificate or have a means of obtaining the key identifier of their public key. If memory is a concern, the public key identifier can be computed from the public key.
署名付き鍵パッケージのエラーレポートを生成するすべてのデバイスは、独自の証明書を保存するか、公開鍵の鍵識別子を取得する手段を備えている必要があります。メモリが問題になる場合は、公開鍵から公開鍵識別子を計算できます。
If the error report signer has access to a real-time clock, then the binary-signing-time attribute [RFC6019] SHOULD be included in the key package error to provide the date and time when it was generated.
エラーレポートの署名者がリアルタイムクロックにアクセスできる場合、バイナリ署名時間属性[RFC6019]をキーパッケージエラーに含めて、生成された日時を提供する必要があります（SHOULD）。
CMS protecting content types, [RFC5652] and [RFC5083], can be used to provide security to the KeyPackageReceipt and KeyPackageError content types:
CMS保護コンテンツタイプ[RFC5652]および[RFC5083]を使用して、KeyPackageReceiptおよびKeyPackageErrorコンテンツタイプにセキュリティを提供できます。
o SignedData can be used to apply a digital signature.
o SignedDataは、デジタル署名を適用するために使用できます。
o EncryptedData can be used to encrypt the content type with simple symmetric encryption, where the sender and the receiver already share the necessary encryption key.
o EncryptedDataを使用すると、送信者と受信者が必要な暗号化キーを既に共有している単純な対称暗号化でコンテンツタイプを暗号化できます。
o EnvelopedData can be used to encrypt the content type with symmetric encryption, where the sender and the receiver do not already share the necessary encryption key.
o EnvelopedDataを使用して、対称暗号化でコンテンツタイプを暗号化できます。送信者と受信者は、必要な暗号化キーをまだ共有していません。
o AuthenticatedData can be used to integrity protect the content type with message authentication algorithms that support authenticated encryption, where key management information is handled in a manner similar to EnvelopedData.
o AuthenticatedDataを使用すると、キー管理情報がEnvelopedDataと同様の方法で処理される、認証された暗号化をサポートするメッセージ認証アルゴリズムでコンテンツタイプを整合性保護できます。
o AuthEnvelopedData can be used to protect the content types with algorithms that support authenticated encryption, where key management information is handled in a manner similar to EnvelopedData.
o AuthEnvelopedDataを使用して、キー管理情報がEnvelopedDataと同様の方法で処理される、認証された暗号化をサポートするアルゴリズムでコンテンツタイプを保護できます。
The media type and parameters for carrying a key package receipt or a key package error content type are specified in [RFC7193].
鍵パッケージの受領書または鍵パッケージのエラーコンテンツタイプを運ぶためのメディアタイプとパラメータは、[RFC7193]で指定されています。
IANA has updated the reference for the following registration in the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry:
IANAは、「SMI Security for S / MIME Module Identifier（1.2.840.113549.1.9.16.0）」レジストリの次の登録の参照を更新しました。
63 id-mod-keyPkgReceiptAndErrV2 [RFC7191]
63 id-mod-keyPkgReceiptAndErrV2 [RFC7191]
The key package receipt and key package error contents are not necessarily protected. These content types can be combined with a security protocol to protect the contents of the package.
鍵パッケージの受領および鍵パッケージのエラーの内容は、必ずしも保護されているわけではありません。これらのコンテンツタイプをセキュリティプロトコルと組み合わせて、パッケージのコンテンツを保護できます。
The KeyPkgReceiptReq structure includes a receiptsFrom list and a receiptsTo list. Both lists contain SIREntityNames. The syntax does not specify a limit on the number of SIREntityNames that may be included in either of these lists. In addition, there is purposefully no requirement that the receiptTo entries have any relation to the sender of the key package. To avoid these features being used as part of a denial-of-service amplification, receipts should only be returned for key packages with a valid signature from a trusted signer.
KeyPkgReceiptReq構造には、receiptsFromリストとreceivesToリストが含まれます。どちらのリストにもSIREntityNamesが含まれています。構文では、これらのリストのいずれかに含めることができるSIREntityNamesの数の制限を指定していません。また、receiveToエントリがキーパッケージの送信者と何らかの関係があることは意図的にはありません。これらの機能がサービス拒否の増幅の一部として使用されるのを防ぐには、信頼できる署名者からの有効な署名を持つ鍵パッケージの場合にのみレシートを返す必要があります。
If an implementation is willing to accept key packages from more than one source, then there is a possibility that the same key package identifier could be used by more than one source. As a result, there is the potential for a receipt for one key package to be confused with the receipt for another, potentially leading to confusion about the keying material that is available to the recipient. In environments with multiple key sources, a convention for assignment of key package identifiers can avoid this potential confusion altogether.
実装が複数のソースからのキーパッケージを受け入れる用意がある場合は、同じキーパッケージ識別子が複数のソースで使用される可能性があります。その結果、1つのキーパッケージのレシートが別のキーパッケージのレシートと混同される可能性があり、受信者が入手できるキー情報について混乱を招く可能性があります。複数のキーソースがある環境では、キーパッケージ識別子の割り当てに関する規則により、この潜在的な混乱を完全に回避できます。
In some situations, returning very detailed error information can provide an attacker with insight into the security processing. Where this is a concern, the implementation should return the most generic error code that is appropriate. However, detailed error codes are very helpful during development, debugging, and interoperability testing. For this reason, implementations may want to have a way to configure the use of a generic error code or a detailed one.
状況によっては、非常に詳細なエラー情報を返すことで、攻撃者がセキュリティ処理を理解することができます。これが問題になる場合、実装は適切な最も一般的なエラーコードを返す必要があります。ただし、詳細なエラーコードは、開発、デバッグ、および相互運用性のテスト中に非常に役立ちます。このため、実装では、一般的なエラーコードまたは詳細なエラーコードの使用を構成する方法が必要になる場合があります。
Many thanks to Radia Perlman, Sean Turner, Jim Schaad, and Carl Wallace for their insightful review. Thanks to Robert Sparks for improved wording.
洞察に満ちたレビューを提供してくれたRadia Perlman、Sean Turner、Jim Schaad、Carl Wallaceに感謝します。表現を改善してくれたRobert Sparksに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[RFC2634] Hoffman、P.、Ed。、「Enhanced Security Services for S / MIME」、RFC 2634、1999年6月。
[RFC4073] Housley, R., "Protecting Multiple Contents with the Cryptographic Message Syntax (CMS)", RFC 4073, May 2005.
[RFC4073] Housley、R。、「Cryptographic Message Syntax（CMS）による複数のコンテンツの保護」、RFC 4073、2005年5月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、2008年5月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652] Housley、R。、「Cryptographic Message Syntax（CMS）」、STD 70、RFC 5652、2009年9月。
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, June 2010.
[RFC5912] Hoffman、P。およびJ. Schaad、「X.509（PKIX）を使用した公開鍵インフラストラクチャ用の新しいASN.1モジュール」、RFC 5912、2010年6月。
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 2010.
[RFC5958]ターナー、S。、「非対称鍵パッケージ」、RFC 5958、2010年8月。
[RFC6010] Housley, R., Ashmore, S., and C. Wallace, "Cryptographic Message Syntax (CMS) Content Constraints Extension", RFC 6010, September 2010.
[RFC6010] Housley、R.、Ashmore、S。、およびC. Wallace、「Cryptographic Message Syntax（CMS）Content Constraints Extension」、RFC 6010、2010年9月。
[RFC6019] Housley, R., "BinaryTime: An Alternate Format for Representing Date and Time in ASN.1", RFC 6019, September 2010.
[RFC6019] Housley、R。、「BinaryTime：ASN.1で日付と時刻を表すための代替フォーマット」、RFC 6019、2010年9月。
[RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type", RFC 6031, December 2010.
[RFC6031]ターナー、S。およびR.ハウズリー、「Cryptographic Message Syntax（CMS）Symmetric Key Package Content Type」、RFC 6031、2010年12月。
[RFC6032] Turner, S. and R. Housley, "Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type", RFC 6032, December 2010.
[RFC6032]ターナー、S。およびR.ハウズリー、「Cryptographic Message Syntax（CMS）Encrypted Key Package Content Type」、RFC 6032、2010年12月。
[RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)", RFC 6268, July 2011.
[RFC6268] Schaad、J。およびS. Turner、「暗号化メッセージ構文（CMS）およびX.509（PKIX）を使用した公開鍵インフラストラクチャのための追加の新しいASN.1モジュール」、RFC 6268、2011年7月。
[RFC7193] Turner, S., Housley, R., and J. Schaad, "The application/cms Media Type", RFC 7193, April 2014.
[RFC7193]ターナー、S。、ハウズリー、R。、およびJ.シャード、「application / cms Media Type」、RFC 7193、2014年4月。
[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002. Information Technology - Abstract Syntax Notation One.
[X.680] ITU-T勧告X.680（2002）| ISO / IEC 8824-1：2002。情報技術-抽象構文記法1。
[X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002. Information Technology - Abstract Syntax Notation One: Information Object Specification.
[X.681] ITU-T勧告X.681（2002）| ISO / IEC 8824-2：2002。情報技術-抽象構文記法1：情報オブジェクト仕様。
[X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002. Information Technology - Abstract Syntax Notation One: Constraint Specification.
[X.682] ITU-T勧告X.682（2002）| ISO / IEC 8824-3：2002。情報技術-抽象構文記法1：制約仕様。
[X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002. Information Technology - Abstract Syntax Notation One: Parameterization of ASN.1 Specifications.
[X.683] ITU-T勧告X.683（2002）| ISO / IEC 8824-4：2002。情報技術-抽象構文記法1：ASN.1仕様のパラメーター化。
[X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825- 1:2002. Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).
[X.690] ITU-T勧告X.690（2002）| ISO / IEC 8825- 1：2002。情報技術-ASN.1エンコーディングルール：Basic Encoding Rules（BER）、Canonical Encoding Rules（CER）、Distinguished Encoding Rules（DER）の仕様。
[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, November 2007.
[RFC5083] Housley、R。、「Cryptographic Message Syntax（CMS）Authenticated-Enveloped-Data Content Type」、RFC 5083、2007年11月。
[RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Management Protocol (TAMP)", RFC 5934, August 2010.
[RFC5934] Housley、R.、Ashmore、S。、およびC. Wallace、「Trust Anchor Management Protocol（TAMP）」、RFC 5934、2010年8月。
This annex provides the normative ASN.1 definitions for the structures described in this specification using ASN.1 as defined in [X.680], [X.681], [X.682], and [X.683].
この附属書は、[X.680]、[X.681]、[X.682]、および[X.683]で定義されているASN.1を使用して、この仕様で説明されている構造の規範的なASN.1定義を提供します。
KeyPackageReceiptAndErrorModuleV2
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-keyPkgReceiptAndErrV2(63) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
ベギン
-- EXPORTS ALL
-すべてエクスポート
IMPORTS
輸入
-- FROM New SMIME ASN.1 [RFC6268]
-新しいSMIME ASN.1から[RFC6268]
CONTENT-TYPE
FROM CryptographicMessageSyntax-2010
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) }
-- From New PKIX ASN.1 [RFC5912]
-新しいPKIX ASN.1 [RFC5912]から
ATTRIBUTE, SingleAttribute {}
FROM PKIX-CommonTypes-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57) }
DistinguishedName
FROM PKIX1Explicit-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-explicit-02(51)}
;
---
--- Key Package Version Number (revised from [RFC6031])
---
KeyPkgVersion ::= INTEGER { v1(1), v2(2) } (1 .. 65535)
-- -- SIR Entity Name --
--SIRエンティティ名-
SIREntityNames ::= SEQUENCE SIZE (1..MAX) OF SIREntityName
SIREntityNameTypes SIR-ENTITY-NAME ::= {
siren-dn,
... -- Expect additional SIR Entity Name types -- }
SIR-ENTITY-NAME ::= CLASS {
&sIRENType OBJECT IDENTIFIER UNIQUE,
&SIRENValue
} WITH SYNTAX {
SYNTAX &SIRENValue IDENTIFIED BY &sIRENType }
SIREntityName ::= SEQUENCE {
sirenType SIR-ENTITY-NAME.&sIRENType({SIREntityNameTypes}),
sirenValue OCTET STRING (CONTAINING
SIR-ENTITY-NAME.&SIRENValue(
{SIREntityNameTypes}{@sirenType}) ) }
siren-dn SIR-ENTITY-NAME ::= {
SYNTAX DistinguishedName
IDENTIFIED BY id-dn }
id-dn OBJECT IDENTIFIER ::= {
joint-iso-ccitt(2) country(16) us(840) organization(1)
gov(101) dod(2) infosec(1) sir-name-types(16) 0 }
-- -- Attribute Definitions --
--属性の定義-
aa-keyPackageIdentifierAndReceiptRequest ATTRIBUTE ::= {
TYPE KeyPkgIdentifierAndReceiptReq
IDENTIFIED BY id-aa-KP-keyPkgIdAndReceiptReq }
id-aa-KP-keyPkgIdAndReceiptReq OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1)
gov(101) dod(2) infosec(1) attributes(5) 65 }
KeyPkgIdentifierAndReceiptReq ::= SEQUENCE {
pkgID KeyPkgID,
receiptReq KeyPkgReceiptReq OPTIONAL }
KeyPkgID ::= OCTET STRING
KeyPkgReceiptReq ::= SEQUENCE {
encryptReceipt BOOLEAN DEFAULT FALSE,
receiptsFrom [0] SIREntityNames OPTIONAL,
receiptsTo SIREntityNames }
-- -- Content Type Definitions --
--コンテンツタイプの定義-
KeyPackageContentTypes CONTENT-TYPE ::= {
ct-key-package-receipt |
ct-key-package-error,
... -- Expect additional content types -- }
-- Key Package Receipt CMS Content Type
-主要パッケージ受領CMSコンテンツタイプ
ct-key-package-receipt CONTENT-TYPE ::= {
TYPE KeyPackageReceipt
IDENTIFIED BY id-ct-KP-keyPackageReceipt }
id-ct-KP-keyPackageReceipt OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1)
gov(101) dod(2) infosec(1) formats(2)
key-package-content-types(78) 3 }
KeyPackageReceipt ::= SEQUENCE {
version KeyPkgVersion DEFAULT v2,
receiptOf KeyPkgIdentifier,
receivedBy SIREntityName }
KeyPkgIdentifier ::= CHOICE {
pkgID KeyPkgID,
attribute SingleAttribute {{ KeyPkgIdentifiers }} }
KeyPkgIdentifiers ATTRIBUTE ::= { ... }
-- Key Package Receipt CMS Content Type
-主要パッケージ受領CMSコンテンツタイプ
ct-key-package-error CONTENT-TYPE ::= {
TYPE KeyPackageError IDENTIFIED BY id-ct-KP-keyPackageError }
id-ct-KP-keyPackageError OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1)
gov(101) dod(2) infosec(1) formats(2)
key-package-content-types(78) 6 }
KeyPackageError ::= SEQUENCE {
version KeyPkgVersion DEFAULT v2,
errorOf [0] KeyPkgIdentifier OPTIONAL,
errorBy SIREntityName,
errorCode ErrorCodeChoice }
ErrorCodeChoice ::= CHOICE {
enum EnumeratedErrorCode,
oid OBJECT IDENTIFIER }
EnumeratedErrorCode ::= ENUMERATED {
decodeFailure (1),
badContentInfo (2),
badSignedData (3),
badEncapContent (4),
badCertificate (5),
badSignerInfo (6),
badSignedAttrs (7),
badUnsignedAttrs (8),
missingContent (9),
noTrustAnchor (10),
notAuthorized (11),
badDigestAlgorithm (12),
badSignatureAlgorithm (13),
unsupportedKeySize (14),
unsupportedParameters (15),
signatureFailure (16),
insufficientMemory (17),
incorrectTarget (23),
missingSignature (29),
resourcesBusy (30),
versionNumberMismatch (31),
revokedCertificate (33),
-- Error codes with values <= 33 are aligned with [RFC5934]
-値が33以下のエラーコードは[RFC5934]に揃えられます
ambiguousDecrypt (60), noDecryptKey (61), badEncryptedData (62), badEnvelopedData (63), badAuthenticatedData (64), badAuthEnvelopedData (65), badKeyAgreeRecipientInfo (66), badKEKRecipientInfo (67), badEncryptContent (68), badEncryptAlgorithm (69), missingCiphertext (70), decryptFailure (71), badMACAlgorithm (72), badAuthAttrs (73), badUnauthAttrs (74), invalidMAC (75), mismatchedDigestAlg (76), missingCertificate (77), tooManySigners (78), missingSignedAttributes (79), derEncodingNotUsed (80), missingContentHints (81), invalidAttributeLocation (82), badMessageDigest (83), badKeyPackage (84), badAttributes (85), attributeComparisonFailure (86), unsupportedSymmetricKeyPackage (87), unsupportedAsymmetricKeyPackage (88), constraintViolation (89), ambiguousDefaultValue (90), noMatchingRecipientInfo (91), unsupportedKeyWrapAlgorithm (92), badKeyTransRecipientInfo (93), other (127), ... -- Expect additional error codes -- }
ambiguousDecrypt（60）、noDecryptKey（61）、badEncryptedData（62）、badEnvelopedData（63）、badAuthenticatedData（64）、badAuthEnvelopedData（65）、badKeyAgreeRecipientInfo（66）、badKEKRecipientInfo（67）、badEncryptContent（68）、badEncryptAlgorithm（69） missingCiphertext（70）、decryptFailure（71）、badMACAlgorithm（72）、badAuthAttrs（73）、badUnauthAttrs（74）、invalidMAC（75）、mismatchedDigestAlg（76）、missingCertificate（77）、tooManySigners（78）、missingSignedAttributes（79）、 derEncodingNotUsed（80）、missingContentHints（81）、invalidAttributeLocation（82）、badMessageDigest（83）、badKeyPackage（84）、badAttributes（85）、attributeComparisonFailure（86）、unsupportedSymmetricKeyPackage（87）、unsupportedAsymmetricKeyPackage（88）、constraintViolation（89）、 ambiguousDefaultValue（90）、noMatchingRecipientInfo（91）、unsupportedKeyWrapAlgorithm（92）、badKeyTransRecipientInfo（93）、その他（127）、...-追加のエラーコードが予想される-}
END
終わり
Author's Address
著者のアドレス
Russ Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
Russ Housley Vigil Security、LLC 918 Spring Knoll Drive Herndon、VA 20170 USA
EMail: housley@vigilsec.com