idnits 2.17.1 draft-ietf-pkix-cmc-compl-01.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.a on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 400. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 377. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 390. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (December 2004) is 7071 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 311, but not defined == Missing Reference: 'CMS' is mentioned on line 298, but not defined == Missing Reference: 'RFC 2119' is mentioned on line 124, but not defined == Missing Reference: 'CMC-STRUCT' is mentioned on line 289, but not defined == Missing Reference: 'CMC-TRANS' is mentioned on line 294, but not defined == Missing Reference: 'CMS-ALG' is mentioned on line 305, but not defined == Missing Reference: 'CMS-RSA-PSS' is mentioned on line 319, but not defined == Missing Reference: 'RSA-256' is mentioned on line 329, but not defined == Missing Reference: 'CMS-AES' is mentioned on line 301, but not defined == Missing Reference: 'CMS-RSA-OAEP' is mentioned on line 314, but not defined == Missing Reference: 'CMS-DH' is mentioned on line 308, but not defined == Missing Reference: 'DH-POP' is mentioned on line 323, but not defined == Missing Reference: 'SMALL-SUBGROUPS' is mentioned on line 266, but not defined == Missing Reference: 'RFC2119' is mentioned on line 326, but not defined == Unused Reference: 'SMALL-SUB-GROP' is defined on line 336, but no explicit reference was found in the text Summary: 7 errors (**), 0 flaws (~~), 17 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: June 4, 2005 M. Myers 5 TraceRoute Security, Inc. 6 X. Liu 7 Cisco 8 J. Weinstein 9 December 2004 11 CMC Complience Document 12 draft-ietf-pkix-cmc-compl-01 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 18 author represents that any applicable patent or other IPR claims of 19 which he or she is aware have been or will be disclosed, and any of 20 which he or she become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on June 4, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2004). 45 Abstract 47 This document provides a set of compliance statements about the CMC 48 (Certificate Management over CMS) enrollment protocol. The ASN.1 49 structures and the transport mechanisms for the CMC enrollment 50 protocol are covered in other documents. This document provides the 51 information needed to make a compliant version of CMC 53 1. Overview 55 The CMC (Certificate Management over CMS) protocol is designed in 56 terms of a client/server relationship. In the simplest case the 57 client is the requestor of the certificate (i.e. the End Entity or 58 EE) and the server is the issuer of the certificate (i.e. the CA). 59 The introduction of an RA (registration authority) into the set of 60 agents complicates the picture only slightly. The RA becomes the 61 server with respect to the certificate requestor, and it becomes the 62 client with respect to the certificate issuer. Any number of RAs can 63 be inserted into the picture in this manner. 65 The RAs may serve specialized purposes that are not currently covered 66 by this document. One such purpose would be a Key Escrow agent. As 67 such all certificate requests for encryption keys would be directed 68 through this RA and it would take appropriate action to do the key 69 archival. Key recovery requests could be defined in the CMC 70 methodology allowing for the Key Escrow agent to perform that 71 operation acting as the final server in the chain of agents. 73 If there are multiple RAs in the system, it is considered normal that 74 not all RAs will see all certificate requests. The routing between 75 the RAs may be dependent on the content of the certificate requests 76 involved 78 This document is divided into six sections, each section specifying 79 the requirements that are specific to a class of agents in the CMC 80 model. These are 1) All agents, 2) all servers, 3) all clients, 4) 81 all End Entities, 5) all Registration Entities, 6) all certificate 82 authorities. 84 2. Terminology 86 There are several different terms, abbreviations and acronyms used in 87 this document that we define here for convenience and consistency of 88 usage: 90 "End-Entity" (EE) refers to the entity that owns a key pair and 91 for whom a certificate is issued. 92 "RA" or "LRA" refers to a (Local) Registration Authority. A 93 registration authority acts as an intermediary between an 94 End-Entity and a Certification Authority. Multiple RAs can exist 95 between the End-Entity and the Certification Authority. 96 "CA" refers to a Certification Authority. A Certification 97 Authority is the entity that performs the actual issuance of a 98 certificate. 99 "Client" refers to an entity that creates a PKI request. In this 100 document both RAs and End-Entities can be clients. 101 "Server" refers to the entities that process PKI requests and 102 create PKI responses. CAs and RAs can be servers in this 103 document. Other documents could define entities such as key 104 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. 108 "CRMF" refers to the Certificate Request Message Format RFC 109 [CRMF]. We are using certificate request message format defined 110 in this document as part of our management protocol. 111 "CMS" refers to the Cryptographic Message Syntax RFC [CMS]. This 112 document provides for basic cryptographic services including 113 encryption and signing with and without key management. 114 "POP" is an acronym for "Proof of Possession". POP refers to a 115 value that can be used to prove that the private key corresponding 116 to a public key is in the possession and can be used by an 117 end-entity. A discussion on POP can be found in appendix C of 118 [CRMF]. 119 "Transport wrapper" refers to the outermost CMS wrapping layer. 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC 2119]. 125 3. Requirements for All Entities 127 All [CMC-STRUCT] and [CMC-TRANS] compliance statements MUST be 128 adhered to unless specifically stated otherwise in this document. 130 The extendedFailInfo field SHOULD NOT be populated in the 131 CMCStatusInfoExt object; the failInfo field SHOULD be used to relay 132 this information. If the extendedFailInfo field is used, it is 133 suggested that an additional CMCStatusInfoExt item exist for the same 134 body part with a failInfo field. 136 All entities MUST process the following control attributes: 137 id-cmc-statusInfoExt, id-cmc-dataReturn, id-cmc-transactionId, 138 id-cmc-senderNonce, id-cmc-recipientNonce, id-cmc-queryPending, 139 id-cmc-identification, id-cmc-identityProof, id-cmc-idPOPLinkRandom, 140 id-cmc-idPOPLinkWitness, id-cmc-confirmCertAcceptance. 142 All entities SHOULD be able to process the following control 143 attributes: id-cmc-statusInfo, id-cmc-revokeRequest, id-cmc-regInfo, 144 id-cmc-responseInfo. 146 Implementation of the id-cmc-getCert, id-cmc-getCRL, 147 id-cmc-trustRoots, id-cmc-authData and id-cmc-publishCertificate 148 controls is optional. Strong consideration should be given to 149 implementing the id-cmc-authData and id-cmc-trustRoots controls as 150 this gives a simple method for distributing trust anchors into 151 clients without user intervention. 153 All entities MUST implement the HTTP transport mechanism as defined 154 in [CMC-TRANS]. Other transport mechanisms MAY be implemented. 156 3.1 Cryptographic Algorithm Requirments 158 All entities MUST verify DSA and RSA-SHA1 signatures as defined in 159 [CMS-ALG]. Other signature algorithms MAY be verified. It is 160 strongly suggested that RSA-PSS as defined in [CMS-RSA-PSS] also be 161 verified. It is strongly suggested that SHA-256 using RSA and 162 RSA-PSS also be verified. (Details are found in [RSA-256].) 164 All entities MUST generate either DSA or RSA-SHA1 signatures as 165 defined in [CMS-ALG]. Other signatures algorithms MAY be used for 166 generation. 168 If an entity implements a data encryption algorithm, AES as defined 169 in [CMS-AES] MUST be implemented. Other algorithms MAY be 170 implemented. 172 If an entity implements a key transport algorithm, RSA as defined in 174 [CMS-ALG] MUST be implemented. RSA-OAEP as defined in [CMS-RSA-OAEP] 175 SHOULD be implemented. Other key transport algorithms MAY be 176 implemented. 178 If an entity implements a key agreement algorithm, Diffie-Hellman as 179 defined in [CMS-DH] MUST be implemented. 181 3.2 CRMF Feature Requirments 183 The following additional restrictions are placed on CRMF features: 185 The registration control tokens id-regCtrl-regToken and 186 id-regCtrl-authToken MUST NOT be used. No specific CMC feature is 187 used to replace these items, but generally the CMC controls 188 identification and identityProof will perform the same service and 189 are more specifically defined. 191 The control token id-regCtrl-pkiArchiveOptions SHOULD NOT be 192 supported. An alternative method is under development to provide 193 this functionality. 195 The behavior of id-regCtrl-oldCertID is not presently used. It is 196 replaced by issuing the new certificate and using the 197 id-cmc-publishCert to remove the old certificate from publication. 198 This operation would not normally be accompanied by an immediate 199 revocation of the old certificate, however that can be accomplished 200 by the id-cmc-revokeRequest control. 202 The id-regCtrl-protocolEncrKey is not used. 204 3.3 Requirements for Clients 206 All compliant client applications MUST support full enrollment 207 responses. (This allows for error handling not otherwise supported.) 209 4. Requirements for Servers 211 All compliant server applications MUST support CRMF certificate 212 requests. All compliant server applications SHOULD support PKCS10 213 certificate requests both in the simple and full message formats. 215 5. Requirements for EEs 217 All EE applications MUST support either the simple or full enrollment 218 requests/response pair. All client application SHOULD support the 219 full enrollment request/response pair. 221 When generating full enrollment requests, the CRMF request format is 222 preferred over the PKCS10 request format. 224 If an entity implements Diffie-Hellman, it MUST implement either the 225 DH-POP Proof-of-Possession as defined in [DH-POP] Section 4 or the 226 challenge-response POP controls id-cmc-encryptedPOP and 227 id-cmc-decryptedPOP. 229 6. Requirements for RAs 231 RAs MUST implement the following controls: id-cmc-modCertTemplate, 232 id-cmc-batchRequests, id-cmc-batchResponses. RAs SHOULD implement 233 the id-cmc-addExtensions control. 235 RAs SHOULD be able to do delegated POP. RAs implementing this 236 feature MUST implement the id-cmc-lraPOPWitness control. 238 RAs MUST generate full enrollment requests. 240 All RAs MUST implement the promotion of the id-aa-cmc-unsignedData as 241 covered in section 3.8 of [CMC-STRUCT] 243 7. Requirements for CAs 245 CAs MUST accept PKCS10 certificate requests. CAs MUST accept CRMF 246 certificate requests. 248 CAs MUST implement the Simple Enrollment protocol. CAs MUST 249 implement the Full Enrollment protocol. 251 CAs MUST implement the following additional control attributes: 252 identification, identityProof, dataReturn, addExtensions, 253 transactionID, senderNonce, recipientNonce, lraPOPWitness, 254 revokeRequest. All CAs designed to work in an environment where RAs 255 are permitted MUST implement the id-cmc-modCertTemplate, 256 id-cmc-batchRequests and id-cmc-BatchResponses controls. Such CAs 257 SHOULD also implement the id-cmc-addExtensions control. 258 Implementation of such support is strongly suggested as this permits 259 the delegation of substantial administrative interaction onto an RA 260 rather than at the CA. 262 CAs MUST perform at least minimal checks on all public keys before 263 issuing a certificate. At a minimum a check for syntax would occur 264 with the POP operation. Additionally CAs SHOULD perform simple 265 checks for known bad keys such as small subgroups for DSA and DH keys 266 [SMALL-SUBGROUPS] or known bad exponents for RSA keys (i.e. 3). 268 CAs MUST enforce POP checking before issuing any certificate. CAs 269 MAY delegate the POP operation to an RA for those cases where 1) a 270 challenge/response message pair must be used, 2) an RA performs 271 escrow of a key and checks for POP in that manner or 3) an unusual 272 algorithm is used and that validation is done at the RA. 274 CAs SHOULD implement both the DH-POP Proof-of-Possession as defined 275 in [DH-POP] Section 4 and the challenge-response POP controls 276 id-cmc-encryptedPOP and id-cmc-decryptedPOP. 278 8. Acknowledgements 280 The authors would like to thank Brian LaMacchia for his work in 281 developing and writing up many of the concepts presented in this 282 document. The authors would also like to thank Alex Deacon and Barb 283 Fox for their contributions. 285 9. References 287 9.1 Nomative References 289 [CMC-STRUCT] 290 Schaad, J., Myers, M., Liu, X. and J. Weinstein, 291 "Certificate Management Messages over CMS", Work in 292 Progress , December 2004. 294 [CMC-TRANS] 295 Schaad, J., Myers, M., Liu, X. and J. Weinstein, "CMC 296 Transport", Work In Progress , December 2004. 298 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", 299 RFC 3852, July 2004. 301 [CMS-AES] Schaad, J., "Use of the Advanced Encryption Standard (AES) 302 Encryption Algorithm in Cryptographic Message Syntax 303 (CMS)", RFC 3565, July 2003. 305 [CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS) 306 Algorithms", RFC 3370, August 2002. 308 [CMS-DH] Rescorla, E., "Diffie-Hellman Key Agreement Method", 309 RFC 2631, June 1999. 311 [CRMF] Schaad, J., "Internet X.509 Certificate Request M2essage 312 Format", Work In Progress , December 1999. 314 [CMS-RSA-OAEP] 315 Housley, R., "Use of the RSAES-OAEP Key Transport 316 Algorithm in the Cryptographic Message Syntax (CMS)", 317 RFC 3560, July 2003. 319 [CMS-RSA-PSS] 320 Schaad, J., "Use of the RSA PSS Signature Algorithm in 321 CMS", Work In Progress , December 2003. 323 [DH-POP] Prafullchandra, H. and J. Schaad, "Diffie-Hellman 324 Proof-of-Possession Algorithms", RFC 2875, June 2000. 326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", RFC 2119, BCP 14, March 1997. 329 [RSA-256] Schaad, J., "Additional Algorithms and Identifiers for RSA 330 Cryptography for use in the Internet X.509 Public Key 331 Infrastructure Certificate and Certificate Revocation List 332 (CRL) Profile", Work in Progress , July 2004. 334 9.2 Informational References 336 [SMALL-SUB-GROP] 337 Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" 338 Attacks on the Diffie-Hellman Key Agreement Method for 339 S/MIME", RFC 2785, March 2000. 341 Authors' Addresses 343 Jim Schaad 344 Soaring Hawk Consulting 345 PO Box 675 346 Gold Bar, WA 98251 348 Phone: (425) 785-1031 349 Email: jimsch@exmsft.com 351 Michael Myers 352 TraceRoute Security, Inc. 354 Email: myers@coastside.inc 356 Xiaoyi Liu 357 Cisco 358 170 West Tasman Drive 359 San Jose, CA 95134 361 Phone: (480) 526-7430 362 Email: xliu@cisco.com 364 Jeff Weinstein 366 Email: jsw@meer.net 368 Intellectual Property Statement 370 The IETF takes no position regarding the validity or scope of any 371 Intellectual Property Rights or other rights that might be claimed to 372 pertain to the implementation or use of the technology described in 373 this document or the extent to which any license under such rights 374 might or might not be available; nor does it represent that it has 375 made any independent effort to identify any such rights. Information 376 on the procedures with respect to rights in RFC documents can be 377 found in BCP 78 and BCP 79. 379 Copies of IPR disclosures made to the IETF Secretariat and any 380 assurances of licenses to be made available, or the result of an 381 attempt made to obtain a general license or permission for the use of 382 such proprietary rights by implementers or users of this 383 specification can be obtained from the IETF on-line IPR repository at 384 http://www.ietf.org/ipr. 386 The IETF invites any interested party to bring to its attention any 387 copyrights, patents or patent applications, or other proprietary 388 rights that may cover technology that may be required to implement 389 this standard. Please address the information to the IETF at 390 ietf-ipr@ietf.org. 392 Disclaimer of Validity 394 This document and the information contained herein are provided on an 395 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 396 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 397 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 398 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 399 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 400 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 402 Copyright Statement 404 Copyright (C) The Internet Society (2004). This document is subject 405 to the rights, licenses and restrictions contained in BCP 78, and 406 except as set forth therein, the authors retain all their rights. 408 Acknowledgment 410 Funding for the RFC Editor function is currently provided by the 411 Internet Society.