PKIX Working Group J. Schaad Internet-Draft Soaring Hawk Consulting Expires: September 3, 2006 M. Myers TraceRoute Security, Inc. March 2, 2006 CMC Complience Document draft-ietf-pkix-cmc-compl-03 Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 3, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document provides a set of compliance statements about the CMC (Certificate Management over CMS) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents. This document provides the information needed to make a compliant version of CMC Schaad & Myers Expires September 3, 2006 [Page 1] Internet-Draft CMC Complience Document March 2006 1. Overview The CMC (Certificate Management over CMS) protocol is designed in terms of a client/server relationship. In the simplest case the 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 CA). The introduction of an RA (registration authority) into the set of agents complicates the picture only slightly. The RA becomes the server with respect to the certificate requestor, and it becomes the client with respect to the certificate issuer. Any number of RAs can be inserted into the picture in this manner. The RAs may serve specialized purposes that are not currently covered by this document. One such purpose would be a Key Escrow agent. As such all certificate requests for encryption keys would be directed through this RA and it would take appropriate action to do the key archival. Key recovery requests could be defined in the CMC methodology allowing for the Key Escrow agent to perform that operation acting as the final server in the chain of agents. If there are multiple RAs in the system, it is considered normal that not all RAs will see all certificate requests. The routing between the RAs may be dependent on the content of the certificate requests involved This document is divided into six sections, each section specifying the requirements that are specific to a class of agents in the CMC model. These are 1) All agents, 2) all servers, 3) all clients, 4) all End Entities, 5) all Registration Entities, 6) all certificate authorities. Schaad & Myers Expires September 3, 2006 [Page 2] Internet-Draft CMC Complience Document March 2006 2. Terminology There are several different terms, abbreviations and acronyms used in this document that we define here for convenience and consistency of usage: "End-Entity" (EE) refers to the entity that owns a key pair and for whom a certificate is issued. "RA" or "LRA" refers to a (Local) Registration Authority. A registration authority acts as an intermediary between an End- Entity and a Certification Authority. Multiple RAs can exist between the End-Entity and the Certification Authority. "CA" refers to a Certification Authority. A Certification Authority is the entity that performs the actual issuance of a certificate. "Client" refers to an entity that creates a PKI request. In this document both RAs and End-Entities can be clients. "Server" refers to the entities that process PKI requests and create PKI responses. CAs and RAs can be servers in this document. Other documents could define entities such as key escrow agents that could also be serves "PKCS#10" refers the Public Key Cryptography Standard #10. This is one of a set of standards defined by RSA Laboratories in the 1980s. PKCS#10 defines a Certificate Request Message syntax. "CRMF" refers to the Certificate Request Message Format RFC [CRMF]. We are using certificate request message format defined in this document as part of our management protocol. "CMS" refers to the Cryptographic Message Syntax RFC [CMS]. This document provides for basic cryptographic services including encryption and signing with and without key management. "POP" is an acronym for "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 possession and can be used by an end- entity. A discussion on POP can be found in appendix C of [CRMF]. "Transport wrapper" refers to the outermost CMS wrapping layer. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. Schaad & Myers Expires September 3, 2006 [Page 3] Internet-Draft CMC Complience Document March 2006 3. Requirements for All Entities All [CMC-STRUCT] and [CMC-TRANS] compliance statements MUST be adhered to unless specifically stated otherwise in this document. The extendedFailInfo field SHOULD NOT be populated in the CMCStatusInfoExt object; the failInfo field SHOULD be used to relay this information. If the extendedFailInfo field is used, it is suggested that an additional CMCStatusInfoExt item exist for the same body part with a failInfo field. All entities MUST process the following control attributes: id-cmc- statusInfoExt, id-cmc-dataReturn, id-cmc-transactionId, id-cmc- senderNonce, id-cmc-recipientNonce, id-cmc-queryPending, id-cmc- identification, id-cmc-identityProof, id-cmc-idPOPLinkRandom, id-cmc- idPOPLinkWitness, id-cmc-confirmCertAcceptance. All entities SHOULD be able to process the following control attributes: id-cmc-statusInfo, id-cmc-revokeRequest, id-cmc-regInfo, id-cmc-responseInfo. Implementation of the id-cmc-getCert, id-cmc-getCRL, id-cmc- trustRoots, id-cmc-authData and id-cmc-publishCertificate controls is optional. Strong consideration should be given to implementing the id-cmc-authData and id-cmc-trustRoots controls as this gives a simple method for distributing trust anchors into clients without user intervention. All entities MUST implement the HTTP transport mechanism as defined in [CMC-TRANS]. Other transport mechanisms MAY be implemented. 3.1. Cryptographic Algorithm Requirments All entities MUST verify DSA and RSA-SHA1 signatures as defined in [CMS-ALG]. Other signature algorithms MAY be verified. It is strongly suggested that RSA-PSS as defined in [CMS-RSA-PSS] also be verified. It is strongly suggested that SHA-256 using RSA and RSA- PSS also be verified. (Details are found in [RSA-256].) All entities MUST generate either DSA or RSA-SHA1 signatures as defined in [CMS-ALG]. Other signatures algorithms MAY be used for generation. If an entity implements a data encryption algorithm, AES as defined in [CMS-AES] MUST be implemented. Other algorithms MAY be implemented. If an entity implements a key transport algorithm, RSA as defined in Schaad & Myers Expires September 3, 2006 [Page 4] Internet-Draft CMC Complience Document March 2006 [CMS-ALG] MUST be implemented. RSA-OAEP as defined in [CMS-RSA-OAEP] SHOULD be implemented. Other key transport algorithms MAY be implemented. If an entity implements a key agreement algorithm, Diffie-Hellman as defined in [CMS-DH] MUST be implemented. 3.2. CRMF Feature Requirments The following additional restrictions are placed on CRMF features: The registration control tokens id-regCtrl-regToken and id-regCtrl- authToken MUST NOT be used. No specific CMC feature is used to replace these items, but generally the CMC controls identification and identityProof will perform the same service and are more specifically defined. The control token id-regCtrl-pkiArchiveOptions SHOULD NOT be supported. An alternative method is under development to provide this functionality. The behavior of id-regCtrl-oldCertID is not presently used. It is replaced by issuing the new certificate and using the id-cmc- publishCert to remove the old certificate from publication. This operation would not normally be accompanied by an immediate revocation of the old certificate, however that can be accomplished by the id-cmc-revokeRequest control. The id-regCtrl-protocolEncrKey is not used. 3.3. Requirements for Clients All compliant client applications MUST support full enrollment responses. (This allows for error handling not otherwise supported.) Schaad & Myers Expires September 3, 2006 [Page 5] Internet-Draft CMC Complience Document March 2006 4. Requirements for Servers All compliant server applications MUST support CRMF certificate requests. All compliant server applications SHOULD support PKCS10 certificate requests both in the simple and full message formats. Schaad & Myers Expires September 3, 2006 [Page 6] Internet-Draft CMC Complience Document March 2006 5. Requirements for EEs All EE applications MUST support either the simple or full enrollment requests/response pair. All client application SHOULD support the full enrollment request/response pair. When generating full enrollment requests, the CRMF request format is preferred over the PKCS10 request format. 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 challenge-response POP controls id-cmc-encryptedPOP and id-cmc- decryptedPOP. Schaad & Myers Expires September 3, 2006 [Page 7] Internet-Draft CMC Complience Document March 2006 6. Requirements for RAs RAs MUST implement the following controls: id-cmc-modCertTemplate, id-cmc-batchRequests, id-cmc-batchResponses, and id-cmc- controlProcessed. RAs SHOULD implement the id-cmc-addExtensions control. RAs SHOULD be able to do delegated POP. RAs implementing this feature MUST implement the id-cmc-lraPOPWitness control. RAs MUST generate full enrollment requests. All RAs MUST implement the promotion of the id-aa-cmc-unsignedData as covered in section 3.8 of [CMC-STRUCT] Schaad & Myers Expires September 3, 2006 [Page 8] Internet-Draft CMC Complience Document March 2006 7. Requirements for CAs CAs MUST accept PKCS10 certificate requests. CAs MUST accept CRMF certificate requests. CAs MUST implement the Simple Enrollment protocol. CAs MUST implement the Full Enrollment protocol. CAs MUST implement the following additional control attributes: id- cmc-revokeRequest. All CAs designed to work in an environment where RAs are permitted MUST implement the id-cmc-lraPOPWitness, id-cmc- modCertTemplate, id-cmc-batchRequests, id-cmc-BatchResponses controls, and id-cmc-controlProcessed. Such CAs SHOULD also implement the id-cmc-addExtensions control. Implementation of such support is strongly suggested as this permits the delegation of substantial administrative interaction onto an RA rather than at the CA. CAs MUST perform at least minimal checks on all public keys before issuing a certificate. At a minimum a check for syntax would occur with the POP operation. Additionally CAs SHOULD perform simple checks for known bad keys such as small subgroups for DSA and DH keys [SMALL-SUBGROUPS] or known bad exponents for RSA keys (i.e. 3). CAs MUST enforce POP checking before issuing any certificate. CAs 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 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. 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- encryptedPOP and id-cmc-decryptedPOP. Schaad & Myers Expires September 3, 2006 [Page 9] Internet-Draft CMC Complience Document March 2006 8. Security Considerations This document uses [CMC-STRUCT] and [CMC-TRANS] as building blocks to this document. The security sections of those two documents are included by reference. Knowledge of how an entity is expected to operate is vital in determining which sections of requirements are appliciable to that entity. Care needs to be taken in determining which sections apply and fulling implmenting the necessary code. Cryptographic algorithms have and will be broken or weakened. Implementers and users need to check that the cryptographic algorithms listed in this document make sense from a security level. The IETF from time to time may issue documents dealing with the current state of the art. Two examples of such documents are [SMALL- SUB-GROUP] and [HASH-ATTACKS]. Schaad & Myers Expires September 3, 2006 [Page 10] Internet-Draft CMC Complience Document March 2006 9. IANA Considerations There are no IANA considerations in this document. Schaad & Myers Expires September 3, 2006 [Page 11] Internet-Draft CMC Complience Document March 2006 10. Acknowledgements The authors and the Working Group are greatful for the participation of Xiaoui Lui and Jeff Weinstein in helping to author the original versions of this document. The authors would like to thank Brian LaMacchia for his work in developing and writing up many of the concepts presented in this document. The authors would also like to thank Alex Deacon and Barb Fox for their contributions. Schaad & Myers Expires September 3, 2006 [Page 12] Internet-Draft CMC Complience Document March 2006 11. References 11.1. Nomative References [CMC-STRUCT] Schaad, J., Myers, M., Liu, X., and J. Weinstein, "Certificate Management Messages over CMS", Work in Progress , December 2004. [CMC-TRANS] Schaad, J., Myers, M., Liu, X., and J. Weinstein, "CMC Transport", Work In Progress , December 2004. [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004. [CMS-AES] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003. [CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002. [CMS-DH] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999. [CRMF] Schaad, J., "Internet X.509 Certificate Request M2essage Format", RFC 4211, September 2005. [CMS-RSA-OAEP] Housley, R., "Use of the RSAES-OAEP Key Transport Algorithm in the Cryptographic Message Syntax (CMS)", RFC 3560, July 2003. [CMS-RSA-PSS] Schaad, J., "Use of the RSA PSS Signature Algorithm in CMS", Work In Progress , December 2003. [DH-POP] Prafullchandra, H. and J. Schaad, "Diffie-Hellman Proof- of-Possession Algorithms", RFC 2875, June 2000. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [RSA-256] Schaad, J., "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", Work in Progress , July 2004. Schaad & Myers Expires September 3, 2006 [Page 13] Internet-Draft CMC Complience Document March 2006 11.2. Informational References [SMALL-SUB-GROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME", RFC 2785, March 2000. [HASH-ATTACKS] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005. Schaad & Myers Expires September 3, 2006 [Page 14] Internet-Draft CMC Complience Document March 2006 Authors' Addresses Jim Schaad Soaring Hawk Consulting PO Box 675 Gold Bar, WA 98251 Phone: (425) 785-1031 Email: jimsch@exmsft.com Michael Myers TraceRoute Security, Inc. Email: myers@coastside.inc Schaad & Myers Expires September 3, 2006 [Page 15] Internet-Draft CMC Complience Document March 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Schaad & Myers Expires September 3, 2006 [Page 16]