idnits 2.17.1 draft-ietf-pkix-cmc-compl-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2119], [CMC-TRANS], [CMC-STRUCT]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 115 has weird spacing: '...ailInfo field...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 16 == Missing Reference: 'CMC-STRUCT' is mentioned on line 95, but not defined == Missing Reference: 'CMC-TRANS' is mentioned on line 122, but not defined == Missing Reference: 'CMS-ALG' is mentioned on line 106, but not defined == Unused Reference: 'DH' is defined on line 168, but no explicit reference was found in the text == Unused Reference: 'HMAC' is defined on line 173, but no explicit reference was found in the text == Unused Reference: 'PKCS1' is defined on line 177, but no explicit reference was found in the text == Unused Reference: 'PKCS7' is defined on line 180, but no explicit reference was found in the text == Unused Reference: 'PKCS8' is defined on line 184, but no explicit reference was found in the text == Unused Reference: 'PKCS10' is defined on line 187, but no explicit reference was found in the text == Unused Reference: 'PKIXCERT' is defined on line 190, but no explicit reference was found in the text == Unused Reference: 'SMIMEV2' is defined on line 197, but no explicit reference was found in the text == Unused Reference: 'SMIMEV3' is defined on line 203, but no explicit reference was found in the text == Unused Reference: 'X942' is defined on line 206, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2630 (ref. 'CMS') (Obsoleted by RFC 3369, RFC 3370) ** Obsolete normative reference: RFC 2511 (ref. 'CRMF') (Obsoleted by RFC 4211) -- Possible downref: Non-RFC (?) normative reference: ref. 'DH' -- Possible downref: Non-RFC (?) normative reference: ref. 'DH-POP' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') ** Obsolete normative reference: RFC 2313 (ref. 'PKCS1') (Obsoleted by RFC 2437) ** Downref: Normative reference to an Informational RFC: RFC 2315 (ref. 'PKCS7') -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS8' ** Obsolete normative reference: RFC 2314 (ref. 'PKCS10') (Obsoleted by RFC 2986) ** Obsolete normative reference: RFC 2459 (ref. 'PKIXCERT') (Obsoleted by RFC 3280) ** Downref: Normative reference to an Historic RFC: RFC 2311 (ref. 'SMIMEV2') ** Obsolete normative reference: RFC 2633 (ref. 'SMIMEV3') (Obsoleted by RFC 3851) Summary: 15 errors (**), 0 flaws (~~), 16 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group M. Myers 3 Internet Draft VeriSign 4 Document: draft-ietf-pkix-cmc-compl-00.txt X. Liu 5 February 2001 Cisco 6 Expires: July 2001 J. Schaad 7 Soaring Hawk Consulting 8 J. Weinstein 10 CMC Compliance Document 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026 [1]. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. Internet-Drafts are draft documents valid for a maximum of 21 six months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Comments or suggestions for improvement may be made on the "ietf- 33 pkix" mailing list, or directly to the author. 35 Copyright Notice 37 Copyright (C) The Internet Society (2000). All Rights Reserved. 39 Abstract 41 This document provides a set of compliance statements about the CMC 42 enrollment protocol. The documents [CMC-STRUCT] and [CMC-TRANS] 43 provide the definitions of the structure and transport protocols 44 defined for CMC. This document provides the information needed to 45 make a compliant version of CMC. 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 49 this document are to be interpreted as described in [RFC 2119]. 51 1. Overview 53 A set of structures and controls for providing an enrollment 54 protocol has been provided in [CMC-STRUCT]. The design of this 55 protocol was such that additional items could be added later as was 56 designed. A set of transport mechanisms for CMC messages as been 57 at a later date. This document covers the compliance issues that 58 are needed to implement a compliant CMC enrollment protocol. 60 2 Terminology 62 There are several different terms, abbreviations and acronyms used 63 in this document that we define here for convenience and consistency 64 of usage: 66 "End-Entity" (EE) refers to the entity that owns a key pair and for 67 whom a certificate is issued. 68 "LRA" or "RA" refers to a (Local) Registration Authority. A 69 registration authority acts as an intermediary between an End-Entity 70 and a Certification Authority. Multiple RAs can exist between the 71 End-Entity and the Certification Authority. 72 "CA" refers to a Certification Authority. A Certification Authority 73 is the entity that performs the actual issuance of a certificate. 74 "Client" refers to an entity that creates a PKI request. In this 75 document both RAs and End-Entities can be clients. 76 "Server" refers to the entities that process PKI requests and create 77 PKI responses. CAs and RAs can be servers in this document. 78 "PKCS#10" refers the Public Key Cryptography Standard #10. This is 79 one of a set of standards defined by RSA Laboratories in the 1980s. 80 PKCS#10 defines a Certificate Request Message syntax. 81 "CRMF" refers to the Certificate Request Message Format RFC [CRMF]. 82 We are using certificate request message format defined in this 83 document as part of our management protocol. 84 "CMS" refers to the Cryptographic Message Syntax RFC [CMS]. This 85 document provides for basic cryptographic services including 86 encryption and signing with and without key management. 87 "POP" is an acronym for "Proof of Possession". POP refers to a 88 value that can be used to prove that the private key corresponding 89 to a public key is in the possession and can be used by an end- 90 entity. 91 "Transport wrapper" refers to the outermost CMS wrapping layer. 93 3. Requirements for All Entities 95 [CMC-STRUCT] and [CMC-TRANS] compliance statements MUST be adhered 96 to unless specifically stated otherwise in this document. 98 If an entity implements a data encryption algorithm, Triple-DES as 99 defined in [CMS-ALG] MUST be implemented. Other algorithms MAY be 100 implemented. 102 All entities MUST verify DSA and RSA-SHA1 signatures as defined in 103 [CMS-ALG]. Other signature algorithms MAY be verified. 105 All entities MUST generate either DSA or RSA-SHA1 signatures as 106 defined in [CMS-ALG]. Other signatures algorithms MAY be used for 107 generation. 109 All entities MUST implement the DH-POP Proof-of-Possession as 110 defined in [DH-POP] Section 4. 112 No signature signing alg. 114 The extendedFailInfo field SHOULD NOT be populated in the 115 CMCStatusInfo object, the failInfo field SHOULD be used to relay 116 this information. 118 All entities MUST process the following control attributes: 119 CMCStatusInfoEx, CMCStatusInfo, 121 All entities MUST implement the HTTP transport mechanism as defined 122 in [CMC-TRANS]. Other transport mechanisms MAY be implemented. 124 4. Requirements for End-Entities 126 EEs MAY generate PKCS10 certificate requests. EEs SHOULD generate 127 CRMF certificate requests. EEs MUST generate one of the certificate 128 request messages. 130 EEs MUST implement either the Simple or Full Enrollment protocol. 132 5. Requirements for CAs 134 CAs MUST accept PKCS10 certificate requests. CAs MUST accept CRMF 135 certificate requests. 137 CAs MUST implement the Simple Enrollment protocol. CAs MUST 138 implement the Full Enrollment protocol. 140 CAs MUST implement the following additional control attributes: 141 identification, identityProof, dataReturn, addExtensions, 142 transactionID, senderNonce, recipientNonce, lraPOPWitness, 143 revokeRequest 145 6. Requirements for RAs 147 RAs MUST implement the following additional control attributes: 148 identification, identityProof, dataReturn, transactionID, 149 senderNonce, recipientNonce, lraPOPWitness, 151 7. Acknowledgments 153 The authors would like to thank Brian LaMacchia for his work in 154 developing and writing up many of the concepts presented in this 155 document. The authors would also like to thank Alex Deacon and Barb 156 Fox for their contributions. 158 8. References 160 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, 161 June 1999. 163 [CRMF] Myers, M., Adams, C., Solo, D. and D. Kemp, "Internet 164 X.509 Certificate Request Message Format", RFC 2511, 165 March 166 1999. 168 [DH] B. Kaliski, "PKCS 3: Diffie-Hellman Key Agreement v1.4" 170 [DH-POP] H. Prafullchandra, J. Schaad, "Diffie-Hellman Proof-of- 171 Possession Algorithms", Work in Progress. 173 [HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- 174 Hashing for Message Authentication", RFC 2104, February 175 1997. 177 [PKCS1] Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5", RFC 178 2313, March 1998. 180 [PKCS7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 181 v1.5", 182 RFC 2315, October 1997. 184 [PKCS8] RSA Laboratories, "PKCS#8: Private-Key Information Syntax 185 Standard, Version 1.2", November 1, 1993. 187 [PKCS10] Kaliski, B., "PKCS #10: Certification Request Syntax 188 v1.5", RFC 2314, October 1997. 190 [PKIXCERT] Housley, R., Ford, W., Polk, W. and D. Solo "Internet 191 X.509 Public Key Infrastructure Certificate and CRL 192 Profile", RFC 2459, January 1999. 194 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 195 Requirement Levels", BCP 14, RFC 2119, March 1997. 197 [SMIMEV2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and 198 L. 199 Repka, "S/MIME Version 2 Message Specification", RFC 200 2311, 201 March 1998. 203 [SMIMEV3] Ramsdell, B., "S/MIME Version 3 Message Specification", 204 RFC 2633, June 1999. 206 [X942] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 207 2631, June 1999. 209 9. Authors' Addresses 211 Michael Myers 212 TraceRoute Security, Inc. 214 EMail: myers@coastside.inc 216 Xiaoyi Liu 217 Cisco Systems 218 170 West Tasman Drive 219 San Jose, CA 95134 221 Phone: (480) 526-7430 222 Jim Schaad 223 Soaring Hawk Consulting 225 EMail: jimsch@exmsft.com 227 Jeff Weinstein 229 EMail: jsw@meer.net 231 Full Copyright Statement 233 Copyright (C) The Internet Society (2000). All Rights Reserved. 235 This document and translations of it may be copied and furnished to 236 others, and derivative works that comment on or otherwise explain it 237 or assist in its implementation may be prepared, copied, published 238 and distributed, in whole or in part, without restriction of any 239 kind, provided that the above copyright notice and this paragraph 240 are included on all such copies and derivative works. However, this 241 document itself may not be modified in any way, such as by removing 242 the copyright notice or references to the Internet Society or other 243 Internet organizations, except as needed for the purpose of 244 developing Internet standards in which case the procedures for 245 copyrights defined in the Internet Standards process must be 246 followed, or as required to translate it into languages other than 247 English. 249 The limited permissions granted above are perpetual and will not be 250 revoked by the Internet Society or its successors or assigns. 252 This document and the information contained herein is provided on an 253 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 254 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 255 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 256 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 257 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 259 Acknowledgement 261 Funding for the RFC Editor function is currently provided by the 262 Internet Society.