< draft-turner-additional-cms-ri-choices-05.txt		draft-turner-additional-cms-ri-choices-06.txt >
	NETWORK WG Sean Turner, IECA		NETWORK WG Sean Turner, IECA
	Internet Draft Russ Housley, Vigil Security		Internet Draft Russ Housley, Vigil Security
	Intended Status: Standards Track May 10, 2010		Intended Status: Standards Track June 3, 2010
	Expires: November 10, 2010		Expires: December 3, 2010
	Additional CMS Revocation Information Choices		Additional CMS Revocation Information Choices
	draft-turner-additional-cms-ri-choices-05.txt		draft-turner-additional-cms-ri-choices-06.txt
	Abstract		Abstract
	The Cryptographic Message Syntax (CMS) allows revocation information		The Cryptographic Message Syntax (CMS) allows revocation information
	to be conveyed as part of the SignedData, EnvelopedData,		to be conveyed as part of the SignedData, EnvelopedData,
	AuthenticatedData, and AuthEnvelopedData content types. The		AuthenticatedData, and AuthEnvelopedData content types. The
	preferred format for revocation information is the Certificate		preferred format for revocation information is the Certificate
	Revocation List (CRL), but an extension mechanism supports other		Revocation List (CRL), but an extension mechanism supports other
	revocation information choices. This document defines two additional		revocation information formats. This document defines two additional
	revocation information formats for Online Certificate Status Protocol		revocation information formats for Online Certificate Status Protocol
	(OCSP) responses and Server-Based Certificate Validation Protocol		(OCSP) responses and Server-Based Certificate Validation Protocol
	(SCVP).		(SCVP).
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF 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
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html
	This Internet-Draft will expire on November 10, 2010.		This Internet-Draft will expire on December 3, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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
	skipping to change at page 2, line 27 ¶		skipping to change at page 2, line 27 ¶
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	1. Introduction		1. Introduction
	The RevocationInfoChoices type defined in [CMS] provides a set of		The RevocationInfoChoices type defined in [CMS] provides a set of
	revocation status information alternatives, which allows revocation		revocation status information alternatives, which allows revocation
	information to be conveyed as part of the SignedData, EnvelopedData,		information to be conveyed as part of the SignedData, EnvelopedData,
	AuthenticatedData, and AuthEnvelopedData content types. The intent		AuthenticatedData, and AuthEnvelopedData content types. The intent
	is to provide information sufficient to determine whether the		is to provide information sufficient to determine whether the
	certificates and attribute certificates carried elsewhere in the CMS		certificates and attribute certificates carried elsewhere in the CMS-
	protecting content are revoked. However, there may be more		protected content have been revoked. There may be more revocation
	revocation status information than necessary or there may be less		status information than necessary or there may be less revocation
	revocation status information than necessary.		status information than necessary.
	X.509 Certificate revocation lists (CRLs) [PROFILE] are the primary		X.509 Certificate revocation lists (CRLs) [PROFILE] are the primary
	source of revocation status information, but any other revocation		source of revocation status information, but any other revocation
	information formats can be supported. This document specifies two		information format can be supported. This document specifies two
	other formats: Online Certificate Status Protocol (OCSP) responses		other formats: Online Certificate Status Protocol (OCSP) responses
	[OCSP] and Server-Based Certificate Validation Protocol (SCVP)		[OCSP] and Server-Based Certificate Validation Protocol (SCVP)
	responses [SCVP].		requests and responses [SCVP].
	Section 2 discusses the RevocationInformation structure. Section 3		Section 2 discusses the RevocationInformation structure. Section 3
	defines a mechanism to carry OCSP responses. Section 4 defines a		defines a mechanism to carry OCSP responses. Section 4 defines a
	mechanism to carry SCVP requests and responses. Appendix A provides		mechanism to carry SCVP requests and responses. Appendix A provides
	the normative ASN.1 syntax for the two mechanisms.		the normative ASN.1 syntax for the two mechanisms.
	1.1. Requirements Terminology		1.1. 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 [WORDS].		document are to be interpreted as described in [WORDS].
	2. Revocation Information		2. Revocation Information
	For convenience, the ASN.1 definition of the RevocationInfoChoices		For convenience, the ASN.1 definition of the RevocationInfoChoices
	type from [CMS] is repeated here:		type from [CMS] is repeated here:
	RevocationInfoChoices ::= SET OF RevocationInfoChoice		RevocationInfoChoices ::= SET OF RevocationInfoChoice
	RevocationInfoChoice ::= CHOICE {		RevocationInfoChoice ::= CHOICE {
	crl CertificateList,		crl CertificateList,
	other [1] IMPLICIT OtherRevocationInfoFormat }		other [1] IMPLICIT OtherRevocationInfoFormat }
	OtherRevocationInfoFormat ::= SEQUENCE {		OtherRevocationInfoFormat ::= SEQUENCE {
	otherRevInfoFormat OBJECT IDENTIFIER,		otherRevInfoFormat OBJECT IDENTIFIER,
	otherRevInfo ANY DEFINED BY otherRevInfoFormat }		otherRevInfo ANY DEFINED BY otherRevInfoFormat }
	The other CHOICE MUST be used to convey OCSP responses, SCVP		The other CHOICE MUST be used to convey OCSP responses, SCVP
	requests, and SCVP responses.		requests, and SCVP responses.
	The revocation information choices are defined under the following		This document defines the id-ri arc under which the revocation
	object identifier arc:		information formats are defined. The id-ri object identifier is:
	id-ri OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)		id-ri OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
	dod(6) internet(1) security(5) mechanisms(5) pkix(7) ri(16) }		dod(6) internet(1) security(5) mechanisms(5) pkix(7) ri(16) }
			NOTE: Numbers 1 and 3 were assigned to CRL and Delta CRL. These two
			numbers are not used because these formats use the
			RevocationInfoChoice crl CHOICE when included in CMS [CMS].
	3. OCSP Response		3. OCSP Response
	To carry an OCSP response, the otherRevInfoFormat is set to		To carry an OCSP response, the otherRevInfoFormat is set to
	id-ri-ocsp-response, which has the following ASN.1 definition:		id-ri-ocsp-response, which has the following ASN.1 definition:
	id-ri-ocsp-response OBJECT IDENTIFIER ::= { id-ri 2 }		id-ri-ocsp-response OBJECT IDENTIFIER ::= { id-ri 2 }
	In this case, otherRevInfo MUST carry the OCSP response using the		In this case, otherRevInfo MUST carry the OCSP response using the
	OCSPResponse type defined in [OCSP]. The responseStatus field MUST		OCSPResponse type defined in [OCSP]. The responseStatus field MUST
	be successful and the responseBytes field MUST be present.		be successful and the responseBytes field MUST be present.
	4. SCVP Request and Response		4. SCVP Request and Response
	Unlike OSCP, SCVP permits unprotected and protected responses, where		Unlike OSCP, SCVP permits unprotected and protected responses, where
	protected responses can be digitally signed or include message		protected responses can be digitally signed or include message
	authentication codes. While this provides more flexibility, it		authentication codes. While this provides more flexibility, it
	complicates when an SCVP response can be validated by entities other		complicates implementations when an SCVP response can be validated by
	than the entity that generated the SCVP request. If a lower layer		entities other than the entity that generated the SCVP request. If a
	provides authentication and integrity for the client-server		lower layer provides authentication and integrity for the client-
	interaction and the response is not protected, then a third party		server interaction and the response is not protected, then a third
	cannot validate the response because there is no way to know that the		party cannot validate the response because there is no way to know
	response was returned over a protected connection. If a message		that the response was returned over a protected connection. If a
	authentication code is used, then the third party will be unable to		message authentication code is used, then the third party will be
	validate the message authentication code because it does not possess		unable to validate the message authentication code because it does
	the necessary private key. For these reasons, SCVP responses sent to		not possess the necessary private key. For these reasons, SCVP
	a third party MUST be signed by the SCVP server so that the third		responses sent to a third party MUST be signed by the SCVP server so
	party can validate them.		that the third party can validate them.
	SCVP response validation requires matching it to the SCVP request.		SCVP response validation requires matching it to the SCVP request.
	This means that the SCVP request MUST always be included with the		This means that the SCVP request MUST always be included with the
	response. SCVP permits the client to retain the response, and SCVP		response. SCVP permits the client to retain the response, and SCVP
	permits the request to be returned in the response (in the requestReq		permits the request to be returned in the response (in the requestReq
	field). The request need not be protected for matching to be		field). The request need not be protected for matching to be
	performed; nonces and certIds can be checked.		performed; nonces and certIds can be checked.
	To carry the SCVP request and response, the otherRevInfoFormat is set		To carry the SCVP request and response, the otherRevInfoFormat is set
	to id-ri-scvp, which has the following ASN.1 definition:		to id-ri-scvp, which has the following ASN.1 definition:
	skipping to change at page 5, line 21 ¶		skipping to change at page 5, line 23 ¶
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[CMS] Housley, R., "Cryptographic Message Syntax", RFC 5652,		[CMS] Housley, R., "Cryptographic Message Syntax", RFC 5652,
	September 2009.		September 2009.
	[CMS-ASN] Hoffman, P., and J. Schaad, "New ASN.1 Modules for		[CMS-ASN] Hoffman, P., and J. Schaad, "New ASN.1 Modules for
	Cryptographic Message Syntax (CMS) and S/MIME", RFC		Cryptographic Message Syntax (CMS) and S/MIME", RFC
	5911, May 2010.		5911, June 2010.
	[OCSP] Meyers, M., Ankney, R., Malpani, A., Galperin, S., and		[OCSP] Meyers, M., Ankney, R., Malpani, A., Galperin, S., and
	C. Adams, "X.509 Internet Public Key Infrastructure		C. Adams, "X.509 Internet Public Key Infrastructure
	Online Certificate Status Protocol - OCSP", RFC 2560,		Online Certificate Status Protocol - OCSP", RFC 2560,
	June 1999.		June 1999.
	[PROFILE-ASN] Hoffman, P., and J. Schaad, "New ASN.1 Modules for the		[PROFILE-ASN] Hoffman, P., and J. Schaad, "New ASN.1 Modules for the
	Public Key Infrastructure Using X.509 (PKIX)", RFC		Public Key Infrastructure Using X.509 (PKIX)", RFC
	5912, May 2010.		5912, June 2010.
	[SCVP] Freeman, T., Housley, R., Malpani, A., Cooper, D., and		[SCVP] Freeman, T., Housley, R., Malpani, A., Cooper, D., and
	W. Polk, "Server-Based Certificate Validation Protocol		W. Polk, "Server-Based Certificate Validation Protocol
	(SCVP)", RFC 5055, December 2007.		(SCVP)", RFC 5055, December 2007.
	[WORDS] Bradner, S., "Key words for use in RFCs to Indicate		[WORDS] 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.
	[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-		[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-
	1:2002. Information Technology - Abstract Syntax		1:2002. Information Technology - Abstract Syntax
	skipping to change at page 7, line 48 ¶		skipping to change at page 8, line 4 ¶
	CMS-Other-RIs-2009-02		CMS-Other-RIs-2009-02
	{ iso(1) identified-organization(3) dod(6) internet(1) security(5)		{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
	mechanisms(5) pkix(7) id-mod(0) id-mod-cms-otherRIs-2009-93(64)		mechanisms(5) pkix(7) id-mod(0) id-mod-cms-otherRIs-2009-93(64)
	}		}
	DEFINITIONS IMPLICIT TAGS ::=		DEFINITIONS IMPLICIT TAGS ::=
	BEGIN		BEGIN
	-- EXPORT ALL		-- EXPORT ALL
	IMPORTS		IMPORTS
	-- FROM [PROFILE-ASN]		-- FROM [PROFILE-ASN]
	OCSPResponse		OCSPResponse
	FROM OCSP-2009		FROM OCSP-2009
	{ iso(1) identified-organization(3) dod(6) internet(1) security(5)		{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
	mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp-02(48) }		mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp-02(48) }
	-- FROM [CMS-ASN]		-- FROM [CMS-ASN]
	ContentInfo, OTHER-REVOK-INFO		ContentInfo, OTHER-REVOK-INFO
	FROM CryptographicMessageSyntax-2009		FROM CryptographicMessageSyntax-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-cms-2004-02(41) }		smime(16) modules(0) id-mod-cms-2004-02(41) }
	;		;
	-- Defines OCSP and SCVP choices for RevocationInfoChoice		-- Defines OCSP and SCVP formats for RevocationInfoChoice
	SupportedOtherRevokInfo OTHER-REVOK-INFO ::= {		SupportedOtherRevokInfo OTHER-REVOK-INFO ::= {
	ri-ocsp-response |		ri-ocsp-response |
	ri-scvp,		ri-scvp,
	... }		... }
	ri-ocsp-response OTHER-REVOK-INFO ::= {		ri-ocsp-response OTHER-REVOK-INFO ::= {
	OCSPResponse IDENTIFIED BY id-ri-ocsp-response }		OCSPResponse IDENTIFIED BY id-ri-ocsp-response }
	id-ri OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)		id-ri OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
End of changes. 16 change blocks.
	29 lines changed or deleted		33 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/