< draft-ietf-pkix-cmc-compl-04.txt		draft-ietf-pkix-cmc-compl-05.txt >
	PKIX Working Group J. Schaad		PKIX Working Group J. Schaad
	Internet-Draft Soaring Hawk Consulting		Internet-Draft Soaring Hawk Consulting
	Expires: May 22, 2008 M. Myers		Expires: June 6, 2008 M. Myers
	TraceRoute Security, Inc.		TraceRoute Security, Inc.
	November 19, 2007		December 4, 2007
	CMC Compliance Document		Certificate Managmement Messages over CMS (CMC): Complience Requirements
	draft-ietf-pkix-cmc-compl-04		draft-ietf-pkix-cmc-compl-05
	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 May 22, 2008.		This Internet-Draft will expire on June 6, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document provides a set of compliance statements about the CMC		This document provides a set of compliance statements about the CMC
	(Certificate Management over CMS) enrollment protocol. The ASN.1		(Certificate Management over CMS) enrollment protocol. The ASN.1
	structures and the transport mechanisms for the CMC enrollment		structures and the transport mechanisms for the CMC enrollment
	protocol are covered in other documents. This document provides the		protocol are covered in other documents. This document provides the
	information needed to make a compliant version of CMC.		information needed to make a compliant version of CMC.
	Table of Contents		Table of Contents
	1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Requirements for All Entities . . . . . . . . . . . . . . . . 6		3. Requirements Terminology . . . . . . . . . . . . . . . . . . . 6
	3.1. Cryptographic Algorithm Requirements . . . . . . . . . . . 6		4. Requirements for All Entities . . . . . . . . . . . . . . . . 7
	3.2. Controls . . . . . . . . . . . . . . . . . . . . . . . . . 7		4.1. Cryptographic Algorithm Requirements . . . . . . . . . . . 7
	3.3. CRMF Feature Requirements . . . . . . . . . . . . . . . . 9		4.2. Controls . . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.4. Requirements for Clients . . . . . . . . . . . . . . . . . 10		4.3. CRMF Feature Requirements . . . . . . . . . . . . . . . . 10
	4. Requirements for Servers . . . . . . . . . . . . . . . . . . . 11		4.4. Requirements for Clients . . . . . . . . . . . . . . . . . 11
	5. Requirements for EEs . . . . . . . . . . . . . . . . . . . . . 12		5. Requirements for Servers . . . . . . . . . . . . . . . . . . . 12
	6. Requirements for RAs . . . . . . . . . . . . . . . . . . . . . 13		6. Requirements for EEs . . . . . . . . . . . . . . . . . . . . . 13
	7. Requirements for CAs . . . . . . . . . . . . . . . . . . . . . 14		7. Requirements for RAs . . . . . . . . . . . . . . . . . . . . . 14
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 15		8. Requirements for CAs . . . . . . . . . . . . . . . . . . . . . 15
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 18		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	11.2. Informational References . . . . . . . . . . . . . . . . . 19		12.1. Normative References . . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20		12.2. Informational References . . . . . . . . . . . . . . . . . 20
	Intellectual Property and Copyright Statements . . . . . . . . . . 21		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
			Intellectual Property and Copyright Statements . . . . . . . . . . 22
	1. Overview		1. Overview
	The CMC (Certificate Management over CMS) protocol is designed in		The CMC (Certificate Management over CMS) protocol is designed in
	terms of a client/server relationship. In the simplest case the		terms of a client/server relationship. In the simplest case the
	client is the requestor of the certificate (i.e. the End Entity or		client is the requestor of the certificate (i.e. the End Entity or
	EE) and the server is the issuer of the certificate (i.e. the		EE) and the server is the issuer of the certificate (i.e. the
	Certificate Authority(CA)). The introduction of an RA (registration		Certificate Authority(CA)). The introduction of an RA (registration
	authority) into the set of agents complicates the picture only		authority) into the set of agents complicates the picture only
	slightly. The RA becomes the server with respect to the certificate		slightly. The RA becomes the server with respect to the certificate
	skipping to change at page 5, line 7 ¶		skipping to change at page 6, line 5 ¶
	Proof-Of-Identity refers to the client proving they are who they say		Proof-Of-Identity refers to the client proving they are who they say
	that are to the server.		that are to the server.
	Proof-Of-Possession (POP) refers to a value that can be used to		Proof-Of-Possession (POP) refers to a value that can be used to
	prove that the private key corresponding to a public key is in the		prove that the private key corresponding to a public key is in the
	possession and can be used by an end-entity.		possession and can be used by an end-entity.
	Transport wrapper refers to the outermost CMS wrapping layer.		Transport wrapper refers to the outermost CMS wrapping layer.
			3. 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 [MUST].
	3. Requirements for All Entities		4. Requirements for All Entities
	All [CMC-STRUCT] and [CMC-TRANS] compliance statements MUST be		All [CMC-STRUCT] and [CMC-TRANS] compliance statements MUST be
	adhered to unless specifically stated otherwise in this document.		adhered to unless specifically stated otherwise in this document.
	All entities MUST support Full PKI Requests, Simple PKI Responses and		All entities MUST support Full PKI Requests, Simple PKI Responses and
	Full PKI Responses. Severs SHOULD support Simple PKI Requests.		Full PKI Responses. Severs SHOULD support Simple PKI Requests.
	All entities MUST support the use of the CRMF syntax for		All entities MUST support the use of the CRMF syntax for
	certification requests. Support for the PKCS#10 syntax for		certification requests. Support for the PKCS#10 syntax for
	certification requests SHOULD be implemented by servers.		certification requests SHOULD be implemented by servers.
	The extendedFailInfo field SHOULD NOT be populated in the		The extendedFailInfo field SHOULD NOT be populated in the
	CMCStatusInfoExt object; the failInfo field SHOULD be used to relay		CMCStatusInfoExt object; the failInfo field SHOULD be used to relay
	this information. If the extendedFailInfo field is used, it is		this information. If the extendedFailInfo field is used, it is
	suggested that an additional CMCStatusInfoExt item exist for the same		suggested that an additional CMCStatusInfoExt item exist for the same
	body part with a failInfo field.		body part with a failInfo field.
	All entities MUST implement the HTTP transport mechanism as defined		All entities MUST implement the HTTP transport mechanism as defined
	in [CMC-TRANS]. Other transport mechanisms MAY be implemented.		in [CMC-TRANS]. Other transport mechanisms MAY be implemented.
	3.1. Cryptographic Algorithm Requirements		4.1. Cryptographic Algorithm Requirements
	All entities MUST verify DSA-SHA1 and RSA-SHA1 signatures in		All entities MUST verify DSA-SHA1 and RSA-SHA1 signatures in
	SignedData (see [CMS-ALG]). Entities MAY be verify other signature		SignedData (see [CMS-ALG]). Entities MAY be verify other signature
	algorithms. It is strongly suggested that RSA-PSS with SHA-1 be		algorithms. It is strongly suggested that RSA-PSS with SHA-1 be
	verified (see [CMS-RSA-PSS]). It is strongly suggested that SHA-256		verified (see [CMS-RSA-PSS]). It is strongly suggested that SHA-256
	using RSA and RSA-PSS be verified (see [RSA-256]).		using RSA and RSA-PSS be verified (see [RSA-256]).
	All entities MUST generate either DSA-SHA1 or RSA-SHA1 signatures for		All entities MUST generate either DSA-SHA1 or RSA-SHA1 signatures for
	SignedData (see [CMS-ALG]). Other signatures algorithms MAY be used		SignedData (see [CMS-ALG]). Other signatures algorithms MAY be used
	for generation.		for generation.
	skipping to change at page 6, line 52 ¶		skipping to change at page 7, line 52 ¶
	All entities MUST support RSA as a key transport algorithm for		All entities MUST support RSA as a key transport algorithm for
	EnvelopedData (see [CMS-ALG]). All entities SHOULD support RSA-OAEP		EnvelopedData (see [CMS-ALG]). All entities SHOULD support RSA-OAEP
	(see [CMS-RSA-OAEP]) as a key transport algorithm. Other key		(see [CMS-RSA-OAEP]) as a key transport algorithm. Other key
	transport algorithms MAY be implemented.		transport algorithms MAY be implemented.
	If an entity supports key agreement for EnvelopedData, they MUST		If an entity supports key agreement for EnvelopedData, they MUST
	support Diffie-Hellman (see [CMS-DH]).		support Diffie-Hellman (see [CMS-DH]).
	If an entity supports PasswordRecipientInfo for EnvelopedData or		If an entity supports PasswordRecipientInfo for EnvelopedData or
	AuthenticatedData, they MUST support PBKDF2 for key derivation		AuthenticatedData, they MUST support PBKDF2 for key derivation
	algorithms. They MUST support AES key wrap (see [RFC3394] as the key		algorithms. They MUST support AES key wrap (see [AES-WRAP] as the
	encryption algorithm.		key encryption algorithm.
	If AuthenticatedData is supported, PasswordRecipientInfo MUST be		If AuthenticatedData is supported, PasswordRecipientInfo MUST be
	supported.		supported.
	Algorithm requirements for the Identity Proof Version 2 control		Algorithm requirements for the Identity Proof Version 2 control
	(Section 6.2.1 of [CMC-STRUCT]) are: SHA-1 MUST be implemented for		(Section 6.2.1 of [CMC-STRUCT]) are: SHA-1 MUST be implemented for
	hashAlgId. SHA-256 SHOULD be implemented for hashAlgId. HMAC-SHA1		hashAlgId. SHA-256 SHOULD be implemented for hashAlgId. HMAC-SHA1
	MUST be implemented for macAlgId. HMAC-SHA256 SHOULD be implemented		MUST be implemented for macAlgId. HMAC-SHA256 SHOULD be implemented
	for macAlgId.		for macAlgId.
	skipping to change at page 7, line 43 ¶		skipping to change at page 8, line 43 ¶
	4 of [DH-POP]. EEs MAY support section 3 of [DH-POP]. CAs and RAs		4 of [DH-POP]. EEs MAY support section 3 of [DH-POP]. CAs and RAs
	that do POP verification MUST support section 4 of [DH-POP] and		that do POP verification MUST support section 4 of [DH-POP] and
	SHOULD support section 3 of [DH-POP].		SHOULD support section 3 of [DH-POP].
	EEs that need to use a signature algorithm for keys that cannot		EEs that need to use a signature algorithm for keys that cannot
	produce a signature MUST support Appendix C of [CMC-STRUCT] and MUST		produce a signature MUST support Appendix C of [CMC-STRUCT] and MUST
	support the Encrypted/Decrypted POP controls. CAs and RAs that do		support the Encrypted/Decrypted POP controls. CAs and RAs that do
	POP verification MUST support this signature algorithm and MUST		POP verification MUST support this signature algorithm and MUST
	support the Encrypted/Decrypted POP controls.		support the Encrypted/Decrypted POP controls.
	3.2. Controls		4.2. Controls
	The following table lists the name and level of support required for		The following table lists the name and level of support required for
	each control.		each control.
	+----------------------------+----------+----------+----------+		+----------------------------+----------+----------+----------+
	| Control | EE | RA | CA |		| Control | EE | RA | CA |
	+----------------------------+----------+----------+----------+		+----------------------------+----------+----------+----------+
	| Extended CMC Status Info | MUST | MUST | MUST |		| Extended CMC Status Info | MUST | MUST | MUST |
	| CMC Status Info | SHOULD | SHOULD | SHOULD |		| CMC Status Info | SHOULD | SHOULD | SHOULD |
	| | | | |		| | | | |
	skipping to change at page 9, line 38 ¶		skipping to change at page 10, line 38 ¶
	algorithms or (b) they need to operate in environments where the		algorithms or (b) they need to operate in environments where the
	hardware keys cannot provide POP.		hardware keys cannot provide POP.
	5. RAs SHOULD implement this if they implement RA POP Witness.		5. RAs SHOULD implement this if they implement RA POP Witness.
	Strong consideration should be given to implementing the Authenticate		Strong consideration should be given to implementing the Authenticate
	Data and Publish Trust Anchors controls as this gives a simple method		Data and Publish Trust Anchors controls as this gives a simple method
	for distributing trust anchors into clients without user		for distributing trust anchors into clients without user
	intervention.		intervention.
	3.3. CRMF Feature Requirements		4.3. CRMF Feature Requirements
	The following additional restrictions are placed on CRMF features:		The following additional restrictions are placed on CRMF features:
	The registration control tokens id-regCtrl-regToken and id-regCtrl-		The registration control tokens id-regCtrl-regToken and id-regCtrl-
	authToken MUST NOT be used. No specific CMC feature is used to		authToken MUST NOT be used. No specific CMC feature is used to
	replace these items, but generally the CMC controls identification		replace these items, but generally the CMC controls identification
	and identityProof will perform the same service and are more		and identityProof will perform the same service and are more
	specifically defined.		specifically defined.
	The control token id-regCtrl-pkiArchiveOptions SHOULD NOT be		The control token id-regCtrl-pkiArchiveOptions SHOULD NOT be
	skipping to change at page 10, line 14 ¶		skipping to change at page 11, line 14 ¶
	The behavior of id-regCtrl-oldCertID is not presently used. It is		The behavior of id-regCtrl-oldCertID is not presently used. It is
	replaced by issuing the new certificate and using the id-cmc-		replaced by issuing the new certificate and using the id-cmc-
	publishCert to remove the old certificate from publication. This		publishCert to remove the old certificate from publication. This
	operation would not normally be accompanied by an immediate		operation would not normally be accompanied by an immediate
	revocation of the old certificate, however that can be accomplished		revocation of the old certificate, however that can be accomplished
	by the id-cmc-revokeRequest control.		by the id-cmc-revokeRequest control.
	The id-regCtrl-protocolEncrKey is not used.		The id-regCtrl-protocolEncrKey is not used.
	3.4. Requirements for Clients		4.4. Requirements for Clients
	No additional requirements.		No additional requirements.
	4. Requirements for Servers		5. Requirements for Servers
	No additional requirements.		No additional requirements.
	5. Requirements for EEs		6. Requirements for EEs
	If an entity implements Diffie-Hellman, it MUST implement either the		If an entity implements Diffie-Hellman, it MUST implement either the
	DH-POP Proof-of-Possession as defined in [DH-POP] Section 4 or the		DH-POP Proof-of-Possession as defined in [DH-POP] Section 4 or the
	challenge-response POP controls id-cmc-encryptedPOP and id-cmc-		challenge-response POP controls id-cmc-encryptedPOP and id-cmc-
	decryptedPOP.		decryptedPOP.
	6. Requirements for RAs		7. Requirements for RAs
	RAs SHOULD be able to do delegated POP. RAs implementing this		RAs SHOULD be able to do delegated POP. RAs implementing this
	feature MUST implement the id-cmc-lraPOPWitness control.		feature MUST implement the id-cmc-lraPOPWitness control.
	All RAs MUST implement the promotion of the id-aa-cmc-unsignedData as		All RAs MUST implement the promotion of the id-aa-cmc-unsignedData as
	covered in section 3.8 of [CMC-STRUCT]		covered in section 3.8 of [CMC-STRUCT]
	7. Requirements for CAs		8. Requirements for CAs
	Providing for CAs to work in an environment with RAs is strongly		Providing for CAs to work in an environment with RAs is strongly
	suggested. Implementation of such support is strongly suggested as		suggested. Implementation of such support is strongly suggested as
	this permits the delegation of substantial administrative interaction		this permits the delegation of substantial administrative interaction
	onto an RA rather than at the CA.		onto an RA rather than at the CA.
	CAs MUST perform at least minimal checks on all public keys before		CAs MUST perform at least minimal checks on all public keys before
	issuing a certificate. At a minimum a check for syntax would occur		issuing a certificate. At a minimum a check for syntax would occur
	with the POP operation. Additionally CAs SHOULD perform simple		with the POP operation. Additionally CAs SHOULD perform simple
	checks for known bad keys such as small subgroups for DSA-SHA1 and DH		checks for known bad keys such as small subgroups for DSA-SHA1 and DH
	skipping to change at page 15, line 5 ¶		skipping to change at page 16, line 5 ¶
	CAs MUST enforce POP checking before issuing any certificate. CAs		CAs MUST enforce POP checking before issuing any certificate. CAs
	MAY delegate the POP operation to an RA for those cases where 1) a		MAY delegate the POP operation to an RA for those cases where 1) a
	challenge/response message pair must be used, 2) an RA performs		challenge/response message pair must be used, 2) an RA performs
	escrow of a key and checks for POP in that manner or 3) an unusual		escrow of a key and checks for POP in that manner or 3) an unusual
	algorithm is used and that validation is done at the RA.		algorithm is used and that validation is done at the RA.
	CAs SHOULD implement both the DH-POP Proof-of-Possession as defined		CAs SHOULD implement both the DH-POP Proof-of-Possession as defined
	in [DH-POP] Section 4 and the challenge-response POP controls id-cmc-		in [DH-POP] Section 4 and the challenge-response POP controls id-cmc-
	encryptedPOP and id-cmc-decryptedPOP.		encryptedPOP and id-cmc-decryptedPOP.
	8. Security Considerations		9. Security Considerations
	This document uses [CMC-STRUCT] and [CMC-TRANS] as building blocks to		This document uses [CMC-STRUCT] and [CMC-TRANS] as building blocks to
	this document. The security sections of those two documents are		this document. The security sections of those two documents are
	included by reference.		included by reference.
	Knowledge of how an entity is expected to operate is vital in		Knowledge of how an entity is expected to operate is vital in
	determining which sections of requirements are applicable to that		determining which sections of requirements are applicable to that
	entity. Care needs to be taken in determining which sections apply		entity. Care needs to be taken in determining which sections apply
	and fullly implementing the necessary code.		and fullly implementing the necessary code.
	Cryptographic algorithms have and will be broken or weakened.		Cryptographic algorithms have and will be broken or weakened.
	Implementers and users need to check that the cryptographic		Implementers and users need to check that the cryptographic
	algorithms listed in this document make sense from a security level.		algorithms listed in this document make sense from a security level.
	The IETF from time to time may issue documents dealing with the		The IETF from time to time may issue documents dealing with the
	current state of the art. Two examples of such documents are		current state of the art. Two examples of such documents are
	[SMALL-SUB-GROUP] and [HASH-ATTACKS].		[SMALL-SUB-GROUP] and [HASH-ATTACKS].
	9. IANA Considerations		10. IANA Considerations
	There are no IANA considerations in this document.		There are no IANA considerations in this document.
	10. Acknowledgements		11. Acknowledgements
	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.
	11. References		12. References
	11.1. Normative References		12.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 , August 2006.		over CMS", draft-ietf-pkix-2797-bis-05.txt , August 2006.
	[CMC-TRANS]		[CMC-TRANS]
	Schaad, J., Myers, M., Liu, X., and J. Weinstein, "CMC		Schaad, J., Myers, M., Liu, X., and J. Weinstein, "CMC
	Transport", Work In Progress , December 2004.		Transport", Work In Progress , December 2004.
	[CMS] Housley, R., "Cryptographic Message Syntax (CMS)",		[CMS] Housley, R., "Cryptographic Message Syntax (CMS)",
	skipping to change at page 18, line 45 ¶		skipping to change at page 19, line 45 ¶
	Algorithm in the Cryptographic Message Syntax (CMS)",		Algorithm in the Cryptographic Message Syntax (CMS)",
	RFC 3560, July 2003.		RFC 3560, July 2003.
	[CMS-RSA-PSS]		[CMS-RSA-PSS]
	Schaad, J., "Use of the RSA PSS Signature Algorithm in		Schaad, J., "Use of the RSA PSS Signature Algorithm in
	CMS", Work In Progress , December 2003.		CMS", Work In Progress , December 2003.
	[DH-POP] Prafullchandra, H. and J. Schaad, "Diffie-Hellman Proof-		[DH-POP] Prafullchandra, H. and J. Schaad, "Diffie-Hellman Proof-
	of-Possession Algorithms", RFC 2875, June 2000.		of-Possession Algorithms", RFC 2875, June 2000.
	[RFC2119] 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.
	[RSA-256] Schaad, J., Kaliski, B., and R. Housley, "Additional		[RSA-256] Schaad, J., Kaliski, B., and R. Housley, "Additional
	Algorithms and Identifiers for RSA Cryptography for use in		Algorithms and Identifiers for RSA Cryptography for use in
	the Internet X.509 Public Key Infrastructure Certificate		the Internet X.509 Public Key Infrastructure Certificate
	and Certificate Revocation List (CRL) Profile", RFC 4055,		and Certificate Revocation List (CRL) Profile", RFC 4055,
	June 2005.		June 2005.
	[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard		[AES-WRAP]
			Schaad, J. and R. Housley, "Advanced Encryption Standard
	(AES) Key Wrap Algorithm", RFC 3394, September 2002.		(AES) Key Wrap Algorithm", RFC 3394, September 2002.
	11.2. Informational References		12.2. Informational References
	[PKCS10] Kaliski, B., "PKCS #10: Certification Request Syntax		[PKCS10] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
	v1.5", RFC 2314, October 1997.		Request Syntax Specification v1.7", RFC 2986,
			November 2000.
	[SMALL-SUB-GROUP]		[SMALL-SUB-GROUP]
	Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"		Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
	Attacks on the Diffie-Hellman Key Agreement Method for		Attacks on the Diffie-Hellman Key Agreement Method for
	S/MIME", RFC 2785, March 2000.		S/MIME", RFC 2785, March 2000.
	[HASH-ATTACKS]		[HASH-ATTACKS]
	Hoffman, P. and B. Schneier, "Attacks on Cryptographic		Hoffman, P. and B. Schneier, "Attacks on Cryptographic
	Hashes in Internet Protocols", RFC 4270, November 2005.		Hashes in Internet Protocols", RFC 4270, November 2005.
	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
	Phone: (425) 785-1031		Phone: (425) 785-1031
	Email: jimsch@exmsft.com		Email: jimsch@nwlink.com
	Michael Myers		Michael Myers
	TraceRoute Security, Inc.		TraceRoute Security, Inc.
	Email: myers@fastq.com		Email: mmyers@fastq.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	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
End of changes. 28 change blocks.
	46 lines changed or deleted		51 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/