< draft-ietf-pkix-cmc-trans-00.txt		draft-ietf-pkix-cmc-trans-01.txt >
	PKIX Working Group M. Myers		PKIX Working Group J. Schaad
	Internet Draft VeriSign		Internet Draft Soaring Hawk Consulting
	Document: draft-ietf-pkix-cmc-trans-00.txt X. Liu		Document: draft-ietf-pkix-cmc-trans-01.txt M.Myers
	February 2001 Cisco		March 2002 TraceRoute Security
	Expires: July 2001 J. Schaad		Expires: September 2002 X.Liu
	Soaring Hawk Consulting		Cisco
	J. Weinstein		J. Weinstein
	CMC Transport		CMC Transport
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026 [1].		all provisions of Section 10 of RFC2026 [1].
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	skipping to change at line 45 ¶		skipping to change at line 45 ¶
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2000). All Rights Reserved.		Copyright (C) The Internet Society (2000). All Rights Reserved.
	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] messages. The transport mechanisms described in this		to move [CMC] messages. The transport mechanisms described in this
	document are: HTTP, file, mail and TCP.		document are: HTTP, file, mail and TCP.
			1. Overview
			This document defines a number of transport methods that are used to
			move [CMC] messages. The transport mechanisms described in this
			document are: HTTP, file, mail and TCP.
	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		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
	this document are to be interpreted as described in [RFC 2119].		this document are to be interpreted as described in [RFC 2119].
	1. Overview
	2. File based protocol		2. File based protocol
	Enrollment messages and responses may be transferred between clients		Enrollment messages and responses may be transferred between clients
	and servers using file system-based mechanisms, such as when		and servers using file system-based mechanisms, such as when
	enrollment is performed for an off-line client. When files are used		enrollment is performed for an off-line client. When files are used
	to transport binary, BER-encoded Full Enrollment Request and		to transport binary, BER-encoded Full Enrollment Request and
	Response messages. There MUST be only one instance of a request or		Response messages. There MUST be only one instance of a request or
	response message in a single file. The following file type		response message in a single file. The following file type
	extensions SHOULD be used:		extensions SHOULD be used:
	Message Type File Extension		Message Type File Extension
	Full PKI Request .crq		Full PKI Request .crq
	Full PKI Response .crp		Full PKI Response .crp
	3. Mail based protocol		3. Mail based protocol
	skipping to change at line 107 ¶		skipping to change at line 110 ¶
	MIME TYPE File Extension SMIME-TYPE		MIME TYPE File Extension SMIME-TYPE
	application/pkcs10 .p10 N/A		application/pkcs10 .p10 N/A
	(simple PKI request)		(simple PKI request)
	application/pkcs7-mime .p7m CMC-request		application/pkcs7-mime .p7m CMC-request
	(full PKI request)		(full PKI request)
	application/pkcs7-mime .p7c certs-only		application/pkcs7-mime .p7c certs-only
	(simple PKI response)		(simple PKI response)
	application/pkcs7-mime .p7m CMC-response		application/pkcs7-mime .p7m CMC-response
	(full PKI response)		(full PKI response)
	4. HTTP/HTTPS based protocol		4. HTTP/HTTPS based protocol
	HTTP messages are wrapped with by a mime object as specified above.		HTTP messages are wrapped with by a mime object as specified above.
	5. TCP based protocol		5. TCP based protocol
	When is the connection closed? How is this represented?		When CMC messages are sent over a TCP-Based connection, no wrapping
			is required of the message. Messages are sent in their binary
	While this section is called TCP-Based and the messages are called		encoded form.
	TCP-message's, the same protocol can be used over any reliable,
	connection oriented transport protocol (e.g. SNA, DECnet, etc.).
	This protocol is suitable for cases where an end entity (or an RA)
	initiates a transaction and can poll to pick up the results.
	The length of the flags field for this version is 1 octet. The LSB
	is used to indicate a connection close; all other bits in the flags
	octet MUST be ignored by receivers, and MUST be set to zero by
	senders.
	By default connections are kept open after the receipt of a		The connection is closed by the server after generating a response
	response. Either party (client or server) MAY set the connection		for the client. (All CMC request messages from client to server
	close bit at any time. If the connection close bit is set on a		generate a response message.) If a second set of messages from the
	request, then the server MUST set the bit in the response and close		client to the server is required to complete the transaction, the
	the connection after sending the response. If the bit is set on a		client generates a new TCP-Based connection for this purpose, it
	response from the server, the client MUST NOT send any further		cannot reuse an existing one.
	requests on that connection. Applications MAY decide to close an
	idle connection (one on which no response is outstanding) after some
	time-out. Because of the problem where a client sends a request and
	the server closes the connection while the request is still in
	flight, clients SHOULD automatically retry a request for which no
	part of the response could be read due to a connection close or
	reset.
	If the connection is kept open, it MUST only be used for subsequent		Out of band setup can be used to keep a TCP-Based connection open
	request/response transactions started by the client - the server		for more than one message pair. A situation where this can occur is
	MUST NOT use it to send requests to the client. Different		an RA talking to a CA over a specially setup TCP connection.
	transactions may be freely interwoven on the same connection. E.g. a
	CR/CP need not immediately be followed by the Confirm, but may be
	followed by any other request from a different transaction.
	7.3 Socket-Based Transport		6 Socket-Based Transport
	When enrollment messages and responses are sent over sockets, no		When enrollment messages and responses are sent over sockets, no
	wrapping is required. Messages SHOULD be sent in their binary, BER-		wrapping is required. Messages MUST be sent in their binary, BER-
	encoded form.		encoded form.
	9. Security Considerations		7. Security Considerations
	Mechanisms for thwarting replay attacks may be required in		Mechanisms for thwarting replay attacks may be required in
	particular implementations of this protocol depending on the		particular implementations of this protocol depending on the
	operational environment. In cases where the CA maintains significant		operational environment. In cases where the CA maintains significant
	state information, replay attacks may be detectable without the		state information, replay attacks may be detectable without the
	inclusion of the optional nonce mechanisms. Implementers of this		inclusion of the optional nonce mechanisms. Implementers of this
	protocol need to carefully consider environmental conditions before		protocol need to carefully consider environmental conditions before
	choosing whether or not to implement the senderNonce and		choosing whether or not to implement the senderNonce and
	recipientNonce attributes described in section 5.6. Developers of		recipientNonce attributes described in section 5.6. 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.
	10. Acknowledgments		8. Acknowledgments
	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.
	11. References		9. References
			[CMC] J. Schaad, M. Myers, X. Liu, J. Weinstein, ôBASEö,
			<base>.
	[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630,		[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630,
	June 1999.		June 1999.
	[CRMF] Myers, M., Adams, C., Solo, D. and D. Kemp, "Internet		[CRMF] Myers, M., Adams, C., Solo, D. and D. Kemp, "Internet
	X.509 Certificate Request Message Format", RFC 2511,		X.509 Certificate Request Message Format", RFC 2511,
	March		March
	1999.		1999.
	[DH] B. Kaliski, "PKCS 3: Diffie-Hellman Key Agreement v1.4"		[DH] B. Kaliski, "PKCS 3: Diffie-Hellman Key Agreement v1.4"
	skipping to change at line 193 ¶		skipping to change at line 179 ¶
	X.509 Certificate Request Message Format", RFC 2511,		X.509 Certificate Request Message Format", RFC 2511,
	March		March
	1999.		1999.
	[DH] B. Kaliski, "PKCS 3: Diffie-Hellman Key Agreement v1.4"		[DH] B. Kaliski, "PKCS 3: Diffie-Hellman Key Agreement v1.4"
	[DH-POP] H. Prafullchandra, J. Schaad, "Diffie-Hellman Proof-of-		[DH-POP] H. Prafullchandra, J. Schaad, "Diffie-Hellman Proof-of-
	Possession Algorithms", Work in Progress.		Possession Algorithms", Work in Progress.
	[HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-		[HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
	Hashing for Message Authentication", RFC 2104, February		Hashing for Message Authentication", RFC 2104, February
	1997.		1997.
	[PKCS1] Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5", RFC		[PKCS1] Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5", RFC
	2313, March 1998.		2313, March 1998.
	[PKCS7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax		[PKCS7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
	v1.5",		v1.5",
	RFC 2315, October 1997.		RFC 2315, October 1997.
	[PKCS8] RSA Laboratories, "PKCS#8: Private-Key Information Syntax		[PKCS8] RSA Laboratories, "PKCS#8: Private-Key Information Syntax
	Standard, Version 1.2", November 1, 1993.		Standard, Version 1.2", November 1, 1993.
	[PKCS10] Kaliski, B., "PKCS #10: Certification Request Syntax		[PKCS10] Kaliski, B., "PKCS #10: Certification Request Syntax
	v1.5", RFC 2314, October 1997.		v1.5", RFC 2314, October 1997.
	[PKIXCERT] Housley, R., Ford, W., Polk, W. and D. Solo "Internet		[PKIXCERT] Housley, R., Ford, W., Polk, W. and D. Solo "Internet
	X.509 Public Key Infrastructure Certificate and CRL		X.509 Public Key Infrastructure Certificate and CRL
	Profile", RFC 2459, January 1999.		Profile", RFC 2459, January 1999.
	[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC 2119] 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.
	[SMIMEV2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and		[SMIMEV2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and
	L.		L.
	Repka, "S/MIME Version 2 Message Specification", RFC		Repka, "S/MIME Version 2 Message Specification", RFC
	2311,		2311,
	March 1998.		March 1998.
	[SMIMEV3] Ramsdell, B., "S/MIME Version 3 Message Specification",		[SMIMEV3] Ramsdell, B., "S/MIME Version 3 Message Specification",
	RFC 2633, June 1999.		RFC 2633, June 1999.
	[X942] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC		[X942] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
	2631, June 1999.		2631, June 1999.
	12. Authors' Addresses		10. Authors' Addresses
			Jim Schaad
			Soaring Hawk Consulting
			EMail: jimsch@exmsft.com
	Michael Myers		Michael Myers
	TraceRoute Security, Inc.		TraceRoute Security, Inc.
	EMail: myers@coastside.net		EMail: myers@coastside.net
	Xiaoyi Liu		Xiaoyi Liu
	Cisco Systems		Cisco Systems
	170 West Tasman Drive		170 West Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	Phone: (480) 526-7430		Phone: (480) 526-7430
	EMail: xliu@cisco.com		EMail: xliu@cisco.com
	Jim Schaad
	Soaring Hawk Consulting
	EMail: jimsch@exmsft.com
	Jeff Weinstein		Jeff Weinstein
	EMail: jsw@meer.net		EMail: jsw@meer.net
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2000). All Rights Reserved.		Copyright (C) The Internet Society (2000). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
End of changes. 25 change blocks.
	52 lines changed or deleted		46 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/