Diff: draft-turner-additional-new-asn-05.txt - draft-turner-additional-new-asn-06.txt

	< draft-turner-additional-new-asn-05.txt	draft-turner-additional-new-asn-06.txt >

	Network Working Group J. Schaad	Network Working Group J. Schaad
	Internet-Draft Soaring Hawk Consulting	Internet-Draft Soaring Hawk Consulting

	Intended status: Standards Track S. Turner	Intended status: Informational S. Turner
	Expires: June 15, 2011 IECA, Inc.	Expires: June 15, 2011 IECA, Inc.
	December 12, 2010	December 12, 2010

	Additional New ASN.1 Modules	Additional New ASN.1 Modules

	draft-turner-additional-new-asn-05	draft-turner-additional-new-asn-06

	Abstract	Abstract

	The Cryptographic Message Syntax (CMS) format, and many associated	The Cryptographic Message Syntax (CMS) format, and many associated
	formats, are expressed using ASN.1. The current ASN.1 modules	formats, are expressed using ASN.1. The current ASN.1 modules
	conform to the 1988 version of ASN.1. This document updates some	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.	auxiliary ASN.1 modules to conform to the 2008 version of ASN.1.
	There are no bits-on-the-wire changes to any of the formats; this is	There are no bits-on-the-wire changes to any of the formats; this is
	simply a change to the syntax.	simply a change to the syntax.


	skipping to change at page 2, line 25 ¶	skipping to change at page 2, line 25 ¶
	not be created outside the IETF Standards Process, except to format	not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other	it for publication as an RFC or to translate it into languages other
	than English.	than English.

	Table of Contents	Table of Contents

	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. ASN.1 Updates (2002 to 2008) . . . . . . . . . . . . . . . 3	1.1. ASN.1 Updates (2002 to 2008) . . . . . . . . . . . . . . . 3
	1.2. Requirements Terminology . . . . . . . . . . . . . . . . . 4	1.2. Requirements Terminology . . . . . . . . . . . . . . . . . 4
	2. ASN.1 Module RFC 3274 . . . . . . . . . . . . . . . . . . . . 5	2. ASN.1 Module RFC 3274 . . . . . . . . . . . . . . . . . . . . 5

	3. ASN.1 Module RFC 3379 . . . . . . . . . . . . . . . . . . . . 8	3. ASN.1 Module RFC 3779 . . . . . . . . . . . . . . . . . . . . 8
	4. ASN.1 Module RFC 4049 . . . . . . . . . . . . . . . . . . . . 11	4. ASN.1 Module RFC 6019 . . . . . . . . . . . . . . . . . . . . 11
	5. ASN.1 Module RFC 4073 . . . . . . . . . . . . . . . . . . . . 13	5. ASN.1 Module RFC 4073 . . . . . . . . . . . . . . . . . . . . 13
	6. ASN.1 Module RFC 4231 . . . . . . . . . . . . . . . . . . . . 15	6. ASN.1 Module RFC 4231 . . . . . . . . . . . . . . . . . . . . 15
	7. ASN.1 Module RFC 4334 . . . . . . . . . . . . . . . . . . . . 18	7. ASN.1 Module RFC 4334 . . . . . . . . . . . . . . . . . . . . 18
	8. ASN.1 Module RFC 5083 . . . . . . . . . . . . . . . . . . . . 20	8. ASN.1 Module RFC 5083 . . . . . . . . . . . . . . . . . . . . 20
	9. ASN.1 Module RFC 5652 . . . . . . . . . . . . . . . . . . . . 22	9. ASN.1 Module RFC 5652 . . . . . . . . . . . . . . . . . . . . 22
	10. ASN.1 Module RFC 5752 . . . . . . . . . . . . . . . . . . . . 33	10. ASN.1 Module RFC 5752 . . . . . . . . . . . . . . . . . . . . 33
	11. Module Identifiers in ASN.1 . . . . . . . . . . . . . . . . . 35	11. Module Identifiers in ASN.1 . . . . . . . . . . . . . . . . . 35
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 37	12. Security Considerations . . . . . . . . . . . . . . . . . . . 37
	13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38	13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
	14. Normative References . . . . . . . . . . . . . . . . . . . . . 39	14. Normative References . . . . . . . . . . . . . . . . . . . . . 39
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41

	1. Introduction	1. Introduction

	Some developers would like the IETF to use the latest version of	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	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	protocols still use ASN.1 from the 1988 standard, which has been
	deprecated. This is particularly true for the standards that relate	deprecated. This is particularly true for the standards that relate
	to PKIX, CMS, and S/MIME.	to PKIX, CMS, and S/MIME.


	In this document we have either change the syntax to use the 2008	In this document we have either changed the syntax to use the 2008
	ASN.1 standard, or done some updates from previous conversions:	ASN.1 standard, or done some updates from previous conversions:

	RFC 3274, Compressed Data Content Type for Cryptographic Message	RFC 3274, Compressed Data Content Type for Cryptographic Message
	Syntax (CMS) [RFC3274].	Syntax (CMS) [RFC3274].


	RFC 3379, Delegated Path Validation and Delegated Path Discovery	RFC 3779, X.509 Extensions for IP Addresses and AS Identifiers
	Protocol Requirements [RFC3379].	[RFC3779].


	RFC 4049, BinaryTime: An Alternate Format for Representing Date	RFC 6019, BinaryTime: An Alternate Format for Representing Date
	and Time in ASN.1 [RFC4049].	and Time in ASN.1 [RFC6019].

	RFC 4073, Protecting Multiple Contents with the Cryptographic	RFC 4073, Protecting Multiple Contents with the Cryptographic
	Message Syntax (CMS) [RFC4073].	Message Syntax (CMS) [RFC4073].

	RFC 4231, Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-	RFC 4231, Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-
	256, HMAC-SHA-384, and HMAC-SHA-512 [RFC4231].	256, HMAC-SHA-384, and HMAC-SHA-512 [RFC4231].

	RFC 4334, Certificate Extensions and Attributes Supporting	RFC 4334, Certificate Extensions and Attributes Supporting
	Authentication in Point-to-Point Protocol (PPP) and Wireless Local	Authentication in Point-to-Point Protocol (PPP) and Wireless Local
	Area Networks (WLAN) [RFC4334].	Area Networks (WLAN) [RFC4334].

	RFC 5083, Cryptographic Message Syntax (CMS) Authenticated-	RFC 5083, Cryptographic Message Syntax (CMS) Authenticated-
	Enveloped-Data Content Type [RFC5083].	Enveloped-Data Content Type [RFC5083].


	RFC 5652, Cryptogrphic Message Syntax (CMS) [RFC5652].	RFC 5652, Cryptographic Message Syntax (CMS) [RFC5652].

	RFC 5752, Multiple Signatures in Cryptographic Message Syntax	RFC 5752, Multiple Signatures in Cryptographic Message Syntax
	(CMS) [RFC5752].	(CMS) [RFC5752].

	Note that some of the modules in this document get some of their	Note that some of the modules in this document get some of their
	definitions from places different than the modules in the original	definitions from places different than the modules in the original
	RFCs. The idea is that these modules, when combined with the modules	RFCs. The idea is that these modules, when combined with the modules
	in [RFC5912] and [RFC5911] can stand on their own and do not need to	in [RFC5912] and [RFC5911] can stand on their own and do not need to
	import definitions from anywhere else.	import definitions from anywhere else.

	1.1. ASN.1 Updates (2002 to 2008)	1.1. ASN.1 Updates (2002 to 2008)


	The modules defined in this document are compatable with the most	The modules defined in this document are compatible with the most
	current ASN.1 specification published in 2008 (see [ASN1-2008]). The	current ASN.1 specification published in 2008 (see [ASN1-2008]). The
	changes between the 2002 specification and the 2008 specification	changes between the 2002 specification and the 2008 specification
	include the creation of some additional pre-defined types (DATE,	include the creation of some additional pre-defined types (DATE,
	DATE-TIME, DURATION, NOT-A-NUMBER, OID-IRI, RELATIVE-OID-IRI, TIME,	DATE-TIME, DURATION, NOT-A-NUMBER, OID-IRI, RELATIVE-OID-IRI, TIME,
	TIME-OF-DAY). The ability to define different encoding rules	TIME-OF-DAY). The ability to define different encoding rules
	(ENCODING-CONTROL, INSTRUCTIONS). None of the newly defined tokens	(ENCODING-CONTROL, INSTRUCTIONS). None of the newly defined tokens
	are currently used in any of the ASN.1 specifications published here.	are currently used in any of the ASN.1 specifications published here.

	1.2. Requirements Terminology	1.2. Requirements Terminology


	skipping to change at page 8, line 5 ¶	skipping to change at page 8, line 5 ¶
	}	}
	WITH SYNTAX {	WITH SYNTAX {
	IDENTIFIER &id	IDENTIFIER &id

	[PARAMS [TYPE &Params] ARE &paramPresence]	[PARAMS [TYPE &Params] ARE &paramPresence]
	[SMIME-CAPS &smimeCaps]	[SMIME-CAPS &smimeCaps]
	}	}

	END	END


	3. ASN.1 Module RFC 3379	3. ASN.1 Module RFC 3779


	We have updated the ASN.1 module assocated with RFC 3379 to be ASN.1	We have updated the ASN.1 module associated with RFC 3779 to be ASN.1
	2008 compliant and to use the set of classes previously defined in	2008 compliant and to use the set of classes previously defined in
	[RFC5912].	[RFC5912].

	IPAddrAndASCertExtn { iso(1) identified-organization(3) dod(6)	IPAddrAndASCertExtn { iso(1) identified-organization(3) dod(6)
	internet(1) security(5) mechanisms(5) pkix(7) mod(0)	internet(1) security(5) mechanisms(5) pkix(7) mod(0)
	id-mod-ip-addr-and-as-ident-2(72) }	id-mod-ip-addr-and-as-ident-2(72) }
	DEFINITIONS EXPLICIT TAGS ::=	DEFINITIONS EXPLICIT TAGS ::=
	BEGIN	BEGIN
	EXPORTS ALL;	EXPORTS ALL;


	skipping to change at page 11, line 5 ¶	skipping to change at page 11, line 5 ¶
	range ASRange }	range ASRange }

	ASRange ::= SEQUENCE {	ASRange ::= SEQUENCE {
	min ASId,	min ASId,
	max ASId }	max ASId }

	ASId ::= INTEGER	ASId ::= INTEGER

	END	END


	4. ASN.1 Module RFC 4049	4. ASN.1 Module RFC 6019

	We have updated the ASN.1 module associated with this document to be	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	2008 compliant and to use the set of classes previously defined in
	[RFC5911].	[RFC5911].

	BinarySigningTimeModule-2009	BinarySigningTimeModule-2009
	{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)	{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
	pkcs-9(9) smime(16) modules(0)	pkcs-9(9) smime(16) modules(0)
	id-mod-binSigningTime-2009(55) }	id-mod-binSigningTime-2009(55) }
	DEFINITIONS IMPLICIT TAGS ::=	DEFINITIONS IMPLICIT TAGS ::=

	skipping to change at page 15, line 12 ¶	skipping to change at page 15, line 12 ¶
	ContentAttributeSet ATTRIBUTE ::= { ... }	ContentAttributeSet ATTRIBUTE ::= { ... }
	END	END

	6. ASN.1 Module RFC 4231	6. ASN.1 Module RFC 4231

	RFC 4231 does not contain an ASN.1 module to be updated. We have	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	therefore created an ASN.1 module to represent the ASN.1 that is
	present in the document. Note that the parameters are defined as	present in the document. Note that the parameters are defined as
	expecting a parameter for the algorithm identifiers in this module,	expecting a parameter for the algorithm identifiers in this module,
	this is different from most of the algorithms used in PKIX and	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 value	S/MIME. There is no concept of being able to truncate the MAC
	in the ASN.1 unlike the XML definitions. This is reflected by not	(Message Authentication Code) value in the ASN.1 unlike the XML
	having a minimum MAC length defined in the ASN.1.	definitions. This is reflected by not having a minimum MAC length
		defined in the ASN.1.

	HMAC { iso(1) identified-organization(3) dod(6) internet(1)	HMAC { iso(1) identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) mod(0) id-mod-hmac(74) }	security(5) mechanisms(5) pkix(7) mod(0) id-mod-hmac(74) }
	DEFINITIONS EXPLICIT TAGS ::=	DEFINITIONS EXPLICIT TAGS ::=
	BEGIN	BEGIN
	EXPORTS ALL;	EXPORTS ALL;

	IMPORTS	IMPORTS

	MAC-ALGORITHM, SMIME-CAPS	MAC-ALGORITHM, SMIME-CAPS

	skipping to change at page 18, line 7 ¶	skipping to change at page 18, line 7 ¶
	IDENTIFIER id-hmacWithSHA512	IDENTIFIER id-hmacWithSHA512
	PARAMS TYPE NULL ARE preferredPresent	PARAMS TYPE NULL ARE preferredPresent
	IS-KEYED-MAC TRUE	IS-KEYED-MAC TRUE
	SMIME-CAPS {IDENTIFIED BY id-hmacWithSHA512}	SMIME-CAPS {IDENTIFIED BY id-hmacWithSHA512}
	}	}

	END	END

	7. ASN.1 Module RFC 4334	7. ASN.1 Module RFC 4334


	We have updated the ASN.1 module assocated with RFC 4334 to be ASN.1	We have updated the ASN.1 module associated with RFC 4334 to be ASN.1
	2008 compliant and to use the set of classes previously defined in	2008 compliant and to use the set of classes previously defined in
	[RFC5912].	[RFC5912].

	WLANCertExtn	WLANCertExtn
	{ iso(1) identified-organization(3) dod(6) internet(1)	{ iso(1) identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) id-mod(0)	security(5) mechanisms(5) pkix(7) id-mod(0)
	id-mod-wlan-extns-2(73) }	id-mod-wlan-extns-2(73) }

	DEFINITIONS IMPLICIT TAGS ::=	DEFINITIONS IMPLICIT TAGS ::=
	BEGIN	BEGIN

	skipping to change at page 20, line 10 ¶	skipping to change at page 20, line 10 ¶

	id-aca-wlanSSID OBJECT IDENTIFIER ::= { id-aca 7 }	id-aca-wlanSSID OBJECT IDENTIFIER ::= { id-aca 7 }

	END	END

	8. ASN.1 Module RFC 5083	8. ASN.1 Module RFC 5083

	This module is updated from RFC 5911 [RFC5911] by the following	This module is updated from RFC 5911 [RFC5911] by the following
	changes:	changes:


	1. Define seperate attribute sets for the unprotected attributes	1. Define separate attribute sets for the unprotected attributes
	used in EnvelopedData, EncryptedData and	used in EnvelopedData, EncryptedData and
	AuthenticatedEnvelopedData (RFC 5083).	AuthenticatedEnvelopedData (RFC 5083).

	2. Define a parameterized type EncryptedContentInfoType so that the	2. Define a parameterized type EncryptedContentInfoType so that the

	basic type can be used with algorithm sets (used for	basic type can be used with different algorithm sets (used for
	EnvelopedData, EncryptedData and AuthenticatedEnvelopedData (RFC	EnvelopedData, EncryptedData and AuthenticatedEnvelopedData (RFC
	5083)). The parameterized type is assigned to an unparameterized	5083)). The parameterized type is assigned to an unparameterized
	type of EncryptedContentInfo to minimize the output changes from	type of EncryptedContentInfo to minimize the output changes from
	previous versions.	previous versions.


	The use of different attribute sets for EncryptedData and	Protocol designers can make use of the '08 ASN.1 contraints to define
	EnvelopedData as well as for AuthenticatedData and AuthEnvelopedData,	different sets of attributes for EncryptedData and EnvelopedData and
	protocol designers can make use of the '08 ASN.1 constraints to	for AuthenticatedData and AuthEnvelopedData. Previously, attributes
	define different sets of attributes for EncryptedData and	could only be constrained based on whether they were in the clear or
	EnvelopedData and for AuthenticatedData and AuthEnvelopedData.	unauthenticated not on the encapsulating content type.
	Previously, attributes could only be constrained based on whether
	they were in the clear or unauthenticated not on the encapsulating
	content type.

	CMS-AuthEnvelopedData-2009	CMS-AuthEnvelopedData-2009
	{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)	{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
	smime(16) modules(0) id-mod-cmsAuthEnvData-2009(57) }	smime(16) modules(0) id-mod-cmsAuthEnvData-2009(57) }
	DEFINITIONS IMPLICIT TAGS ::=	DEFINITIONS IMPLICIT TAGS ::=
	BEGIN	BEGIN
	IMPORTS	IMPORTS

	CMSVersion, EncryptedContentInfoType{},	CMSVersion, EncryptedContentInfoType{},
	MessageAuthenticationCode, OriginatorInfo, RecipientInfos,	MessageAuthenticationCode, OriginatorInfo, RecipientInfos,

	skipping to change at page 22, line 10 ¶	skipping to change at page 22, line 10 ¶

	UnauthEnvDataAttributeSet ATTRIBUTE ::= {...}	UnauthEnvDataAttributeSet ATTRIBUTE ::= {...}

	END	END

	9. ASN.1 Module RFC 5652	9. ASN.1 Module RFC 5652

	This module is updated from RFC 5911 [RFC5911] by the following	This module is updated from RFC 5911 [RFC5911] by the following
	changes:	changes:


	1. Define seperate attribute sets for the unprotected attributes	1. Define separate attribute sets for the unprotected attributes
	used in EnvelopedData, EncryptedData and	used in EnvelopedData, EncryptedData and
	AuthenticatedEnvelopedData (RFC 5083).	AuthenticatedEnvelopedData (RFC 5083).

	2. Define a parameterized type EncryptedContentInfoType so that the	2. Define a parameterized type EncryptedContentInfoType so that the
	basic type can be used with algorithm sets (used for	basic type can be used with algorithm sets (used for
	EnvelopedData, EncryptedData and AuthenticatedEnvelopedData (RFC	EnvelopedData, EncryptedData and AuthenticatedEnvelopedData (RFC
	5083)). The parameterized type is assigned to an unparameterized	5083)). The parameterized type is assigned to an unparameterized
	type of EncryptedContentInfo to minimize the output changes from	type of EncryptedContentInfo to minimize the output changes from
	previous versions.	previous versions.


	The use of different attribute sets for EncryptedData and	We are anticipating the definition of attributes that are going to be
	EnvelopedData as well as for AuthenticatedData and AuthEnvelopedData,	resticted to the use of only EnvelopedData. We are therefore
	protocol designers can make use of the '08 ASN.1 constraints to	separating the different attribute sets so that protocol designers
	define different sets of attributes for EncryptedData and	that need to do this will be able to define attributes that are used
	EnvelopedData and for AuthenticatedData and AuthEnvelopedData.	for EnvelopedData but not for EncryptedData. The same separation is
	Previously, attributes could only be constrained based on whether	also being applied to AuthenticatedData and AuthEnvelopedData.
	they were in the clear or unauthenticated not on the encapsulating
	content type.

	CryptographicMessageSyntax-2009	CryptographicMessageSyntax-2009
	{ iso(1) member-body(2) us(840) rsadsi(113549)	{ iso(1) member-body(2) us(840) rsadsi(113549)
	pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) }	pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) }
	DEFINITIONS IMPLICIT TAGS ::=	DEFINITIONS IMPLICIT TAGS ::=
	BEGIN	BEGIN
	IMPORTS	IMPORTS

	ParamOptions, DIGEST-ALGORITHM, SIGNATURE-ALGORITHM,	ParamOptions, DIGEST-ALGORITHM, SIGNATURE-ALGORITHM,
	PUBLIC-KEY, KEY-DERIVATION, KEY-WRAP, MAC-ALGORITHM,	PUBLIC-KEY, KEY-DERIVATION, KEY-WRAP, MAC-ALGORITHM,

	skipping to change at page 35, line 26 ¶	skipping to change at page 35, line 26 ¶
	matching using first the object identifier and if that is not present	matching using first the object identifier and if that is not present
	the textual name of the module. Note however that some older	the textual name of the module. Note however that some older
	implementations used the textual name of the module for the purposes	implementations used the textual name of the module for the purposes
	of matching. In a full implementation the name assigned to the	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	module is scoped to the ASN.1 module that it appears in (and thus
	need to match the module it is importing from).	need to match the module it is importing from).

	One can create a module that contains only the module number	One can create a module that contains only the module number
	assignments and import the module assignments from the new module.	assignments and import the module assignments from the new module.
	This means that when a module is replaced, one can replace the	This means that when a module is replaced, one can replace the

	previous module, update the module number assigment module and	previous module, update the module number assignment module and
	recompile without having to modify any other modules.	recompile without having to modify any other modules.


	A sample module assigment module would be:	A sample module assignment module would be:

	ModuleNumbers	ModuleNumbers
	DEFINITIONS TAGS ::=	DEFINITIONS TAGS ::=
	BEGIN	BEGIN
	id-mod-CMS ::= { iso(1) member-body(2) us(840) rsadsi(113549)	id-mod-CMS ::= { iso(1) member-body(2) us(840) rsadsi(113549)
	pkcs(1) pkcs-9(9) smime(16) modules(0) TBD }	pkcs(1) pkcs-9(9) smime(16) modules(0) TBD }

	id-mod-AlgInfo ::=	id-mod-AlgInfo ::=
	{iso(1) identified-organization(3) dod(6) internet(1)	{iso(1) identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) id-mod(0)	security(5) mechanisms(5) pkix(7) id-mod(0)

	skipping to change at page 39, line 13 ¶	skipping to change at page 39, line 13 ¶
	None.	None.

	14. Normative References	14. Normative References

	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.	Requirement Levels", BCP 14, RFC 2119, March 1997.

	[RFC3274] Gutmann, P., "Compressed Data Content Type for	[RFC3274] Gutmann, P., "Compressed Data Content Type for
	Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.	Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.


	[RFC3379] Pinkas, D. and R. Housley, "Delegated Path Validation and	[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
	Delegated Path Discovery Protocol Requirements", RFC 3379,	Addresses and AS Identifiers", RFC 3779, June 2004.
	September 2002.


	[RFC4049] Housley, R., "BinaryTime: An Alternate Format for	[RFC6019] Housley, R., "BinaryTime: An Alternate Format for
	Representing Date and Time in ASN.1", RFC 4049,	Representing Date and Time in ASN.1", RFC 6019,
	April 2005.	September 2010.

	[RFC4073] Housley, R., "Protecting Multiple Contents with the	[RFC4073] Housley, R., "Protecting Multiple Contents with the
	Cryptographic Message Syntax (CMS)", RFC 4073, May 2005.	Cryptographic Message Syntax (CMS)", RFC 4073, May 2005.

	[RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-	[RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-
	224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512",	224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512",
	RFC 4231, December 2005.	RFC 4231, December 2005.

	[RFC4334] Housley, R. and T. Moore, "Certificate Extensions and	[RFC4334] Housley, R. and T. Moore, "Certificate Extensions and
	Attributes Supporting Authentication in Point-to-Point	Attributes Supporting Authentication in Point-to-Point
	Protocol (PPP) and Wireless Local Area Networks (WLAN)",	Protocol (PPP) and Wireless Local Area Networks (WLAN)",
	RFC 4334, February 2006.	RFC 4334, February 2006.

	[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS)	[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS)
	Authenticated-Enveloped-Data Content Type", RFC 5083,	Authenticated-Enveloped-Data Content Type", RFC 5083,
	November 2007.	November 2007.


	[RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated
	Encryption in the Cryptographic Message Syntax (CMS)",
	RFC 5084, November 2007.

	[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,	[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
	RFC 5652, September 2009.	RFC 5652, September 2009.

	[RFC5752] Turner, S. and J. Schaad, "Multiple Signatures in	[RFC5752] Turner, S. and J. Schaad, "Multiple Signatures in
	Cryptographic Message Syntax (CMS)", RFC 5752,	Cryptographic Message Syntax (CMS)", RFC 5752,
	January 2010.	January 2010.

	[RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for	[RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for
	Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911,	Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911,
	June 2010.	June 2010.

End of changes. 23 change blocks.
	49 lines changed or deleted	40 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/