< draft-turner-additional-new-asn-06.txt		draft-turner-additional-new-asn-07.txt >
	Network Working Group J. Schaad		Network Working Group J. Schaad
	Internet-Draft Soaring Hawk Consulting		Internet-Draft Soaring Hawk Consulting
	Intended status: Informational S. Turner		Updates: 5911 (if approved) S. Turner
	Expires: June 15, 2011 IECA, Inc.		Intended status: Informational IECA, Inc.
	December 12, 2010		Expires: August 11, 2011 February 7, 2011
	Additional New ASN.1 Modules		Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS)
	draft-turner-additional-new-asn-06		and the Public Key Infrastructure Using X.509 (PKIX)
			draft-turner-additional-new-asn-07
	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; the
	There are no bits-on-the-wire changes to any of the formats; this is		1988 ASN.1 modules remain the normative version. There are no bits-
	simply a change to the syntax.		on-the-wire changes to any of the formats; this is simply a change to
			the syntax.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on June 15, 2011.		This Internet-Draft will expire on August 11, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 21 ¶		skipping to change at page 3, line 7 ¶
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. ASN.1 Updates (2002 to 2008) . . . . . . . . . . . . . . . 3		1.1. ASN.1 Updates (2002 to 2008) . . . . . . . . . . . . . . . 5
	1.2. Requirements Terminology . . . . . . . . . . . . . . . . . 4		1.2. Requirements Terminology . . . . . . . . . . . . . . . . . 5
	2. ASN.1 Module RFC 3274 . . . . . . . . . . . . . . . . . . . . 5		2. ASN.1 Module RFC 3274 . . . . . . . . . . . . . . . . . . . . 6
	3. ASN.1 Module RFC 3779 . . . . . . . . . . . . . . . . . . . . 8		3. ASN.1 Module RFC 3779 . . . . . . . . . . . . . . . . . . . . 9
	4. ASN.1 Module RFC 6019 . . . . . . . . . . . . . . . . . . . . 11		4. ASN.1 Module RFC 6019 . . . . . . . . . . . . . . . . . . . . 12
	5. ASN.1 Module RFC 4073 . . . . . . . . . . . . . . . . . . . . 13		5. ASN.1 Module RFC 4073 . . . . . . . . . . . . . . . . . . . . 14
	6. ASN.1 Module RFC 4231 . . . . . . . . . . . . . . . . . . . . 15		6. ASN.1 Module RFC 4231 . . . . . . . . . . . . . . . . . . . . 16
	7. ASN.1 Module RFC 4334 . . . . . . . . . . . . . . . . . . . . 18		7. ASN.1 Module RFC 4334 . . . . . . . . . . . . . . . . . . . . 19
	8. ASN.1 Module RFC 5083 . . . . . . . . . . . . . . . . . . . . 20		8. ASN.1 Module RFC 5083 . . . . . . . . . . . . . . . . . . . . 21
	9. ASN.1 Module RFC 5652 . . . . . . . . . . . . . . . . . . . . 22		9. ASN.1 Module RFC 5652 . . . . . . . . . . . . . . . . . . . . 23
	10. ASN.1 Module RFC 5752 . . . . . . . . . . . . . . . . . . . . 33		10. ASN.1 Module RFC 5752 . . . . . . . . . . . . . . . . . . . . 34
	11. Module Identifiers in ASN.1 . . . . . . . . . . . . . . . . . 35		11. Module Identifiers in ASN.1 . . . . . . . . . . . . . . . . . 36
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 37		12. Security Considerations . . . . . . . . . . . . . . . . . . . 38
	13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38		13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
	14. Normative References . . . . . . . . . . . . . . . . . . . . . 39		14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41		14.1. Normative References . . . . . . . . . . . . . . . . . . . 40
			14.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 41
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
	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 changed the syntax to use the 2008		In this document we have either changed the syntax to use the 2008
	skipping to change at page 3, line 49 ¶		skipping to change at page 4, line 49 ¶
	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.
			This document does not explicitly update the RFCs that the ASN.1
			modules have been extracted from. This is because the orginal 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.
	1.1. ASN.1 Updates (2002 to 2008)		1.1. ASN.1 Updates (2002 to 2008)
	The modules defined in this document are compatible 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.
			Information on the changes to ASN.1 between the 1988 and 2002
			versions can be found in [RFC6025].
	1.2. Requirements Terminology		1.2. Requirements Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. ASN.1 Module RFC 3274		2. ASN.1 Module RFC 3274
	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
	skipping to change at page 16, line 5 ¶		skipping to change at page 17, line 5 ¶
	}		}
	--		--
	-- This object set contains all of the S/MIME capabilities that		-- This object set contains all of the S/MIME capabilities that
	-- have been defined for all the MAC algorithms in this module.		-- have been defined for all the MAC algorithms in this module.
	-- One would add this to an object set that is used to restrict		-- One would add this to an object set that is used to restrict
	-- smime capabilities such as the SMimeCapsSet variable in		-- smime capabilities such as the SMimeCapsSet variable in
	-- the S/MIME message draft		-- the S/MIME message draft
	--		--
	SMimeCaps SMIME-CAPS ::= {		SMimeCaps SMIME-CAPS ::= {
	maca-hMAC-SHA224.&smimeCaps |		maca-hMAC-SHA224.&amp;smimeCaps |
	maca-hMAC-SHA256.&smimeCaps |		maca-hMAC-SHA256.&amp;smimeCaps |
	maca-hMAC-SHA384.&smimeCaps |		maca-hMAC-SHA384.&amp;smimeCaps |
	maca-hMAC-SHA512.&smimeCaps		maca-hMAC-SHA512.&amp;smimeCaps
	}		}
	--		--
	-- Define the base OID for the algorithm identifiers		-- Define the base OID for the algorithm identifiers
	--		--
	rsadsi OBJECT IDENTIFIER ::=		rsadsi OBJECT IDENTIFIER ::=
	{iso(1) member-body(2) us(840) rsadsi(113549)}		{iso(1) member-body(2) us(840) rsadsi(113549)}
	digestAlgorithm OBJECT IDENTIFIER ::= {rsadsi 2}		digestAlgorithm OBJECT IDENTIFIER ::= {rsadsi 2}
	skipping to change at page 16, line 30 ¶		skipping to change at page 17, line 30 ¶
	--		--
	-- Define the necessary algorithm identifiers		-- Define the necessary algorithm identifiers
	--		--
	id-hmacWithSHA224 OBJECT IDENTIFIER ::= {digestAlgorithm 8}		id-hmacWithSHA224 OBJECT IDENTIFIER ::= {digestAlgorithm 8}
	id-hmacWithSHA256 OBJECT IDENTIFIER ::= {digestAlgorithm 9}		id-hmacWithSHA256 OBJECT IDENTIFIER ::= {digestAlgorithm 9}
	id-hmacWithSHA384 OBJECT IDENTIFIER ::= {digestAlgorithm 10}		id-hmacWithSHA384 OBJECT IDENTIFIER ::= {digestAlgorithm 10}
	id-hmacWithSHA512 OBJECT IDENTIFIER ::= {digestAlgorithm 11}		id-hmacWithSHA512 OBJECT IDENTIFIER ::= {digestAlgorithm 11}
	--		--
	-- Define each of the MAC-ALGOIRTHM objects to describe the		-- Define each of the MAC-ALGORITHM objects to describe the
	-- algorithms defined		-- algorithms defined
	--		--
	maca-hMAC-SHA224 MAC-ALGORITHM ::= {		maca-hMAC-SHA224 MAC-ALGORITHM ::= {
	IDENTIFIER id-hmacWithSHA224		IDENTIFIER id-hmacWithSHA224
	PARAMS TYPE NULL ARE preferredPresent		PARAMS TYPE NULL ARE preferredPresent
	IS-KEYED-MAC TRUE		IS-KEYED-MAC TRUE
	SMIME-CAPS {IDENTIFIED BY id-hmacWithSHA224}		SMIME-CAPS {IDENTIFIED BY id-hmacWithSHA224}
	}		}
	skipping to change at page 20, line 21 ¶		skipping to change at page 21, line 21 ¶
	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 different 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.
	Protocol designers can make use of the '08 ASN.1 contraints to define		Protocol designers can make use of the '08 ASN.1 constraints to
	different sets of attributes for EncryptedData and EnvelopedData and		define different sets of attributes for EncryptedData and
	for AuthenticatedData and AuthEnvelopedData. Previously, attributes		EnvelopedData and for AuthenticatedData and AuthEnvelopedData.
	could only be constrained based on whether they were in the clear or		Previously, attributes could only be constrained based on whether
	unauthenticated not on the encapsulating content type.		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 25 ¶		skipping to change at page 23, line 25 ¶
	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.
	We are anticipating the definition of attributes that are going to be		We are anticipating the definition of attributes that are going to be
	resticted to the use of only EnvelopedData. We are therefore		resticted to the use of only EnvelopedData. We are therefore
	separating the different attribute sets so that protocol designers		separating the different attribute sets so that protocol designers
	that need to do this will be able to define attributes that are used		that need to do this will be able to define attributes that are used
	for EnvelopedData but not for EncryptedData. The same separation is		for EnvelopedData, but not for EncryptedData. The same separation is
	also being applied to AuthenticatedData and AuthEnvelopedData.		also being applied to AuthenticatedData and AuthEnvelopedData.
	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,
	skipping to change at page 35, line 16 ¶		skipping to change at page 36, line 16 ¶
	One potential issue that can occur when updating modules is the fact		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		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		from a newly updated module. This section addresses one method that
	can be used to deal with this problem, but the modules in this		can be used to deal with this problem, but the modules in this
	document don't currently implement the solution discussed here.		document don't currently implement the solution discussed here.
	When looking at an import statement, there are three portions: The		When looking at an import statement, there are three portions: The
	list of items imported, a textual name for the module and an object		list of items imported, a textual name for the module and an object
	identifier for the module. Full implementations of ASN.1 do module		identifier for the module. Full implementations of ASN.1 do module
	matching using first the object identifier and if that is not present		matching using first the object identifier, and if that is not
	the textual name of the module. Note however that some older		present, the textual name of the module. Note however that some
	implementations used the textual name of the module for the purposes		older implementations used the textual name of the module for the
	of matching. In a full implementation the name assigned to the		purposes of matching. In a full implementation the name assigned to
	module is scoped to the ASN.1 module that it appears in (and thus		the module is scoped to the ASN.1 module that it appears in (and thus
	need to match the module it is importing from).		the 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 assignment 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 assignment module would be:		A sample module assignment module would be:
	ModuleNumbers		ModuleNumbers
	skipping to change at page 39, line 5 ¶		skipping to change at page 40, line 5 ¶
	12. Security Considerations		12. Security Considerations
	This document itself does not have any security considerations. The		This document itself does not have any security considerations. The
	ASN.1 modules keep the same bits-on-the-wire as the modules that they		ASN.1 modules keep the same bits-on-the-wire as the modules that they
	replace.		replace.
	13. IANA Considerations		13. IANA Considerations
	None.		None.
	14. Normative References		14. References
			14.1. 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.
	[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP		[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
	Addresses and AS Identifiers", RFC 3779, June 2004.		Addresses and AS Identifiers", RFC 3779, June 2004.
	skipping to change at page 41, line 5 ¶		skipping to change at page 41, line 9 ¶
	June 2010.		June 2010.
	[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the		[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
	Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,		Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
	June 2010.		June 2010.
	[ASN1-2008]		[ASN1-2008]
	ITU-T, "ITU-T Recommendations X.680, X.681, X.682, and		ITU-T, "ITU-T Recommendations X.680, X.681, X.682, and
	X.683", 2008.		X.683", 2008.
			14.2. Informative
			[RFC6025] Wallace, C. and C. Gardiner, "ASN.1 Translation",
			RFC 6025, October 2010.
	Authors' Addresses		Authors' Addresses
	Jim Schaad		Jim Schaad
	Soaring Hawk Consulting		Soaring Hawk Consulting
	Email: jimsch@augustcellars.com		Email: jimsch@augustcellars.com
	Sean Turner		Sean Turner
	IECA, Inc.		IECA, Inc.
	3057 Nutley Street, Suite 106		3057 Nutley Street, Suite 106
End of changes. 15 change blocks.
	45 lines changed or deleted		66 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/