idnits 2.17.1 draft-ietf-pkix-cmc-compl-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 421. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 398. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 405. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 411. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2, 2006) is 6623 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CRMF' is mentioned on line 340, but not defined == Missing Reference: 'CMS' is mentioned on line 327, but not defined == Missing Reference: 'RFC 2119' is mentioned on line 127, but not defined == Missing Reference: 'CMC-STRUCT' is mentioned on line 318, but not defined == Missing Reference: 'CMC-TRANS' is mentioned on line 323, but not defined == Missing Reference: 'CMS-ALG' is mentioned on line 334, but not defined == Missing Reference: 'CMS-RSA-PSS' is mentioned on line 348, but not defined == Missing Reference: 'RSA-256' is mentioned on line 358, but not defined == Missing Reference: 'CMS-AES' is mentioned on line 330, but not defined == Missing Reference: 'CMS-RSA-OAEP' is mentioned on line 343, but not defined == Missing Reference: 'CMS-DH' is mentioned on line 337, but not defined == Missing Reference: 'DH-POP' is mentioned on line 352, but not defined == Missing Reference: 'SMALL-SUBGROUPS' is mentioned on line 269, but not defined == Missing Reference: 'RFC2119' is mentioned on line 355, but not defined Summary: 3 errors (**), 0 flaws (~~), 16 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group J. Schaad 3 Internet-Draft Soaring Hawk Consulting 4 Expires: September 3, 2006 M. Myers 5 TraceRoute Security, Inc. 6 March 2, 2006 8 CMC Complience Document 9 draft-ietf-pkix-cmc-compl-03 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 3, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document provides a set of compliance statements about the CMC 43 (Certificate Management over CMS) enrollment protocol. The ASN.1 44 structures and the transport mechanisms for the CMC enrollment 45 protocol are covered in other documents. This document provides the 46 information needed to make a compliant version of CMC 48 1. Overview 50 The CMC (Certificate Management over CMS) protocol is designed in 51 terms of a client/server relationship. In the simplest case the 52 client is the requestor of the certificate (i.e. the End Entity or 53 EE) and the server is the issuer of the certificate (i.e. the CA). 54 The introduction of an RA (registration authority) into the set of 55 agents complicates the picture only slightly. The RA becomes the 56 server with respect to the certificate requestor, and it becomes the 57 client with respect to the certificate issuer. Any number of RAs can 58 be inserted into the picture in this manner. 60 The RAs may serve specialized purposes that are not currently covered 61 by this document. One such purpose would be a Key Escrow agent. As 62 such all certificate requests for encryption keys would be directed 63 through this RA and it would take appropriate action to do the key 64 archival. Key recovery requests could be defined in the CMC 65 methodology allowing for the Key Escrow agent to perform that 66 operation acting as the final server in the chain of agents. 68 If there are multiple RAs in the system, it is considered normal that 69 not all RAs will see all certificate requests. The routing between 70 the RAs may be dependent on the content of the certificate requests 71 involved 73 This document is divided into six sections, each section specifying 74 the requirements that are specific to a class of agents in the CMC 75 model. These are 1) All agents, 2) all servers, 3) all clients, 4) 76 all End Entities, 5) all Registration Entities, 6) all certificate 77 authorities. 79 2. Terminology 81 There are several different terms, abbreviations and acronyms used in 82 this document that we define here for convenience and consistency of 83 usage: 85 "End-Entity" (EE) refers to the entity that owns a key pair and 86 for whom a certificate is issued. 88 "RA" or "LRA" refers to a (Local) Registration Authority. A 89 registration authority acts as an intermediary between an End- 90 Entity and a Certification Authority. Multiple RAs can exist 91 between the End-Entity and the Certification Authority. 93 "CA" refers to a Certification Authority. A Certification 94 Authority is the entity that performs the actual issuance of a 95 certificate. 97 "Client" refers to an entity that creates a PKI request. In this 98 document both RAs and End-Entities can be clients. 100 "Server" refers to the entities that process PKI requests and 101 create PKI responses. CAs and RAs can be servers in this 102 document. Other documents could define entities such as key 103 escrow agents that could also be serves 105 "PKCS#10" refers the Public Key Cryptography Standard #10. This 106 is one of a set of standards defined by RSA Laboratories in the 107 1980s. PKCS#10 defines a Certificate Request Message syntax. 109 "CRMF" refers to the Certificate Request Message Format RFC 110 [CRMF]. We are using certificate request message format defined 111 in this document as part of our management protocol. 113 "CMS" refers to the Cryptographic Message Syntax RFC [CMS]. This 114 document provides for basic cryptographic services including 115 encryption and signing with and without key management. 117 "POP" is an acronym for "Proof of Possession". POP refers to a 118 value that can be used to prove that the private key corresponding 119 to a public key is in the possession and can be used by an end- 120 entity. A discussion on POP can be found in appendix C of [CRMF]. 122 "Transport wrapper" refers to the outermost CMS wrapping layer. 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC 2119]. 128 3. Requirements for All Entities 130 All [CMC-STRUCT] and [CMC-TRANS] compliance statements MUST be 131 adhered to unless specifically stated otherwise in this document. 133 The extendedFailInfo field SHOULD NOT be populated in the 134 CMCStatusInfoExt object; the failInfo field SHOULD be used to relay 135 this information. If the extendedFailInfo field is used, it is 136 suggested that an additional CMCStatusInfoExt item exist for the same 137 body part with a failInfo field. 139 All entities MUST process the following control attributes: id-cmc- 140 statusInfoExt, id-cmc-dataReturn, id-cmc-transactionId, id-cmc- 141 senderNonce, id-cmc-recipientNonce, id-cmc-queryPending, id-cmc- 142 identification, id-cmc-identityProof, id-cmc-idPOPLinkRandom, id-cmc- 143 idPOPLinkWitness, id-cmc-confirmCertAcceptance. 145 All entities SHOULD be able to process the following control 146 attributes: id-cmc-statusInfo, id-cmc-revokeRequest, id-cmc-regInfo, 147 id-cmc-responseInfo. 149 Implementation of the id-cmc-getCert, id-cmc-getCRL, id-cmc- 150 trustRoots, id-cmc-authData and id-cmc-publishCertificate controls is 151 optional. Strong consideration should be given to implementing the 152 id-cmc-authData and id-cmc-trustRoots controls as this gives a simple 153 method for distributing trust anchors into clients without user 154 intervention. 156 All entities MUST implement the HTTP transport mechanism as defined 157 in [CMC-TRANS]. Other transport mechanisms MAY be implemented. 159 3.1. Cryptographic Algorithm Requirments 161 All entities MUST verify DSA and RSA-SHA1 signatures as defined in 162 [CMS-ALG]. Other signature algorithms MAY be verified. It is 163 strongly suggested that RSA-PSS as defined in [CMS-RSA-PSS] also be 164 verified. It is strongly suggested that SHA-256 using RSA and RSA- 165 PSS also be verified. (Details are found in [RSA-256].) 167 All entities MUST generate either DSA or RSA-SHA1 signatures as 168 defined in [CMS-ALG]. Other signatures algorithms MAY be used for 169 generation. 171 If an entity implements a data encryption algorithm, AES as defined 172 in [CMS-AES] MUST be implemented. Other algorithms MAY be 173 implemented. 175 If an entity implements a key transport algorithm, RSA as defined in 177 [CMS-ALG] MUST be implemented. RSA-OAEP as defined in [CMS-RSA-OAEP] 178 SHOULD be implemented. Other key transport algorithms MAY be 179 implemented. 181 If an entity implements a key agreement algorithm, Diffie-Hellman as 182 defined in [CMS-DH] MUST be implemented. 184 3.2. CRMF Feature Requirments 186 The following additional restrictions are placed on CRMF features: 188 The registration control tokens id-regCtrl-regToken and id-regCtrl- 189 authToken MUST NOT be used. No specific CMC feature is used to 190 replace these items, but generally the CMC controls identification 191 and identityProof will perform the same service and are more 192 specifically defined. 194 The control token id-regCtrl-pkiArchiveOptions SHOULD NOT be 195 supported. An alternative method is under development to provide 196 this functionality. 198 The behavior of id-regCtrl-oldCertID is not presently used. It is 199 replaced by issuing the new certificate and using the id-cmc- 200 publishCert to remove the old certificate from publication. This 201 operation would not normally be accompanied by an immediate 202 revocation of the old certificate, however that can be accomplished 203 by the id-cmc-revokeRequest control. 205 The id-regCtrl-protocolEncrKey is not used. 207 3.3. Requirements for Clients 209 All compliant client applications MUST support full enrollment 210 responses. (This allows for error handling not otherwise supported.) 212 4. Requirements for Servers 214 All compliant server applications MUST support CRMF certificate 215 requests. All compliant server applications SHOULD support PKCS10 216 certificate requests both in the simple and full message formats. 218 5. Requirements for EEs 220 All EE applications MUST support either the simple or full enrollment 221 requests/response pair. All client application SHOULD support the 222 full enrollment request/response pair. 224 When generating full enrollment requests, the CRMF request format is 225 preferred over the PKCS10 request format. 227 If an entity implements Diffie-Hellman, it MUST implement either the 228 DH-POP Proof-of-Possession as defined in [DH-POP] Section 4 or the 229 challenge-response POP controls id-cmc-encryptedPOP and id-cmc- 230 decryptedPOP. 232 6. Requirements for RAs 234 RAs MUST implement the following controls: id-cmc-modCertTemplate, 235 id-cmc-batchRequests, id-cmc-batchResponses, and id-cmc- 236 controlProcessed. RAs SHOULD implement the id-cmc-addExtensions 237 control. 239 RAs SHOULD be able to do delegated POP. RAs implementing this 240 feature MUST implement the id-cmc-lraPOPWitness control. 242 RAs MUST generate full enrollment requests. 244 All RAs MUST implement the promotion of the id-aa-cmc-unsignedData as 245 covered in section 3.8 of [CMC-STRUCT] 247 7. Requirements for CAs 249 CAs MUST accept PKCS10 certificate requests. CAs MUST accept CRMF 250 certificate requests. 252 CAs MUST implement the Simple Enrollment protocol. CAs MUST 253 implement the Full Enrollment protocol. 255 CAs MUST implement the following additional control attributes: id- 256 cmc-revokeRequest. All CAs designed to work in an environment where 257 RAs are permitted MUST implement the id-cmc-lraPOPWitness, id-cmc- 258 modCertTemplate, id-cmc-batchRequests, id-cmc-BatchResponses 259 controls, and id-cmc-controlProcessed. Such CAs SHOULD also 260 implement the id-cmc-addExtensions control. Implementation of such 261 support is strongly suggested as this permits the delegation of 262 substantial administrative interaction onto an RA rather than at the 263 CA. 265 CAs MUST perform at least minimal checks on all public keys before 266 issuing a certificate. At a minimum a check for syntax would occur 267 with the POP operation. Additionally CAs SHOULD perform simple 268 checks for known bad keys such as small subgroups for DSA and DH keys 269 [SMALL-SUBGROUPS] or known bad exponents for RSA keys (i.e. 3). 271 CAs MUST enforce POP checking before issuing any certificate. CAs 272 MAY delegate the POP operation to an RA for those cases where 1) a 273 challenge/response message pair must be used, 2) an RA performs 274 escrow of a key and checks for POP in that manner or 3) an unusual 275 algorithm is used and that validation is done at the RA. 277 CAs SHOULD implement both the DH-POP Proof-of-Possession as defined 278 in [DH-POP] Section 4 and the challenge-response POP controls id-cmc- 279 encryptedPOP and id-cmc-decryptedPOP. 281 8. Security Considerations 283 This document uses [CMC-STRUCT] and [CMC-TRANS] as building blocks to 284 this document. The security sections of those two documents are 285 included by reference. 287 Knowledge of how an entity is expected to operate is vital in 288 determining which sections of requirements are appliciable to that 289 entity. Care needs to be taken in determining which sections apply 290 and fulling implmenting the necessary code. 292 Cryptographic algorithms have and will be broken or weakened. 293 Implementers and users need to check that the cryptographic 294 algorithms listed in this document make sense from a security level. 295 The IETF from time to time may issue documents dealing with the 296 current state of the art. Two examples of such documents are [SMALL- 297 SUB-GROUP] and [HASH-ATTACKS]. 299 9. IANA Considerations 301 There are no IANA considerations in this document. 303 10. Acknowledgements 305 The authors and the Working Group are greatful for the participation 306 of Xiaoui Lui and Jeff Weinstein in helping to author the original 307 versions of this document. 309 The authors would like to thank Brian LaMacchia for his work in 310 developing and writing up many of the concepts presented in this 311 document. The authors would also like to thank Alex Deacon and Barb 312 Fox for their contributions. 314 11. References 316 11.1. Nomative References 318 [CMC-STRUCT] 319 Schaad, J., Myers, M., Liu, X., and J. Weinstein, 320 "Certificate Management Messages over CMS", Work in 321 Progress , December 2004. 323 [CMC-TRANS] 324 Schaad, J., Myers, M., Liu, X., and J. Weinstein, "CMC 325 Transport", Work In Progress , December 2004. 327 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", 328 RFC 3852, July 2004. 330 [CMS-AES] Schaad, J., "Use of the Advanced Encryption Standard (AES) 331 Encryption Algorithm in Cryptographic Message Syntax 332 (CMS)", RFC 3565, July 2003. 334 [CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS) 335 Algorithms", RFC 3370, August 2002. 337 [CMS-DH] Rescorla, E., "Diffie-Hellman Key Agreement Method", 338 RFC 2631, June 1999. 340 [CRMF] Schaad, J., "Internet X.509 Certificate Request M2essage 341 Format", RFC 4211, September 2005. 343 [CMS-RSA-OAEP] 344 Housley, R., "Use of the RSAES-OAEP Key Transport 345 Algorithm in the Cryptographic Message Syntax (CMS)", 346 RFC 3560, July 2003. 348 [CMS-RSA-PSS] 349 Schaad, J., "Use of the RSA PSS Signature Algorithm in 350 CMS", Work In Progress , December 2003. 352 [DH-POP] Prafullchandra, H. and J. Schaad, "Diffie-Hellman Proof- 353 of-Possession Algorithms", RFC 2875, June 2000. 355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 356 Requirement Levels", RFC 2119, BCP 14, March 1997. 358 [RSA-256] Schaad, J., "Additional Algorithms and Identifiers for RSA 359 Cryptography for use in the Internet X.509 Public Key 360 Infrastructure Certificate and Certificate Revocation List 361 (CRL) Profile", Work in Progress , July 2004. 363 11.2. Informational References 365 [SMALL-SUB-GROUP] 366 Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" 367 Attacks on the Diffie-Hellman Key Agreement Method for 368 S/MIME", RFC 2785, March 2000. 370 [HASH-ATTACKS] 371 Hoffman, P. and B. Schneier, "Attacks on Cryptographic 372 Hashes in Internet Protocols", RFC 4270, November 2005. 374 Authors' Addresses 376 Jim Schaad 377 Soaring Hawk Consulting 378 PO Box 675 379 Gold Bar, WA 98251 381 Phone: (425) 785-1031 382 Email: jimsch@exmsft.com 384 Michael Myers 385 TraceRoute Security, Inc. 387 Email: myers@coastside.inc 389 Intellectual Property Statement 391 The IETF takes no position regarding the validity or scope of any 392 Intellectual Property Rights or other rights that might be claimed to 393 pertain to the implementation or use of the technology described in 394 this document or the extent to which any license under such rights 395 might or might not be available; nor does it represent that it has 396 made any independent effort to identify any such rights. Information 397 on the procedures with respect to rights in RFC documents can be 398 found in BCP 78 and BCP 79. 400 Copies of IPR disclosures made to the IETF Secretariat and any 401 assurances of licenses to be made available, or the result of an 402 attempt made to obtain a general license or permission for the use of 403 such proprietary rights by implementers or users of this 404 specification can be obtained from the IETF on-line IPR repository at 405 http://www.ietf.org/ipr. 407 The IETF invites any interested party to bring to its attention any 408 copyrights, patents or patent applications, or other proprietary 409 rights that may cover technology that may be required to implement 410 this standard. Please address the information to the IETF at 411 ietf-ipr@ietf.org. 413 Disclaimer of Validity 415 This document and the information contained herein are provided on an 416 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 417 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 418 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 419 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 420 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 421 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 423 Copyright Statement 425 Copyright (C) The Internet Society (2006). This document is subject 426 to the rights, licenses and restrictions contained in BCP 78, and 427 except as set forth therein, the authors retain all their rights. 429 Acknowledgment 431 Funding for the RFC Editor function is currently provided by the 432 Internet Society.