[要約] RFC 7906は、NSA（アメリカ国家安全保障局）が提案するCryptographic Message Syntax (CMS) Key Management Attributesに関する文書です。このRFCは、CMSで使用される鍵管理属性のセットを定義し、特に国家安全保障システム（NSS）内での使用を目的としています。これらの属性は、鍵の生成、処理、配布の方法を標準化し、セキュアなメッセージングとデータ保護を強化するために設計されています。関連するRFCには、RFC 5652（CMSに関する基本的な仕様）などがあります。利用場面としては、高度なセキュリティが求められる通信での鍵管理プロセスの標準化に貢献します。
Independent Submission P. Timmel
Request for Comments: 7906 National Security Agency
Category: Informational R. Housley
ISSN: 2070-1721 Vigil Security
S. Turner
IECA
June 2016
NSA's Cryptographic Message Syntax (CMS) Key Management Attributes
NSAの暗号化メッセージ構文（CMS）キー管理属性
Abstract
概要
This document defines key management attributes used by the National Security Agency (NSA). The attributes can appear in asymmetric and/or symmetric key packages as well as the Cryptographic Message Syntax (CMS) content types that subsequently envelope the key packages. Key packages described in RFCs 5958 and 6031 are examples of where these attributes can be used.
このドキュメントでは、国家安全保障局（NSA）が使用する主要な管理属性を定義しています。属性は、非対称および/または対称のキーパッケージ、およびその後にキーパッケージをエンベロープする暗号化メッセージ構文（CMS）コンテンツタイプで表示できます。 RFC 5958および6031で説明されている主要なパッケージは、これらの属性を使用できる場所の例です。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション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/rfc7906.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7906で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Attribute Locations ........................................3
1.2. ASN.1 Notation .............................................4
1.3. Terminology ................................................5
2. CMS-Defined Attributes ..........................................6
3. Community Identifiers ...........................................7
4. Key Province Attribute ..........................................8
5. Binary Signing Time .............................................8
6. Manifest ........................................................9
7. Key Algorithm ...................................................9
8. User Certificate ...............................................11
9. Key Package Receivers ..........................................11
10. TSEC Nomenclature .............................................13
11. Key Purpose ...................................................16
12. Key Use .......................................................17
13. Transport Key .................................................20
14. Key Distribution Period .......................................20
15. Key Validity Period ...........................................22
16. Key Duration ..................................................23
17. Classification ................................................24
17.1. Security Label ...........................................25
18. Split Key Identifier ..........................................29
19. Key Package Type ..............................................30
20. Signature Usage ...............................................30
21. Other Certificate Format ......................................33
22. PKI Path ......................................................34
23. Useful Certificates ...........................................35
24. Key Wrap Algorithm ............................................35
25. Content Decryption Key Identifier .............................36
25.1. Content Decryption Key Identifier: Symmetric Key
and Symmetric ............................................36
25.2. Content Decryption Key Identifier: Unprotected ...........37
26. Certificate Pointers ..........................................37
27. CRL Pointers ..................................................38
28. Key Package Identifier and Receipt Request ....................38
29. Additional Error Codes ........................................39
30. Processing Key Package Attribute Values and CMS
Content Constraints ...........................................39
31. Attribute Scope ...............................................41
32. Security Considerations .......................................48
33. References ....................................................48
33.1. Normative References .....................................48
33.2. Informative References ...................................51
Appendix A. ASN.1 Module ..........................................52
Authors' Addresses ................................................68
This document defines key management attributes used by the National Security Agency (NSA). The attributes can appear in asymmetric and/or symmetric key packages as well as the Cryptographic Message Syntax (CMS) content types that subsequently envelope the key packages.
このドキュメントでは、国家安全保障局（NSA）が使用する主要な管理属性を定義しています。属性は、非対称および/または対称のキーパッケージ、およびその後にキーパッケージをエンベロープする暗号化メッセージ構文（CMS）コンテンツタイプで表示できます。
This document contains definitions for new attributes as well as previously defined attributes. References are provided to the previously defined attributes; however, their definitions are included herein for convenience.
このドキュメントには、以前に定義された属性だけでなく、新しい属性の定義も含まれています。以前に定義された属性への参照が提供されます。しかしながら、それらの定義は便宜上ここに含まれている。
CMS allows for arbitrary nesting of content types. Attributes are also supported in various locations in content types and key packages, which are themselves content types (see Section 1.1). An implementation that supports all of the possibilities would be extremely complex. Instead of implementing the full flexibility supported by this document, some devices may choose to support one or more templates, which is a profile for a combination of CMS content type(s), key package, and attribute(s); see Section 19.
CMSでは、コンテンツタイプを任意にネストできます。属性は、コンテンツタイプおよびキーパッケージのさまざまな場所でもサポートされます。これらは、それ自体がコンテンツタイプです（セクション1.1を参照）。すべての可能性をサポートする実装は非常に複雑になります。このドキュメントでサポートされている完全な柔軟性を実装する代わりに、一部のデバイスは、CMSコンテンツタイプ、キーパッケージ、および属性の組み合わせのプロファイルである1つ以上のテンプレートをサポートすることを選択できます。セクション19を参照してください。
There are a number of CMS content types that support attributes SignedData [RFC5652], EnvelopedData [RFC5652], EncryptedData [RFC5652], AuthenticatedData [RFC5652], and AuthEnvelopedData [RFC5083] as well as ContentWithAttributes [RFC4073]. There are also a number of other content types defined with CONTENT-TYPE [RFC6268] that support attributes including AsymmetricKeyPackage [RFC5958] and SymmetricKeyPackage [RFC6031].
属性SignedData [RFC5652]、EnvelopedData [RFC5652]、EncryptedData [RFC5652]、AuthenticatedData [RFC5652]、AuthEnvelopedData [RFC5083]、およびContentWithAttributes [RFC4073]をサポートするCMSコンテンツタイプがいくつかあります。また、AsymmetricKeyPackage [RFC5958]やSymmetricKeyPackage [RFC6031]などの属性をサポートするCONTENT-TYPE [RFC6268]で定義された他の多くのコンテンツタイプがあります。
CMS defines a number of "protecting content types" -- SignedData [RFC5652], EnvelopedData [RFC5652], EncryptedData [RFC5652], AuthenticatedData [RFC5652], and AuthEnvelopedData [RFC5083] -- that provide some type of security service. There are also other CMS content types -- Data [RFC5652], ContentWithAttributes [RFC4073], and ContentCollection [RFC4073] -- that provide no security service.
CMSは、いくつかのタイプのセキュリティサービスを提供する、いくつかの「保護コンテンツタイプ」を定義します。他のCMSコンテンツタイプもあります-データ[RFC5652]、ContentWithAttributes [RFC4073]、およびContentCollection [RFC4073]-セキュリティサービスを提供しません。
There are also different kinds of attributes in these content types:
これらのコンテンツタイプには、さまざまな種類の属性もあります。
o SignedData supports two kinds of attributes: signed and unsigned attributes in the signedAttrs and unsignedAttrs fields, respectively.
o SignedDataは2種類の属性をサポートします。それぞれ、signedAttrsフィールドとunsignedAttrsフィールドのsigned属性とunsigned属性です。
o EnvelopedData and EncryptedData each support one kind of attribute: unprotected attributes in the unprotectedAttrs field.
o EnvelopedDataとEncryptedDataはそれぞれ、1種類の属性をサポートしています。unprotectedAttrsフィールドの非保護属性です。
o AuthEnvelopedData supports two kinds of attributes: authenticated and unauthenticated attributes in the authAttrs and unauthAttrs fields, respectively. Both of these attributes are also unprotected (i.e., they are not encrypted); therefore, when referring to AuthEnvelopedData attributes, they are authenticated&unprotected and unauthenticated&unprotected. For this specification, unauthenticated attributes MUST NOT be included.
o AuthEnvelopedDataは2種類の属性をサポートしています。authAttrsおよびunauthAttrsフィールドの認証済み属性と非認証属性です。これらの属性はどちらも保護されていません（つまり、暗号化されていません）。したがって、AuthEnvelopedData属性を参照する場合、それらは認証および保護されず、認証も保護もされません。この仕様では、認証されていない属性を含めることはできません。
o AuthenticatedData supports two kinds of attributes: authenticated and unauthenticated attributes in the authAttrs and unauthAttrs fields, respectively. For this specification, unauthenticated attributes MUST NOT be included.
o AuthenticatedDataは2種類の属性をサポートします。authAttrsおよびunauthAttrsフィールドの認証済み属性と非認証属性です。この仕様では、認証されていない属性を含めることはできません。
o ContentWithAttributes supports one kind of attribute: content attributes in the attrs field.
o ContentWithAttributesは、attrsフィールドのコンテンツ属性という1種類の属性をサポートしています。
o AsymmetricKeyPackage supports one kind of attribute: asymmetric key attributes in the attributes field. If an attribute appears as part of an asymmetric key package, it SHOULD appear in the attributes field of the AsymmetricKeyPackage.
o AsymmetricKeyPackageは1種類の属性をサポートしています。属性フィールドの非対称キー属性です。属性が非対称キーパッケージの一部として表示される場合は、AsymmetricKeyPackageの属性フィールドに表示する必要があります（SHOULD）。
o SymmetricKeyPackage supports two kinds of attributes: symmetric key and symmetric key package attributes in the sKeyAttrs and sKeyPkgAttrs fields, respectively. Note that [RFC6031] prohibits the same attribute from appearing in both locations in the same SymmetricKeyPackage.
o SymmetricKeyPackageは、sKeyAttrsフィールドとsKeyPkgAttrsフィールドの対称キーと対称キーパッケージの属性の2種類の属性をそれぞれサポートしています。 [RFC6031]は、同じSymmetricKeyPackageの両方の場所に同じ属性を表示することを禁止していることに注意してください。
Note that this specification updates the following information object sets SignedAttributesSet, UnsignedAttributes, UnprotectedEnvAttributes, UnprotectedEncAttributes, AuthAttributeSet, UnauthAttributeSet, AuthEnvDataAttributeSet, UnauthEnvDataAttributeSet, and ContentAttributeSet from [RFC6268] as well as OneAsymmetricKeyAttributes from [RFC5958], SKeyPkgAttributes from [RFC6031], and SKeyAttributes from [RFC6031] to constrain the permissible locations for attributes. See Appendix A for the ASN.1 for the information object sets.
この仕様は、次の情報オブジェクトセットを更新することに注意してください。 [RFC6031]は、属性の許容される場所を制限します。情報オブジェクトセットのASN.1については、付録Aを参照してください。
The attributes defined in this document use 2002 ASN.1 [X.680] [X.681] [X.682] [X.683]. The attributes MUST be DER [X.690] encoded.
このドキュメントで定義されている属性は、2002 ASN.1 [X.680] [X.681] [X.682] [X.683]を使用しています。属性はDER [X.690]でエンコードする必要があります。
Each of the attributes has a single attribute value instance in the values set. Even though the syntax is defined as a set, there MUST be exactly one instance of AttributeValue present. Further, the SignedAttributes, UnsignedAttributes, UnprotectedAttributes, AuthAttributes, and UnauthAttributes are also defined as a set, and this set MUST include only one instance of any particular type of attribute. That is, any object identifier appearing in AttributeType MUST only appear one time in the set of attributes.
各属性の値セットには、単一の属性値インスタンスがあります。構文はセットとして定義されていますが、AttributeValueのインスタンスが1つだけ存在している必要があります。さらに、SignedAttributes、UnsignedAttributes、UnprotectedAttributes、AuthAttributes、およびUnauthAttributesもセットとして定義されており、このセットには特定のタイプの属性のインスタンスを1つだけ含める必要があります。つまり、AttributeTypeに現れるオブジェクト識別子は、属性のセットに1回だけ現れる必要があります。
SignedData, EnvelopedData, EncryptedData, AuthenticatedData, AuthEnvelopedData, and ContentWithAttributes were originally defined using the 1988 version of ASN.1. These definitions were updated to the 2008 version of ASN.1 by [RFC6268]. None of the new 2008 ASN.1 tokens are used; this allows 2002 compilers to compile 2008 ASN.1. AsymmetricKeyPackage and SymmetricKeyPackage are defined using the 2002 ASN.1.
SignedData、EnvelopedData、EncryptedData、AuthenticatedData、AuthEnvelopedData、およびContentWithAttributesは、もともと1988バージョンのASN.1を使用して定義されていました。これらの定義は、[RFC6268]によって2008バージョンのASN.1に更新されました。新しい2008 ASN.1トークンは使用されません。これにより、2002コンパイラは2008 ASN.1をコンパイルできます。 AsymmetricKeyPackageおよびSymmetricKeyPackageは、2002 ASN.1を使用して定義されています。
[RFC5652] and [RFC2634] define generally useful attributes for CMS using the 1988 version of ASN.1. These definitions were updated to the 2008 version of ASN.1 by [RFC6268] and the 2002 version of ASN.1 by [RFC5911], respectively. [RFC4108] and [RFC6019] also defined attributes using the 1988 version of ASN.1, which this document uses. Both were updated by [RFC5911] to the 2002 ASN.1. Refer to [RFC2634], [RFC4108], [RFC5652], and [RFC6019] for the attribute's semantics, but refer to [RFC5911] or [RFC6268] for the attribute's ASN.1 syntax.
[RFC5652]および[RFC2634]は、1988バージョンのASN.1を使用するCMSの一般的に有用な属性を定義します。これらの定義は、[RFC6268]によって2008年版のASN.1に、[RFC5911]によって2002年版のASN.1にそれぞれ更新されました。 [RFC4108]と[RFC6019]も、このドキュメントで使用する1988バージョンのASN.1を使用して属性を定義しました。どちらも[RFC5911]によって2002 ASN.1に更新されました。属性のセマンティクスについては[RFC2634]、[RFC4108]、[RFC5652]、および[RFC6019]を参照してください。属性のASN.1構文については[RFC5911]または[RFC6268]を参照してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの "は、RFC 2119 [RFC2119]で説明されているように解釈されます。
Attribute Scope: The scope of an attribute is the compilation of keying material to which the attribute value is assigned. The scope of each attribute is determined by its placement within the key package or content collection. See Section 31.
属性のスコープ：属性のスコープは、属性値が割り当てられるキー情報の編集です。各属性のスコープは、キーパッケージまたはコンテンツコレクション内での配置によって決まります。セクション31を参照してください。
SIR: Source Intermediary Receiver is a model with three entities:
SIR：Source Intermediary Receiverは、3つのエンティティを持つモデルです。
o A source initiates the delivery of a key to one or more receivers. It may wrap or encrypt the key for delivery. This is expected to be the common case, since a cleartext key is vulnerable to exposure and compromise. If the sender is to encrypt the key for delivery, it must know how to encrypt the key so that the receiver(s) can decrypt it. A sender may also carry out any of the functions of an intermediary.
o ソースは、1つ以上の受信者へのキーの配信を開始します。配信のために鍵をラップまたは暗号化する場合があります。平文の鍵は公開や侵害に対して脆弱であるため、これは一般的なケースであると予想されます。送信者が配信用にキーを暗号化する場合、受信者がキーを復号化できるようにキーを暗号化する方法を知っている必要があります。送信者は、仲介者の機能のいずれかを実行することもできます。
* The original key package creators are sometimes referred to as key source authorities. These entities create the symmetric and/or asymmetric key package and apply the initial CMS protecting layer, which is normally a SignedData but sometimes an AuthenticatedData. This initial CMS protecting layer is maintained through any intermediary for the receivers of the key package to ensure that receivers can validate the key source authority.
*元のキーパッケージの作成者は、キーソース機関と呼ばれることもあります。これらのエンティティは、対称および/または非対称のキーパッケージを作成し、最初のCMS保護層を適用します。これは通常SignedDataですが、AuthenticatedDataになることもあります。この初期CMS保護層は、キーパッケージの受信者の仲介者を通じて維持され、受信者がキーソースの権限を検証できるようにします。
o An intermediary does not have access to the cleartext key. An intermediary may perform source authentication on key packages and may append or remove management information related to the package. It may encapsulate the encrypted key packages in larger packages that contain other user data destined for later intermediaries or receivers.
o 仲介者はクリアテキストキーにアクセスできません。仲介者は、主要なパッケージでソース認証を実行し、パッケージに関連する管理情報を追加または削除できます。暗号化されたキーパッケージを、後の仲介者または受信者宛ての他のユーザーデータを含む大きなパッケージにカプセル化する場合があります。
o A receiver has access to the cleartext key. If the received key package is encrypted, it can unwrap or decrypt the encrypted key to obtain the cleartext key. A receiver may be the final destination of the cryptographic product. An element that acts as a receiver and is not the final destination of the key package may also act as a sender or as an intermediary. After receiving a key, a receiver may encrypt the received key for local storage.
o 受信者はクリアテキストキーにアクセスできます。受信したキーパッケージが暗号化されている場合は、暗号化されたキーをアンラップまたは復号化してクリアテキストキーを取得できます。受信者は、暗号化製品の最終的な宛先である場合があります。レシーバーとして機能し、キーパッケージの最終的な宛先ではない要素は、送信者または仲介者としても機能します。キーを受信した後、受信者はローカルストレージ用に受信したキーを暗号化できます。
NOTE: As noted in Section 1, a receiver can be tailored to support a particular combination of CMS content type(s), key package, and attribute(s) resulting in less-complex implementations. All of these tailored receivers can be supported by a common key management infrastructure that uses this specification; this also can yield efficiencies in generation and provisioning. Senders and intermediaries that have to understand multiple tailored receivers get the efficiency of a common specification language and modular implementation, as opposed to needing stove-piped processing for each different receiver.
注：セクション1で述べたように、CMSコンテンツタイプ、キーパッケージ、および属性の特定の組み合わせをサポートするようにレシーバーを調整することで、実装の複雑さが軽減されます。これらの調整されたレシーバーはすべて、この仕様を使用する共通の鍵管理インフラストラクチャーでサポートできます。これにより、生成とプロビジョニングの効率も向上します。複数の調整された受信者を理解する必要がある送信者と仲介者は、異なる受信者ごとにストーブパイプ処理を必要とするのではなく、共通の仕様言語とモジュール式実装の効率を実現します。
The following attributes are defined for [RFC5652]:
[RFC5652]には次の属性が定義されています。
o content-type [RFC5652] [RFC5911] [RFC6268] uniquely specifies the CMS content type. This attribute MUST be included as a signed, authenticated, or authenticated&unprotected attribute.
o content-type [RFC5652] [RFC5911] [RFC6268]は、CMSコンテンツタイプを一意に指定します。この属性は、署名済み、認証済み、または認証済みおよび非保護の属性として含める必要があります。
o message-digest [RFC5652] [RFC5911] [RFC6268] is the message digest of the encapsulated content calculated using the signer's message digest algorithm. As specified in [RFC5652], it must be included as a signed attribute and an authenticated attribute; as specified in [RFC5652], it must not be an unsigned attribute, unauthenticated attribute, or unprotected attribute; as specified in [RFC5083], it should not be included as an authenticated&unprotected attribute in AuthEnvelopedData. This attribute MUST NOT be included elsewhere.
o message-digest [RFC5652] [RFC5911] [RFC6268]は、署名者のメッセージダイジェストアルゴリズムを使用して計算された、カプセル化されたコンテンツのメッセージダイジェストです。 [RFC5652]で指定されているように、署名付き属性および認証済み属性として含める必要があります。 [RFC5652]で指定されているように、署名されていない属性、認証されていない属性、または保護されていない属性であってはなりません。 [RFC5083]で指定されているように、AuthEnvelopedDataのauthentication＆unprotected属性として含めることはできません。この属性は他の場所に含めてはいけません。
o content-hints [RFC2634] [RFC5911] [RFC6268] identifies the innermost content when multiple layers of encapsulation have been applied. Every instance of SignedData, AuthenticatedData, and AuthEnvelopedData that does not directly encapsulate a SymmetricKeyPackage, an AsymmetricKeyPackage, or an EncryptedKeyPackage [RFC6032] MUST include this attribute.
o content-hints [RFC2634] [RFC5911] [RFC6268]は、カプセル化の複数のレイヤーが適用されている場合、最も内側のコンテンツを識別します。 SymmetricKeyPackage、AsymmetricKeyPackage、またはEncryptedKeyPackage [RFC6032]を直接カプセル化しないSignedData、AuthenticatedData、およびAuthEnvelopedDataのすべてのインスタンスには、この属性を含める必要があります。
The community-identifiers attribute, defined in [RFC4108] and [RFC5911], lists the communities that are authorized recipients of the signed content. It can appear as a signed, authenticated, authenticated&unprotected, or content attribute. This attribute MUST be supported.
[RFC4108]と[RFC5911]で定義されているcommunity-identifiers属性は、署名されたコンテンツの許可された受信者であるコミュニティをリストします。これは、署名済み、認証済み、認証済み/非保護、またはコンテンツ属性として表示できます。この属性はサポートされている必要があります。
The 2002 ASN.1 syntax for the community-identifiers attribute is included for convenience:
community-identifiers属性の2002 ASN.1構文は、便宜上含まれています。
aa-communityIdentifiers ATTRIBUTE ::= {
TYPE CommunityIdentifiers
IDENTIFIED BY id-aa-communityIdentifiers }
id-aa-communityIdentifiers OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 40 }
CommunityIdentifiers ::= SEQUENCE OF CommunityIdentifier
CommunityIdentifier ::= CHOICE {
communityOID OBJECT IDENTIFIER,
hwModuleList HardwareModules }
HardwareModules ::= SEQUENCE {
hwType OBJECT IDENTIFIER,
hwSerialEntries SEQUENCE OF HardwareSerialEntry }
HardwareSerialEntry ::= CHOICE {
all NULL,
single OCTET STRING,
block SEQUENCE {
low OCTET STRING,
high OCTET STRING } }
Consult [RFC4108] for the attribute's semantics.
属性のセマンティクスについては、[RFC4108]を参照してください。
The key-province-v2 attribute identifies the scope, range, or jurisdiction in which the key is to be used. The key-province-v2 attribute MUST be present as a signed attribute or an authenticated attribute in the innermost CMS protection content type that provides authentication (i.e., SignedData, AuthEnvelopedData, or AuthenticatedData) and encapsulates a symmetric key package or an asymmetric key package.
key-province-v2属性は、キーが使用されるスコープ、範囲、または管轄区域を識別します。 key-province-v2属性は、認証（つまり、SignedData、AuthEnvelopedData、またはAuthenticatedData）を提供し、対称鍵パッケージまたは非対称鍵パッケージをカプセル化する最も内側のCMS保護コンテンツタイプの署名済み属性または認証済み属性として存在する必要があります。
The key-province attribute has the following syntax:
key-province属性の構文は次のとおりです。
aa-keyProvince-v2 ATTRIBUTE ::= {
TYPE KeyProvinceV2
IDENTIFIED BY id-aa-KP-keyProvinceV2 }
id-aa-KP-keyProvinceV2 OBJECT IDENTIFIER ::=
{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) attributes(5) 71 }
KeyProvinceV2 ::= OBJECT IDENTIFIER
The binary-signing-time attribute, defined in [RFC6019] and [RFC6268], specifies the time at which the signature or the Message Authentication Code (MAC) was applied to the encapsulated content. It can appear as a signed, authenticated, or authenticated&unprotected attribute.
[RFC6019]および[RFC6268]で定義されているbinary-signing-time属性は、署名またはメッセージ認証コード（MAC）がカプセル化されたコンテンツに適用された時刻を指定します。これは、署名済み、認証済み、または認証済みおよび非保護の属性として表示できます。
The 2002 ASN.1 syntax is included for convenience:
2002 ASN.1構文は便宜上含まれています。
aa-binarySigningTime ATTRIBUTE ::= {
TYPE BinarySigningTime
IDENTIFIED BY id-aa-binarySigningTime }
id-aa-binarySigningTime OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 46 }
BinarySigningTime ::= BinaryTime
BinaryTime ::= INTEGER (0..MAX)
Consult [RFC6019] for the binary-signing-time attribute's semantics.
binary-signing-time属性のセマンティクスについては、[RFC6019]を参照してください。
The manifest attribute lists the short titles of all the Transmission Security Nomenclature (TSEC-Nomenclature) attributes from inner key packages. It MUST only appear as an outermost signed, authenticated, or authenticated&unprotected attribute. If a short title is repeated in inner packages, it need only appear once in the manifest attribute. The manifest attribute MUST NOT appear in the same level as the TSEC-Nomenclature from Section 10.
manifest属性は、内部キーパッケージのすべてのTransmission Security Nomenclature（TSEC-Nomenclature）属性の短いタイトルをリストします。これは、最も外側の署名、認証、または認証および非保護の属性としてのみ表示する必要があります。短いタイトルが内部パッケージで繰り返される場合、manifest属性に1回だけ表示する必要があります。 manifest属性は、セクション10のTSEC-Nomenclatureと同じレベルに出現してはなりません（MUST NOT）。
The manifest attribute has the following syntax:
manifest属性の構文は次のとおりです。
aa-manifest ATTRIBUTE ::= {
TYPE Manifest
IDENTIFIED BY id-aa-KP-manifest }
id-aa-KP-manifest OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1)
gov(101) dod(2) infosec(1) attributes(5) 72 }
Manifest ::= SEQUENCE SIZE (1..MAX) OF ShortTitle
The key-algorithm attribute indirectly specifies the size and format of the keying material in the skey field of a symmetric key package, which is defined in [RFC6031]. It can appear as a symmetric key, symmetric key package, signed, authenticated, authenticated&unprotected, or content attribute. If this attribute appears as a signed attribute, then all of the keying material within the SignedData content MUST be associated with the same algorithm. If this attribute appears as an authenticated or authenticated&unprotected attribute, then all of the keying material within the AuthenticatedData or AuthEnvelopedData content type MUST be associated with the same algorithm. If this attribute appears as a content attribute, then all of the keying material within the collection MUST be associated with the same algorithm. If both the key-wrap-algorithm (Section 24) and key-algorithm attributes apply to an sKey, then the key-algorithm attribute refers to the decrypted value of sKey rather than to the content of sKey itself. This attribute MUST be supported.
key-algorithm属性は、[RFC6031]で定義されている対称鍵パッケージのskeyフィールドの鍵素材のサイズと形式を間接的に指定します。対称キー、対称キーパッケージ、署名済み、認証済み、認証済み/非保護、またはコンテンツ属性として表示できます。この属性が署名された属性として表示される場合、SignedDataコンテンツ内のすべてのキー情報は同じアルゴリズムに関連付けられている必要があります。この属性が認証済みまたは認証済みおよび保護されていない属性として表示される場合、AuthenticatedDataまたはAuthEnvelopedDataコンテンツタイプ内のすべてのキー情報は、同じアルゴリズムに関連付けられている必要があります。この属性がコンテンツ属性として表示される場合、コレクション内のすべてのキー素材は同じアルゴリズムに関連付けられている必要があります。 key-wrap-algorithm（セクション24）とkey-algorithm属性の両方がsKeyに適用される場合、key-algorithm属性はsKey自体の内容ではなく、sKeyの復号化された値を参照します。この属性はサポートされている必要があります。
The key-algorithm attribute has the following syntax:
key-algorithm属性の構文は次のとおりです。
aa-keyAlgorithm ATTRIBUTE ::= {
TYPE KeyAlgorithm
IDENTIFIED BY id-kma-keyAlgorithm }
id-kma-keyAlgorithm OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1)
gov(101) dod(2) infosec(1) keying-material-attributes(13) 1 }
KeyAlgorithm ::= SEQUENCE {
keyAlg OBJECT IDENTIFIER,
checkWordAlg [1] OBJECT IDENTIFIER OPTIONAL,
crcAlg [2] OBJECT IDENTIFIER OPTIONAL }
The fields in the key-algorithm attribute have the following semantics:
key-algorithm属性のフィールドには、次のセマンティクスがあります。
o keyAlg specifies the size and format of the keying material.
o keyAlgは、キー素材のサイズとフォーマットを指定します。
o If the particular key format supports more than one check-word algorithm, then the OPTIONAL checkWordAlg identifier indicates which check-word algorithm was used to generate the check word that is present. If the check-word algorithm is implied by the key algorithm, then the checkWordAlg field SHOULD be omitted.
o 特定のキー形式が複数のチェックワードアルゴリズムをサポートする場合、OPTIONAL checkWordAlg識別子は、存在するチェックワードの生成に使用されたチェックワードアルゴリズムを示します。チェックワードアルゴリズムがキーアルゴリズムによって暗示されている場合は、checkWordAlgフィールドを省略してください。
o If the particular key format supports more than one Cyclic Redundancy Check (CRC) algorithm, then the OPTIONAL crcAlg identifier indicates which CRC algorithm was used to generate the value that is present. If the CRC algorithm is implied by the key algorithm, then the crcAlg field SHOULD be omitted.
o 特定のキー形式が複数の巡回冗長検査（CRC）アルゴリズムをサポートする場合、OPTIONAL crcAlg識別子は、存在する値を生成するために使用されたCRCアルゴリズムを示します。 CRCアルゴリズムがキーアルゴリズムによって暗示される場合、crcAlgフィールドは省略されるべきです（SHOULD）。
The keyAlg identifier, the checkWordAlg identifier, and the crcAlg identifier are object identifiers. The use of an object identifier accommodates any algorithm from any registry.
keyAlg識別子、checkWordAlg識別子、およびcrcAlg識別子はオブジェクト識別子です。オブジェクト識別子を使用すると、レジストリからのアルゴリズムに対応できます。
The format of the keying material in the skey field of a symmetric key package will not match this attribute if the keying material is split (see Section 18 for a discussion of the split-identifier attribute). In this situation, this attribute identifies the format of the keying material once the two splits are combined.
対称鍵パッケージのskeyフィールドの鍵素材の形式は、鍵素材が分割されている場合、この属性と一致しません（split-identifier属性の説明については、セクション18を参照してください）。この状況では、この属性は、2つの分割が結合された後の鍵情報の形式を識別します。
Due to multiple layers of encapsulation or the use of content collections, the key-algorithm attribute can appear in more than one location in the overall key package. When there are multiple occurrences of the key-algorithm attribute within the same scope, the keyAlg field MUST match in all instances. The OPTIONAL checkWordAlg and crcAlg fields can be omitted in the key-algorithm attribute when it appears as a signed, authenticated, authenticated&unprotected, or content attribute. However, if these optional fields are present, they MUST also match the other occurrences within the same scope. Receivers MUST reject any key package that fails these consistency checks.
カプセル化の複数のレイヤーまたはコンテンツコレクションの使用により、key-algorithm属性は、キーパッケージ全体の複数の場所に表示される可能性があります。同じスコープ内にkey-algorithm属性が複数存在する場合、keyAlgフィールドはすべてのインスタンスで一致する必要があります。オプションのcheckWordAlgフィールドとcrcAlgフィールドは、署名済み、認証済み、認証済み、および保護されていない、またはコンテンツ属性として表示される場合、key-algorithm属性で省略できます。ただし、これらのオプションフィールドが存在する場合、それらは同じスコープ内の他のオカレンスとも一致する必要があります。受信者は、これらの整合性チェックに失敗したすべてのキーパッケージを拒否する必要があります。
The user-certificate attribute specifies the type, format, and value of an X.509 certificate and is used in asymmetric key package's attributes field. This attribute can appear as an asymmetric key attribute. This attribute MUST NOT appear in an asymmetric key package attributes field that includes the other-certificate-formats attribute. Symmetric key packages do not contain any certificates, so the user-certificate attribute MUST NOT appear in a symmetric key package. The user-certificate attribute MUST NOT appear as a signed, authenticated, authenticated&unprotected, or content attribute. This attribute MUST be supported.
user-certificate属性は、X.509証明書のタイプ、形式、および値を指定し、非対称鍵パッケージの属性フィールドで使用されます。この属性は、非対称キー属性として表示できます。この属性は、other-certificate-formats属性を含む非対称キーパッケージ属性フィールドに表示してはなりません（MUST NOT）。対称鍵パッケージには証明書が含まれていないため、ユーザー証明書属性を対称鍵パッケージに含めてはなりません（MUST NOT）。 user-certificate属性は、署名済み、認証済み、認証済み、および保護なし、またはコンテンツ属性として表示してはなりません。この属性はサポートされている必要があります。
The syntax is taken from [X.509] but redefined using the ATTRIBUTE CLASS from [RFC5912]. The user-certificate attribute has the following syntax:
構文は[X.509]から取得されますが、[RFC5912]のATTRIBUTE CLASSを使用して再定義されます。 user-certificate属性の構文は次のとおりです。
aa-userCertificate ATTRIBUTE ::= {
TYPE Certificate
EQUALITY MATCHING RULE certificateExactMatch
IDENTIFIED BY id-at-userCertificate }
id-at-userCertificate OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) ds(5) attributes(4) 36 }
Since the user-certificate attribute MUST NOT appear as a signed, authenticated, authenticated&unprotected, or content attribute, an asymmetric key package cannot include multiple occurrences of the user-certificate attribute within the same scope. Receivers MUST reject any asymmetric key package in which the user-certificate attribute appears as a signed, authenticated, authenticated&unprotected, or content attribute.
ユーザー証明書属性は、署名済み、認証済み、認証済み、および保護されていない、またはコンテンツ属性として表示されてはならないため、非対称鍵パッケージに、同じスコープ内でユーザー証明書属性の複数のオカレンスを含めることはできません。受信者は、ユーザー証明書属性が署名済み、認証済み、認証済み、および保護されていない、またはコンテンツ属性として表示される非対称鍵パッケージを拒否する必要があります。
The key-package-receivers-v2 attribute indicates the intended audience for the key package. The key-package-receivers-v2 attribute is not intended for access control decisions; rather, intermediate systems may use this attribute to make routing and relaying decisions. If the receiver is not listed, it will not be able to decrypt the package; therefore, the receiver SHOULD reject the key package if the key-package-receivers-v2 attribute is present and they are not listed as an intended receiver. The key-package-receivers-v2 attribute can be used as a signed, authenticated, authenticated&unprotected, or content attribute. If the key-package-receivers-v2 attribute is associated with a collection, then the named receivers MUST be able to receive all of the key packages within the collection. This attribute MUST be supported.
key-package-receivers-v2属性は、キーパッケージの対象読者を示します。 key-package-receivers-v2属性は、アクセス制御の決定を目的としたものではありません。むしろ、中間システムはこの属性を使用して、ルーティングとリレーの決定を行うことができます。レシーバーがリストされていない場合は、パッケージを復号化できません。したがって、key-package-receivers-v2属性が存在し、それらが意図されたレシーバーとしてリストされていない場合、レシーバーはキーパッケージを拒否する必要があります（SHOULD）。 key-package-receivers-v2属性は、署名済み、認証済み、認証済みおよび保護なし、またはコンテンツ属性として使用できます。 key-package-receivers-v2属性がコレクションに関連付けられている場合、名前付きレシーバーはコレクション内のすべてのキーパッケージを受信できる必要があります。この属性はサポートされている必要があります。
The key-package-receivers-v2 attribute has the following syntax:
key-package-receivers-v2属性の構文は次のとおりです。
aa-keyPackageReceivers-v2 ATTRIBUTE ::= {
TYPE KeyPkgReceiversV2
IDENTIFIED BY id-kma-keyPkgReceiversV2 }
id-kma-keyPkgReceiversV2 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) keying-material-attributes(13) 16 }
KeyPkgReceiversV2 ::= SEQUENCE SIZE (1..MAX) OF KeyPkgReceiver
KeyPkgReceiver ::= CHOICE {
sirEntity [0] SIREntityName,
community [1] CommunityIdentifier }
The key-package-receivers-v2 attribute contains a list of receiver identifiers. The receiver identifier is either a SIREntityName [RFC7191] or a CommunityIdentifier (see Section 3). The SIREntityName syntax does not impose any particular structure on the receiver identifier, but it does require registration of receiver identifier types. The nameType ensures that two receiver identifiers of different types that contain the same values are not interpreted as equivalent. Name types are expected to be defined that represent several different granularities. For example, one name type will represent the receiver organization. At a finer granularity, the name type will identify a specific cryptographic device, perhaps using a manufacturer identifier and serial number.
key-package-receivers-v2属性には、受信者識別子のリストが含まれています。受信者識別子は、SIREntityName [RFC7191]またはCommunityIdentifierです（セクション3を参照）。 SIREntityName構文は、レシーバー識別子に特定の構造を課しませんが、レシーバー識別子タイプの登録を必要とします。 nameTypeは、同じ値を含む異なるタイプの2つのレシーバー識別子が同等として解釈されないようにします。いくつかの異なる粒度を表す名前タイプが定義されることが期待されています。たとえば、1つの名前タイプはレシーバー組織を表します。より細かい単位で、名前タイプは、おそらく製造元の識別子とシリアル番号を使用して、特定の暗号デバイスを識別します。
If a receiver does not recognize a particular nameType or a community identifier, then keying material within the scope of the unrecognized nameType or community identifier MUST NOT be used in any manner. However, the receiver need not discard the associated key package. Since many cryptographic devices are programmable, a different firmware load may recognize the nameType. Likewise, a change in the configuration may lead to the recognition of a previously unrecognized community identifier. Therefore, the receiver may retain the key package, but refuse to use it for anything with a firmware load that does not recognize the nameType or a configuration that does not recognize the community identifier.
受信者が特定のnameTypeまたはコミュニティ識別子を認識しない場合、認識されないnameTypeまたはコミュニティ識別子の範囲内のキーイング情報は、いかなる方法でも使用してはなりません（MUST NOT）。ただし、受信者は関連するキーパッケージを破棄する必要はありません。多くの暗号デバイスはプログラム可能であるため、別のファームウェアロードがnameTypeを認識する場合があります。同様に、構成の変更により、以前は認識されていなかったコミュニティ識別子が認識される可能性があります。したがって、レシーバーはキーパッケージを保持しますが、nameTypeを認識しないファームウェアロードまたはコミュニティIDを認識しない構成での使用には拒否します。
Whenever a key package is saved for later processing due to an unrecognized nameType or community identifier, subsequent processing MUST NOT rely on any checks that were made the first time the key package processing was attempted. That is, the subsequent processing MUST include the full complement of checks. Further, a receipt for the packages MUST NOT be generated unless all of these checks are successfully completed.
認識されないnameTypeまたはコミュニティ識別子が原因で、キーパッケージが後の処理のために保存されるときはいつでも、後続の処理は、キーパッケージ処理が最初に試行されたときに行われたチェックに依存してはなりません。つまり、後続の処理にはチェックの完全な補完が含まれている必要があります。さらに、これらのチェックがすべて正常に完了しない限り、パッケージの領収書を生成してはなりません。
Due to multiple layers of encapsulation or the use of content collections, the key-package-receivers-v2 attribute can appear in more than one location in the overall key package. When that happens, each occurrence is evaluated independently.
カプセル化の複数のレイヤーまたはコンテンツコレクションの使用により、key-package-receivers-v2属性は、キーパッケージ全体の複数の場所に表示される場合があります。その場合、発生ごとに個別に評価されます。
In a content collection, each member of the collection might contain its own signed, authenticated, authenticated&unprotected, or content attribute that includes a key-package-receivers-v2 attribute. In this situation, each member of the collection is evaluated separately, and any member that includes an acceptable receiver SHOULD be retained. Other members can be rejected or retained for later processing with a different firmware load.
コンテンツコレクションでは、コレクションの各メンバーに、key-package-receivers-v2属性を含む独自の署名、認証、認証、非保護、またはコンテンツ属性を含めることができます。この状況では、コレクションの各メンバーは個別に評価され、受け入れ可能なレシーバーを含むメンバーは保持されるべきです（SHOULD）。他のメンバーは拒否されるか、別のファームウェアロードで後で処理するために保持されます。
The Telecommunications Security Nomenclature (TSEC-Nomenclature) attribute provides the name for a piece of keying material, which always includes a printable string called a "short title" (see below). The TSEC-Nomenclature attribute also contains other identifiers when the shortTitle is insufficient to uniquely name a particular piece of keying material. This attribute can appear as a symmetric key, symmetric key package, asymmetric key, signed, authenticated, authenticated&unprotected, or content attribute. If this attribute appears in the sKeyAttrs field, the editionID, registerID, and segmentID attribute fields MUST NOT be ranges. If this attribute appears as a signed, authenticated, authenticated&unprotected, or content attribute, all of the keying material within the associated content MUST have the same shortTitle, and the attribute value MUST contain only a shortTitle. That is, when this attribute appears as a signed, authenticated, authenticated&unprotected, or content attribute, all of the optional fields MUST be absent. If this attribute is associated with a collection, all of the keying material within the collection MUST have the same shortTitle; however, the editionID, registerID, and segmentID will be different for each key package in the collection. This attribute MUST be supported.
Telecommunications Security Nomenclature（TSEC-Nomenclature）属性は、キーマテリアルの名前を提供します。これには、「短いタイトル」と呼ばれる印刷可能な文字列が常に含まれます（以下を参照）。 TSEC-Nomenclature属性には、shortTitleで特定のキー情報に一意の名前を付けるのに不十分な場合、他の識別子も含まれます。この属性は、対称鍵、対称鍵パッケージ、非対称鍵、署名済み、認証済み、認証済み、保護なし、またはコンテンツ属性として表示できます。この属性がsKeyAttrsフィールドに表示される場合、editionID、registerID、およびsegmentID属性フィールドは範囲であってはなりません。この属性が署名された、認証された、認証された、保護されていない、またはコンテンツ属性として表示される場合、関連するコンテンツ内のすべてのキー素材は同じshortTitleを持ち、属性値にはshortTitleのみが含まれている必要があります。つまり、この属性が署名された、認証された、認証された、保護されていない、またはコンテンツ属性として表示される場合、すべてのオプションフィールドは存在しない必要があります。この属性がコレクションに関連付けられている場合、コレクション内のすべてのキー情報は同じshortTitleを持つ必要があります。ただし、editionID、registerID、およびsegmentIDは、コレクション内のキーパッケージごとに異なります。この属性はサポートされている必要があります。
The TSEC-Nomenclature attribute has the following syntax:
TSEC-Nomenclature属性の構文は次のとおりです。
aa-tsecNomenclature ATTRIBUTE ::= {
TYPE TSECNomenclature
IDENTIFIED BY id-kma-TSECNomenclature }
id-kma-TSECNomenclature OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) keying-material-attributes(13) 3 }
TSECNomenclature ::= SEQUENCE {
shortTitle ShortTitle,
editionID EditionID OPTIONAL,
registerID RegisterID OPTIONAL,
segmentID SegmentID OPTIONAL }
ShortTitle ::= PrintableString
EditionID ::= CHOICE {
char CHOICE {
charEdition [1] CharEdition,
charEditionRange [2] CharEditionRange }
num CHOICE {
numEdition [3] NumEdition,
numEditionRange [4] NumEditionRange } }
CharEdition ::= PrintableString
CharEditionRange ::= SEQUENCE {
firstCharEdition CharEdition,
lastCharEdition CharEdition }
NumEdition ::= INTEGER (0..308915776)
NumEditionRange ::= SEQUENCE {
firstNumEdition NumEdition,
lastNumEdition NumEdition }
RegisterID ::= CHOICE {
register [5] Register,
registerRange [6] RegisterRange }
Register ::= INTEGER (0..2147483647)
RegisterRange ::= SEQUENCE {
firstRegister Register,
lastRegister Register }
SegmentID ::= CHOICE {
segmentNumber [7] SegmentNumber,
segmentRange [8] SegmentRange }
SegmentNumber ::= INTEGER (1..127)
SegmentRange ::= SEQUENCE {
firstSegment SegmentNumber,
lastSegment SegmentNumber }
The fields in the TSEC-Nomenclature attribute have the following semantics:
TSEC-Nomenclature属性のフィールドには、次のセマンティクスがあります。
o The shortTitle consists of up to 32 alphanumeric characters. shortTitle processing always uses the value in its entirety.
o shortTitleは、最大32文字の英数字で構成されます。 shortTitle処理では常に値全体が使用されます。
o The editionID is OPTIONAL, and the editionIdentifier is used to distinguish accountable items. The editionID consists of either six alphanumeric characters or an integer. When present, the editionID is either a single value or a range. The integer encoding should be used when it is important to keep key package size to a minimum.
o editionIDはオプションであり、editionIdentifierは責任のあるアイテムを区別するために使用されます。 editionIDは、6つの英数字または整数で構成されます。存在する場合、editionIDは単一の値または範囲のいずれかです。キーパッケージのサイズを最小限に抑えることが重要な場合は、整数エンコーディングを使用する必要があります。
o The registerID is OPTIONAL. For electronic keying material, the registerID is usually omitted. The registerID is an accounting number assigned to identify Communications Security (COMSEC) material. The registerID is either a single value or a range.
o registerIDはオプションです。電子キー素材の場合、registerIDは通常省略されます。 registerIDは、Communications Security（COMSEC）資料を識別するために割り当てられた会計番号です。 registerIDは、単一の値または範囲です。
o The segmentID is OPTIONAL, and it distinguishes the individual symmetric keys delivered in one edition. A unique segmentNumber is assigned to each key in an edition. The segmentNumber is set to one for the first item in each edition, and it is incremented by one for each additional item within that edition. The segmentID is either a single value or a range.
o segmentIDはオプションであり、1つのエディションで提供される個々の対称鍵を区別します。エディションの各キーには一意のsegmentNumberが割り当てられています。各エディションの最初のアイテムについては、segmentNumberが1に設定され、そのエディション内の追加のアイテムごとに1ずつ増加します。 segmentIDは、単一の値または範囲です。
The order that the keying material will appear in the key package is
illustrated by the following example: a cryptographic device may
require fresh keying material every day, an edition represents the
keying material for a single month, and the segments represent the
keying material for a day within that month. Consider a key package
that contains the keying material for July and August; it will
contain keying material for 62 days. The keying material will appear
in the following order: Edition 1, Segment 1; Edition 1, Segment 2;
Edition 1, Segment 3; ...; Edition 1, Segment 31; Edition 2,
Segment 1; Edition 2, Segment 2; Edition 2, Segment 3; ...;
Edition 2, Segment 31.
Due to multiple layers of encapsulation or the use of content collections, the TSEC-Nomenclature attribute can appear in more than one location in the overall key package. When there are multiple occurrences of the TSEC-Nomenclature attribute within the same scope, the shortTitle field MUST match in all instances. Receivers MUST reject any key package that fails these consistency checks.
カプセル化の複数のレイヤーまたはコンテンツコレクションの使用により、TSEC-Nomenclature属性は、キーパッケージ全体の複数の場所に表示される可能性があります。同じスコープ内にTSEC-Nomenclature属性が複数出現する場合、すべてのインスタンスでshortTitleフィールドが一致する必要があります。受信者は、これらの整合性チェックに失敗したすべてのキーパッケージを拒否する必要があります。
When the manifest attribute from Section 6 is included in an outer layer, the ShortTitle field values present in TSEC-Nomenclature attributes MUST be one of the values in the manifest attribute. Receivers MUST reject any key package that fails this consistency check.
セクション6のマニフェスト属性が外側のレイヤーに含まれている場合、TSEC-Nomenclature属性に存在するShortTitleフィールド値は、マニフェスト属性の値の1つである必要があります。受信者は、この整合性チェックに失敗したすべてのキーパッケージを拒否する必要があります。
The key-purpose attribute specifies the intended purpose of the key material. It can appear as a symmetric key, symmetric key package, asymmetric key, signed, authenticated, authenticated&unprotected, or content attribute. If the key-purpose attribute appears as a signed, authenticated, authenticated&unprotected, or content attribute, then all of the keying material within the associated content MUST have the same key purpose value.
key-purpose属性は、鍵素材の使用目的を指定します。対称鍵、対称鍵パッケージ、非対称鍵、署名済み、認証済み、認証済み/非保護、またはコンテンツ属性として表示できます。 key-purpose属性が、signed、authenticated、authentication＆unprotected、またはcontent属性として表示される場合、関連するコンテンツ内のすべてのキー生成情報は、同じキー目的値を持つ必要があります。
The key-purpose attribute has the following syntax:
key-purpose属性の構文は次のとおりです。
aa-keyPurpose ATTRIBUTE ::= {
TYPE KeyPurpose
IDENTIFIED BY id-kma-keyPurpose }
id-kma-keyPurpose OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) keying-material-attributes(13) 13 }
KeyPurpose ::= ENUMERATED {
n-a (0), -- Not Applicable
A (65), -- Operational
B (66), -- Compatible Multiple Key
L (76), -- Logistics Combinations
M (77), -- Maintenance
R (82), -- Reference
S (83), -- Sample
T (84), -- Training
V (86), -- Developmental
X (88), -- Exercise
Z (90), -- "On the Air" Testing
... -- Expect additional key purpose values -- }
Due to multiple layers of encapsulation or the use of content collections, the key-purpose attribute can appear in more than one location in the overall key package. When there are multiple occurrences of the key-purpose attribute within the same scope, all fields within the attribute MUST contain exactly the same values. Receivers MUST reject any key package that fails these consistency checks.
カプセル化の複数のレイヤーまたはコンテンツコレクションの使用により、key-purpose属性は、キーパッケージ全体の複数の場所に表示される場合があります。同じスコープ内でkey-purpose属性の複数のオカレンスがある場合、属性内のすべてのフィールドには、まったく同じ値が含まれている必要があります。受信者は、これらの整合性チェックに失敗したすべてのキーパッケージを拒否する必要があります。
The key-use attribute specifies the intended use of the key material. It can appear as a symmetric key, symmetric key package, asymmetric, signed, authenticated, authenticated&unprotected, or content attribute. If the key-use attribute appears as a signed, authenticated, authenticated&unprotected, or content attribute, then all of the keying material within the associated content MUST have the same key use value.
key-use属性は、キーマテリアルの使用目的を指定します。これは、対称鍵、対称鍵パッケージ、非対称、署名済み、認証済み、認証済み/非保護、またはコンテンツ属性として表示できます。 key-use属性が署名済み、認証済み、認証済み、および保護されていない、またはコンテンツ属性として表示される場合、関連するコンテンツ内のすべてのキー素材は同じキー使用値を持つ必要があります。
The key-use attribute has the following syntax:
key-use属性の構文は次のとおりです。
aa-key-Use ATTRIBUTE ::= {
TYPE KeyUse
IDENTIFIED BY id-kma-keyUse }
id-kma-keyUse OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) keying-material-attributes(13) 14 }
KeyUse ::= ENUMERATED {
n-a (0), -- Not applicable
ffk (1), -- FIREFLY/CROSSTALK Key (Basic Format)
kek (2), -- Key Encryption Key
kpk (3), -- Key Production Key
msk (4), -- Message Signature Key
qkek (5), -- QUADRANT Key Encryption Key
tek (6), -- Traffic Encryption Key
tsk (7), -- Transmission Security Key
trkek (8), -- Transfer Key Encryption Key
nfk (9), -- Netted FIREFLY Key
effk (10), -- FIREFLY Key (Enhanced Format)
ebfk (11), -- FIREFLY Key (Enhanceable Basic Format)
aek (12), -- Algorithm Encryption Key
wod (13), -- Word of Day
kesk (246), -- Key Establishment Key
eik (247), -- Entity Identification Key
ask (248), -- Authority Signature Key
kmk (249), -- Key Modifier Key
rsk (250), -- Revocation Signature Key
csk (251), -- Certificate Signature Key
sak (252), -- Symmetric Authentication Key
rgk (253), -- Random Generation Key
cek (254), -- Certificate Encryption Key
exk (255), -- Exclusion Key
... -- Expect additional key use values -- }
The values for the key-use attribute have the following semantics:
key-use属性の値には、次のセマンティクスがあります。
o ffk: A FIREFLY/CROSSTALK key is used to establish a Key Establishment Key (KEK) or a Transmission Encryption Key (TEK) between two parties. The KEK or TEK generated from the exchange is used with a symmetric encryption algorithm. This key use value is associated with keys in the basic format.
o ffk：FIREFLY / CROSSTALKキーは、2つのパーティ間でキー確立キー（KEK）または伝送暗号化キー（TEK）を確立するために使用されます。交換から生成されたKEKまたはTEKは、対称暗号化アルゴリズムで使用されます。このキー使用値は、基本形式のキーに関連付けられています。
o kek: A Key Encryption Key is used to encrypt or decrypt other keys for transmission or storage.
o kek：キー暗号化キーは、送信または保存用に他のキーを暗号化または復号化するために使用されます。
o kpk: A Key Production Key is used to initialize a keystream generator for the production of other electronically generated keys.
o kpk：キー生成キーは、他の電子的に生成されたキーの生成のためにキーストリームジェネレーターを初期化するために使用されます。
o msk: A Message Signature Key is used in a digital signature process that operates on a message to assure message source authentication, message integrity, and non-repudiation.
o msk：メッセージ署名キーは、メッセージに作用するデジタル署名プロセスで使用され、メッセージソースの認証、メッセージの整合性、および否認防止を保証します。
o qkek: QUADRANT Key Encryption Key is one part of a tamper-resistance solution.
o qkek：QUADRANT Key Encryption Keyは改ざん防止ソリューションの一部です。
o tek: A Traffic Encryption Key is used to encrypt plaintext, to superencrypt previously encrypted data, and/or to decrypt ciphertext.
o tek：トラフィック暗号化キーは、平文の暗号化、以前に暗号化されたデータの超暗号化、暗号文の復号化に使用されます。
o tsk: A Transmission Security Key is used to protect transmissions from interception and exploitation by means other than cryptanalysis.
o tsk：送信セキュリティキーは、暗号解読以外の方法で送信を傍受や悪用から保護するために使用されます。
o trkek: Transfer Key Encryption Key. The keys used to protect communications with an intermediary.
o trkek：転送キー暗号化キー。仲介者との通信を保護するために使用されるキー。
o nfk: A Netted FIREFLY Key is a FIREFLY key that has an edition number associated with it. When rekeyed, it is incremented, preventing communications with FIREFLY key of previous editions. This edition number is maintained within a universal edition.
o nfk：ネットFIREFLYキーは、エディション番号が関連付けられているFIREFLYキーです。キーを再生成すると、キーが増加し、以前のエディションのFIREFLYキーとの通信ができなくなります。このエディション番号は、ユニバーサルエディション内で維持されます。
o effk: Enhanced FIREFLY Key is used to establish a KEK or a TEK between two parties. The KEK or TEK generated from an exchange is used with a symmetric encryption algorithm. This key use value is associated with keys in the enhanced format.
o effk：拡張FIREFLYキーは、2者間でKEKまたはTEKを確立するために使用されます。交換から生成されたKEKまたはTEKは、対称暗号化アルゴリズムで使用されます。このキー使用値は、拡張形式のキーに関連付けられています。
o ebfk: Enhanceable Basic FIREFLY Key is used to establish a KEK or a TEK between two parties. The KEK or TEK generated from an exchange is used with a symmetric encryption algorithm. This key use value is associated with keys in the enhanceable basic format.
o ebfk：Enhanceable Basic FIREFLY Keyは、2者間でKEKまたはTEKを確立するために使用されます。交換から生成されたKEKまたはTEKは、対称暗号化アルゴリズムで使用されます。このキー使用値は、拡張可能な基本形式のキーに関連付けられています。
o aek: An Algorithm Encryption Key is used to encrypt or decrypt an algorithm implementation as well as other functionality in the implementation.
o aek：アルゴリズム暗号化キーは、アルゴリズムの実装および実装の他の機能を暗号化または復号化するために使用されます。
o wod: A key used to generate the Word of the Day (WOD).
o wod：今日の単語（WOD）を生成するために使用されるキー。
o kesk: A Key Establishment Key is an asymmetric key set (e.g., public/private/parameters) used to enable the establishment of symmetric key(s) between entities.
o kesk：Key Establishment Keyは、エンティティ間の対称鍵の確立を可能にするために使用される非対称鍵セット（例：public / private / parameters）です。
o eik: An Entity Identification Key is an asymmetric key set (e.g., public/private/parameters) used to identify one entity to another for access control and other similar purposes.
o eik：エンティティ識別キーは、アクセス制御や他の同様の目的でエンティティを別のエンティティに識別するために使用される非対称キーセット（例：public / private / parameters）です。
o ask: An Authority Signature Key is an asymmetric key set (e.g., public/private/parameters) used by designated authorities to sign objects such as Trust Anchor Management Protocol (TAMP) messages and firmware packages.
o ask：Authority Signature Keyは、指定された機関がTrust Anchor Management Protocol（TAMP）メッセージやファームウェアパッケージなどのオブジェクトに署名するために使用する非対称鍵セット（例：public / private / parameters）です。
o kmk: A Key Modifier Key is a symmetric key used to modify the results of the process that forms a symmetric key from a public key exchange process.
o kmk：Key Modifier Keyは、公開鍵交換プロセスから対称鍵を形成するプロセスの結果を変更するために使用される対称鍵です。
o rsk: A Revocation Signature Key is an asymmetric key set (e.g., public/private/parameters) used to sign and authenticate revocation lists and compromised key lists.
o rsk：失効署名キーは、失効リストと不正使用されたキーリストの署名と認証に使用される非対称キーセット（例：public / private / parameters）です。
o csk: A Certificate Signature Key is an asymmetric key set (e.g., public/private/parameters) used to sign and authenticate public key certificates.
o csk：証明書署名鍵は、公開鍵証明書の署名と認証に使用される非対称鍵セット（例：public / private / parameters）です。
o sak: A Symmetric Authentication Key is used in a MAC algorithm to provide message integrity. Differs from a Message Signature Key in that it is symmetric key material and it does not provide source authentication or non-repudiation.
o sak：対称認証キーはMACアルゴリズムで使用され、メッセージの整合性を提供します。対称鍵素材であり、ソース認証または否認防止を提供しないという点で、メッセージ署名鍵とは異なります。
o rgk: Random Generation Key is a key used to seed a deterministic pseudorandom number generator.
o rgk：ランダム生成キーは、確定的疑似乱数ジェネレーターをシードするために使用されるキーです。
o cek: A Certificate Encryption Key is used to encrypt public key certificates to support privacy.
o cek：証明書暗号化キーは、公開キー証明書を暗号化してプライバシーをサポートするために使用されます。
o exk: An Exclusion Key is a symmetric key used to cryptographically subdivide a single large security domain into smaller segregated domains.
o exk：Exclusion Keyは、単一の大きなセキュリティドメインを暗号化して小さな分離ドメインに細分するために使用される対称キーです。
Due to multiple layers of encapsulation or the use of content collections, the key-use attribute can appear in more than one location in the overall key package. When there are multiple occurrences of the key-use attribute within the same scope, all fields within the attribute MUST contain exactly the same values. Receivers MUST reject any key package that fails these consistency checks.
カプセル化の複数のレイヤーまたはコンテンツコレクションの使用により、key-use属性は、キーパッケージ全体の複数の場所に表示される場合があります。同じスコープ内でkey-use属性が複数出現する場合、属性内のすべてのフィールドにまったく同じ値を含める必要があります。受信者は、これらの整合性チェックに失敗したすべてのキーパッケージを拒否する必要があります。
The transport-key attribute identifies whether an asymmetric key is a transport key or an operational key (i.e., whether or not the key can be used as is). It can appear as an asymmetric key, signed, authenticated, authenticated&unprotected, or content attribute. If the transport-key attribute appears as a signed, authenticated, authenticated&unprotected, or content attribute, then all of the keying material within the associated content MUST have the same operational/transport key material.
transport-key属性は、非対称鍵がトランスポート鍵であるか操作鍵であるか（つまり、鍵をそのまま使用できるかどうか）を識別します。非対称キー、署名済み、認証済み、認証済み/非保護、またはコンテンツ属性として表示できます。 transport-key属性が署名済み、認証済み、認証済み、保護なし、またはコンテンツ属性として表示される場合、関連するコンテンツ内のすべてのキーイングマテリアルは、同じ操作/トランスポートキーマテリアルを持つ必要があります。
aa-transportKey ATTRIBUTE ::= {
TYPE TransOp
IDENTIFIED BY id-kma-transportKey }
id-kma-transportKey OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) keying-material-attributes(13) 15 }
TransOp ::= ENUMERATED {
transport (1),
operational (2) }
Due to multiple layers of encapsulation or the use of content collections, the transport-key attribute can appear in more than one location in the overall key package. When there are multiple occurrences of the transport-key attribute within the same scope, all fields within the attribute MUST contain exactly the same values. Receivers MUST reject any key package that fails these consistency checks.
カプセル化の複数のレイヤーまたはコンテンツコレクションの使用により、transport-key属性は、キーパッケージ全体の複数の場所に表示される可能性があります。同じスコープ内にtransport-key属性が複数出現する場合、属性内のすべてのフィールドにまったく同じ値を含める必要があります。受信者は、これらの整合性チェックに失敗したすべてのキーパッケージを拒否する必要があります。
The key-distribution-period attribute indicates the period of time that the keying material is intended for distribution. Keying material is often distributed before it is intended to be used. Time of day must be represented in Coordinated Universal Time (UTC). It can appear as a symmetric key, symmetric key package, asymmetric key, signed, authenticated, authenticated&unprotected, or content attribute. If the key-distribution-period attribute appears as a signed, authenticated, authenticated&unprotected, or content attribute, then all of the keying material within the content MUST have the same key distribution period.
key-distribution-period属性は、鍵素材が配布される予定の期間を示します。鍵素材は、使用する前に配布されることがよくあります。時刻は協定世界時（UTC）で表す必要があります。対称鍵、対称鍵パッケージ、非対称鍵、署名済み、認証済み、認証済み/非保護、またはコンテンツ属性として表示できます。 key-distribution-period属性が署名済み、認証済み、認証済み、および保護されていない、またはコンテンツ属性として表示される場合、コンテンツ内のすべてのキー素材は同じキー配布期間を持つ必要があります。
The key-distribution-period attribute has the following syntax:
key-distribution-period属性の構文は次のとおりです。
aa-keyDistributionPeriod ATTRIBUTE ::= {
TYPE KeyDistPeriod
IDENTIFIED BY id-kma-keyDistPeriod }
id-kma-keyDistPeriod OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) keying-material-attributes(13) 5 }
KeyDistPeriod ::= SEQUENCE {
doNotDistBefore [0] BinaryTime OPTIONAL,
doNotDistAfter BinaryTime }
BinaryTime ::= INTEGER
The fields in the key-distribution-period attribute have the following semantics:
key-distribution-period属性のフィールドには、次のセマンティクスがあります。
o The doNotDistBefore field is OPTIONAL, and when it is present, the keying material SHOULD NOT be distributed before the date and time provided.
o doNotDistBeforeフィールドはオプションであり、このフィールドが存在する場合、指定された日時の前にキー情報を配布してはなりません（SHOULD NOT）。
o The doNotDistAfter field is REQUIRED, and the keying material SHOULD NOT be distributed after the date and time provided.
o doNotDistAfterフィールドは必須であり、提供された日時の後に鍵情報を配布してはなりません（SHOULD NOT）。
When the key-distribution-period attribute is associated with a collection of keying material, the distribution period applies to all of the keys in the collection. None of the keying material in the collection SHOULD be distributed outside the indicated period.
key-distribution-period属性がキー生成情報のコレクションに関連付けられている場合、配布期間はコレクション内のすべてのキーに適用されます。コレクション内の鍵情報は、示された期間外に配布してはなりません。
Due to multiple layers of encapsulation or the use of content collections, the key-distribution-period attribute can appear in more than one location in the overall key package. When there are multiple occurrences of the key-distribution-period attribute within the same scope, all of the included attribute fields MUST contain exactly the same value. However, if the doNotDistBefore field is absent in an inner layer, a value MAY appear in an outer layer because the outer layer constrains the inner layer. Receivers MUST reject any key package that fails these consistency checks.
カプセル化の複数のレイヤーまたはコンテンツコレクションの使用により、key-distribution-period属性は、キーパッケージ全体の複数の場所に表示される可能性があります。同じスコープ内にkey-distribution-period属性が複数存在する場合、含まれるすべての属性フィールドにまったく同じ値を含める必要があります。ただし、doNotDistBeforeフィールドが内層に存在しない場合、外層が内層を制約するため、外層に値が表示される場合があります。受信者は、これらの整合性チェックに失敗したすべてのキーパッケージを拒否する必要があります。
The key-validity-period attribute indicates the period of time that the keying material is intended for use. Time of day MUST be represented in Coordinated Universal Time (UTC). It can appear as a symmetric key, symmetric key package, asymmetric key, signed, authenticated, authenticated&unprotected, or content attribute. If the key-validity-period attribute appears as a signed, authenticated, authenticated&unprotected, or content attribute, then all of the keying material within the content MUST have the same key validity period.
key-validity-period属性は、キー情報が使用される予定の期間を示します。時刻は協定世界時（UTC）で表す必要があります。対称鍵、対称鍵パッケージ、非対称鍵、署名済み、認証済み、認証済み/非保護、またはコンテンツ属性として表示できます。 key-validity-period属性が署名済み、認証済み、認証済み、および保護されていない、またはコンテンツ属性として表示される場合、コンテンツ内のすべてのキー素材は同じキー有効期間を持つ必要があります。
The key-validity-period attribute has the following syntax:
key-validity-period属性の構文は次のとおりです。
aa-keyValidityPeriod ATTRIBUTE ::= {
TYPE KeyValidityPeriod
IDENTIFIED BY id-kma-keyValidityPeriod }
id-kma-keyValidityPeriod OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) keying-material-attributes(13) 6 }
KeyValidityPeriod ::= SEQUENCE {
doNotUseBefore BinaryTime,
doNotUseAfter BinaryTime OPTIONAL }
BinaryTime ::= INTEGER
The fields in the key-validity-period attribute have the following semantics:
key-validity-period属性のフィールドには、次のセマンティクスがあります。
o The doNotUseBefore field is REQUIRED, and the keying material SHOULD NOT be used before the date and time provided.
o doNotUseBeforeフィールドは必須であり、指定された日時の前にキー情報を使用してはなりません（SHOULD NOT）。
o The doNotUseAfter field is OPTIONAL, and when it is present, the keying material SHOULD NOT be used after the date and time provided.
o doNotUseAfterフィールドはオプションであり、存在する場合、提供された日付と時刻の後にキー情報を使用してはなりません（SHOULD NOT）。
For a key package that is being used for rekey, the doNotUseAfter field MAY be required by some templates even though the syntax is OPTIONAL.
キーの再生成に使用されているキーパッケージの場合、一部のテンプレートでは、構文がオプションであってもdoNotUseAfterフィールドが必要になる場合があります。
When the key-validity-period attribute is associated with a collection of keying material, the validity period applies to all of the keys in the collection. None of the keying material in the collection SHOULD be used outside the indicated period.
key-validity-period属性がキー生成情報のコレクションに関連付けられている場合、有効期間はコレクション内のすべてのキーに適用されます。コレクション内の鍵情報は、指定された期間以外は使用しないでください。
The key-validity-period attribute described in this section and the key-duration attribute described in the next section provide complementary functions. The key-validity-period attribute provides explicit date and time values, which indicate the beginning and ending of the keying material usage period. The key-duration attribute provides the maximum length of time that the keying material SHOULD be used. If both attributes are provided, this duration MAY occur at any time within the specified period, but the limits imposed by both attributes SHOULD be honored.
このセクションで説明するkey-validity-period属性と次のセクションで説明するkey-duration属性は、補足的な機能を提供します。 key-validity-period属性は、鍵素材の使用期間の開始と終了を示す明示的な日付と時刻の値を提供します。 key-duration属性は、キー情報が使用されるべき最長の期間を提供します。両方の属性が指定されている場合、この期間は指定された期間内のいつでも発生する可能性がありますが、両方の属性によって課された制限が守られる必要があります。
Due to multiple layers of encapsulation or the use of content collections, the key-validity-period attribute can appear in more than one location in the overall key package. When there are multiple occurrences of the key-validity-period attribute within the same scope, all of the included attribute fields MUST contain exactly the same value. However, if the doNotUseAfter field is absent in an inner layer, a value MAY appear in an outer layer. Receivers MUST reject any key package that fails these consistency checks.
カプセル化の複数のレイヤーまたはコンテンツコレクションの使用により、key-validity-period属性は、キーパッケージ全体の複数の場所に表示される可能性があります。同じスコープ内にkey-validity-period属性が複数出現する場合、含まれるすべての属性フィールドにまったく同じ値が含まれている必要があります。ただし、doNotUseAfterフィールドが内層に存在しない場合、値は外層に表示される場合があります。受信者は、これらの整合性チェックに失敗したすべてのキーパッケージを拒否する必要があります。
The key-duration attribute indicates the maximum period of time that the keying material is intended for use. The date and time that the duration begins is not specified, but the maximum amount of time that the keying material can be used to provide security services is specified. It can appear as a symmetric key, symmetric key package, asymmetric key, signed, authenticated, authenticated&unprotected, or content attribute. If the key-duration attribute appears as a signed, authenticated, authenticated&unprotected, or content attribute, then all of the keying material within the content MUST have the same key duration.
key-duration属性は、キー生成情報の使用が意図されている最大期間を示します。期間の開始日時は指定されていませんが、キーサービスを使用してセキュリティサービスを提供できる最大時間を指定しています。対称鍵、対称鍵パッケージ、非対称鍵、署名済み、認証済み、認証済み/非保護、またはコンテンツ属性として表示できます。 key-duration属性が署名済み、認証済み、認証済み、および保護されていない、またはコンテンツ属性として表示される場合、コンテンツ内のすべてのキー素材は同じキー期間を持つ必要があります。
The key-duration attribute has the following syntax:
key-duration属性の構文は次のとおりです。
aa-keyDurationPeriod ATTRIBUTE ::= {
TYPE KeyDuration
IDENTIFIED BY id-kma-keyDuration }
id-kma-keyDuration OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) keying-material-attributes(13) 7 }
KeyDuration ::= CHOICE {
hours [0] INTEGER (1..ub-KeyDuration-hours),
days INTEGER (1..ub-KeyDuration-days),
weeks [1] INTEGER (1..ub-KeyDuration-weeks),
months [2] INTEGER (1..ub-KeyDuration-months),
years [3] INTEGER (1..ub-KeyDuration-years) }
ub-KeyDuration-hours INTEGER ::= 96
ub-KeyDuration-days INTEGER ::= 732
ub-KeyDuration-weeks INTEGER ::= 104
ub-KeyDuration-months INTEGER ::= 72
ub-KeyDuration-years INTEGER ::= 100
The key-validity-period attribute described in the previous section and the key-duration attribute described in this section provide a complementary function. The relationship between these attributes is described in the previous section.
前のセクションで説明したkey-validity-period属性と、このセクションで説明したkey-duration属性は、補足的な機能を提供します。これらの属性間の関係については、前のセクションで説明しています。
Due to multiple layers of encapsulation or the use of content collections, the key-duration attribute can appear in more than one location in the overall key package. When there are multiple occurrences of the key-duration attribute within the same scope, all of the included attribute fields MUST contain exactly the same value. Receivers MUST reject any key package that fails these consistency checks.
カプセル化の複数のレイヤーまたはコンテンツコレクションの使用により、key-duration属性は、全体的なキーパッケージの複数の場所に表示される場合があります。同じスコープ内でkey-duration属性が複数出現する場合、含まれているすべての属性フィールドにまったく同じ値が含まれている必要があります。受信者は、これらの整合性チェックに失敗したすべてのキーパッケージを拒否する必要があります。
The classification attribute indicates level of classification. The classification attribute specifies the aggregate classification of the package content. It can appear as a symmetric key, symmetric key package, asymmetric key, signed, authenticated, authenticated&unprotected, or content attribute. If the classification attribute appears as a signed, authenticated, authenticated&unprotected, or content attribute, then the value MUST represent the classification of all of the keying material within the content. Encrypted layers MAY contain content at a higher classification that will be revealed once they are decrypted. If the classification attribute is associated with a collection, then the sensitivity of all the data within the collection MUST be dominated by the classification carried in this attribute.
分類属性は、分類のレベルを示します。分類属性は、パッケージコンテンツの集計分類を指定します。対称鍵、対称鍵パッケージ、非対称鍵、署名済み、認証済み、認証済み/非保護、またはコンテンツ属性として表示できます。分類属性が署名済み、認証済み、認証済み、および保護されていない、またはコンテンツ属性として表示される場合、値はコンテンツ内のすべてのキー素材の分類を表す必要があります。暗号化されたレイヤーには、より高い分類のコンテンツが含まれる場合があり（MAY）、それらは復号化されると明らかになります。分類属性がコレクションに関連付けられている場合、コレクション内のすべてのデータの機密性は、この属性に含まれる分類によって支配されなければなりません（MUST）。
The classification attribute makes use of the ESSSecurityLabel defined in Section 17.1 as well as [RFC2634] and [RFC5911]. The term "classification" is used in this document, but the term "security label" is used in [RFC2634]. The two terms have the same meaning.
分類属性は、セクション17.1で定義されているESSSecurityLabel、ならびに[RFC2634]および[RFC5911]を利用します。この文書では「分類」という用語を使用していますが、[RFC2634]では「セキュリティラベル」という用語を使用しています。 2つの用語の意味は同じです。
[RFC2634] and [RFC5911] specify an object identifier and syntax for the security label attribute. The same values are used for the classification attribute:
[RFC2634]と[RFC5911]は、セキュリティラベル属性のオブジェクト識別子と構文を指定します。同じ値が分類属性に使用されます。
aa-classificationAttribute ATTRIBUTE ::= {
TYPE Classification
IDENTIFIED BY id-aa-KP-classification }
id-aa-KP-classification OBJECT IDENTIFIER ::= id-aa-securityLabel
-- id-aa-securityLabel OBJECT IDENTIFIER ::= {
-- iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
-- pkcs-9(9) smime(16) id-aa(2) 2 }
Classification ::= ESSSecurityLabel
The syntax of ESSSecurityLabel is not repeated here; however, see Section 17.1 for security label conventions that MUST be followed by implementations of this specification. See [RFC2634] for a complete discussion of the semantics and syntax.
ESSSecurityLabelの構文はここでは繰り返されません。ただし、この仕様の実装が従わなければならないセキュリティラベルの規則については、セクション17.1を参照してください。セマンティクスと構文の詳細については、[RFC2634]を参照してください。
When the classification attribute appears in more than one location in the overall key package, each occurrence is evaluated independently. The content originator MUST ensure that the classification attribute represents the sensitivity of the plaintext within the content. That is, the classification MUST dominate any other plaintext classification attribute value that is present elsewhere in the overall key package. Note that the classification attribute value may exceed these other plaintext classification attribute values if the other attribute values within the SignerInfo, AuthEnvelopedData, or AuthenticatedData are themselves classified and warrant the higher-security label value.
分類属性が全体的なキーパッケージの複数の場所にある場合、各オカレンスは個別に評価されます。コンテンツ発信者は、分類属性がコンテンツ内の平文の機密性を表すことを保証しなければなりません（MUST）。つまり、分類は、キーパッケージ全体の他の場所に存在する他のプレーンテキスト分類属性値よりも優位でなければなりません（MUST）。 SignerInfo、AuthEnvelopedData、またはAuthenticatedData内の他の属性値自体が分類され、より高いセキュリティのラベル値を保証する場合、分類属性値はこれらの他の平文分類属性値を超える可能性があることに注意してください。
When the classification attribute appears in more than one location in the overall key package, each security label might be associated with a different security policy. Content originators SHOULD avoid mixing multiple security policies in the same key package whenever possible, since this requires that receivers and intermediaries that check the classification attribute values include support for the union of the security policies that are present. Failure to recognize an included security policy MUST result in rejection of the key package.
分類属性が全体的なキーパッケージの複数の場所に表示される場合、各セキュリティラベルは異なるセキュリティポリシーに関連付けられている可能性があります。コンテンツの発信者は、分類属性値をチェックするレシーバーと仲介者が、存在するセキュリティポリシーの結合のサポートを含む必要があるため、可能な限り、同じキーパッケージで複数のセキュリティポリシーを混在させることは避けてください。含まれているセキュリティポリシーを認識できない場合は、キーパッケージを拒否する必要があります。
Receivers MUST reject any key package that includes a classification for which the receiver's processing environment is not authorized.
受信者は、受信者の処理環境が許可されていない分類を含むすべてのキーパッケージを拒否する必要があります。
The ESSSecurityLabel ASN.1 type is used to represent the classification. The ESSSecurityLabel is defined in Section 3.2 of [RFC2634]. The syntax definition is repeated here to facilitate discussion:
ESSSecurityLabel ASN.1タイプは、分類を表すために使用されます。 ESSSecurityLabelは、[RFC2634]のセクション3.2で定義されています。議論を容易にするために、構文定義をここで繰り返します。
ESSSecurityLabel ::= SET {
security-policy-identifier SecurityPolicyIdentifier,
security-classification SecurityClassification OPTIONAL,
privacy-mark ESSPrivacyMark OPTIONAL,
security-categories SecurityCategories OPTIONAL }
ESSPrivacyMark ::= CHOICE {
pString PrintableString (SIZE (1..ub-privacy-mark-length)),
utf8String UTF8String (SIZE (1..MAX)) }
A security policy is a set of criteria for the provision of security services. The security-policy-identifier, which is an object identifier, is used to identify the security policy associated with the security label. It indicates the semantics of the other security label components.
セキュリティポリシーは、セキュリティサービスを提供するための一連の基準です。オブジェクト識別子であるsecurity-policy-identifierは、セキュリティラベルに関連付けられたセキュリティポリシーを識別するために使用されます。他のセキュリティラベルコンポーネントのセマンティクスを示します。
If the key package receiver does not recognize the object identifier in the security-policy-identifier field and the security label includes a security-categories field, then the key package contents MUST NOT be accepted and the enclosed keying material MUST NOT be used. If the key package receiver does not recognize the object identifier in the security-policy-identifier field and the security label does not include a security-categories field, then the key package contents MAY be accepted only if the security-classification field is present and it contains a value from the basic hierarchy as described below.
鍵パッケージの受信者がsecurity-policy-identifierフィールドのオブジェクト識別子を認識せず、セキュリティラベルにsecurity-categoriesフィールドが含まれている場合は、鍵パッケージの内容を受け入れてはならず、同封の鍵情報を使用してはなりません。キーパッケージレシーバーがsecurity-policy-identifierフィールドのオブジェクト識別子を認識せず、セキュリティラベルにsecurity-categoriesフィールドが含まれていない場合、キーパッケージの内容は、セキュリティ分類フィールドが存在し、かつ以下に説明するように、基本階層の値が含まれています。
This specification defines the use of the SecurityClassification field exactly as is it specified in the 1988 edition of ITU-T Recommendation X.411 [X.411], which states in part:
この仕様では、1988年版のITU-T勧告X.411 [X.411]で指定されているとおりにSecurityClassificationフィールドの使用を定義しています。
If present, a security-classification may have one of a hierarchical list of values. The basic security-classification hierarchy is defined in this Recommendation, but the use of these values is defined by the security-policy in force. Additional values of security-classification, and their position in the hierarchy, may also be defined by a security-policy as a local matter or by bilateral agreement. The basic security-classification hierarchy is, in ascending order: unmarked, unclassified, restricted, confidential, secret, top-secret.
存在する場合、セキュリティ分類には値の階層リストの1つが含まれる場合があります。基本的なセキュリティ分類階層はこの勧告で定義されていますが、これらの値の使用は有効なセキュリティポリシーによって定義されています。セキュリティ分類の追加の値、および階層におけるそれらの位置も、ローカルポリシーとしてのセキュリティポリシーまたは二国間合意によって定義される場合があります。基本的なセキュリティ分類階層は、昇順で、マークなし、分類なし、制限付き、機密、秘密、最高機密です。
Implementations MUST support the basic security classification hierarchy. Such implementations MAY also support other security-classification values; however, the placement of additional values in the hierarchy MUST be specified by the security policy.
実装は、基本的なセキュリティ分類階層をサポートする必要があります。そのような実装は他のセキュリティ分類値もサポートするかもしれません。ただし、階層内の追加の値の配置は、セキュリティポリシーで指定する必要があります。
Implementations MUST NOT make access control decisions based on the privacy-mark. However, information in the privacy-mark can be displayed to human users by devices that have displays to do so. The privacy-mark length MUST NOT exceed 128 characters. The privacy-mark SHALL use the PrintableString choice if all of the characters in the privacy-mark are members of the printable string character set.
実装は、プライバシーマークに基づいてアクセス制御の決定を行ってはなりません。ただし、プライバシーマークの情報は、ディスプレイを備えたデバイスによって人間のユーザーに表示できます。プライバシーマークの長さは128文字を超えてはなりません。プライバシーマークは、プライバシーマークのすべての文字が印刷可能な文字列の文字セットのメンバーである場合、PrintableStringの選択肢を使用する必要があります（SHALL）。
If present, security-categories provide further granularity for the keying material. The security policy in force indicates the permitted syntaxes of any entries in the set of security categories. At most, 64 security categories may be present. The security-categories have ASN.1 type SecurityCategories and further SecurityCategory [RFC5912], which are both repeated here to facilitate discussion:
存在する場合、セキュリティカテゴリは、キー情報の詳細を提供します。有効なセキュリティポリシーは、一連のセキュリティカテゴリのエントリの許可された構文を示します。最大で64のセキュリティカテゴリが存在する可能性があります。 security-categoriesには、ASN.1タイプのSecurityCategoriesと、さらにSecurityCategory [RFC5912]があります。これらは、説明を容易にするために、ここで繰り返します。
SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
SecurityCategory
{{SupportedSecurityCategories}}
SecurityCategory {SECURITY-CATEGORY:Supported} ::= SEQUENCE {
type [0] IMPLICIT SECURITY-CATEGORY.
&id({Supported}),
value [1] EXPLICIT SECURITY-CATEGORY.
&Type({Supported}{@type})
}
Four security categories are defined and are referred to as the Restrictive Tag, the Enumerated Tag, the Permissive Tag, and the Informative Tag. Only the Enumerated Tag and Informative Tag are permitted in the classification attribute.
4つのセキュリティカテゴリが定義され、制限タグ、列挙タグ、許可タグ、および情報タグと呼ばれます。列挙型タグと情報タグのみが分類属性で許可されています。
The Enumerated Tag is composed of one or more non-negative integers. Each non-negative integer represents a non-hierarchical security attribute that applies to the labeled content. A security policy might define a large set of security categories attributes, but a particular key package generally contains only a few security categories attributes. In this case, use of the integer representation is intended to minimize the size of the label. Security attributes enumerated by tags of this type could be restrictive (such as compartments) or permissive (such as release permissions). Two object identifiers for the SecurityCategory type field have been defined, one for restrictive and one for permissive. The object identifiers are:
列挙タグは、1つ以上の負でない整数で構成されます。負でない各整数は、ラベル付きコンテンツに適用される非階層的なセキュリティ属性を表します。セキュリティポリシーは、セキュリティカテゴリ属性の大きなセットを定義する場合がありますが、特定のキーパッケージには、通常、いくつかのセキュリティカテゴリ属性のみが含まれています。この場合、整数表現の使用は、ラベルのサイズを最小限に抑えることを目的としています。このタイプのタグによって列挙されるセキュリティ属性は、制限的（コンパートメントなど）または許容的（リリース許可など）である可能性があります。 SecurityCategoryタイプフィールドの2つのオブジェクト識別子が定義されています。1つは制限用、もう1つは許可用です。オブジェクト識別子は次のとおりです。
id-enumeratedRestrictiveAttributes OBJECT IDENTIFIER ::= {
2 16 840 1 101 2 1 8 3 4 }
id-enumeratedPermissiveAttributes OBJECT IDENTIFIER ::= {
2 16 840 1 101 2 1 8 3 1 }
With both the restrictive and permissive security category types, the corresponding SecurityCategory value has the following ASN.1 definition:
制限と許容の両方のセキュリティカテゴリタイプの場合、対応するSecurityCategory値には次のASN.1定義があります。
EnumeratedTag ::= SEQUENCE {
tagName OBJECT IDENTIFIER,
attributeList SET OF SecurityAttribute }
SecurityAttribute ::= INTEGER (0..MAX)
Any security policy that makes use of security categories MUST assign object identifiers for each tagName, assign the set of integer values associated with each tagName, and specify the semantic meaning for each integer value. Restrictive security attributes and permissive security attributes SHOULD be associated with different tagName object identifiers.
セキュリティカテゴリを利用するセキュリティポリシーでは、各tagNameにオブジェクト識別子を割り当て、各tagNameに関連付けられた整数値のセットを割り当て、各整数値の意味を指定する必要があります。制限的なセキュリティ属性と許容的なセキュリティ属性は、異なるtagNameオブジェクト識別子に関連付ける必要があります（SHOULD）。
The Informative Tag is composed of either a) one or more non-negative integers or b) a bit string. Only the integer choice is allowed in this specification. Each non-negative integer represents a non-hierarchical security attribute that applies to the labeled content. Use of the integer representation is intended to minimize the size of the label since a particular key package generally contains only a few security categories attributes, even though a security policy might define a large set of security categories attributes. Security attributes enumerated by tags of this type are informative (i.e., no access control is performed). One object identifier for the SecurityCategory type field has been defined and is as follows:
情報タグは、a）1つ以上の非負の整数、またはb）ビット文字列のいずれかで構成されます。この仕様では整数の選択のみが許可されています。負でない各整数は、ラベル付きコンテンツに適用される非階層的なセキュリティ属性を表します。整数表現の使用は、セキュリティポリシーでセキュリティカテゴリ属性の大規模なセットが定義されている場合でも、特定のキーパッケージには通常少数のセキュリティカテゴリ属性しか含まれていないため、ラベルのサイズを最小限に抑えることを目的としています。このタイプのタグで列挙されるセキュリティ属性は、情報を提供します（つまり、アクセス制御は実行されません）。 SecurityCategoryタイプフィールドの1つのオブジェクト識別子が定義されており、次のとおりです。
id-informativeAttributes OBJECT IDENTIFIER ::= {
2 16 840 1 101 2 1 8 3 3 }
The corresponding SecurityCategory value has the following ASN.1 definition:
対応するSecurityCategory値には、次のASN.1定義があります。
InformativeTag ::= SEQUENCE {
tagName OBJECT IDENTIFIER,
attributes FreeFormField }
FreeFormField ::= CHOICE {
bitSetAttributes BIT STRING,
securityAttributes SET OF SecurityAttribute }
Any security policy that makes use of security categories MUST assign object identifiers for each tagName, assign the set of integer values associated with each tagName, and specify the semantic meaning for each integer value.
セキュリティカテゴリを利用するセキュリティポリシーでは、各tagNameにオブジェクト識別子を割り当て、各tagNameに関連付けられた整数値のセットを割り当て、各整数値の意味を指定する必要があります。
The key package originator may include a split-identifier attribute to designate that the keying material contains a split rather than a complete key. It may appear as a symmetric and asymmetric key attribute. The split-identifier attribute MUST NOT appear as a symmetric key package, signed, authenticated, authenticated&unprotected, or content attribute. Split keys have two halves, which are called "A" and "B". The split-identifier attribute indicates which half is included in the key package, and it optionally indicates the algorithm that is needed to combine the two halves. The combine algorithm is OPTIONAL since each key algorithm has a default mechanism for this purpose, and the combine algorithm is present only if the default mechanism is not employed.
キーパッケージの作成者は、split-identifier属性を含めて、キー情報に完全なキーではなくスプリットが含まれていることを指定できます。対称および非対称のキー属性として表示される場合があります。 split-identifier属性は、対称鍵パッケージ、署名済み、認証済み、認証済み、および保護なし、またはコンテンツ属性として表示してはなりません（MUST NOT）。分割キーには「A」と「B」と呼ばれる2つの半分があります。 split-identifier属性は、キーパッケージに含まれる半分を示し、オプションで、2つの半分を組み合わせるために必要なアルゴリズムを示します。各鍵アルゴリズムにはこの目的のためのデフォルトのメカニズムがあるため、結合アルゴリズムはオプションです。結合アルゴリズムは、デフォルトのメカニズムが採用されていない場合にのみ存在します。
The split-identifier attribute has the following syntax:
split-identifier属性の構文は次のとおりです。
aa-splitIdentifier ATTRIBUTE ::= {
TYPE SplitID
IDENTIFIED BY id-kma-splitID }
id-kma-splitID OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) keying-material-attributes(13) 11 }
SplitID ::= SEQUENCE {
ENUMERATED { a(0), b(1) },
combineAlg AlgorithmIdentifier
{COMBINE-ALGORITHM, {CombineAlgorithms}} OPTIONAL }
In most cases, the default combine algorithm will be employed; it makes this attribute a simple constant that identifies either the "A" or "B" half of the split key. This supports implementation of some key distribution policies.
ほとんどの場合、デフォルトの結合アルゴリズムが使用されます。この属性は、分割キーの「A」または「B」の半分を識別する単純な定数になります。これは、いくつかの主要な配布ポリシーの実装をサポートします。
Note that each split might have its own CRC, but the key and the check word are both recovered when the two splits are combined.
各スプリットには独自のCRCがある場合がありますが、2つのスプリットを組み合わせると、キーとチェックワードの両方が復元されることに注意してください。
Since the split-identifier attribute MUST NOT appear as a signed, authenticated, authenticated&unprotected, or content attribute, a key package cannot include multiple occurrences of the split-identifier attribute within the same scope. Receivers MUST reject any key package in which the split-identifier attribute appears as a signed, authenticated, authenticated&unprotected, or content attribute.
split-identifier属性は、署名された、認証された、認証された、および保護されていない、またはコンテンツ属性として表示されてはならないため、キーパッケージには、同じスコープ内でsplit-identifier属性の複数のオカレンスを含めることはできません。受信者は、split-identifier属性が署名済み、認証済み、認証済み、および保護されていない、またはコンテンツ属性として表示されるすべてのキーパッケージを拒否する必要があります。
The key-package-type attribute is a shorthand method for specifying all aspects of the key package format, including which attributes are present and the structure of the encapsulated content or collection. The key-package-type attribute can be used as a signed, authenticated, authenticated&unprotected, or content attribute.
key-package-type属性は、存在する属性やカプセル化されたコンテンツまたはコレクションの構造など、キーパッケージの形式のすべての側面を指定するための簡略法です。 key-package-type属性は、署名済み、認証済み、認証済み、および保護なし、またはコンテンツ属性として使用できます。
Rather than implementing the full flexibility of this specification, some devices may implement support for one or more specific key package formats instantiating this specification. Those specific formats are called templates and can be identified using a key-package-type attribute.
一部のデバイスは、この仕様の完全な柔軟性を実装するのではなく、この仕様をインスタンス化する1つ以上の特定の主要なパッケージ形式のサポートを実装する場合があります。これらの特定の形式はテンプレートと呼ばれ、key-package-type属性を使用して識別できます。
The key-package-type attribute has the following syntax:
key-package-type属性の構文は次のとおりです。
aa-keyPackageType ATTRIBUTE ::= {
TYPE KeyPkgType
IDENTIFIED BY id-kma-keyPkgType }
id-kma-keyPkgType OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) keying-material-attributes(13) 12 }
KeyPkgType ::= OBJECT IDENTIFIER
Due to multiple layers of encapsulation or the use of content collections, the key-package-type attribute can appear in more than one location in the overall key package. When that happens, each occurrence is used independently. Since the receiver is likely to use the key-package-type attribute value as a decoding aid, any error will most likely lead to parsing problems, and these problems could result in many different errors being reported.
カプセル化の複数のレイヤーまたはコンテンツコレクションの使用により、key-package-type属性は、キーパッケージ全体の複数の場所に表示される場合があります。その場合、各オカレンスは独立して使用されます。レシーバーはkey-package-type属性値をデコード補助として使用する可能性が高いため、エラーが発生すると解析の問題が発生する可能性が高く、これらの問題が原因でさまざまなエラーが報告される可能性があります。
The signature-usage attribute identifies the CMS content types that this key can be used to sign, or that are permitted to be signed by the end-entity key in a cert path validated by this key. Symmetric key packages do not contain signature generation or signature validation keying material, so the signature-usage attribute MUST NOT appear in a symmetric key package. For an asymmetric key package, the signature-usage attribute indicates the kind of objects that are to be signed with the private key in the package. However, if the asymmetric key package contains a Certificate Signature Key, then the signature-usage attribute also indicates what signed objects can be validated using certificates that are signed by the private key in the asymmetric key package. Therefore, the signature-usage attribute also indicates what kind of objects can be signed by the private keys associated with these certificates. The signature-usage attribute MUST NOT appear as a signed, authenticated, authenticated&unprotected, or content attribute.
signature-usage属性は、このキーを使用して署名できるCMSコンテンツタイプ、またはこのキーによって検証された証明書パスのエンドエンティティキーによる署名が許可されているCMSコンテンツタイプを識別します。対称鍵パッケージには、署名生成または署名検証の鍵情報が含まれていないため、signature-usage属性を対称鍵パッケージに含めてはなりません。非対称キーパッケージの場合、signature-usage属性は、パッケージ内の秘密キーで署名されるオブジェクトの種類を示します。ただし、非対称鍵パッケージに証明書署名鍵が含まれている場合、signature-usage属性は、非対称鍵パッケージの秘密鍵によって署名された証明書を使用して検証できる署名付きオブジェクトも示します。したがって、signature-usage属性は、これらの証明書に関連付けられた秘密鍵で署名できるオブジェクトの種類も示します。 signature-usage属性は、署名された、認証された、認証された、および保護されていない、またはコンテンツ属性として表示してはなりません。
The signature-usage attribute has the following syntax:
signature-usage属性の構文は次のとおりです。
aa-signatureUsage-v3 ATTRIBUTE ::= {
TYPE SignatureUsage
IDENTIFIED BY id-kma-sigUsageV3 }
id-kma-sigUsageV3 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) keying-material-attributes(13) 22 }
SignatureUsage ::= CMSContentConstraints
The SignatureUsage structure has the same syntax as the CMSContentConstraints structure from [RFC6010], and it is repeated here for convenience.
SignatureUsage構造は[RFC6010]のCMSContentConstraints構造と同じ構文を持ち、便宜上ここで繰り返されています。
CMSContentConstraints ::= SEQUENCE SIZE (1..MAX) OF
ContentTypeConstraint
ContentTypeGeneration ::= ENUMERATED {
canSource(0),
cannotSource(1)}
ContentTypeConstraint ::= SEQUENCE {
contentType CONTENT-TYPE.&id ({ContentSet|ct-Any,...}),
canSource ContentTypeGeneration DEFAULT canSource,
attrConstraints AttrConstraintList OPTIONAL }
Constraint { ATTRIBUTE:ConstraintList } ::= SEQUENCE {
attrType ATTRIBUTE.&id({ConstraintList}),
attrValues SET SIZE (1..MAX) OF ATTRIBUTE.
&Type({ConstraintList}{@attrType}) }
SupportedConstraints ATTRIBUTE ::= {SignedAttributesSet, ... }
AttrConstraintList ::= SEQUENCE SIZE (1..MAX) OF
Constraint {{ SupportedConstraints }}
NOTE: SignedAttributesSet is updated by this specification.
注：SignedAttributesSetはこの仕様によって更新されます。
The SignatureUsage contains a type of CMSContentConstraints. One or more ContentTypeConstraint MUST appear in CMSContentConstraints.
SignatureUsageには、CMSContentConstraintsのタイプが含まれています。 1つ以上のContentTypeConstraintがCMSContentConstraintsに表示される必要があります。
Within ContentTypeConstraint, the contentType field indicates the encapsulated content type identifier that can be signed with the signature key. A particular content type MUST NOT appear more than once in the list. The CMS protecting content types need not be included in the list of permitted content types as the use of CMS is always authorized (see [RFC6010]).
ContentTypeConstraint内のcontentTypeフィールドは、署名キーで署名できるカプセル化されたコンテンツタイプ識別子を示します。特定のコンテンツタイプがリストに2回以上出現してはなりません。 CMSの使用は常に許可されているため（[RFC6010]を参照）、CMS保護コンテンツタイプを許可コンテンツタイプのリストに含める必要はありません。
Within ContentTypeConstraint, the canSource enumeration indicates whether the signature key can be used to directly sign the indicated content type. If the ContentTypeConstraint is canSource (the default value), then the signature key can be used to directly sign the specified content type. If the ContentTypeConstraint is cannotSource, then the signature key can only be used with the specified content type if it encapsulates a signature that was generated by an originator with a ContentTypeConstraint that is canSource.
ContentTypeConstraint内のcanSource列挙は、指定されたコンテンツタイプに直接署名するために署名キーを使用できるかどうかを示します。 ContentTypeConstraintがcanSource（デフォルト値）の場合、署名キーを使用して、指定されたコンテンツタイプに直接署名できます。 ContentTypeConstraintがcannotSourceである場合、canSourceであるContentTypeConstraintを使用して発信者によって生成された署名をカプセル化する場合、署名キーは指定されたコンテンツタイプでのみ使用できます。
Within ContentTypeList, the attrConstraints OPTIONAL field contains a sequence of constraints specific to the content type. If the attrConstraints field is absent, the signature key can be used to sign the specified content type, without any further checking. If the attrConstraints field is present, then the signature key can only be used to sign the specified content type if all of the constraints for that content type are satisfied. Content type constraints are checked by matching the attribute values in the attrConstraint field against the attribute value in the content. The constraints succeed if the attribute is not present; they fail if the attribute is present and the value is not one of the values provided in attrConstraint.
ContentTypeList内で、attrConstraints OPTIONALフィールドには、コンテンツタイプに固有の一連の制約が含まれています。 attrConstraintsフィールドが存在しない場合、署名キーを使用して、それ以上チェックすることなく、指定されたコンテンツタイプに署名できます。 attrConstraintsフィールドが存在する場合、そのコンテンツタイプのすべての制約が満たされた場合にのみ、署名キーを使用して、指定されたコンテンツタイプに署名できます。コンテンツタイプの制約は、attrConstraintフィールドの属性値をコンテンツの属性値と照合することによってチェックされます。属性が存在しない場合、制約は成功します。属性が存在し、値がattrConstraintで提供されている値のいずれでもない場合は失敗します。
The fields of attrConstraints implement constraints specific to the content type. The attrType field is an AttributeType, which is an object identifier of a signed attribute carried in the SignerInfo of the content. The attrValues field provides one or more acceptable signed attribute values. It is a set of AttributeValue. For a signed content to satisfy the constraint, the SignerInfo MUST include a signed attribute of the type identified in the attrType field, and the signed attribute MUST contain one of the values in the set carried in attrValues.
attrConstraintsのフィールドは、コンテンツタイプに固有の制約を実装します。 attrTypeフィールドはAttributeTypeです。これは、コンテンツのSignerInfoに含まれる署名済み属性のオブジェクト識別子です。 attrValuesフィールドは、1つ以上の受け入れ可能な署名済み属性値を提供します。 AttributeValueのセットです。署名されたコンテンツが制約を満たすためには、SignerInfoはattrTypeフィールドで識別されたタイプの署名された属性を含まなければならず（MUST）、署名された属性はattrValuesで運ばれるセットの値の1つを含まなければなりません（MUST）。
Since the signature-usage attribute MUST NOT appear as a signed, authenticated, authenticated&unprotected, or content attribute, an asymmetric key package cannot include multiple occurrences of the signature-usage attribute within the same scope. Receivers MUST reject any asymmetric key package in which the signature-usage attribute appears as a signed, authenticated, authenticated&unprotected, or content attribute.
signature-usage属性は、signed、authentication、authentication＆unprotected、またはcontent属性として表示されてはならないため、非対称鍵パッケージには、同じスコープ内で複数のsignature-usage属性を含めることはできません。受信者は、signature-usage属性が署名済み、認証済み、認証済み、非保護済み、またはコンテンツ属性として表示される非対称鍵パッケージを拒否する必要があります。
The other-certificate-formats attribute specifies the type, format, and value of certificates that are not X.509 public key certificates. Symmetric key packages do not contain any certificates, so the other-certificate-formats attribute MUST NOT appear in a symmetric key package. It SHOULD appear in the attributes field, when the publicKey field is absent and the certificate format is not X.509. This attribute MUST NOT appear in an attributes field that includes the user-certificate attribute from Section 8. The other-certificate-formats attribute MUST NOT appear as a signed, authenticated, authenticated&unprotected, or content attribute.
other-certificate-formats属性は、X.509公開鍵証明書ではない証明書のタイプ、形式、および値を指定します。対称鍵パッケージには証明書が含まれていないため、other-certificate-formats属性を対称鍵パッケージに含めてはなりません（MUST NOT）。 publicKeyフィールドがなく、証明書の形式がX.509でない場合は、属性フィールドに表示する必要があります（SHOULD）。この属性は、セクション8のユーザー証明書属性を含む属性フィールドに出現してはなりません（MUST NOT）。other-certificate-formats属性は、署名済み、認証済み、認証済み、および保護されていない、またはコンテンツ属性として出現してはなりません。
The other-certificate-formats attribute has the following syntax:
other-certificate-formats属性の構文は次のとおりです。
aa-otherCertificateFormats ATTRIBUTE ::= {
TYPE CertificateChoices
IDENTIFIED BY id-kma-otherCertFormats }
id-kma-otherCertFormats OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) keying-material-attributes(13) 19 }
CertificateChoices ::= CHOICE {
certificate Certificate,
extendedCertificate [0] IMPLICIT ExtendedCertificate,
-- Obsolete
v1AttrCert [1] IMPLICIT AttributeCertificateV1,
-- Obsolete
v2AttrCert [2] IMPLICIT AttributeCertificateV2,
other [3] IMPLICIT OtherCertificateFormat }
OtherCertificateFormat ::= SEQUENCE {
otherCertFormat OBJECT IDENTIFIER,
otherCert ANY DEFINED BY otherCertFormat }
The other-certificate-formats attribute makes use of the CertificateChoices field defined in Section 10.2.2 of [RFC5652]. The certificate, extendedCertificate, and v1AttrCert fields MUST be omitted. The v2AttrCert field can include Version 2 Attribute Certificates. The other field can include Enhanced FIREFLY certificates and other as yet undefined certificate formats.
other-certificate-formats属性は、[RFC5652]のセクション10.2.2で定義されているCertificateChoicesフィールドを利用します。証明書、extendedCertificate、およびv1AttrCertフィールドは省略しなければなりません。 v2AttrCertフィールドには、バージョン2の属性証明書を含めることができます。その他のフィールドには、Enhanced FIREFLY証明書やその他の未定義の証明書形式を含めることができます。
Since the other-certificate-formats attribute MUST NOT appear as a signed, authenticated, authenticated&unprotected, or content attribute, an asymmetric key package cannot include multiple occurrences of the other-certificate-formats attribute within the same scope. Receivers MUST reject any asymmetric key package in which the other-certificate-formats attribute appears as a signed, authenticated, authenticated&unprotected, or content attribute.
other-certificate-formats属性は、署名された、認証された、認証された、保護されていない、またはコンテンツ属性として表示されてはならないため、非対称鍵パッケージに、同じスコープ内でother-certificate-formats属性の複数のオカレンスを含めることはできません。受信者は、other-certificate-formats属性が署名済み、認証済み、認証済み、非保護済み、またはコンテンツ属性として表示される非対称鍵パッケージを拒否する必要があります。
The pki-path attribute includes certificates that can aid in the validation of the certificate carried in the user-certificate attribute. Symmetric key packages do not contain any certificates, so the pkiPath attribute MUST NOT appear in a symmetric key package. It can appear as an asymmetric key, signed, authenticated, authenticated&unprotected, or content attribute. It can appear in the attributes field, when the publicKey field is absent and the certificate format is X.509. This attribute MUST NOT appear in an AsymmetricKeyPackage that has an other-certificate-formats attribute in the attributes field. If the pki-path attribute appears as a signed, authenticated, authenticated&unprotected, or content attribute, then the value includes certificates that can be used to construct a certification path to all of the keying material within the content. This attribute MUST be supported.
pki-path属性には、ユーザー証明書属性に含まれる証明書の検証に役立つ証明書が含まれています。対称鍵パッケージには証明書が含まれていないため、対称鍵パッケージにpkiPath属性を含めることはできません。非対称キー、署名済み、認証済み、認証済み/非保護、またはコンテンツ属性として表示できます。 publicKeyフィールドがなく、証明書の形式がX.509の場合、属性フィールドに表示されます。この属性は、attributesフィールドにother-certificate-formats属性を持つAsymmetricKeyPackageに出現してはなりません（MUST NOT）。 pki-path属性が署名済み、認証済み、認証済み、保護なし、またはコンテンツの属性として表示される場合、値には、コンテンツ内のすべてのキー情報への証明書パスを構築するために使用できる証明書が含まれます。この属性はサポートされている必要があります。
The syntax is taken from [X.509] but redefined using the ATTRIBUTE CLASS from [RFC5912]. The pki-path attribute has the following syntax:
構文は[X.509]から取得されますが、[RFC5912]のATTRIBUTE CLASSを使用して再定義されます。 pki-path属性の構文は次のとおりです。
aa-pkiPath ATTRIBUTE ::= {
TYPE PkiPath
IDENTIFIED BY id-at-pkiPath }
id-at-pkiPath OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) ds(5) attributes(4) 70 }
PkiPath ::= SEQUENCE SIZE (1..MAX) OF Certificate
The first certificate in the sequence is the subject's parent Certification Authority (CA). The next certificate is that CA's parent, and so on. The end-entity and trust anchor are not included in this attribute.
シーケンスの最初の証明書は、サブジェクトの親の証明機関（CA）です。次の証明書は、そのCAの親などです。エンドエンティティとトラストアンカーは、この属性には含まれません。
Due to multiple layers of encapsulation or the use of content collections, the pki-path attribute can appear in more than one location in the overall key package. When that happens, each occurrence is evaluated independently.
カプセル化の複数のレイヤーまたはコンテンツコレクションの使用により、pki-path属性は、キーパッケージ全体の複数の場所に表示される場合があります。その場合、発生ごとに個別に評価されます。
The useful-certificates attribute includes certificates that can aid in the validation of certificates associated with other parties with whom secure communications are anticipated. It can appear as an asymmetric key, signed, authenticated, authenticated&unprotected, or content attribute. For an asymmetric key that has an other-certificate-formats attribute (Section 21) in the attributes field, the useful-certificates attribute MUST NOT appear. If the useful-certificates attribute appears as a signed, authenticated, authenticated&unprotected, or content attribute, then the value includes certificates that may be used to validate certificates of others with whom the receiver communicates. This attribute MUST be supported.
有用な証明書属性には、安全な通信が期待される他の関係者に関連付けられた証明書の検証に役立つ証明書が含まれます。非対称キー、署名済み、認証済み、認証済み/非保護、またはコンテンツ属性として表示できます。属性フィールドにother-certificate-formats属性（セクション21）を持つ非対称鍵の場合、有用な証明書属性は表示されてはなりません（MUST NOT）。有用な証明書属性が、署名された、認証された、認証された、および保護されていない、またはコンテンツ属性として表示される場合、値には、受信者が通信する他の証明書を検証するために使用できる証明書が含まれます。この属性はサポートされている必要があります。
The useful-certificates attribute has the following syntax:
有用な証明書属性の構文は次のとおりです。
aa-usefulCertificates ATTRIBUTE ::= {
TYPE CertificateSet
IDENTIFIED BY id-kma-usefulCerts }
id-kma-usefulCerts OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) keying-material-attributes(13) 20 }
CertificateSet ::= SET OF CertificateChoices
The useful-certificates attribute makes use of the CertificateSet field defined in Section 10.2.3 of [RFC5652]. Within the CertificateChoices field, the extendedCertificate and v1AttrCert fields MUST always be omitted. If the userCertificate attribute from Section 8 is included, the other field MUST NOT be present. If the other-certificate-formats attribute (Section 21) is included, the certificate field MUST NOT be present.
有用な証明書属性は、[RFC5652]のセクション10.2.3で定義されているCertificateSetフィールドを利用します。 CertificateChoicesフィールド内では、extendedCertificateおよびv1AttrCertフィールドを常に省略しなければなりません。セクション8のuserCertificate属性が含まれている場合、他のフィールドは存在してはなりません（MUST NOT）。 other-certificate-formats属性（セクション21）が含まれている場合、証明書フィールドは存在してはなりません（MUST NOT）。
Due to multiple layers of encapsulation or the use of content collections, the useful-certificates attribute can appear in more than one location in the overall key package. When the useful-certificates attribute appears in more than one location in the overall key package, each occurrence is evaluated independently.
カプセル化の複数の層またはコンテンツコレクションの使用により、有用な証明書属性は、全体的なキーパッケージの複数の場所に表示される場合があります。キー全体のパッケージの複数の場所に有用な証明書属性が表示される場合、各オカレンスは個別に評価されます。
The key-wrap-algorithm attribute identifies a key wrap algorithm with an algorithm identifier. It can appear as a symmetric key or symmetric key package attribute. When this attribute is present in sKeyAttrs, it indicates that the associated sKey field contains a black key, which is an encrypted key, that was wrapped by the identified algorithm. When this attribute is present in sKeyPkgAttrs, it indicates that every sKey field in that symmetric key package contains a black key and that all keys are wrapped by the same designated algorithm.
key-wrap-algorithm属性は、アルゴリズム識別子でキーラップアルゴリズムを識別します。対称キーまたは対称キーパッケージ属性として表示できます。この属性がsKeyAttrsに存在する場合、関連付けられたsKeyフィールドに、識別されたアルゴリズムによってラップされた、暗号化されたキーである黒いキーが含まれていることを示します。この属性がsKeyPkgAttrsに存在する場合、その対称鍵パッケージのすべてのsKeyフィールドに黒い鍵が含まれており、すべての鍵が同じ指定されたアルゴリズムでラップされていることを示しています。
The key-wrap-algorithm attribute has the following syntax:
key-wrap-algorithm属性の構文は次のとおりです。
aa-keyWrapAlgorithm ATTRIBUTE ::= {
TYPE AlgorithmIdentifier{KEY-WRAP, {KeyEncryptionAlgorithmSet}}
IDENTIFIED BY id-kma-keyWrapAlgorithm }
id-kma-keyWrapAlgorithm OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) keying-material-attributes(13) 21 }
KeyEncryptionAlgorithmSet KEY-WRAP ::= { ... }
The content-decryption-key-identifier attribute can appear as an unprotected attribute as well as a symmetric and symmetric key package attribute. The attribute's semantics differ based on the location.
content-decryption-key-identifier属性は、保護されていない属性としても、対称および対称キーパッケージ属性としても表示できます。属性のセマンティクスは、場所によって異なります。
25.1. Content Decryption Key Identifier: Symmetric Key and Symmetric Key Package
25.1. コンテンツ復号化キー識別子：対称キーと対称キーパッケージ
The content-decryption-key-identifier attribute [RFC6032] identifies the keying material needed to decrypt the sKey. It can appear as a symmetric key and symmetric key package attribute. If the key-wrap-algorithm attribute appears in sKeyPkgAttrs, then the corresponding content-decryption-identifier attribute can appear in either sKeyPkgAttrs or sKeyAttrs. If the key-wrap-algorithm attribute (Section 24) appears in sKeyAttrs, then the corresponding content-decryption-identifier attribute MUST appear in sKeyAttrs.
content-decryption-key-identifier属性[RFC6032]は、sKeyの復号化に必要な鍵情報を識別します。対称キーおよび対称キーパッケージ属性として表示できます。 key-wrap-algorithm属性がsKeyPkgAttrsに表示される場合、対応するcontent-decryption-identifier属性はsKeyPkgAttrsまたはsKeyAttrsに表示されます。 key-wrap-algorithm属性（セクション24）がsKeyAttrsにある場合、対応するcontent-decryption-identifier属性がsKeyAttrsにある必要があります。
The content-decryption-key-identifier attribute in included for convenience:
content-decryption-key-identifier属性は、便宜上含まれています。
aa-contentDecryptKeyIdentifier ATTRIBUTE ::= {
TYPE ContentDecryptKeyID
IDENTIFIED BY id-aa-KP-contentDecryptKeyID }
id-aa-KP-contentDecryptKeyID OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) attributes(5) 66 }
ContentDecryptKeyID ::= OCTET STRING
The content decryption key identifier contains an octet string, and this syntax does not impose any particular structure on the identifier value.
コンテンツ復号化キー識別子にはオクテット文字列が含まれており、この構文は識別子値に特定の構造を課しません。
The content-decryption-key-identifier attribute can be used to identify the keying material that is needed for decryption of the EncryptedData content if there is any ambiguity.
content-decryption-key-identifier属性を使用すると、あいまいな場合に、EncryptedDataコンテンツの復号化に必要なキー情報を識別できます。
The content-decryption-key-identifier attribute syntax is found in Section 25.1. The content decryption key identifier contains an octet string, and this syntax does not impose any particular structure on the identifier value.
content-decryption-key-identifier属性の構文は、セクション25.1にあります。コンテンツ復号化キー識別子にはオクテット文字列が含まれており、この構文は識別子値に特定の構造を課しません。
Due to multiple layers of encryption, the content-decryption-key-identifier attribute can appear in more than one location in the overall key package. When that happens, each occurrence is evaluated independently. Each one is used to identify the needed keying material for that layer of encryption.
暗号化には複数のレイヤーがあるため、content-decryption-key-identifier属性は、キーパッケージ全体の複数の場所に出現する可能性があります。その場合、発生ごとに個別に評価されます。それぞれを使用して、暗号化のそのレイヤーに必要なキー情報を識別します。
The certificate-pointers attribute can be used to reference one or more certificates that may be helpful in the processing of the content once it is decrypted. Sometimes certificates are omitted if they can be easily fetched. However, an intermediary may have better facilities to perform the fetching than the receiver. The certificate-pointers attribute may be useful in some environments. This attribute can appear as an unprotected and an unauthenticated&unprotected attribute.
certificate-pointers属性を使用して、コンテンツが復号化された後のコンテンツの処理に役立つ1つ以上の証明書を参照できます。簡単に取得できる証明書は省略される場合があります。ただし、仲介者には、受信者よりもフェッチを実行するための優れた機能がある場合があります。 certificate-pointers属性は、一部の環境で役立つ場合があります。この属性は、保護されていない、認証されていない、保護されていない属性として表示されることがあります。
The certificate-pointers attribute uses the same syntax and semantics as the subject information access certificate extension [RFC5280]. The certificate-pointers attribute has the following syntax:
certificate-pointers属性は、サブジェクト情報アクセス証明書拡張[RFC5280]と同じ構文とセマンティクスを使用します。 certificate-pointers属性の構文は次のとおりです。
aa-certificatePointers ATTRIBUTE ::= {
TYPE SubjectInfoAccessSyntax
IDENTIFIED BY id-pe-subjectInfoAccess }
id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) pe(1) 11 }
SubjectInfoAccessSyntax ::= SEQUENCE SIZE (1..MAX) OF
AccessDescription
AccessDescription ::= SEQUENCE {
accessMethod OBJECT IDENTIFIER,
accessLocation GeneralName }
As specified in [RFC5280], the id-ad-caRepository access method can be used to point to a repository where a Certification Authority publishes certificates and Certificate Revocation Lists (CRLs). In this case, the accessLocation field tells how to access the repository. Where the information is available via HTTP, FTP, or the Lightweight Directory Access Protocol (LDAP), accessLocation contains a Uniform Resource Identifier (URI). Where the information is available via the Directory Access Protocol (DAP), accessLocation contains a directory name.
[RFC5280]で指定されているように、id-ad-caRepositoryアクセスメソッドを使用して、認証局が証明書と証明書失効リスト（CRL）を公開するリポジトリをポイントできます。この場合、accessLocationフィールドはリポジトリへのアクセス方法を示します。 HTTP、FTP、またはライトウェイトディレクトリアクセスプロトコル（LDAP）を介して情報を入手できる場合、accessLocationにはURI（Uniform Resource Identifier）が含まれます。情報がディレクトリアクセスプロトコル（DAP）を介して利用できる場合、accessLocationにはディレクトリ名が含まれます。
The CRL-pointers attribute can be used to reference one or more CRLs that may be helpful in the processing of the content once it is decrypted. Sometimes CRLs are omitted to conserve space or to ensure that the most recent CRL is obtained when the certificate is validated. However, an intermediary may have better facilities to perform the fetching than the receiver. The CRL-pointers attribute may be useful in some environments. This attribute can appear as an unprotected and unauthenticated&unprotected attribute.
CRL-pointers属性を使用して、コンテンツが復号化された後のコンテンツの処理に役立つ1つ以上のCRLを参照できます。スペースを節約するため、または証明書の検証時に最新のCRLを確実に取得するために、CRLが省略される場合があります。ただし、仲介者には、受信者よりもフェッチを実行するための優れた機能がある場合があります。 CRL-pointers属性は、一部の環境で役立つ場合があります。この属性は、保護されておらず、認証および保護されていない属性として表示される場合があります。
The CRL-pointers attribute has the following syntax:
CRL-pointers属性の構文は次のとおりです。
aa-crlPointers ATTRIBUTE ::= {
TYPE GeneralNames
IDENTIFIED BY id-aa-KP-crlPointers }
id-aa-KP-crlPointers OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) attributes(5) 70 }
The CRL-pointers attribute uses the GeneralNames syntax from [RFC5280]. Each name describes a different mechanism to obtain the same CRL. Where the information is available via HTTP, FTP, or LDAP, GeneralNames contains a URI. Where the information is available via DAP, GeneralNames contains a directory name.
CRL-pointers属性は、[RFC5280]のGeneralNames構文を使用します。それぞれの名前は、同じCRLを取得するための異なるメカニズムを説明しています。 HTTP、FTP、またはLDAPを介して情報を入手できる場合、GeneralNamesにはURIが含まれます。 DAPを介して情報を入手できる場合、GeneralNamesにはディレクトリ名が含まれます。
The key-package-identifier-and-receipt-request attribute from [RFC7191] is also supported. It can appear as a signed attribute, authenticated, authenticated&unprotected, or content attribute.
[RFC7191]のkey-package-identifier-and-receipt-request属性もサポートされています。これは、署名済み属性、認証済み、認証済みおよび保護されていない、またはコンテンツ属性として表示できます。
This specification also defines three additional extended ErrorCodeChoice object identifiers for the oid field [RFC7191]:
この仕様は、oidフィールド[RFC7191]の3つの追加の拡張ErrorCodeChoiceオブジェクト識別子も定義しています。
id-errorCodes OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) errorCodes(22) }
id-missingKeyType OBJECT IDENTIFIER ::= {
id-errorCodes 1 }
id-privacyMarkTooLong OBJECT IDENTIFIER ::= {
id-errorCodes 2 }
id-unrecognizedSecurityPolicy OBJECT IDENTIFIER ::= {
id-errorCodes 3 }
id-incorrectKeyProvince OBJECT IDENTIFIER ::= {
id-errorCodes 4 }
missingKeyType indicates that all keying material within a package is of the same type; however, the key-package-type attribute is not specified in sKeyPkgAttrs [RFC6031].
missingKeyTypeは、パッケージ内のすべてのキー情報が同じタイプであることを示します。ただし、key-package-type属性はsKeyPkgAttrs [RFC6031]で指定されていません。
privacyMarkTooLong indicates that a classification attribute includes a privacy-mark that exceeds 128 characters in length.
privacyMarkTooLongは、分類属性に128文字を超えるプライバシーマークが含まれていることを示します。
unrecognizedSecurityPolicy indicates that a security-policy-identifier is not supported.
unrecognizedSecurityPolicyは、セキュリティポリシー識別子がサポートされていないことを示します。
incorrectKeyProvince indicates that the value of the key-province-v2 attribute in a key package does not match the key province constraint of the trust anchor used to validate the key package.
correctKeyProvinceは、キーパッケージのkey-province-v2属性の値が、キーパッケージの検証に使用されるトラストアンカーのキーの州の制約と一致しないことを示します。
Trust anchors may contain constraints for any content type [RFC5934]. When the trust anchor contains constraints for the symmetric key package content type or the asymmetric key package content type, then the constraints provide default values for key package attributes that are not present in the key package and define the set of acceptable values for key package attributes that are present.
トラストアンカーには、任意のコンテンツタイプの制約が含まれる場合があります[RFC5934]。トラストアンカーに対称キーパッケージコンテンツタイプまたは非対称キーパッケージコンテンツタイプの制約が含まれている場合、制約はキーパッケージに存在しないキーパッケージ属性のデフォルト値を提供し、キーパッケージ属性の許容値のセットを定義します存在しています。
When a trust anchor delegates authority by issuing an X.509 certificate, the CMS content constraints certificate extension [RFC6010] may be included to constrain the authorizations. The trust anchor and the X.509 certification path provide default values for key package attributes that are not present in the key package and define the set of acceptable of values for key package attributes that are present.
トラストアンカーがX.509証明書を発行して権限を委任する場合、CMSコンテンツ制約証明書拡張[RFC6010]を含めて、承認を制約することができます。トラストアンカーとX.509証明書パスは、キーパッケージに存在しないキーパッケージ属性のデフォルト値を提供し、存在するキーパッケージ属性の受け入れ可能な値のセットを定義します。
Constraints on content type usage are represented as attributes.
コンテンツタイプの使用に関する制約は、属性として表されます。
The processing procedures for the CMS content constraints certificate extension [RFC6010] are part of the validation of a signed or authenticated object, and the procedures yield three output values: cms_constraints, cms_effective_attributes, and cms_default_attributes. Object validation MUST be performed before processing the key package contents, and these output values are used as part of key package processing. These same output values are easily generated directly from a trust anchor and the key package when no X.509 certification path is involved in validation.
CMSコンテンツ制約証明書拡張[RFC6010]の処理手順は、署名または認証されたオブジェクトの検証の一部であり、この手順では、cms_constraints、cms_effective_attributes、およびcms_default_attributesの3つの出力値が生成されます。キーパッケージのコンテンツを処理する前にオブジェクトの検証を実行する必要があります。これらの出力値は、キーパッケージの処理の一部として使用されます。これらの同じ出力値は、検証にX.509証明書パスが含まれていない場合、トラストアンカーとキーパッケージから直接簡単に生成されます。
The cms_effective_attributes provides the set of acceptable values for attributes. Each attribute present in the key package that corresponds to an entry in cms_effective_attributes MUST contain a value that appears in cms_effective_attributes entry. Attributes that do not correspond to an entry in cms_effective_attributes are unconstrained and may contain any value. Correspondence between attributes and cms_effective_attributes is determined by comparing the attribute object identifier to object identifier for each entry in cms_effective_attributes.
cms_effective_attributesは、属性の受け入れ可能な値のセットを提供します。 cms_effective_attributesのエントリに対応するキーパッケージに存在する各属性には、cms_effective_attributesエントリに表示される値が含まれている必要があります。 cms_effective_attributesのエントリに対応しない属性は制約されず、任意の値を含むことができます。属性とcms_effective_attributesの間の対応は、属性オブジェクト識別子をcms_effective_attributesの各エントリのオブジェクト識別子と比較することによって決定されます。
The cms_default_attributes provides values for attributes that do not appear in the key package. If cms_default_attributes includes only one attribute value for a particular attribute, then that value is used as if it were included in the key package itself. However, if cms_default_attributes includes more than one value for a particular attribute, then the appropriate value remains ambiguous and the key package should be rejected.
cms_default_attributesは、キーパッケージに表示されない属性の値を提供します。 cms_default_attributesに特定の属性の属性値が1つしか含まれていない場合、その値は、キーパッケージ自体に含まれているかのように使用されます。ただし、cms_default_attributesに特定の属性の複数の値が含まれている場合、適切な値があいまいであり、キーパッケージを拒否する必要があります。
Some attributes can appear in more than one place in the key package, and for this reason, the attribute definitions include consistency checks. These checks are independent of constraints checking. In addition to the consistency checks, each instance of the attribute MUST be checked against the set of cms_effective_attributes, and the key package MUST be rejected if any of the attributes values are not in the set of authorized set of values.
一部の属性は、キーパッケージの複数の場所に表示される可能性があるため、属性定義には整合性チェックが含まれています。これらのチェックは、制約チェックから独立しています。整合性チェックに加えて、属性の各インスタンスを一連のcms_effective_attributesに対してチェックする必要があり、いずれかの属性値が許可された値のセットにない場合、キーパッケージを拒否する必要があります。
This section provides an example symmetric key package in order to provide a discussion of the scope of attributes. This is an informative section; it is not a normative portion of this specification. Figure 1 provides the example. All of the concepts apply to either a symmetric key package or an asymmetric key package, with the exception of the key-algorithm attribute, which is only applicable to a symmetric key package. Each of the components is labeled with a number inside parentheses for easy reference:
このセクションでは、属性のスコープについて説明するために、対称キーパッケージの例を示します。これは有益なセクションです。これは、この仕様の規範的な部分ではありません。図1に例を示します。対称鍵パッケージにのみ適用できるkey-algorithm属性を除き、すべての概念が対称鍵パッケージまたは非対称鍵パッケージのいずれかに適用されます。参照しやすいように、各コンポーネントには括弧内に番号が付けられています。
(1) is the ContentInfo that must be present as the outermost layer of encapsulation. It contains no attributes. It is shown for completeness.
（1）は、カプセル化の最外層として存在する必要があるContentInfoです。属性は含まれていません。完全を期すために示しています。
(2) is a SignedData content type, which includes six signed attributes. Four of the signed attributes are keying material attributes.
（2）は、6つの署名済み属性を含むSignedDataコンテンツタイプです。署名された属性の4つは、キーマテリアル属性です。
(3) is a ContentCollection that includes two encapsulated content types: a ContentWithAttributes and an EncryptedKeyPackage. This content type does not provide any attributes.
（3）は、ContentWithAttributesとEncryptedKeyPackageの2つのカプセル化されたコンテンツタイプを含むContentCollectionです。このコンテンツタイプは属性を提供しません。
(4) is a ContentWithAttributes content type. It encapsulates a SignedData content type. Four key material attributes are provided.
（4）はContentWithAttributesコンテンツタイプです。 SignedDataコンテンツタイプをカプセル化します。 4つの主要な材料属性が提供されます。
(5) is a SignedData content type. It encapsulates a SymmetricKeyPackage content type. Six signed attributes are provided. Four attributes are key material attributes.
（5）はSignedDataコンテンツタイプです。 SymmetricKeyPackageコンテンツタイプをカプセル化します。 6つの署名された属性が提供されます。 4つの属性が主要な材料属性です。
(6) is a SymmetricKeyPackage content type, and it includes three key material attributes. Note that the contents of this key package are not encrypted, but the contents are covered by two digital signatures.
（6）はSymmetricKeyPackageコンテンツタイプであり、3つの主要なマテリアル属性が含まれています。この鍵パッケージの内容は暗号化されていませんが、内容は2つのデジタル署名でカバーされていることに注意してください。
(7) is an EncryptedKeyPackage content type. It encapsulates a SignedData content type. This content type provides one unprotected attribute.
（7）は、EncryptedKeyPackageコンテンツタイプです。 SignedDataコンテンツタイプをカプセル化します。このコンテンツタイプは、1つの保護されていない属性を提供します。
(8) is a SignedData content type. It encapsulates a SymmetricKeyPackage content type. Six signed attributes are provided. Four attributes are key material attributes.
（8）はSignedDataコンテンツタイプです。 SymmetricKeyPackageコンテンツタイプをカプセル化します。 6つの署名された属性が提供されます。 4つの属性が主要な材料属性です。
(9) is a SymmetricKeyPackage content type, and it includes three key material attributes. Note that the contents of this key package are encrypted; the plaintext keying material is covered by one digital signature, and the ciphertext keying material is covered by another digital signature.
（9）はSymmetricKeyPackageコンテンツタイプであり、3つの主要なマテリアル属性が含まれています。この鍵パッケージの内容は暗号化されていることに注意してください。平文の鍵情報は1つのデジタル署名で保護されており、暗号文の鍵情報は別のデジタル署名で保護されています。
SignedData content type (2) includes six signed attributes:
SignedDataコンテンツタイプ（2）には、6つの署名済み属性が含まれています。
o The content-type attribute contains id-ct-contentCollection to indicate the type of the encapsulated content, and it has no further scope.
o content-type属性には、カプセル化されたコンテンツのタイプを示すid-ct-contentCollectionが含まれ、それ以上のスコープはありません。
o The message-digest attribute contains the one-way hash value of the encapsulated content; it is needed to validate the digital signature. It has no further scope.
o message-digest属性には、カプセル化されたコンテンツの一方向のハッシュ値が含まれます。デジタル署名を検証するために必要です。それ以上のスコープはありません。
o The classification attribute contains the security label for all of the plaintext in the encapsulated content. Each classification attribute is evaluated separately; it has no further scope. In general, the values of this attribute will match or dominate the security label values in (4), (5), and (6). The value of this attribute might not match or dominate the security label values in (8) and (9) since they are encrypted. It is possible that these various security label values are associated with different security policies. To avoid the processing complexity associated with policy mapping, comparison is not required.
o 分類属性には、カプセル化されたコンテンツのすべてのプレーンテキストのセキュリティラベルが含まれています。各分類属性は個別に評価されます。それ以上のスコープはありません。一般に、この属性の値は、（4）、（5）、および（6）のセキュリティラベルの値と一致または支配します。この属性の値は、暗号化されているため、（8）および（9）のセキュリティラベル値と一致しないか、支配する可能性があります。これらのさまざまなセキュリティラベル値が異なるセキュリティポリシーに関連付けられている可能性があります。ポリシーマッピングに関連する処理の複雑さを回避するために、比較は必要ありません。
o The key-package-receivers-v2 attribute indicates the authorized key package receivers, and it has no further scope. The additional instances of key-package-receivers-v2 attribute embedded in (4) are evaluated without regard to the value of the instance in (2).
o key-package-receivers-v2属性は、承認されたキーパッケージレシーバーを示し、それ以上のスコープはありません。 （4）に埋め込まれたkey-package-receivers-v2属性の追加インスタンスは、（2）のインスタンスの値に関係なく評価されます。
o The key-distribution-period attribute contains two date values: doNotDistBefore and doNotDistAfter. These values must match all others within the same scope, which in this example is the key-distribution-period within (4).
o key-distribution-period属性には、doNotDistBeforeとdoNotDistAfterの2つの日付値が含まれています。これらの値は、同じスコープ内の他のすべてと一致する必要があります。この例では、（4）内のkey-distribution-periodです。
o The key-package-type attributes indicates the format of the key package, and it has no further scope. The key-package-type attributes values within (5) and (8) are evaluated without regard to the value of this attribute.
o key-package-type属性は、キーパッケージの形式を示し、それ以上のスコープはありません。 （5）および（8）内のkey-package-type属性値は、この属性の値に関係なく評価されます。
ContentWithAttributes content type (4) includes four attributes:
ContentWithAttributesコンテンツタイプ（4）には4つの属性が含まれます。
o The classification attribute contains the security label for all of the plaintext in the encapsulated content. Each classification attribute is evaluated separately; it has no further scope.
o 分類属性には、カプセル化されたコンテンツのすべてのプレーンテキストのセキュリティラベルが含まれています。各分類属性は個別に評価されます。それ以上のスコープはありません。
o The TSEC-Nomenclature attribute includes only the shortTitle field, and the value must match all other instances within the same scope, which appear in (5) and (6). Note that the TSEC-Nomenclature attribute values in (8) and (9) are not in the same scope as the TSEC-Nomenclature attribute that appears in (4).
o TSEC-Nomenclature属性にはshortTitleフィールドのみが含まれ、値は（5）と（6）に表示される同じスコープ内の他のすべてのインスタンスと一致する必要があります。 （8）と（9）のTSEC-Nomenclature属性値は、（4）に表示されるTSEC-Nomenclature属性と同じスコープではないことに注意してください。
o The key-package-receivers-v2 attribute indicates the authorized key package receivers, and it has no further scope. The enveloping instance of key-package-receivers-v2 attribute value in (2) is evaluated without regard to the value of this instance in (4), and has no effect on the value of this instance in (4).
o key-package-receivers-v2属性は、承認されたキーパッケージレシーバーを示し、それ以上のスコープはありません。 （2）のkey-package-receivers-v2属性値のエンベロープインスタンスは、（4）のこのインスタンスの値に関係なく評価され、（4）のこのインスタンスの値には影響しません。
o The key-distribution-period attribute contains two date values: doNotDistBefore and doNotDistAfter. These values must match all others within the same scope, which in this example is the key-distribution-period within (2).
o key-distribution-period属性には、doNotDistBeforeとdoNotDistAfterの2つの日付値が含まれています。これらの値は、同じスコープ内の他のすべてと一致する必要があります。この例では、（2）内のkey-distribution-periodです。
SignedData content type (5) includes six signed attributes:
SignedDataコンテンツタイプ（5）には、6つの署名済み属性が含まれています。
o The content-type attribute contains id-ct-KP-skeyPackage to indicate the type of the encapsulated content, and it has no further scope.
o content-type属性には、カプセル化されたコンテンツのタイプを示すid-ct-KP-skeyPackageが含まれ、それ以上のスコープはありません。
o The message-digest attribute contains the one-way hash value of the encapsulated content; it is needed to validate the digital signature. It has no further scope.
o message-digest属性には、カプセル化されたコンテンツの一方向のハッシュ値が含まれます。デジタル署名を検証するために必要です。それ以上のスコープはありません。
o The classification attribute contains the security label for all of the plaintext in the encapsulated content. Each classification attribute is evaluated separately; it has no further scope.
o 分類属性には、カプセル化されたコンテンツのすべてのプレーンテキストのセキュリティラベルが含まれています。各分類属性は個別に評価されます。それ以上のスコープはありません。
o The TSEC-Nomenclature attribute includes only the shortTitle field, and the value must match all other instances within the same scope, which appear in (6). Since this is within the scope of (4), these shortTitle field values must match as well. Note that the TSEC-Nomenclature attribute values in (8) and (9) are not in the same scope.
o TSEC-Nomenclature属性にはshortTitleフィールドのみが含まれ、値は（6）に表示される同じスコープ内の他のすべてのインスタンスと一致する必要があります。これは（4）の範囲内であるため、これらのshortTitleフィールド値も一致する必要があります。 （8）と（9）のTSEC-Nomenclature属性値は同じスコープ内にないことに注意してください。
o The key-purpose attribute specifies the purpose of the key material. All occurrences within the scope must have the same value; however, in this example, there are no other occurrences within the scope. The key-purpose attribute value within (8) is evaluated without regard to the value of this attribute.
o key-purpose属性は、鍵素材の目的を指定します。スコープ内のすべてのオカレンスは同じ値でなければなりません。ただし、この例では、スコープ内に他のオカレンスはありません。 （8）内のキー目的の属性値は、この属性の値に関係なく評価されます。
o The key-package-type attribute indicates the format of the key package, and it has no further scope. The key-package-type attribute values within (2) and (8) are evaluated without regard to the value of this attribute.
o key-package-type属性は、キーパッケージの形式を示し、それ以上のスコープはありません。 （2）と（8）内のkey-package-type属性値は、この属性の値に関係なく評価されます。
SymmetricKeyPackage content type (6) includes three keying material attributes, which could appear in the sKeyPkgAttrs or sKeyAttrs fields:
SymmetricKeyPackageコンテンツタイプ（6）には、sKeyPkgAttrsまたはsKeyAttrsフィールドに表示される3つのキーマテリアル属性が含まれています。
o The key-algorithm attribute includes only the keyAlg field, and it must match all other occurrences within the same scope. However, there are no other key-algorithm attribute occurrences in the same scope; the key-algorithm attribute value in (9) is not in the same scope.
o key-algorithm属性にはkeyAlgフィールドのみが含まれ、同じスコープ内の他のすべてのオカレンスと一致する必要があります。ただし、同じスコープ内に他のキーアルゴリズム属性オカレンスはありません。 （9）のキーアルゴリズム属性値は同じスコープ内にありません。
o The classification attribute contains the security label for all of the plaintext in the key package. Each classification attribute is evaluated separately; it has no further scope.
o 分類属性には、キーパッケージ内のすべてのプレーンテキストのセキュリティラベルが含まれています。各分類属性は個別に評価されます。それ以上のスコープはありません。
o The TSEC-Nomenclature attribute includes the shortTitle field as well as some of the optional fields. The shortTitle field value must match the values in (4) and (5), since this content type is within their scope. Note that the TSEC-Nomenclature attribute values in (8) and (9) are not in the same scope.
o TSEC-Nomenclature属性には、shortTitleフィールドと一部のオプションフィールドが含まれます。このコンテンツタイプはスコープ内にあるため、shortTitleフィールドの値は（4）および（5）の値と一致する必要があります。 （8）と（9）のTSEC-Nomenclature属性値は同じスコープ内にないことに注意してください。
EncryptedKeyPackage content type (7) includes one unprotected attribute, and the encryption will prevent any intermediary that does not have the ability to decrypt the content from making any consistency checks on (8) and (9):
EncryptedKeyPackageコンテンツタイプ（7）には保護されていない属性が1つ含まれており、暗号化により、コンテンツを復号化できない中間者が（8）と（9）の整合性チェックを実行できなくなります。
o The content-decryption-key-identifier attribute identifies the key that is needed to decrypt the encapsulated content; it has no further scope.
o content-decryption-key-identifier属性は、カプセル化されたコンテンツを復号化するために必要なキーを識別します。それ以上のスコープはありません。
SignedData content type (8) includes six signed attributes:
SignedDataコンテンツタイプ（8）には、6つの署名済み属性が含まれています。
o The content-type attribute contains id-ct-KP-skeyPackage to indicate the type of the encapsulated content, and it has no further scope.
o content-type属性には、カプセル化されたコンテンツのタイプを示すid-ct-KP-skeyPackageが含まれ、それ以上のスコープはありません。
o The message-digest attribute contains the one-way hash value of the encapsulated content; it is needed to validate the digital signature. It has no further scope.
o message-digest属性には、カプセル化されたコンテンツの一方向のハッシュ値が含まれます。デジタル署名を検証するために必要です。それ以上のスコープはありません。
o The classification attribute contains the security label for content. Each classification attribute is evaluated separately; it has no further scope.
o 分類属性には、コンテンツのセキュリティラベルが含まれています。各分類属性は個別に評価されます。それ以上のスコープはありません。
o The TSEC-Nomenclature attribute includes only the shortTitle field, and the value must match all other instances within the same scope, which appear in (9). Note that the TSEC-Nomenclature attribute values in (4), (5), and (6) are not in the same scope.
o TSEC-Nomenclature属性にはshortTitleフィールドのみが含まれ、値は（9）に表示される同じスコープ内の他のすべてのインスタンスと一致する必要があります。 （4）、（5）、および（6）のTSEC-Nomenclature属性値は同じスコープ内にないことに注意してください。
o The key-purpose attribute specifies the purpose of the key material. All occurrences within the scope must have the same value; however, in this example, there are no other occurrences within the scope. The key-purpose attribute value within (5) is evaluated without regard to the value of this attribute.
o key-purpose属性は、鍵素材の目的を指定します。スコープ内のすべてのオカレンスは同じ値でなければなりません。ただし、この例では、スコープ内に他のオカレンスはありません。 （5）内のキー目的の属性値は、この属性の値に関係なく評価されます。
o The key-package-type attribute indicates the format of the key package, and it has no further scope. The key-package-type attribute values within (2) and (5) are evaluated without regard to the value of this attribute.
o key-package-type属性は、キーパッケージの形式を示し、それ以上のスコープはありません。 （2）および（5）内のkey-package-type属性値は、この属性の値に関係なく評価されます。
SymmetricKeyPackage content type (9) includes three keying material attributes, which could appear in the sKeyPkgAttrs or sKeyAttrs fields:
SymmetricKeyPackageコンテンツタイプ（9）には、sKeyPkgAttrsまたはsKeyAttrsフィールドに表示される3つのキーマテリアル属性が含まれています。
o The key-algorithm attribute includes only the keyAlg field, and it must match all other occurrences within the same scope. However, there are no other key-algorithm attribute occurrences in the same scope; the key-algorithm attribute value in (6) is not in the same scope.
o key-algorithm属性にはkeyAlgフィールドのみが含まれ、同じスコープ内の他のすべてのオカレンスと一致する必要があります。ただし、同じスコープ内に他のキーアルゴリズム属性オカレンスはありません。 （6）のキーアルゴリズム属性値は同じスコープ内にありません。
o The classification attribute contains the security label for all of the plaintext in the key package. Each classification attribute is evaluated separately; it has no further scope.
o 分類属性には、キーパッケージ内のすべてのプレーンテキストのセキュリティラベルが含まれています。各分類属性は個別に評価されます。それ以上のスコープはありません。
o The TSEC-Nomenclature attribute includes the shortTitle field as well as some of the optional fields. The shortTitle field value must match the values in (8), since this content type is within its scope. Note that the TSEC-Nomenclature attributes values in (4), (5), and (6) are not in the same scope.
o TSEC-Nomenclature属性には、shortTitleフィールドと一部のオプションフィールドが含まれます。このコンテンツタイプはスコープ内にあるため、shortTitleフィールドの値は（8）の値と一致する必要があります。 （4）、（5）、および（6）のTSEC-Nomenclature属性値は同じスコープ内にないことに注意してください。
In summary, the scope of an attribute includes the encapsulated content of the CMS content type in which it appears, and some attributes also require consistency checks with other instances that appear within the encapsulated content. Proper recognition of scope is required to accurately perform attribute processing.
要約すると、属性のスコープには、それが表示されるCMSコンテンツタイプのカプセル化されたコンテンツが含まれます。また、一部の属性は、カプセル化されたコンテンツ内に表示される他のインスタンスとの整合性チェックも必要です。属性処理を正確に実行するには、スコープの適切な認識が必要です。
+------------------------------------------------------------------+
| ContentInfo (1) |
|+----------------------------------------------------------------+|
|| SignedData (2) ||
||+--------------------------------------------------------------+||
||| ContentCollection (3) |||
|||+-----------------------------++-----------------------------+|||
|||| ContentWithAttributes (4) || EncryptedKeyPackage (7) ||||
||||+---------------------------+||+---------------------------+||||
||||| SignedData (5) |||| SignedData (8) |||||
|||||+-------------------------+||||+-------------------------+|||||
|||||| SymmetricKeyPackage (6) |||||| SymmetricKeyPackage (9) ||||||
|||||| Attributes: |||||| Attributes: ||||||
|||||| Key Algorithm |||||| Key Algorithm ||||||
|||||| Classification |||||| Classification ||||||
|||||| TSEC-Nomenclature |||||| TSEC-Nomenclature ||||||
|||||+-------------------------+||||+-------------------------+|||||
||||| Attributes: |||| Attributes: |||||
||||| Content Type |||| Content Type |||||
||||| Message Digest |||| Message Digest |||||
||||| Classification |||| Classification |||||
||||| TSEC-Nomenclature |||| TSEC-Nomenclature |||||
||||| Key Purpose |||| Key Purpose |||||
||||| Key Package Type |||| Key Package Type |||||
||||+-------------------------- +||+---------------------------+||||
|||| Attributes: || Unprotect Attributes: ||||
|||| Classification || Content Decrypt Key ID ||||
|||| TSEC-Nomenclature |+-----------------------------+|||
|||| Key Package Receivers | |||
|||| Key Distribution Period | |||
|||+-----------------------------+ |||
||+--------------------------------------------------------------+||
|| Attributes: ||
|| Content Type ||
|| Message Digest ||
|| Classification ||
|| Key Package Receivers ||
|| Key Distribution Period ||
|| Key Package Type ||
|+----------------------------------------------------------------+|
+------------------------------------------------------------------+
Figure 1: Example Illustrating Scope of Attributes
図1：属性のスコープを示す例
The majority of this specification is devoted to the syntax and semantics of key package attributes. It relies on other specifications, especially [RFC2634], [RFC4073], [RFC4108], [RFC5652], [RFC5911], [RFC5912], [RFC5958], [RFC6010], and [RFC6031]; their security considerations apply here. Additionally, cryptographic algorithms are used with CMS protecting content types as specified in [RFC5959], [RFC6160], [RFC6161], and [RFC6162]; the security considerations from those documents apply here as well.
この仕様の大部分は、主要なパッケージ属性の構文とセマンティクスに特化しています。他の仕様、特に[RFC2634]、[RFC4073]、[RFC4108]、[RFC5652]、[RFC5911]、[RFC5912]、[RFC5958]、[RFC6010]、および[RFC6031]に依存しています。ここでは、セキュリティに関する考慮事項が適用されます。さらに、暗号化アルゴリズムは、[RFC5959]、[RFC6160]、[RFC6161]、および[RFC6162]で指定されているコンテンツタイプを保護するCMSで使用されます。これらのドキュメントのセキュリティに関する考慮事項もここに適用されます。
This specification also relies upon [RFC5280] for the syntax and semantics of X.509 certificates. Digital signatures provide data integrity or data origin authentication, and encryption provides confidentiality.
この仕様は、X.509証明書の構文とセマンティクスについても[RFC5280]に依存しています。デジタル署名はデータの整合性またはデータ発信元の認証を提供し、暗号化は機密性を提供します。
Security factors outside the scope of this specification greatly affect the assurance provided. The procedures used by Certification Authorities (CAs) to validate the binding of the subject identity to their public key greatly affect the assurance that ought to be placed in the certificate. This is particularly important when issuing certificates to other CAs.
この仕様の範囲外のセキュリティ要素は、提供される保証に大きく影響します。証明機関（CA）がサブジェクトIDと公開キーのバインドを検証するために使用する手順は、証明書に配置する必要がある保証に大きく影響します。これは、他のCAに証明書を発行するときに特に重要です。
The CMS AuthenticatedData content type MUST be used with care since a Message Authentication Code (MAC) is used. The same key is needed to generate the MAC or validate the MAC. Thus, any party with access to the key needed to validate the MAC can generate a replacement that will be acceptable to other recipients.
メッセージ認証コード（MAC）が使用されるため、CMS AuthenticatedDataコンテンツタイプは注意して使用する必要があります。 MACの生成またはMACの検証には、同じキーが必要です。したがって、MACを検証するために必要なキーへのアクセス権を持つ任意の当事者が、他の受信者に受け入れられる置換を生成できます。
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 generic or detailed error codes.
状況によっては、非常に詳細なエラー情報を返すことで、攻撃者がセキュリティ処理を理解することができます。これが問題になる場合、実装は適切な最も一般的なエラーコードを返す必要があります。ただし、詳細なエラーコードは、開発、デバッグ、および相互運用性のテスト中に非常に役立ちます。このため、実装では、一般的なエラーコードまたは詳細なエラーコードの使用を構成する方法が必要になる場合があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC 2634, DOI 10.17487/RFC2634, June 1999, <http://www.rfc-editor.org/info/rfc2634>.
[RFC2634] Hoffman、P.、Ed。、「Enhanced Security Services for S / MIME」、RFC 2634、DOI 10.17487 / RFC2634、1999年6月、<http://www.rfc-editor.org/info/rfc2634>。
[RFC4073] Housley, R., "Protecting Multiple Contents with the Cryptographic Message Syntax (CMS)", RFC 4073, DOI 10.17487/RFC4073, May 2005, <http://www.rfc-editor.org/info/rfc4073>.
[RFC4073] Housley、R。、「暗号化メッセージ構文（CMS）による複数のコンテンツの保護」、RFC 4073、DOI 10.17487 / RFC4073、2005年5月、<http://www.rfc-editor.org/info/rfc4073> 。
[RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", RFC 4108, DOI 10.17487/RFC4108, August 2005, <http://www.rfc-editor.org/info/rfc4108>.
[RFC4108] Housley、R。、「Cryptographic Message Syntax（CMS）to Protect Firmware Packages」、RFC 4108、DOI 10.17487 / RFC4108、2005年8月、<http://www.rfc-editor.org/info/rfc4108> 。
[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, DOI 10.17487/RFC5083, November 2007, <http://www.rfc-editor.org/info/rfc5083>.
[RFC5083] Housley、R。、「Cryptographic Message Syntax（CMS）Authenticated-Enveloped-Data Content Type」、RFC 5083、DOI 10.17487 / RFC5083、2007年11月、<http://www.rfc-editor.org/info/ rfc5083>。
[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, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[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、DOI 10.17487 / RFC5280、2008年5月、<http://www.rfc-editor.org/info/rfc5280>。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <http://www.rfc-editor.org/info/rfc5652>.
[RFC5652] Housley、R。、「Cryptographic Message Syntax（CMS）」、STD 70、RFC 5652、DOI 10.17487 / RFC5652、2009年9月、<http://www.rfc-editor.org/info/rfc5652>。
[RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, DOI 10.17487/RFC5911, June 2010, <http://www.rfc-editor.org/info/rfc5911>.
[RFC5911] Hoffman、P。およびJ. Schaad、「暗号化メッセージ構文（CMS）およびS / MIMEの新しいASN.1モジュール」、RFC 5911、DOI 10.17487 / RFC5911、2010年6月、<http：//www.rfc -editor.org/info/rfc5911>。
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010, <http://www.rfc-editor.org/info/rfc5912>.
[RFC5912] Hoffman、P。およびJ. Schaad、「X.509（PKIX）を使用した公開鍵インフラストラクチャ用の新しいASN.1モジュール」、RFC 5912、DOI 10.17487 / RFC5912、2010年6月、<http：// www。 rfc-editor.org/info/rfc5912>。
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 10.17487/RFC5958, August 2010, <http://www.rfc-editor.org/info/rfc5958>.
[RFC5958]ターナー、S。、「非対称鍵パッケージ」、RFC 5958、DOI 10.17487 / RFC5958、2010年8月、<http://www.rfc-editor.org/info/rfc5958>。
[RFC5959] Turner, S., "Algorithms for Asymmetric Key Package Content Type", RFC 5959, DOI 10.17487/RFC5959, August 2010, <http://www.rfc-editor.org/info/rfc5959>.
[RFC5959] Turner、S。、「Algorithms for Asymmetric Key Package Content Type」、RFC 5959、DOI 10.17487 / RFC5959、2010年8月、<http://www.rfc-editor.org/info/rfc5959>。
[RFC6010] Housley, R., Ashmore, S., and C. Wallace, "Cryptographic Message Syntax (CMS) Content Constraints Extension", RFC 6010, DOI 10.17487/RFC6010, September 2010, <http://www.rfc-editor.org/info/rfc6010>.
[RFC6010] Housley、R.、Ashmore、S。、およびC. Wallace、「Cryptographic Message Syntax（CMS）Content Constraints Extension」、RFC 6010、DOI 10.17487 / RFC6010、2010年9月、<http：//www.rfc- editor.org/info/rfc6010>。
[RFC6019] Housley, R., "BinaryTime: An Alternate Format for Representing Date and Time in ASN.1", RFC 6019, DOI 10.17487/RFC6019, September 2010, <http://www.rfc-editor.org/info/rfc6019>.
[RFC6019] Housley、R。、「BinaryTime：ASN.1で日付と時刻を表すための代替フォーマット」、RFC 6019、DOI 10.17487 / RFC6019、2010年9月、<http://www.rfc-editor.org/info / rfc6019>。
[RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type", RFC 6031, DOI 10.17487/RFC6031, December 2010, <http://www.rfc-editor.org/info/rfc6031>.
[RFC6031]ターナー、S。およびR.ハウズリー、「Cryptographic Message Syntax（CMS）Symmetric Key Package Content Type」、RFC 6031、DOI 10.17487 / RFC6031、2010年12月、<http://www.rfc-editor.org/ info / rfc6031>。
[RFC6032] Turner, S. and R. Housley, "Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type", RFC 6032, DOI 10.17487/RFC6032, December 2010, <http://www.rfc-editor.org/info/rfc6032>.
[RFC6032]ターナー、S。およびR.ハウズリー、「Cryptographic Message Syntax（CMS）Encrypted Key Package Content Type」、RFC 6032、DOI 10.17487 / RFC6032、2010年12月、<http://www.rfc-editor.org/ info / rfc6032>。
[RFC6160] Turner, S., "Algorithms for Cryptographic Message Syntax (CMS) Protection of Symmetric Key Package Content Types", RFC 6160, DOI 10.17487/RFC6160, April 2011, <http://www.rfc-editor.org/info/rfc6160>.
[RFC6160]ターナー、S。、「対称キーパッケージコンテンツタイプの暗号化メッセージ構文（CMS）保護のアルゴリズム」、RFC 6160、DOI 10.17487 / RFC6160、2011年4月、<http://www.rfc-editor.org/ info / rfc6160>。
[RFC6162] Turner, S., "Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Asymmetric Key Package Content Type", RFC 6162, DOI 10.17487/RFC6162, April 2011, <http://www.rfc-editor.org/info/rfc6162>.
[RFC6162]ターナーS.、「暗号化メッセージ構文（CMS）非対称鍵パッケージコンテンツタイプの楕円曲線アルゴリズム」、RFC 6162、DOI 10.17487 / RFC6162、2011年4月、<http://www.rfc-editor.org/ info / rfc6162>。
[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, DOI 10.17487/RFC6268, July 2011, <http://www.rfc-editor.org/info/rfc6268>.
[RFC6268] Schaad、J。およびS. Turner、「暗号化メッセージ構文（CMS）およびX.509（PKIX）を使用した公開鍵インフラストラクチャのための追加の新しいASN.1モジュール」、RFC 6268、DOI 10.17487 / RFC6268、7月2011、<http://www.rfc-editor.org/info/rfc6268>。
[RFC7191] Housley, R., "Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types", RFC 7191, DOI 10.17487/RFC7191, April 2014, <http://www.rfc-editor.org/info/rfc7191>.
[RFC7191] Housley、R。、「Cryptographic Message Syntax（CMS）Key Package Receipt and Error Content Types」、RFC 7191、DOI 10.17487 / RFC7191、2014年4月、<http://www.rfc-editor.org/info/ rfc7191>。
[X.509] ITU-T, "Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks", ITU-T Recommendation X.509 | ISO/IEC 9594-8:2005, 2005.
[X.509] ITU-T、「情報技術-オープンシステム相互接続-ディレクトリ：公開鍵と属性証明書フレームワーク」、ITU-T勧告X.509 | ISO / IEC 9594-8：2005、2005。
[X.680] ITU-T, "Information Technology - Abstract Syntax Notation One", ITU-T Recommendation X.680 | ISO/IEC 8824-1:2002, 2002.
[X.680] ITU-T、「情報技術-抽象構文記法1」、ITU-T勧告X.680 | ISO / IEC 8824-1：2002、2002。
[X.681] ITU-T, "Information Technology - Abstract Syntax Notation One: Information Object Specification", ITU-T Recommendation X.681 | ISO/IEC 8824-2:2002, 2002.
[X.681] ITU-T、「情報技術-抽象構文記法1：情報オブジェクト仕様」、ITU-T勧告X.681 | ISO / IEC 8824-2：2002、2002。
[X.682] ITU-T, "Information Technology - Abstract Syntax Notation One: Constraint Specification", ITU-T Recommendation X.682 | ISO/IEC 8824-3:2002, 2002.
[X.682] ITU-T、「情報技術-抽象構文記法1：制約仕様」、ITU-T勧告X.682 | ISO / IEC 8824-3：2002、2002。
[X.683] ITU-T, "Information Technology - Abstract Syntax Notation One: Parameterization of ASN.1 Specifications", ITU-T Recommendation X.683 | ISO/IEC 8824-4:2002, 2002.
[X.683] ITU-T、「情報技術-抽象構文記法1：ASN.1仕様のパラメーター化」、ITU-T勧告X.683 | ISO / IEC 8824-4：2002、2002。
[X.690] ITU-T, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690 | ISO/IEC 8825-1:2002, 2002.
[X.690] ITU-T、「情報技術-ASN.1エンコーディングルール：基本エンコーディングルール（BER）、正規エンコーディングルール（CER）およびDistinguished Encodingルール（DER）の仕様」、ITU-T勧告X.690 | ISO / IEC 8825-1：2002、2002。
[RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Management Protocol (TAMP)", RFC 5934, DOI 10.17487/RFC5934, August 2010, <http://www.rfc-editor.org/info/rfc5934>.
[RFC5934] Housley、R.、Ashmore、S。、およびC. Wallace、「Trust Anchor Management Protocol（TAMP）」、RFC 5934、DOI 10.17487 / RFC5934、2010年8月、<http：//www.rfc-editor。 org / info / rfc5934>。
[X.411] ITU-T, "Information technology - Message Handling Systems (MHS): Message Transfer System: Abstract Service Definition and Procedures", ITU-T Recommendation X.411 | ISO/IEC 10021-4:1999, 1999.
[X.411] ITU-T、「情報技術-メッセージ処理システム（MHS）：メッセージ転送システム：抽象サービスの定義と手順」、ITU-T勧告X.411 | ISO / IEC 10021-4：1999、1999。
KMAttributes2012
{ joint-iso-itu-t(2) country(16) us(840) organization(1)
gov(101) dod(2) infosec(1) modules(0) 39 }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
ベギン
-- EXPORT ALL
-すべてエクスポート
IMPORTS
輸入
-- From [RFC5911]
-[RFC5911]から
aa-communityIdentifiers, CommunityIdentifier
FROM CMSFirmwareWrapper-2009
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cms-firmware-wrap-02(40) }
-- From [RFC5911]
-[RFC5911]から
aa-contentHint, ESSSecurityLabel, id-aa-securityLabel
FROM ExtendedSecurityServices-2009
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-ess-2006-02(42) }
-- From [RFC5911] [RFC5912]
-[RFC5911] [RFC5912]から
AlgorithmIdentifier{}, SMIME-CAPS, ParamOptions, KEY-WRAP
FROM AlgorithmInformation-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) }
-- From [RFC5912]
-[RFC5912]から
Name, Certificate
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) }
-- From [RFC5912]
-[RFC5912]から
GeneralNames, SubjectInfoAccessSyntax, id-pe-subjectInfoAccess
FROM PKIX1Implicit-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-implicit-02(59) }
-- FROM [RFC5912]
-FROM [RFC5912]
ATTRIBUTE
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) }
-- From [RFC6010]
-[RFC6010]から
CMSContentConstraints
FROM CMSContentConstraintsCertExtn
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
cmsContentConstr-93(42) }
-- From [RFC6268]
-[RFC6268]から
aa-binarySigningTime, BinaryTime
FROM BinarySigningTimeModule-2010
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-binSigningTime-2009(55) }
-- From [RFC6268]
-[RFC6268]から
CertificateChoices, CertificateSet, Attribute {},
aa-contentType, aa-messageDigest
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 [RFC7191]
-[RFC7191]から
aa-keyPackageIdentifierAndReceiptRequest, SIREntityName
FROM KeyPackageReceiptAndErrorModuleV2
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-keyPkgReceiptAndErrV2(63) }
-- From [X.509]
-[X.509]から
certificateExactMatch
FROM CertificateExtensions
{ joint-iso-itu-t ds(5) module(1) certificateExtensions(26) 4 }
;
；
-- ATTRIBUTES
-属性
-- Replaces SignedAttributesSet information object set from
-- [RFC6268].
SignedAttributesSet ATTRIBUTE ::= {
aa-contentType |
aa-messageDigest |
aa-contentHint |
aa-communityIdentifiers |
aa-binarySigningTime |
aa-keyProvince-v2 |
aa-keyPackageIdentifierAndReceiptRequest |
aa-manifest |
aa-keyAlgorithm |
aa-userCertificate |
aa-keyPackageReceivers-v2 |
aa-tsecNomenclature |
aa-keyPurpose |
aa-keyUse |
aa-transportKey |
aa-keyDistributionPeriod |
aa-keyValidityPeriod |
aa-keyDurationPeriod |
aa-classificationAttribute |
aa-keyPackageType |
aa-pkiPath |
aa-usefulCertificates,
... }
-- Replaces UnsignedAttributes from [RFC6268].
-[RFC6268]のUnsignedAttributesを置き換えます。
UnsignedAttributes ATTRIBUTE ::= {
...
}
-- Replaces UnprotectedEnvAttributes from [RFC6268].
-UnprotectedEnvAttributesを[RFC6268]から置き換えます。
UnprotectedEnvAttributes ATTRIBUTE ::= {
aa-contentDecryptKeyIdentifier |
aa-certificatePointers |
aa-cRLDistributionPoints,
...
}
-- Replaces UnprotectedEncAttributes from [RFC6268].
-[RFC6268]のUnprotectedEncAttributesを置き換えます。
UnprotectedEncAttributes ATTRIBUTE ::= {
aa-certificatePointers |
aa-cRLDistributionPoints,
...
}
-- Replaces AuthAttributeSet from [RFC6268]
-[RFC6268]のAuthAttributeSetを置き換えます
AuthAttributeSet ATTRIBUTE ::= {
aa-contentType |
aa-messageDigest |
aa-contentHint |
aa-communityIdentifiers |
aa-keyProvince-v2 |
aa-binarySigningTime |
aa-keyPackageIdentifierAndReceiptRequest |
aa-manifest |
aa-keyAlgorithm |
aa-userCertificate |
aa-keyPackageReceivers-v2 |
aa-tsecNomenclature |
aa-keyPurpose |
aa-keyUse |
aa-transportKey |
aa-keyDistributionPeriod |
aa-keyValidityPeriod |
aa-keyDurationPeriod |
aa-classificationAttribute |
aa-keyPackageType |
aa-pkiPath |
aa-usefulCertificates,
... }
-- Replaces UnauthAttributeSet from [RFC6268]
-[RFC6268]のUnauthAttributeSetを置き換えます
UnauthAttributeSet ATTRIBUTE ::= {
...
}
-- Replaces AuthEnvDataAttributeSet from [RFC6268]
-[RFC6268]のAuthEnvDataAttributeSetを置き換えます
AuthEnvDataAttributeSet ATTRIBUTE ::= {
aa-certificatePointers |
aa-cRLDistributionPoints,
...
}
-- Replaces UnauthEnvDataAttributeSet from [RFC6268]
-[RFC6268]のUnauthEnvDataAttributeSetを置き換えます
UnauthEnvDataAttributeSet ATTRIBUTE ::= {
...
}
-- Replaces OneAsymmetricKeyAttributes from [RFC5958]
-[RFC5958]のOneAsymmetricKeyAttributesを置き換えます
OneAsymmetricKeyAttributes ATTRIBUTE ::= {
aa-userCertificate |
aa-tsecNomenclature |
aa-keyPurpose |
aa-keyUse |
aa-transportKey |
aa-keyDistributionPeriod |
aa-keyValidityPeriod |
aa-keyDurationPeriod |
aa-classificationAttribute |
aa-splitIdentifier |
aa-signatureUsage-v3 |
aa-otherCertificateFormats |
aa-pkiPath |
aa-usefulCertificates,
... }
-- Replaces SKeyPkgAttributes from [RFC6031]
-[RFC6031]のSKeyPkgAttributesを置き換えます
SKeyPkgAttributes ATTRIBUTE ::= {
aa-keyAlgorithm |
aa-tsecNomenclature |
aa-keyPurpose |
aa-keyUse |
aa-keyDistributionPeriod |
aa-keyValidityPeriod |
aa-keyDurationPeriod |
aa-classificationAttribute |
aa-keyWrapAlgorithm |
aa-contentDecryptKeyIdentifier,
... }
-- Replaces SKeyAttributes from [RFC6031]
-[RFC6031]の主要な属性を置き換えます
SKeyAttributes ATTRIBUTE ::= {
aa-keyAlgorithm |
aa-tsecNomenclature |
aa-keyPurpose |
aa-keyUse |
aa-keyDistributionPeriod |
aa-keyValidityPeriod |
aa-keyDurationPeriod |
aa-classificationAttribute |
aa-splitIdentifier |
aa-keyWrapAlgorithm |
aa-contentDecryptKeyIdentifier,
... }
-- Replaces ContentAttributeSet from [RFC6268]
-[RFC6268]のContentAttributeSetを置き換えます
ContentAttributeSet ATTRIBUTE ::= {
aa-communityIdentifiers |
aa-keyPackageIdentifierAndReceiptRequest |
aa-keyAlgorithm |
aa-keyPackageReceivers-v2 |
aa-tsecNomenclature |
aa-keyPurpose |
aa-keyUse |
aa-transportKey |
aa-keyDistributionPeriod |
aa-transportKey |
aa-keyDistributionPeriod |
aa-keyValidityPeriod |
aa-keyDurationPeriod |
aa-classificationAttribute |
aa-keyPackageType |
aa-pkiPath |
aa-usefulCertificates,
... }
-- Content Type, Message Digest, Content Hint, and Binary Signing
-- Time are imported from [RFC6268].
-- Community Identifiers is imported from [RFC5911].
-- Key Province
-キー州
aa-keyProvince-v2 ATTRIBUTE ::= {
TYPE KeyProvinceV2
IDENTIFIED BY id-aa-KP-keyProvinceV2 }
id-aa-KP-keyProvinceV2 OBJECT IDENTIFIER ::=
{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) attributes(5) 71 }
KeyProvinceV2 ::= OBJECT IDENTIFIER
-- Manifest Attribute
-マニフェスト属性
aa-manifest ATTRIBUTE ::= {
TYPE Manifest
IDENTIFIED BY id-aa-KP-manifest }
id-aa-KP-manifest OBJECT IDENTIFIER ::=
{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) attributes(5) 72 }
Manifest ::= SEQUENCE SIZE (1..MAX) OF ShortTitle
-- Key Algorithm Attribute
-主要なアルゴリズム属性
aa-keyAlgorithm ATTRIBUTE ::= {
TYPE KeyAlgorithm
IDENTIFIED BY id-kma-keyAlgorithm }
id-kma-keyAlgorithm OBJECT IDENTIFIER ::=
{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) keying-material-attributes(13) 1 }
KeyAlgorithm ::= SEQUENCE {
keyAlg OBJECT IDENTIFIER,
checkWordAlg [1] OBJECT IDENTIFIER OPTIONAL,
crcAlg [2] OBJECT IDENTIFIER OPTIONAL }
-- User Certificate Attribute
-ユーザー証明書属性
aa-userCertificate ATTRIBUTE ::= {
TYPE Certificate
EQUALITY MATCHING RULE certificateExactMatch
IDENTIFIED BY id-at-userCertificate }
id-at-userCertificate OBJECT IDENTIFIER ::=
{ joint-iso-itu-t(2) ds(5) attributes(4) 36 }
-- Key Package Receivers Attribute
-主要なパッケージレシーバー属性
aa-keyPackageReceivers-v2 ATTRIBUTE ::= {
TYPE KeyPkgReceiversV2
IDENTIFIED BY id-kma-keyPkgReceiversV2 }
id-kma-keyPkgReceiversV2 OBJECT IDENTIFIER ::=
{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) keying-material-attributes(13) 16 }
KeyPkgReceiversV2 ::= SEQUENCE SIZE (1..MAX) OF KeyPkgReceiver
KeyPkgReceiver ::= CHOICE {
sirEntity [0] SIREntityName,
community [1] CommunityIdentifier }
-- TSEC Nomenclature Attribute
-TSECの命名属性
aa-tsecNomenclature ATTRIBUTE ::= {
TYPE TSECNomenclature
IDENTIFIED BY id-kma-TSECNomenclature }
id-kma-TSECNomenclature OBJECT IDENTIFIER ::=
{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) keying-material-attributes(13) 3 }
TSECNomenclature ::= SEQUENCE {
shortTitle ShortTitle,
editionID EditionID OPTIONAL,
registerID RegisterID OPTIONAL,
segmentID SegmentID OPTIONAL }
ShortTitle ::= PrintableString
EditionID ::= CHOICE {
char CHOICE {
charEdition [1] CharEdition,
charEditionRange [2] CharEditionRange },
num CHOICE {
numEdition [3] NumEdition,
numEditionRange [4] NumEditionRange } }
CharEdition ::= PrintableString
CharEditionRange ::= SEQUENCE {
firstCharEdition CharEdition,
lastCharEdition CharEdition }
NumEdition ::= INTEGER (0..308915776)
NumEditionRange ::= SEQUENCE {
firstNumEdition NumEdition,
lastNumEdition NumEdition }
RegisterID ::= CHOICE {
register [5] Register,
registerRange [6] RegisterRange }
Register ::= INTEGER (0..2147483647)
RegisterRange ::= SEQUENCE {
firstRegister Register,
lastRegister Register }
SegmentID ::= CHOICE {
segmentNumber [7] SegmentNumber,
segmentRange [8] SegmentRange }
SegmentNumber ::= INTEGER (1..127)
SegmentRange ::= SEQUENCE {
firstSegment SegmentNumber,
lastSegment SegmentNumber }
-- Key Purpose Attribute
-主な目的の属性
aa-keyPurpose ATTRIBUTE ::= {
TYPE KeyPurpose
IDENTIFIED BY id-kma-keyPurpose }
id-kma-keyPurpose OBJECT IDENTIFIER ::=
{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) keying-material-attributes(13) 13 }
KeyPurpose ::= ENUMERATED {
n-a (0), -- Not Applicable
a (65), -- Operational
b (66), -- Compatible Multiple Key
l (76), -- Logistics Combinations
m (77), -- Maintenance
r (82), -- Reference
s (83), -- Sample
t (84), -- Training
v (86), -- Developmental
x (88), -- Exercise
z (90), -- "On the Air" Testing
... -- Expect additional key purpose values -- }
-- Key Use Attribute
-キー使用属性
aa-keyUse ATTRIBUTE ::= {
TYPE KeyUse
IDENTIFIED BY id-kma-keyUse }
id-kma-keyUse OBJECT IDENTIFIER ::=
{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) keying-material-attributes(13) 14 }
KeyUse ::= ENUMERATED {
n-a (0), -- Not Applicable
ffk (1), -- FIREFLY/CROSSTALK Key (Basic Format)
kek (2), -- Key Encryption Key
kpk (3), -- Key Production Key
msk (4), -- Message Signature Key
qkek (5), -- QUADRANT Key Encryption Key
tek (6), -- Traffic Encryption Key
tsk (7), -- Transmission Security Key
trkek (8), -- Transfer Key Encryption Key
nfk (9), -- Netted FIREFLY Key
effk (10), -- FIREFLY Key (Enhanced Format)
ebfk (11), -- FIREFLY Key (Enhanceable Basic Format)
aek (12), -- Algorithm Encryption Key
wod (13), -- Word of Day
kesk (246), -- Key Establishment Key
eik (247), -- Entity Identification Key
ask (248), -- Authority Signature Key
kmk (249), -- Key Modifier Key
rsk (250), -- Revocation Signature Key
csk (251), -- Certificate Signature Key
sak (252), -- Symmetric Authentication Key
rgk (253), -- Random Generation Key
cek (254), -- Certificate Encryption Key
exk (255), -- Exclusion Key
... -- Expect additional key use values -- }
-- Transport Key Attribute
-トランスポートキー属性
aa-transportKey ATTRIBUTE ::= {
TYPE TransOp
IDENTIFIED BY id-kma-transportKey }
id-kma-transportKey OBJECT IDENTIFIER ::=
{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) keying-material-attributes(13) 15 }
TransOp ::= ENUMERATED {
transport (1),
operational (2) }
-- Key Distribution Period Attribute
-キー配布期間属性
aa-keyDistributionPeriod ATTRIBUTE ::= {
TYPE KeyDistPeriod
IDENTIFIED BY id-kma-keyDistPeriod }
id-kma-keyDistPeriod OBJECT IDENTIFIER ::=
{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) keying-material-attributes(13) 5 }
KeyDistPeriod ::= SEQUENCE {
doNotDistBefore [0] BinaryTime OPTIONAL,
doNotDistAfter BinaryTime }
-- Key Validity Period Attribute
-主な有効期間属性
aa-keyValidityPeriod ATTRIBUTE ::= {
TYPE KeyValidityPeriod
IDENTIFIED BY id-kma-keyValidityPeriod }
id-kma-keyValidityPeriod OBJECT IDENTIFIER ::=
{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) keying-material-attributes(13) 6 }
KeyValidityPeriod ::= SEQUENCE {
doNotUseBefore BinaryTime,
doNotUseAfter BinaryTime OPTIONAL }
-- Key Duration Attribute
-キー期間属性
aa-keyDurationPeriod ATTRIBUTE ::= {
TYPE KeyDuration
IDENTIFIED BY id-kma-keyDuration }
id-kma-keyDuration OBJECT IDENTIFIER ::=
{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) keying-material-attributes(13) 7 }
KeyDuration ::= CHOICE {
hours [0] INTEGER (1..ub-KeyDuration-hours),
days INTEGER (1..ub-KeyDuration-days),
weeks [1] INTEGER (1..ub-KeyDuration-weeks),
months [2] INTEGER (1..ub-KeyDuration-months),
years [3] INTEGER (1..ub-KeyDuration-years) }
ub-KeyDuration-hours INTEGER ::= 96
ub-KeyDuration-days INTEGER ::= 732
ub-KeyDuration-weeks INTEGER ::= 104
ub-KeyDuration-months INTEGER ::= 72
ub-KeyDuration-years INTEGER ::= 100
-- Classification Attribute
-分類属性
-- The attribute syntax is imported from [RFC6268]. The term
-- "classification" is used in this document, but the term "security
-- label" is used in [RFC2634]. The terms have the same meaning.
aa-classificationAttribute ATTRIBUTE ::= {
TYPE Classification
IDENTIFIED BY id-aa-KP-classification }
id-aa-KP-classification OBJECT IDENTIFIER ::= id-aa-securityLabel
Classification ::= ESSSecurityLabel
id-enumeratedRestrictiveAttributes OBJECT IDENTIFIER ::=
{ 2 16 840 1 101 2 1 8 3 4 }
id-enumeratedPermissiveAttributes OBJECT IDENTIFIER ::=
{ 2 16 840 1 101 2 1 8 3 1 }
EnumeratedTag ::= SEQUENCE {
tagName OBJECT IDENTIFIER,
attributeList SET OF SecurityAttribute }
SecurityAttribute ::= INTEGER (0..MAX)
-- Split Identifier Attribute
-識別子属性の分割
aa-splitIdentifier ATTRIBUTE ::= {
TYPE SplitID
IDENTIFIED BY id-kma-splitID }
id-kma-splitID OBJECT IDENTIFIER ::=
{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) keying-material-attributes(13) 11 }
SplitID ::= SEQUENCE {
half ENUMERATED { a(0), b(1) },
combineAlg AlgorithmIdentifier
{COMBINE-ALGORITHM, {CombineAlgorithms}} OPTIONAL }
COMBINE-ALGORITHM ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Params OPTIONAL,
¶mPresence ParamOptions DEFAULT absent,
&smimeCaps SMIME-CAPS OPTIONAL
}
WITH SYNTAX {
IDENTIFIER &id
[PARAMS [TYPE &Params] ARE ¶mPresence]
[SMIME-CAPS &smimeCaps]
}
CombineAlgorithms COMBINE-ALGORITHM ::= {
...
}
-- Key Package Type Attribute
-主要なパッケージタイプ属性
aa-keyPackageType ATTRIBUTE ::= {
TYPE KeyPkgType
IDENTIFIED BY id-kma-keyPkgType }
id-kma-keyPkgType OBJECT IDENTIFIER ::=
{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) keying-material-attributes(13) 12 }
KeyPkgType ::= OBJECT IDENTIFIER
-- Signature Usage Attribute
-署名の使用属性
aa-signatureUsage-v3 ATTRIBUTE ::= {
TYPE SignatureUsage
IDENTIFIED BY id-kma-sigUsageV3 }
id-kma-sigUsageV3 OBJECT IDENTIFIER ::=
{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) keying-material-attributes(13) 22 }
SignatureUsage ::= CMSContentConstraints
-- Other Certificate Format Attribute
-その他の証明書形式属性
aa-otherCertificateFormats ATTRIBUTE ::= {
TYPE CertificateChoices
IDENTIFIED BY id-kma-otherCertFormats }
id-kma-otherCertFormats OBJECT IDENTIFIER ::=
{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) keying-material-attributes(13) 19 }
-- PKI Path Attribute
-PKIパス属性
aa-pkiPath ATTRIBUTE ::= {
TYPE PkiPath
IDENTIFIED BY id-at-pkiPath }
id-at-pkiPath OBJECT IDENTIFIER ::=
{ joint-iso-itu-t(2) ds(5) attributes(4) 70 }
PkiPath ::= SEQUENCE SIZE (1..MAX) OF Certificate
-- Useful Certificates Attribute
-有用な証明書属性
aa-usefulCertificates ATTRIBUTE ::= {
TYPE CertificateSet
IDENTIFIED BY id-kma-usefulCerts }
id-kma-usefulCerts OBJECT IDENTIFIER ::=
{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) keying-material-attributes(13) 20 }
-- Key Wrap Attribute
-キーラップ属性
aa-keyWrapAlgorithm ATTRIBUTE ::= {
TYPE AlgorithmIdentifier{KEY-WRAP, {KeyEncryptionAlgorithmSet}}
IDENTIFIED BY id-kma-keyWrapAlgorithm }
id-kma-keyWrapAlgorithm OBJECT IDENTIFIER ::=
{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) keying-material-attributes(13) 21 }
KeyEncryptionAlgorithmSet KEY-WRAP ::= { ... }
-- Content Decryption Key Identifier Attribute
-コンテンツ復号化キー識別子属性
aa-contentDecryptKeyIdentifier ATTRIBUTE ::= {
TYPE ContentDecryptKeyID
IDENTIFIED BY id-aa-KP-contentDecryptKeyID }
id-aa-KP-contentDecryptKeyID OBJECT IDENTIFIER ::=
{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) attributes(5) 66 }
ContentDecryptKeyID::= OCTET STRING
-- Certificate Pointers Attribute
-証明書ポインター属性
aa-certificatePointers ATTRIBUTE ::= {
TYPE SubjectInfoAccessSyntax
IDENTIFIED BY id-pe-subjectInfoAccess }
-- CRL Pointers Attribute
-CRLポインター属性
aa-cRLDistributionPoints ATTRIBUTE ::= {
TYPE GeneralNames
IDENTIFIED BY id-aa-KP-crlPointers }
id-aa-KP-crlPointers OBJECT IDENTIFIER ::=
{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) attributes (5) 70 }
-- ExtendedErrorCodes
-ExtendedErrorCodes
id-errorCodes OBJECT IDENTIFIER ::=
{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) errorCodes(22) }
id-missingKeyType OBJECT IDENTIFIER ::= {
id-errorCodes 1 }
id-privacyMarkTooLong OBJECT IDENTIFIER ::= {
id-errorCodes 2 }
id-unrecognizedSecurityPolicy OBJECT IDENTIFIER ::= {
id-errorCodes 3 }
END
終わり
Authors' Addresses
著者のアドレス
Paul Timmel National Information Assurance Research Laboratory National Security Agency
ポールティメル国家情報保証研究所国家安全保障局
Email: pstimme@nsa.gov
Russ Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 United States
Russ Housley Vigil Security、LLC 918 Spring Knoll Drive Herndon、VA 20170アメリカ
Email: housley@vigilsec.com
Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 United States
Sean Turner IECA、Inc. 3057 Nutley Street、Suite 106 Fairfax、VA 22031アメリカ合衆国
Email: turners@ieca.com