< draft-ietf-pkix-cmc-trans-07.txt		draft-ietf-pkix-cmc-trans-08.txt >
	PKIX Working Group J. Schaad		PKIX Working Group J. Schaad
	Internet-Draft Soaring Hawk Consulting		Internet-Draft Soaring Hawk Consulting
	Expires: June 6, 2008 M. Myers		Expires: September 11, 2008 M. Myers
	TraceRoute Security, Inc.		TraceRoute Security, Inc.
	December 4, 2007		March 10, 2008
	Certificate Management over CMS (CMC): Transport Protocols		Certificate Management over CMS (CMC): Transport Protocols
	draft-ietf-pkix-cmc-trans-07.txt		draft-ietf-pkix-cmc-trans-08.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 June 6, 2008.		This Internet-Draft will expire on September 11, 2008.
	Copyright Notice
	Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document defines a number of transport mechanisms that are used		This document defines a number of transport mechanisms that are used
	to move CMC (Certificate Management over CMS (Cryptographic Message		to move CMC (Certificate Management over CMS (Cryptographic Message
	Syntax)) messages. The transport mechanisms described in this		Syntax)) messages. The transport mechanisms described in this
	document are: HTTP, file, mail and TCP.		document are: HTTP, file, mail and TCP.
	1. Overview		1. Overview
	skipping to change at page 3, line 33 ¶		skipping to change at page 3, line 27 ¶
	| Simple PKI | application/pkcs10 | .p10 | N/A |		| Simple PKI | application/pkcs10 | .p10 | N/A |
	| Request | | | |		| Request | | | |
	| Full PKI | application/pkcs7-mime | .p7m | CMC-request |		| Full PKI | application/pkcs7-mime | .p7m | CMC-request |
	| Request | | | |		| Request | | | |
	| Simple PKI | application/pkcs7-mime | .p7c | certs-only |		| Simple PKI | application/pkcs7-mime | .p7c | certs-only |
	| Response | | | |		| Response | | | |
	| Full PKI | application/pkcs7-mime | .p7m | CMC-response |		| Full PKI | application/pkcs7-mime | .p7m | CMC-response |
	| Response | | | |		| Response | | | |
	+--------------+------------------------+------------+--------------+		+--------------+------------------------+------------+--------------+
	Table 2: MIME PKI Request/Response Identification		Table 1: MIME PKI Request/Response Identification
	4. HTTP/HTTPS based protocol		4. HTTP/HTTPS based protocol
	This section describes the conventions for use of HTTP [HTTP] as a		This section describes the conventions for use of HTTP [HTTP] as a
	transport layer. In most circumstances, the use of HTTP over TLS		transport layer. In most circumstances, the use of HTTP over TLS
	[TLS] provides any necessary content protection from ease-droppers.		[TLS] provides any necessary content protection from ease-droppers.
	In order for CMC clients and servers using HTTP to interoperate, the		In order for CMC clients and servers using HTTP to interoperate, the
	following rules apply.		following rules apply.
	Clients MUST use the POST method to submit their requests.		Clients MUST use the POST method to submit their requests.
	skipping to change at page 4, line 4 ¶		skipping to change at page 3, line 44 ¶
	In order for CMC clients and servers using HTTP to interoperate, the		In order for CMC clients and servers using HTTP to interoperate, the
	following rules apply.		following rules apply.
	Clients MUST use the POST method to submit their requests.		Clients MUST use the POST method to submit their requests.
	Servers MUST use the 200 response code for successful reponses.		Servers MUST use the 200 response code for successful reponses.
	Clients MAY attempt to send HTTP requests using TLS 1.0 [TLS] or		Clients MAY attempt to send HTTP requests using TLS 1.0 [TLS] or
	later, although servers are not required to support TLS.		later, although servers are not required to support TLS.
	Servers MUST NOT assume client support for any type of HTTP		Servers MUST NOT assume client support for any type of HTTP
	authentication such as cookies, Basic authentication or Digest		authentication such as cookies, Basic authentication or Digest
	authentication.		authentication.
	Clients and servers are expected to follow the other rules and		Clients and servers are expected to follow the other rules and
	restrictions in [HTTP]. Note that some of those rules are for		restrictions in [HTTP]. Note that some of those rules are for
	HTTP methods other than POST; clearly, only the rules that apply		HTTP methods other than POST; clearly, only the rules that apply
	to POST are relevant for this specification.		to POST are relevant for this specification.
	4.1. PKI Request		4.1. PKI Request
	A PKI Request using the POST method is constructed as follows:		A PKI Request using the POST method is constructed as follows:
	The Content-Type header MUST have the appropriate value from Table 2.		The Content-Type header MUST have the appropriate value from Table 1.
	The body of the message is the binary value of the encoding of the		The body of the message is the binary value of the encoding of the
	PKI Request.		PKI Request.
	4.2. PKI Response		4.2. PKI Response
	An HTTP-based PKI Response is composed of the appropriate HTTP		An HTTP-based PKI Response is composed of the appropriate HTTP
	headers, followed by the binary value of the BER (Basic Encoding		headers, followed by the binary value of the BER (Basic Encoding
	Rules) encoding of either a Simple or Full PKI Response.		Rules) encoding of either a Simple or Full PKI Response.
	The Content-Type header MUST have the appropriate value from Table 2.		The Content-Type header MUST have the appropriate value from Table 1.
	5. TCP based protocol		5. TCP based protocol
	When CMC messages are sent over a TCP-Based connection, no wrapping		When CMC messages are sent over a TCP-Based connection, no wrapping
	is required of the message. Messages are sent in their binary		is required of the message. Messages are sent in their binary
	encoded form.		encoded form.
	The connection is closed by the server after generating a response		The connection is closed by the client after recieving a final
	for the client. (All CMC request messages from client to server		response. If a second round of messages is needed, the client can
	generate a response message.) If a second set of messages from the		either re-use the same connection or use a new one.
	client to the server is required to complete the transaction, the
	client generates a new TCP-Based connection for this purpose; it
	cannot reuse an existing one.
	Out of band setup can be used to keep a TCP-Based connection open for
	more than one message pair. A situation where this can occur is an
	RA talking to a CA over a specially setup TCP connection.
	There is no specific port that is to be used when doing TCP based		There is no specific port that is to be used when doing TCP based
	transport. This is to be configured out of band.		transport. Only the Private Ports (49152-65535) may be used in this
			manner (without registration). The ports in the range of (1-49151)
	6. Socket-Based Transport		SHOULD NOT be used. The port to be used is configured out of band.
	When enrollment messages and responses are sent over sockets, no
	wrapping is required. Messages MUST be sent in their binary, BER-
	encoded form.
	7. Security Considerations		6. Security Considerations
	Mechanisms for thwarting replay attacks may be required in particular		Mechanisms for thwarting replay attacks may be required in particular
	implementations of this protocol depending on the operational		implementations of this protocol depending on the operational
	environment. In cases where the CA maintains significant state		environment. In cases where the CA maintains significant state
	information, replay attacks may be detectable without the inclusion		information, replay attacks may be detectable without the inclusion
	of the optional nonce mechanisms. Implementers of this protocol need		of the optional nonce mechanisms. Implementers of this protocol need
	to carefully consider environmental conditions before choosing		to carefully consider environmental conditions before choosing
	whether or not to implement the senderNonce and recipientNonce		whether or not to implement the senderNonce and recipientNonce
	attributes described in section 5.6 of [CMC-STRUCT]. Developers of		attributes described in section 5.6 of [CMC-STRUCT]. Developers of
	state-constrained PKI clients are strongly encouraged to incorporate		state-constrained PKI clients are strongly encouraged to incorporate
	the use of these attributes.		the use of these attributes.
	8. IANA Considerations		Initiation of a secure communications channel between an end-entity
			and a CA or RA (and, similarly, between an RA and another RA or CA)
			necessarily requires an out-of-band trust initiation mechanism. For
			example, a secure channel may be constructed between the end-entity
			and the CA via IPsec [IPsec] or TLS [TLS]. Many such schemes exist
			and the choice of any particular scheme for trust initiation is
			outside the scope of this document. 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.
			In some instances no prior out-of-band trust will have been initiated
			prior to use of this protocol. This can occur when the protocol
			itself is being used to download onto the system the set of trust
			anchors to be used for these protocols. In these instances the
			Enveloped Data Content type (section 3.2.1.3.3 in [CMC-STRUCT]) must
			be used to provide the same shrouding that TLS would have provided.
			7. IANA Considerations
	There are no IANA considerations in this document.		There are no IANA considerations in this document.
	9. Acknowledgments		8. Acknowledgments
	The authors and the Working Group are grateful for the participation		The authors and the Working Group are grateful for the participation
	of Xiaoui Lui and Jeff Weinstein in helping to author the original		of Xiaoui Lui and Jeff Weinstein in helping to author the original
	versions of this document.		versions of this document.
	The authors would like to thank Brian LaMacchia for his work in		The authors would like to thank Brian LaMacchia for his work in
	developing and writing up many of the concepts presented in this		developing and writing up many of the concepts presented in this
	document. The authors would also like to thank Alex Deacon and Barb		document. The authors would also like to thank Alex Deacon and Barb
	Fox for their contributions.		Fox for their contributions.
	10. References		9. References
	10.1. Normative References		9.1. Normative References
	[CMC-STRUCT]		[CMC-STRUCT]
	Schaad, J. and M. Myers, "Certificate Management Messages		Schaad, J. and M. Myers, "Certificate Management Messages
	over CMS", draft-ietf-pkix-2797-bis-05.txt ,		over CMS", draft-ietf-pkix-2797-bis-05.txt ,
	September 2005.		September 2005.
	[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.		Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
			[IPsec] Kent, S. and K. Seo, "Security Architecture for the
			Internet Protocol", RFC 4301, December 2005.
	[MUST] Bradner, S., "Key words for use in RFCs to Indicate		[MUST] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, BCP 14, March 1997.		Requirement Levels", RFC 2119, BCP 14, March 1997.
	[SMIMEV3] Ramsdell, B., "Secure/Multipurpose Internet Mail		[SMIMEV3] Ramsdell, B., "Secure/Multipurpose Internet Mail
	Extensions (S/MIME) Version 3.1 Message Specification",		Extensions (S/MIME) Version 3.1 Message Specification",
	RFC 3851, July 2004.		RFC 3851, July 2004.
	10.2. Informative References		9.2. Informative References
	[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security		[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.1", RFC 4346, April 2006.		(TLS) Protocol Version 1.1", RFC 4346, April 2006.
	Authors' Addresses		Authors' Addresses
	Jim Schaad		Jim Schaad
	Soaring Hawk Consulting		Soaring Hawk Consulting
	PO Box 675		PO Box 675
	Gold Bar, WA 98251		Gold Bar, WA 98251
	skipping to change at page 7, line 7 ¶		skipping to change at page 7, line 7 ¶
	Phone: (425) 785-1031		Phone: (425) 785-1031
	Email: jimsch@nwlink.com		Email: jimsch@nwlink.com
	Michael Myers		Michael Myers
	TraceRoute Security, Inc.		TraceRoute Security, Inc.
	Email: mmyers@fastq.com		Email: mmyers@fastq.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	skipping to change at page 7, line 44 ¶		skipping to change at line 300 ¶
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 19 change blocks.
	36 lines changed or deleted		41 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/