Internet Engineering Task Force (IETF) S. Turner Request for Comments: 6031 IECA Category: Standards Track R. Housley ISSN: 2070-1721 Vigil Security December 2010
Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type
Abstract
This document defines the symmetric key format content type. It is transport independent. The Cryptographic Message Syntax (CMS) can be used to digitally sign, digest, authenticate, or encrypt this content type.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
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/rfc6031.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Turner & Housley Standards Track [Page 1]
RFC 6031 CMS Symmetric Key Package Content Type December 2010
This document defines the symmetric key format content type. It is transport independent. The Cryptographic Message Syntax (CMS) [RFC5652] can be used to digitally sign, digest, authenticate, or encrypt this content type.
The use cases that motivated the attributes in this work are elaborated in [RFC6030]. They are omitted to avoid duplication.
This document also includes ASN.1 definitions of the Extensible Markup Language (XML) element and attributes defined in [RFC6030].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
The symmetric key package content type is used to transfer one or more plaintext symmetric keys from one party to another. A symmetric key package MAY be encapsulated in one or more CMS protecting content types. This content type MUST be Distinguished Encoding Rules (DER) encoded [X.690].
The symmetric key package content type has the following syntax:
ct-symmetric-key-package CONTENT-TYPE ::= { TYPE SymmetricKeyPackage IDENTIFIED BY id-ct-KP-sKeyPackage }
The SymmetricKeyPackage fields are used as follows:
- version identifies the version of the symmetric key package content structure. For this version of the specification, the default value, v1, MUST be used.
- sKeyPkgAttrs optionally provides attributes that apply to all of the symmetric keys in the package. The SKeyPkgAttributes information object set restricts the attributes allowed in sKeyPkgAttrs. If an attribute appears here, then it MUST NOT also be included in sKeyAttrs.
- sKeys contains a sequence of OneSymmetricKey values. This structure is discussed below.
The OneSymmetricKey fields are used as follows:
- sKeyAttrs optionally provides attributes that apply to one symmetric key. The SKeyAttributes information object set restricts the attributes permitted in sKeyAttrs. If an attribute appears here, then it MUST NOT also be included in sKeyPkgAttrs.
- sKey optionally contains the key value encoded as an OCTET STRING.
The OneSymmetricKey field MUST include sKeyAttrs, sKey, or sKeyAttrs and sKey.
The following attributes are defined to assist those using the symmetric key package defined in this document as part of a Dynamic Symmetric Key Provision Protocol (DSKPP) [RFC6063] with Portable Symmetric Key Container (PSKC) attributes. [RFC6030] should be consulted for the definitive attribute descriptions. The attributes fall into three categories. The first category includes attributes that apply to a key package, and these attributes will generally appear in sKeyPkgAttrs. The second category includes attributes that
Turner & Housley Standards Track [Page 4]
RFC 6031 CMS Symmetric Key Package Content Type December 2010
apply to a particular key, and these attributes will generally appear in sKeyAttrs. The third category includes attributes that apply to a key policy. Of the attributes defined, only the Key Identifier (Section 3.2.1) and Algorithm (Section 3.2.2) key attributes MUST be included. All other attributes are OPTIONAL.
Like PSKC, the Symmetric Key Content Type supports extensibility. Primarily, this is accomplished through the definition and inclusion of new attributes, but in some instances in which the attribute contains more than one type, the ASN.1 "..." extensibility mechanism is employed.
A straightforward approach to conversion from XML types to ASN.1 is employed. The <xs:string> type converts to UTF8String; the XML <xs:dateTime> type converts to GeneralizedTime; and the XML integer types convert to INTEGER or BinaryTime [RFC6019].
PSKC key package attributes apply to an entire key package. These attributes can be categorized by two different attribute collections: device information and cryptographic module attributes. All of these key package attributes are OPTIONAL.
The Manufacturer attribute indicates the manufacturer of the device. Values for Manufacturer MUST be taken from either [OATHMAN] prefixes (i.e., the left column) or from the IANA Private Enterprise Number Registry [IANAPENREG], using the Organization value. When the value is taken from [OATHMAN] "oath." MUST be prepended to the value (e.g., "oath.<values from [OATHMAN]>"). When the value is taken from [IANAPENREG], "iana." MUST be prepended to the value (e.g., "iana.<Organization value from [IANAPENREG]>"). The attribute definition is as follows:
at-pskc-manufacturer ATTRIBUTE ::= { TYPE UTF8String IDENTIFIED BY id-pskc-manufacturer }
The Issue Number attribute contains an issue number to distinguish between two devices with the same serial number. The attribute definition is as follows:
at-pskc-issueNo ATTRIBUTE ::= { TYPE UTF8String IDENTIFIED BY id-pskc-issueNo }
The Device Binding attribute provides an opaque identifier that allows keys to be bound to the device or to a class of devices.
When loading keys into a device, the attribute's value MUST be checked against information provided to the user via out-of-band mechanisms. The implementation then ensures that the correct device or class of device is being used with respect to the provisioned key.
at-pskc-deviceBinding ATTRIBUTE ::= { TYPE UTF8String IDENTIFIED BY id-pskc-deviceBinding }
When included in sKeyPkgAttrs, the Device Start Date attribute indicates the start date for a device. The date MUST be represented in a form that matches the dateTime production in "canonical representation" [XMLSCHEMA]. Implementations SHOULD NOT rely on time resolution finer than milliseconds and MUST NOT generate time instants that specify leap seconds. Keys that are on the device SHOULD only be used when the current date is on or after the device start date. The attribute definition is as follows:
at-pskc-deviceStartDate ATTRIBUTE ::= { TYPE GeneralizedTime IDENTIFIED BY id-pskc-deviceStartDate }
Note that usage enforcement of the keys with respect to the dates MAY only happen on the validation server as some devices, such as smart cards, do not have an internal clock. Systems thus SHOULD NOT rely upon the device to enforce key usage date restrictions.
When included in sKeyPkgAttrs, the Device Expiry Date attribute indicates the expiry date for a device. The date MUST be represented in a form that matches the dateTime production in "canonical representation" [XMLSCHEMA]. Implementations SHOULD NOT rely on time resolution finer than milliseconds and MUST NOT generate time instants that specify leap seconds. Keys that are on the device SHOULD only be used when the current date is before the device expiry date. The attribute definition is as follows:
at-pskc-deviceExpiryDate ATTRIBUTE ::= { TYPE GeneralizedTime IDENTIFIED BY id-pskc-deviceExpiryDate }
id-pskc-deviceExpiryDate OBJECT IDENTIFIER ::= { id-pskc 7 } Note that usage enforcement of the keys with respect to the dates MAY only happen on the validation server as some devices, such as smart cards, do not have an internal clock. Systems thus SHOULD NOT rely upon the device to enforce key usage date restrictions.
The Device User Id attribute indicates the user with whom the device is associated using a distinguished name, as defined in [RFC4514]. For example: UID=jsmith,DC=example,DC=net. The attribute definition is as follows:
Turner & Housley Standards Track [Page 7]
RFC 6031 CMS Symmetric Key Package Content Type December 2010
at-pskc-deviceUserId ATTRIBUTE ::= { TYPE UTF8String IDENTIFIED BY id-pskc-deviceUserId }
As specified in [RFC6030], there are no semantics associated with this element, i.e., there are no checks enforcing that only a specific user can use this device. As such, this element is for informational purposes only.
3.1.2. Cryptographic Module Information Attributes
Cryptographic Module attributes uniquely identify a cryptographic module. This is useful when the device contains more than one cryptographic module. At this time, only one attribute is defined.
When included in sKeyPkgAttrs, the Cryptographic Module Identifier attribute uniquely identifies the cryptographic module to which the key is being or was provisioned. The attribute definition is as follows:
at-pskc-moduleId ATTRIBUTE ::= { TYPE UTF8String IDENTIFIED BY id-pskc-moduleId }
PSKC key attributes apply to a specific key. As noted earlier, the Key Identifier (Section 3.2.1) and Algorithm (Section 3.2.2) key attributes are REQUIRED. All other attributes are OPTIONAL.
When included in sKeyAttrs, the Key Identifier attribute identifies the key in the context of key provisioning exchanges between two parties. This means that if PSKC is used in multiple interactions between a sending and receiving party, using different containers referencing the same keys, the KeyId MUST use the same KeyId values (e.g., after initial provisioning, if a system wants to update key metadata values in the other system, the KeyId value of the key where the metadata is to be updates MUST be the same as the original KeyId value provisioned). The attribute definition is as follows:
Turner & Housley Standards Track [Page 8]
RFC 6031 CMS Symmetric Key Package Content Type December 2010
at-pskc-keyId ATTRIBUTE ::= { TYPE UTF8String IDENTIFIED BY id-pskc-keyId }
The Algorithm attribute uniquely identifies the PSKC algorithm profile. [RFC6030] defines two algorithm profiles "HOTP" and "PIN". The attribute definition is as follows:
at-pskc-algorithm ATTRIBUTE ::= { TYPE UTF8String IDENTIFIED BY id-pskc-algorithm }
The Key Profile Identifier attribute carries a unique identifier used between the sending and receiving parties to establish a set of key attribute values that are not transmitted within the container but are agreed upon between the two parties out of band. This attribute will then represent the unique reference to a set of key attribute values.
at-pskc-keyProfileId ATTRIBUTE ::= { TYPE UTF8String IDENTIFIED BY id-pskc-keyProfileId }
The Key Reference attribute refers to an external key to be used with a key derivation scheme and no specific key value (secret) is transported; only the reference to the external master key is used (e.g., the PKCS #11 key label).
Turner & Housley Standards Track [Page 9]
RFC 6031 CMS Symmetric Key Package Content Type December 2010
at-pskc-keyReference ATTRIBUTE ::= { TYPE UTF8String IDENTIFIED BY id-pskc-keyReference }
The text is encoded in UTF-8 [RFC3629], which accommodates most of the world's writing systems. The friendlyNameLangTag field identifies the language used to express the friendlyName. When the friendlyNameLangTag field is absent, English, whose associated language tag is "en", is used. The value of the friendlyNameLangTag field MUST be a language tag, as described in [RFC5646].
The Algorithm Parameters attribute contains parameters that influence the result of the algorithmic computation, for example, response truncation and format in One-Time Password (OTP) and Challenge/Response (CR) algorithms.
at-pskc-algorithmParameters ATTRIBUTE ::= { TYPE PSKCAlgorithmParameters IDENTIFIED BY id-pskc-algorithmParams }
The fields in PSKCAlgorithmParameters have the following meanings:
o Suite defines additional characteristics of the algorithm used, which are algorithm specific. For example, in an HMAC-based (Hashed Message Authentication Code) OTP algorithm it could designate the strength of the hash algorithm used (SHA1, SHA256, etc.). Please refer to the algorithm profile specification [RFC6030] for the exact semantics of the value for each algorithm profile.
o ChallengeFormat defines the characteristics of the challenge in a CR usage scenario, whereby the following fields are defined:
o encoding specifies the encoding of the challenge accepted by the device and MUST be one of the following values: DECIMAL, HEXADECIMAL, ALPHANUMERIC, BASE64, or BINARY. The BASE64 encoding is done as in Section 4 of [RFC4648].
o checkDigit indicates whether a device needs to check the appended Luhn check digit, as defined in [ISOIEC7812], contained in a challenge. The checkDigit MUST NOT be present if the encoding value is anything other than 'DECIMAL'. A value of TRUE indicates that the device will check the appended Luhn check digit in a provided challenge. A value of FALSE indicates that the device will not check the appended Luhn check digit in the challenge.
Turner & Housley Standards Track [Page 11]
RFC 6031 CMS Symmetric Key Package Content Type December 2010
o min defines the minimum size of the challenge accepted by the device for CR mode. If encoding is 'DECIMAL', 'HEXADECIMAL', or 'ALPHANUMERIC', this value indicates the minimum number of digits/characters. If encoding is 'BASE64' or 'BINARY', this value indicates the minimum number of bytes of the unencoded value.
o max defines the maximum size of the challenge accepted by the device for CR mode. If encoding is 'DECIMAL', 'HEXADECIMAL', or 'ALPHANUMERIC', this value indicates the maximum number of digits/characters. If the encoding is 'BASE64' or 'BINARY', this value indicates the maximum number of bytes of the unencoded value.
o ResponseFormat defines the characteristics of the result of a computation and defines the format of the OTP or the response to a challenge. For cases where the key is a personal identification number (PIN) value, this element contains the format of the PIN itself (e.g., DECIMAL, length 4 for a 4 digit PIN). The following fields are defined:
o encoding specifies the encoding of the response generated by the device and MUST be one of the following values: DECIMAL, HEXADECIMAL, ALPHANUMERIC, BASE64, or BINARY. BASE64 is defined as in Section 4 of [RFC4648].
o length defines the length of the response generated by the device. If encoding is 'DECIMAL', 'HEXADECIMAL', or 'ALPHANUMERIC', this value indicates the number of digits/characters. If encoding is 'BASE64' or 'BINARY', this value indicates the number of bytes of the unencoded value.
o checkDigit indicates whether the device needs to append a Luhn check digit, as defined in [ISOIEC7812], to the response. This is only valid if the encoding attribute is 'DECIMAL'. If the value is TRUE, then the device will append a Luhn check digit to the response. If the value is FALSE, then the device will not append a Luhn check digit to the response.
The Time attribute conveys the time for time-based OTP algorithms. If the Time Interval attribute is included, then this element carries the number of time intervals passed for a specific start point. If the time interval is used, then this element carries the number of time intervals passed from a specific start point, normally it is algorithm dependent. It uses the BinaryTime syntax from [RFC6019]. The attribute definition is as follows:
at-pskc-time ATTRIBUTE ::= { TYPE BinaryTime IDENTIFIED BY id-pskc-time }
The Time Interval attribute conveys the time interval value for time- based OTP algorithms in seconds (e.g., a value of 30 for this would indicate a time interval of 30 seconds). It is an integer. The attribute definition is as follows:
at-pskc-timeInterval ATTRIBUTE ::= { TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-timeInterval }
The Time Drift attribute contains the device clock drift value for time-based OTP algorithms. It is an integer, either positive or negative, that indicates the number of time intervals that a validation server has established that the device clock drifted after the last successful authentication. The attribute definition is as follows:
at-pskc-timeDrift ATTRIBUTE ::= { TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-timeDrift }
The Value MAC attribute is a Message Authentication Code (MAC) generated from the encrypted value in the case that the encryption algorithm does not support integrity checks (e.g., AES-CBC does not provide integrity while AES Key Wrap with a message length indicator (MLI) does). The attribute definition is as follows:
Turner & Housley Standards Track [Page 13]
RFC 6031 CMS Symmetric Key Package Content Type December 2010
at-pskc-valueMAC ATTRIBUTE ::= { TYPE ValueMac IDENTIFIED BY id-pskc-valueMAC }
The Key User Id attribute indicates the user with whom the key is associated using a distinguished name, as defined in [RFC4514]. For example, UID=jsmith,DC=example,DC=net. The attribute definition is as follows:
at-pskc-keyUserId ATTRIBUTE ::= { TYPE UTF8String IDENTIFIED BY id-pskc-keyUserId }
As specified in [RFC6030], there are no semantics associated with this element, i.e., there are no checks enforcing that only a specific user can use this key. As such, this element is for informational purposes only.
When included in sKeyAttrs, the Key Start Date attribute indicates the start of the key's validity period. The date MUST be represented in a form that matches the dateTime production in "canonical representation" [XMLSCHEMA]. Implementations SHOULD NOT rely on time resolution finer than milliseconds and MUST NOT generate time instants that specify leap seconds. The attribute definition is as follows:
Turner & Housley Standards Track [Page 14]
RFC 6031 CMS Symmetric Key Package Content Type December 2010
at-pskc-keyStartDate ATTRIBUTE ::= { TYPE GeneralizedTime IDENTIFIED BY id-pskc-keyStartDate }
When included in sKeyAttrs, the Key Expiry Date attribute indicates the end of the key's validity period. The date MUST be represented in a form that matches the dateTime production in "canonical representation" [XMLSCHEMA]. Implementations SHOULD NOT rely on time resolution finer than milliseconds and MUST NOT generate time instants that specify leap seconds. The attribute definition is as follows:
at-pskc-keyExpiryDate ATTRIBUTE ::= { TYPE GeneralizedTime IDENTIFIED BY id-pskc-keyExpiryDate }
The Number of Transactions attribute indicates the maximum number of times a key carried within the package can be used. When this element is omitted, there is no restriction regarding the number of times a key can be used. The attribute definition is as follows:
at-pskc-noOfTransactions ATTRIBUTE ::= { TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-noOfTransactions }
RFC 6031 CMS Symmetric Key Package Content Type December 2010
The fields in PSKCKeyUsage have the following meanings:
o OTP: The key MUST only be used for OTP generation.
o CR: The key MUST only be used for Challenge/Response purposes.
o Encrypt: The key MUST only be used for data encryption purposes.
o Integrity: The key MUST only be used to generate a keyed message digest for data integrity or authentication purposes.
o Verify: The key MUST only be used to verify a keyed message digest for data integrity or authentication purposes (is the converse of Integrity).
o Unlock: The key MUST only be used for an inverse Challenge/Response in the case in which a user has locked the device by entering an incorrect PIN too many times (for devices with PIN-input capability).
o Decrypt: The key MUST only be used for data decryption purposes.
o KeyWrap: The key MUST only be used for key wrap purposes.
o Unwrap: The key MUST only be used for key unwrap purposes.
o Derive: The key MUST only be used with a key derivation function to derive a new key (see also Section 8.2.4 of [NIST800-57]).
o Generate: The key MUST only be used to generate a new key based on a random number and the previous value of the key (see also Section 8.1.5.2.1 of [NIST800-57]).
The fields in PIN Policy have the following meanings:
o pinKeyId uniquely identifies the key held within this container that contains the value of the PIN that protects the key.
o pinUsageMode indicates the way the PIN is used during the usage of the key. The following values are defined in [RFC6030]: Local, Prepend, Append, and Algorithmic.
o maxFailedAttempts indicates the maximum number of times the PIN may be entered incorrectly before it MUST NOT be possible to use the key anymore (reasonable values are in the positive integer range of at least 2 and no more than 10).
o minLength indicates the minimum length of a PIN that can be set to protect the associated key. It MUST NOT be possible to set a PIN shorter than this value. If pinEncoding is 'DECIMAL', 'HEXADECIMAL', or 'ALPHANUMERIC', this value indicates the number of digits/ characters. If pinEncoding is 'BASE64' or 'BINARY', this value indicates the number of bytes of the unencoded value.
o maxLength indicates the maximum length of a PIN that can be set to protect this key. It MUST NOT be possible to set a PIN longer than this value. If pinEncoding is 'DECIMAL', 'HEXADECIMAL', or 'ALPHANUMERIC', this value indicates the number of digits/characters. If the pinEncoding is 'BASE64' or 'BINARY', this value indicates the number of bytes of the unencoded value.
o pinEncoding is based on Encoding, which is defined in Section 3.2.7, and specifies encoding of the PIN and MUST be one of the following values: DECIMAL, HEXADECIMAL, ALPHANUMERIC, BASE64, or BINARY.
If pinUsageMode is set to "Local", then the device MUST enforce the restriction indicated in maxFailedAttempts, minLength, maxLength, and pinEncoding; otherwise, it MUST be enforced on the server side.
Turner & Housley Standards Track [Page 17]
RFC 6031 CMS Symmetric Key Package Content Type December 2010
Two parties receiving the same key as an sKey OCTET STRING must make use of the key in exactly the same way in order to interoperate. To ensure that this occurs, it is necessary to define a correspondence between the abstract syntax of sKey and the notation in the standard algorithm description that defines how the key is used. The next sections establish that correspondence for the AES algorithm [FIPS197] and the Triple Data Encryption Algorithm (TDEA or Triple DES) [SP800-67].
[FIPS197], Section 5.2, titled "Key Expansion", uses the input key as an array of bytes indexed starting at 0. The first octet of sKey SHALL become the key byte in the AES, labeled index 0 in [FIPS197]; the succeeding octets of sKey SHALL become key bytes in AES, in increasing index order.
Proper parsing and key load of the contents of sKey for AES SHALL be determined by using the following sKey OCTET STRING to generate and match the key expansion test vectors in [FIPS197], Appendix A, for AES Cipher Key: 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
Tag Length Value 04 16 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
A Triple-DES key consists of three keys for the cryptographic engine (Key1, Key2, and Key3) that are each 64 bits (56 key bits and 8 parity bits); the three keys are also collectively referred to as a key bundle [SP800-67]. A key bundle may employ either two or three independent keys. When only two independent keys are employed (called two-key Triple DES), the same value is used for Key1 and Key3.
Each key in a Triple-DES key bundle is expanded into a key schedule according to a procedure defined in [SP800-67], Appendix A. That procedure numbers the bits in the key from 1 to 64, with number 1 being the leftmost, or most significant bit (MSB). The first octet of sKey SHALL be bits 1 through 8 of Key1 with bit 1 being the MSB. The second octet of sKey SHALL be bits 9 through 16 of Key1, and so forth, so that the trailing octet of sKey SHALL be bits 57 through 64 of Key3 (or Key2 for two-key Triple DES).
Turner & Housley Standards Track [Page 18]
RFC 6031 CMS Symmetric Key Package Content Type December 2010
Proper parsing and key load of the contents of sKey for Triple DES SHALL be determined by using the following sKey OCTET STRING to generate and match the key expansion test vectors in [SP800-67], Appendix B, for the key bundle:
Key1 = 0123456789ABCDEF
Key2 = 23456789ABCDEF01
Key3 = 456789ABCDEF0123
Tag Length Value 04 24 0123456789ABCDEF 23456789ABCDEF01 456789ABCDEF0123
Implementers of this protocol are strongly encouraged to consider generally accepted principles of secure key management when integrating this capability within an overall security architecture.
The symmetric key package contents are not protected. This content type can be combined with a security protocol to protect the contents of the package. One possibility is to include this content type in place of a PSKC package in [RFC6063] exchanges. In this case, the algorithm requirements are found in those documents. Another possibility is to encapsulate this content type in a CMS [RFC5652] protecting content type.
This document makes use of object identifiers to identify a CMS content type (Appendix A.1), the ASN.1 version of the PSKC attributes (Appendix A.2), and the ASN.1 modules found in Appendix A.1 and A.2.
All OIDs are registered in an arc delegated by RSADSI to the SMIME Working Group.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC5646] Phillips, A., Ed., and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, June 2010.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, June 2010.
[RFC6019] Housley, R., "BinaryTime: An Alternate Format for Representing Date and Time in ASN.1", RFC 6019, September 2010.
[RFC6030] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric Key Container (PSKC)", RFC 6030, October 2010.
[SP800-67] National Institute of Standards and Technology, "NIST Special Publication 800-67 Version 1.1: Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher", NIST Special Publication 800-67, May 2008.
Turner & Housley Standards Track [Page 20]
RFC 6031 CMS Symmetric Key Package Content Type December 2010
[X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824- 4:2002. Information Technology - Abstract Syntax Notation One: Parameterization of ASN.1 Specifications.
[X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825- 1:2002. Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).
[XMLSCHEMA] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041082, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[NIST800-57] National Institute of Standards and Technology, "NIST Special Publication 800-57, Recommendation for Key Management - Part 1: General (Revised)", NIST Special Publication 800-57, March 2007.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC6063] Doherty, A., Pei, M., Machani, S., and M. Nystrom, "Dynamic Symmetric Key Provisioning Protocol (DSKPP)", RFC 6063, December 2010.
Turner & Housley Standards Track [Page 21]
RFC 6031 CMS Symmetric Key Package Content Type December 2010
This appendix provides the normative ASN.1 definitions for the structures described in this specification using ASN.1 as defined in [X.680], [X.681], [X.682], and [X.683].