Internet Engineering Task Force (IETF) J. Schaad Request for Comments: 6268 Soaring Hawk Consulting Updates: 5911 S. Turner Category: Informational IECA, Inc. ISSN: 2070-1721 July 2011
Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)
Abstract
The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates some auxiliary ASN.1 modules to conform to the 2008 version of ASN.1; the 1988 ASN.1 modules remain the normative version. There are no bits- on-the-wire changes to any of the formats; this is simply a change to the syntax.
Status of This Memo
This document is not an Internet Standards Track specification; it is published for informational purposes.
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see 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/rfc6268.
Copyright Notice
Copyright (c) 2011 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
Schaad & Turner Informational [Page 1]
RFC 6268 Additional New ASN.1 Modules July 2011
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.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
Some developers would like the IETF to use the latest version of ASN.1 in its standards. Most of the RFCs that relate to security protocols still use ASN.1 from the 1988 standard, which has been deprecated. This is particularly true for the standards that relate to PKIX, CMS, and Secure/Multipurpose Internet Mail Extensions (S/MIME).
In this document we have either changed the syntax to use the 2008 ASN.1 standard, or done some updates from previous conversions. The ASN.1 modules updated came from the following RFCs:
o RFC 3274, Compressed Data Content Type for Cryptographic Message Syntax (CMS) [RFC3274].
o RFC 3779, X.509 Extensions for IP Addresses and AS Identifiers [RFC3779].
o RFC 6019, BinaryTime: An Alternate Format for Representing Date and Time in ASN.1 [RFC6019].
o RFC 4073, Protecting Multiple Contents with the Cryptographic Message Syntax (CMS) [RFC4073].
o RFC 4231, Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 [RFC4231].
o RFC 4334, Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN) [RFC4334].
o RFC 5083, Cryptographic Message Syntax (CMS) Authenticated- Enveloped-Data Content Type [RFC5083].
o RFC 5752, Multiple Signatures in Cryptographic Message Syntax (CMS) [RFC5752].
Note that some of the modules in this document get some of their definitions from places different than the modules in the original RFCs. The idea is that these modules, when combined with the modules in [RFC5911] and [RFC5912], can stand on their own and do not need to import definitions from anywhere else.
Schaad & Turner Informational [Page 3]
RFC 6268 Additional New ASN.1 Modules July 2011
This document does not explicitly update the RFCs from which the ASN.1 modules have been extracted. This is because the original 1988 ASN.1 syntax remains the normative version and the modules in this document as well as in [RFC5911] and [RFC5912] are informative (but hopefully useful) annexes.
The modules defined in this document are compatible with the most current ASN.1 specification published in 2008 (see [ASN1-2008]). The changes between the 2002 specification and the 2008 specification include the creation of additional pre-defined types (DATE, DATE- TIME, DURATION, NOT-A-NUMBER, OID-IRI, RELATIVE-OID-IRI, TIME, TIME- OF-DAY) and the ability to define different encoding rules (ENCODING- CONTROL, INSTRUCTIONS). None of the newly defined tokens are currently used in any of the ASN.1 specifications published here.
Information on the changes to ASN.1 between the 1988 and 2002 versions can be found in [RFC6025].
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].
-- -- ContentTypes contains the set of content types that are -- defined in this module. -- -- The contents of ContentTypes should be added to -- ContentSet defined in [RFC5652] --
ContentTypes CONTENT-TYPE ::= {ct-compressedData}
-- -- SMimeCaps contains the set of S/MIME capabilities that -- are associated with the algorithms defined in this -- document. -- -- SMimeCaps are added to the SMimeCapsSet defined in -- [RFC5751] as updated by [RFC5911].
-- -- Extensions contains the set of extensions defined in this -- module -- -- These are intended to be placed in public key certificates -- and thus should be added to the CertExtensions extension -- set in PKIXImplicit-2009 defined for [RFC5280] --
-- -- BinaryTime Definition -- -- BinaryTime contains the number seconds since -- midnight Jan 1, 1970 UTC. -- Leap seconds are EXCLUDED from the computation. --
BinaryTime ::= INTEGER (0..MAX)
-- -- Signing Binary Time Attribute -- -- The binary signing time should be added to -- SignedAttributeSet and AuthAttributeSet in CMS [RFC5652] -- and to AuthEnvDataAttributeSet in [RFC5083] with the -- new modules in this document, RFC 6268. --
Schaad & Turner Informational [Page 10]
RFC 6268 Additional New ASN.1 Modules July 2011
aa-binarySigningTime ATTRIBUTE ::= { TYPE BinarySigningTime IDENTIFIED BY id-aa-binarySigningTime }
RFC 4231 does not contain an ASN.1 module to be updated. We have therefore created an ASN.1 module to represent the ASN.1 that is present in the document. Note that the parameters are defined as expecting a parameter for the algorithm identifiers in this module; this is different from most of the algorithms used in PKIX and S/MIME. There is no concept of being able to truncate the MAC (Message Authentication Code) value in the ASN.1 unlike the XML definitions. This is reflected by not having a minimum MAC length defined in the ASN.1.
-- -- This object set contains all of the MAC algorithms that are -- defined in this module. -- One would add it to a constraining set of objects such as the -- MessageAuthenticationCodeAlgorithmSet in [RFC5652] --
-- -- This object set contains all of the S/MIME capabilities that -- have been defined for all the MAC algorithms in this module. -- One would add this to an object set that is used to restrict -- S/MIME capabilities such as the SMimeCapsSet variable in -- RFC 3851 (obsoleted by RFC 5751) as modified in RFC 5911. --
This module is updated from RFC 5911 [RFC5911] by the following changes:
1. Define separate attribute sets for the unprotected attributes used in EnvelopedData, EncryptedData, and AuthenticatedEnvelopedData (RFC 5083).
2. Define a parameterized type EncryptedContentInfoType so that the basic type can be used with different algorithm sets (used for EnvelopedData, EncryptedData, and AuthenticatedEnvelopedData (RFC
Schaad & Turner Informational [Page 16]
RFC 6268 Additional New ASN.1 Modules July 2011
5083)). The parameterized type is assigned to an unparameterized type of EncryptedContentInfo to minimize the output changes from previous versions.
Protocol designers can make use of the '08 ASN.1 constraints to define different sets of attributes for EncryptedData and EnvelopedData and for AuthenticatedData and AuthEnvelopedData. Previously, attributes could only be constrained based on whether they were in the clear or unauthenticated not on the encapsulating content type.
This module is updated from RFC 5911 [RFC5911] by the following changes:
1. Define separate attribute sets for the unprotected attributes used in EnvelopedData, EncryptedData, and AuthenticatedEnvelopedData (RFC 5083).
2. Define a parameterized type EncryptedContentInfoType so that the basic type can be used with algorithm sets (used for EnvelopedData, EncryptedData, and AuthenticatedEnvelopedData (RFC 5083)). The parameterized type is assigned to an unparameterized type of EncryptedContentInfo to minimize the output changes from previous versions.
We are anticipating the definition of attributes that are going to be restricted to the use of only EnvelopedData. We are therefore separating the different attribute sets so that protocol designers that need to do this will be able to define attributes that are used for EnvelopedData, but not for EncryptedData. The same separation is also being applied to AuthenticatedData and AuthEnvelopedData.
-- The following are used for version numbers using the ASN.1 -- NOTE: The document reference represents where the versioned -- feature was introduced to the module. -- -- idiom "[[n:" -- Version 1 = PKCS #7 -- Version 2 = S/MIME V2 -- Version 3 = RFC 2630 -- Version 4 = RFC 3369 -- Version 5 = RFC 3852
CONTENT-TYPE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE, &Type OPTIONAL } WITH SYNTAX { [TYPE &Type] IDENTIFIED BY &id }
We have updated the ASN.1 module associated with this document to be 2008 compliant and to use the set of classes previously defined in [RFC5911].
MultipleSignatures-2010 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) modules(0) id-mod-multipleSign-2009(59) } DEFINITIONS IMPLICIT TAGS ::= BEGIN -- EXPORTS All -- The types and values defined in this module are exported for use -- in the other ASN.1 modules. Other applications may use them for -- their own purposes.
One potential issue that can occur when updating modules is the fact that a large number of modules may need to be updated if they import from a newly updated module. This section addresses one method that can be used to deal with this problem, but the modules in this document don't currently implement the solution discussed here.
Schaad & Turner Informational [Page 30]
RFC 6268 Additional New ASN.1 Modules July 2011
When looking at an import statement, there are three portions: The list of items imported, a textual name for the module, and an object identifier for the module. Full implementations of ASN.1 do module matching using first the object identifier, and if that is not present, the textual name of the module. Note however that some older implementations used the textual name of the module for the purposes of matching. In a full implementation, the name assigned to the module is scoped to the ASN.1 module that it appears in (and thus the need to match the module it is importing from).
One can create a module that contains only the module number assignments and import the module assignments from the new module. This means that when a module is replaced, one can replace the previous module, update the module number assignment module, and recompile without having to modify any other modules.
[ASN1-2008] ITU-T, "ITU-T Recommendations X.680, X.681, X.682, and X.683", 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3274] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC4073] Housley, R., "Protecting Multiple Contents with the Cryptographic Message Syntax (CMS)", RFC 4073, May 2005.
[RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA- 512", RFC 4231, December 2005.
[RFC4334] Housley, R. and T. Moore, "Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)", RFC 4334, February 2006.
[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, November 2007.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
Schaad & Turner Informational [Page 32]
RFC 6268 Additional New ASN.1 Modules July 2011
[RFC5752] Turner, S. and J. Schaad, "Multiple Signatures in Cryptographic Message Syntax (CMS)", RFC 5752, January 2010.
[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.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC6025] Wallace, C. and C. Gardiner, "ASN.1 Translation", RFC 6025, October 2010.
Authors' Addresses
Jim Schaad Soaring Hawk Consulting
EMail: ietf@augustcellars.com
Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031