idnits 2.17.1 draft-ietf-sacred-pkienrollinfo-00.txt: -(99): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 5 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 119: '... PKI_EEIndividualParameters OPTIONAL...' RFC 2119 keyword, line 137: '... cAResponderAddress [1] PKI_Entity OPTIONAL,...' RFC 2119 keyword, line 138: '... rAResponderAddress [2] PKI_Entity OPTIONAL,...' RFC 2119 keyword, line 141: '... PKI_Protocol OPTIONAL,...' RFC 2119 keyword, line 143: '... PKI_POP OPTIONAL,...' (23 more instances...) 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 (June 2001) is 8350 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) -- Looks like a reference, but probably isn't: '0' on line 422 -- Looks like a reference, but probably isn't: '1' on line 423 -- Looks like a reference, but probably isn't: '2' on line 424 -- Looks like a reference, but probably isn't: '3' on line 426 -- Looks like a reference, but probably isn't: '4' on line 428 -- Looks like a reference, but probably isn't: '5' on line 430 -- Looks like a reference, but probably isn't: '6' on line 434 -- Looks like a reference, but probably isn't: '7' on line 436 -- Looks like a reference, but probably isn't: '8' on line 438 -- Looks like a reference, but probably isn't: '9' on line 440 == Unused Reference: 'PKCS15' is defined on line 329, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2315 (ref. 'PKCS7') ** Obsolete normative reference: RFC 2314 (ref. 'PKCS10') (Obsoleted by RFC 2986) -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS15' ** Obsolete normative reference: RFC 2459 (Obsoleted by RFC 3280) ** Obsolete normative reference: RFC 2510 (Obsoleted by RFC 4210) ** Obsolete normative reference: RFC 2511 (Obsoleted by RFC 4211) ** Obsolete normative reference: RFC 2797 (Obsoleted by RFC 5272) Summary: 14 errors (**), 0 flaws (~~), 5 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Sacred Working Group N. Kapidzic-Cicovic 3 Internet Draft Entegrity Solutions 4 Document: draft-ietf-sacred-pkienrollinfo-00.txt 5 Expires: December 2001 June 2001 7 PKI Enrollment Information 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 10 of RFC2026. Internet-Drafts are working documents of 13 the Internet Engineering Task Force (IETF), its areas, and its 14 working groups. Note that other groups may also distribute working 15 documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/lid-abstracts.html 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html 28 Comments or suggestions for improvement may be made on the "ietf- 29 sacred" mailing list, or directly to the author. 31 Copyright Notice 33 Copyright (C) The Internet Society (1998). All Rights Reserved. 35 Abstract 37 This document describes the format of PKI enrollment information, 38 which may be used by an RA/CA to enable automated end entity 39 certification. The PKI enrollment information contains PKI 40 parameters describing RA/CA certification policy requirements put on 41 end entities during their enrollment for a public key certificate. 43 1. End Entity PKI Enrollment 45 End entities represent all users of PKI (individuals or software 46 processes), who are issued public key certificates. The process of 47 issuing a certificate for an end entity is known as end-entity PKI 48 enrollment. Certificates are issued by a Certification Authority 49 (CA), with or without the interaction of a Registration Authority 50 (RA) [RFC2510]. 52 An end entity PKI enrollment can be initiated at the RA/CA or at the 53 end entity (EE). 55 When PKI enrollment is initiated at the RA or CA, the end entity 56 eventually gets a token containing a private key and the 57 corresponding certificate as issued by the CA. After receiving the 58 token, the EE is capable of performing authenticated signing 59 operations (e.g., S/MIME or SSL) without any further interaction 60 with the RA/CA. The drawback of this solution is that non- 61 repudiation of signatures cannot be guaranteed since the keys are 62 generated by the RA/CA. 64 Alternatively, PKI enrollment can be initiated by the end entity and 65 the enrollment process can be performed with or without the human 66 interaction. An example of an end entity initiated PKI enrollment is 67 a browser-based enrollment with the RA/CA providing HTML forms, 68 requiring human interaction to populate the fields and complete the 69 enrollment. 71 This draft proposes a solution for performing automated end entity 72 PKI enrollment (without requiring human intervention). The automated 73 end entity PKI enrollment is based on the assumption that the RA/CA 74 configuration information is made available to the end entity prior 75 to the initiation of the enrollment, and that the end entity is in 76 possession of client software capable of interpreting the 77 configuration information. 79 With this solution keys are being generated by the end entity, and 80 non-repudiation is thus provided for. When there is a need for using 81 multiple keys for different key usage (dual keys), with RA/CA 82 generation and optionally backup of encipherment keys, then a mixed 83 model can be used. The RA/CA is creating a token for an end entity 84 with encipherment private key and corresponding certificate, and PKI 85 enrollment information. After receiving the token, the end entity is 86 able to initiate automated PKI enrollment for signature keys. 88 The PKI enrollment information can alternatively be used by the 89 RA/CA to make its PKI parameters publicly available to end entities 90 (and RAs) wishing to communicate with the RA/CA. This communication 91 can involve more than just the initial PKI enrollment e.g., key 92 update, certificate update, certificate revocation, etc. 94 Depending on the type of PKI enrollment information, it can contain 95 only general RA/CA configuration information and be made publicly 96 available to everyone, or it can be tailored with each end entity�s 97 individual data and thus required to be available only for the 98 particular end entity. In the former case, the PKI enrollment data 99 may be placed at the RA�s or CA�s web page, and in the latter case 100 it should be distributed to the EE in a secure way. 102 The PKI enrollment information may be stored on the end entity�s 103 token in the Personal Security Environment (PSE) and handed to the 104 end entity prior to PKI enrollment. PKCS#15 token format could be 105 extended to define a placeholder for the PKI enrollment information 106 [PKCS#15]. 108 The format of the end entity token and its location after PKI 109 enrollment (e.g., at a credential server) is not covered by this 110 draft document. 112 2. PKI Enrollment Information 114 A PKI enrollment structure is composed of general RA/CA parameters 115 and optionally individual end entity parameters: 117 PKI_EnrollmentInfo ::= SEQUENCE { 118 generalParameters PKI_GeneralParameters, 119 eeIndividualParameters PKI_EEIndividualParameters OPTIONAL 120 } 122 The fully automated end entity initiated PKI enrollment can be 123 achieved only if the information required for authentication of the 124 end entity is contained in the PKI enrollment information 125 (eeIndividualParameters). Otherwise, some human intervention is 126 still required during the enrollment in order to achieve 127 authentication. 129 2.1 PKI Enrollment Information - General Parameters 131 PKI enrollment information general parameters structure contains a 132 version number and several optional RA/CA parameters. Their detailed 133 description is given in sections 2.1.1 to 2.1.7. 135 PKI_GeneralParameters ::= SEQUENCE { 136 Version [0] EXPLICIT Version DEFAULT v1, 137 cAResponderAddress [1] PKI_Entity OPTIONAL, 138 rAResponderAddress [2] PKI_Entity OPTIONAL, 139 -- either rA or parentCA should be present 140 pkiProtocol [3] SEQUENCE OF -- all supported by RA/CA 141 PKI_Protocol OPTIONAL, 142 popMethod [4] SEQUENCE OF -- all supported by RA/CA 143 PKI_POP OPTIONAL, 144 certTemplate [5] CertTemplate OPTIONAL, 145 -- the presence of a part of CertTemplate means that the 146 -- RA/CA accepts this part to be populated by the EE 147 -- (the actual value is not important) 148 keyGenerators [6] SEQUENCE OF -- as required by RA/CA 149 KeyGenerator OPTIONAL, 150 minKeySize [7] SEQUENCE OF -- as required by RA/CA 151 KeySizeRequirement OPTIONAL, 152 maxKeySize [8] SEQUENCE OF -- as required by RA/CA 153 KeySizeRequirement OPTIONAL, 154 keyTypes [9] SEQUENCE OF -- all supported by RA/CA 155 KeyTypeRequirement OPTIONAL 156 } 158 2.1.1 Responder Address 159 The responder address parameter specifies the address of the RA/CA 160 responder where certification requests and other PKI messages are to 161 be sent for processing by the RA/CA. The address is to be provided 162 as a uniformResourceIdentifier choice of GeneralName [RFC2459], thus 163 specifying the transport protocol as well as the address of the 164 responder (e.g. "http://www.myCA.com/responder"); 166 PKI_Entity ::= SEQUENCE { 167 name [0] Name OPTIONAL, -- EE, RA or CA DN 168 altNames [1] GeneralNames OPTIONAL -- e.g., e-mail for EE, 169 -- URL or IP of the RA/CA 170 } -- either one of name and altNames or both must be present 172 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 174 GeneralName ::= CHOICE { 175 otherName [0] OtherName, 176 rfc822Name [1] IA5String, 177 dNSName [2] IA5String, 178 x400Address [3] ORAddress, 179 directoryName [4] Name, 180 ediPartyName [5] EDIPartyName, 181 uniformResourceIdentifier [6] IA5String, 182 iPAddress [7] OCTET STRING, 183 registeredID [8] OBJECT IDENTIFIER} 185 2.1.2 PKI Protocol 187 There are a number of existing standards for PKI enrollment. The 188 most usually used ones are PKCS #10 certification requests [PKCS10] 189 with PKCS #7 certification responses [PKCS7], PKIX CMP [RFC2510] and 190 PKIX CMC [RFC2797]. The RA/CA may use this parameter to express its 191 preferred PKI protocol for end entities to use when enrolling for 192 certificates. 194 PKI_Protocol ::= ENUMERATED { 195 PKIX_CMPv1 (0), -- RFC 2510 196 PKIX_CMPv2 (1), -- 2510 bis 197 PKCS10_PKCS7 (2), 198 PKIX_CMC (3) -- RFC 2797 199 } 201 2.1.3 POP Method 203 There are different ways for an end entity to supply proof of 204 possession of the private key corresponding to the public key 205 contained in the certification request. This parameter specifies the 206 private key proof-of-possession method as required by the CA 207 [RFC2511]. 209 PKI_POP ::= ENUMERATED { 210 ImplicitPOP (0), 211 ExplicitPOP (1) 212 } 214 2.1.4 Certificate Template 216 The CA certification policy dictates which fields of the end entity 217 certificate are to be populated. For some certificate fields it is 218 the end entity that should provide the value in the certification 219 request (e.g., key usage, subject alternative name, etc.). 221 The certificate template parameter provides a way for the CA to 222 specify which fields in the certificate request template are 223 required to be populated by the end entity. 225 For example, the certificate template parameter may contain the 226 following fields: 227 - Subject DN (to be present in the request or not), 228 - Subject alternative names (e.g., e-mail), 229 - Key usage, 230 - Extended key usage, 231 - Other extensions (e.g., private). 233 The encoding of the certificate template parameter is as 234 CertTemplate specified in [RFC2511]. 236 The presence of a field in the certificate template means that its 237 value is to be provided by an end entity in the certification 238 request. The actual value that is encoded in the certificate 239 template of the PKI enrollment info is to be ignored. 241 2.1.5 Key Generators 243 The CA certification policy may require certain type of keys to be 244 generated at the RA or CA, e.g., encipherment keys for backup 245 purposes. Some other types of keys should preferably be generated by 246 the end-entity, e.g., signature keys in order to provide for non- 247 repudiation. Alternatively encipherment keys may be generated at the 248 end entity side and sent to the RA/CA for backup purposes. 250 An RA/CA may use the parameter Key Generators in order to provide 251 this information about its certification policy to end entities. 253 PKI_EntityType ::= ENUMERATED { 254 EE (0), 255 RA (1), 256 CA (2) 257 } 259 KeyGenerator ::= SEQUENCE { 260 keyUsage KeyUsage, -- only one value at a time 261 entityType PKI_EntityType, -- RA, CA or EE 262 backupRequired BOOLEAN DEFAULT FALSE 263 -- if TRUE and keys generated by EE, 264 -- the private key MUST be sent 265 -- to RA/CA for backup 266 } 268 2.1.6 Supported Key Sizes 270 The RA/CA may specify the minimal key size that is acceptable for a 271 specific key usage according to the CA certification policy. 272 Furthermore, the RA/CA may have an upper limit on the length of the 273 key it is capable of handling. The KeySizeRequirement structure may 274 be used to provide this information to end entities. 276 KeySizeRequirement ::= SEQUENCE { 277 keyUsage KeyUsage, -- only one value at a time 278 size INTEGER -- bit size of the key 279 } 281 2.1.7 Supported Key Types 283 The RA/CA may be capable of handling only certain key algorithm 284 types for a specific key usage, e.g. only DSA keys for digital 285 signature and only Diffie-Hellman keys for key agreement 286 (alternatively, only RSA key type for all key usages). The 287 KeyTypeRequirement structure may be used to provide this type of 288 information to end entities. 290 KeyTypeRequirement ::= SEQUENCE { 291 keyUsage KeyUsage, -- only one value at a time 292 keyType OBJECT IDENTIFIER -- algorithm identifier 293 } 295 2.2 PKI Enrollment Information - End Entity Individual Parameters 297 The individual end entity parameters are to be encoded in 298 PKI_EEIndividualParameters structure. 300 PKI_EEIndividualParameters ::= SEQUENCE { 301 endEntityNamingInfo PKI_Entity, 302 sharedSecret BIT STRING OPTIONAL 303 } 305 The RA/CA policy may be such that it requires end entities to 306 populate certification requests with the same DN and alternative 307 names as registered at the RA/CA. If this is the case, end entity 308 naming info parameter may be used to provide this information to 309 each end entity in the RA/CA�s domain. 311 In order to provide authenticity of the initial EE certification 312 requests, the RA/CA usually share a secret with each end entity. The 313 shared secret parameter may be used to communicate this information 314 to end entities. 316 3. Security Considerations 317 The PKI Enrollment Information needs to be provided to end entities 318 in secure way only if it contains end entity individual data 319 required for authentication of the end entity during certification. 320 In case that these parameters are not included in the PKI Enrollment 321 Information, no extra security measures need to be taken. 323 4. References 325 [PKCS7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 326 v1.5", RFC 2315, October 1997. 327 [PKCS10] Kaliski, B., "PKCS #10: Certification Request Syntax 328 v1.5", RFC 2314, October 1997. 329 [PKCS15] RSA Laboratories, "The Public-Key Cryptography Standards 330 (PKCS 15)", RSA Data Security Inc., Redwood City, 331 California, June 2000 Release. 332 [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo "Internet 333 X.509 Public Key Infrastructure Certificate and CRL 334 Profile", RFC 2459, January 1999. 335 [RFC2510] Adams, C., Farrell, S., "Internet X.509 Public Key 336 Infrastructure: Certificate Management Protocols", RFC 337 2510, March 1999 338 [RFC2511] Myers, M., Adams, C., Solo, D. and D. Kemp, "Internet 339 X.509 Certificate Request Message Format", RFC 2511, 340 March 1999. 341 [RFC2797] Myers, M., Liu, X., Schaad, J., Weinstein, J. 342 "Certificate Management Messages over CMS", RFC 2797, 343 April 2000 345 5. Author�s Address 347 Nada Kapidzic Cicovic 348 Entegrity Solutions 349 164 74 Kista 350 Sweden 352 Phone: +46 8 477 77 37 353 EMail: nada@entegrity.com 355 Appendix A: ASN.1 Module using 1988 Syntax 357 PKIEnr??? {iso(1) ... ???} 359 DEFINITIONS EXPLICIT TAGS ::= 361 BEGIN 363 -- EXPORTS ALL -- 365 IMPORTS 367 Version, KeyUsage, Name, GeneralNames 368 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 369 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 370 id-mod(0) id-pkix1-explicit-88(1)}} 372 CertTemplate 373 FROM PKIXCRMF {iso(1) identified-organization(3) 374 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 375 id-mod(0) id-mod-crmf(5)}} 377 -- Locally defined OIDs -- 379 PKI_Entity ::= SEQUENCE { 380 name [0] Name OPTIONAL, -- EE, RA or CA DN 381 altNames [1] GeneralNames OPTIONAL -- e.g., e-mail for EE, 382 -- URL or IP of the RA/CA 383 } -- either one of name and altNames or both must be present 385 PKI_EntityType ::= ENUMERATED { 386 EE (0), 387 RA (1), 388 CA (2) 389 } 391 PKI_Protocol ::= ENUMERATED { 392 PKIX_CMPv1 (0), -- RFC 2510 393 PKIX_CMPv2 (1), -- 2510 bis 394 PKCS10_PKCS7 (2), 395 PKIX_CMC (3) 396 } 398 PKI_POP ::= ENUMERATED { 399 ImplicitPOP (0), 400 ExplicitPOP (1) 401 } 403 KeyGenerator ::= SEQUENCE { 404 keyUsage KeyUsage, -- only one value at a time 405 entityType PKI_EntityType, -- RA, CA or EE 406 backupRequired BOOLEAN DEFAULT FALSE 407 -- if TRUE and keys generated by EE, 408 -- the private key MUST be sent 409 -- to RA/CA for backup 410 } 412 KeySizeRequirement ::= SEQUENCE { 413 keyUsage KeyUsage, -- only one value at a time 414 size INTEGER -- bit size of the key 415 } 417 KeyTypeRequirement ::= SEQUENCE { 418 keyUsage KeyUsage, -- only one value at a time 419 keyType OBJECT IDENTIFIER -- algorithm identifier 420 } 421 PKI_GeneralParameters ::= SEQUENCE { 422 Version [0] EXPLICIT Version DEFAULT v1, 423 cAResponderAddress [1] PKI_Entity OPTIONAL, 424 rAResponderAddress [2] PKI_Entity OPTIONAL, 425 -- either rA or parentCA should be present 426 pkiProtocol [3] SEQUENCE OF -- all supported by RA/CA 427 PKI_Protocol OPTIONAL, 428 popMethod [4] SEQUENCE OF -- all supported by RA/CA 429 PKI_POP OPTIONAL, 430 certTemplate [5] CertTemplate OPTIONAL, 431 -- the presence of a part of CertTemplate means that the 432 -- RA/CA accepts this part to be populated by the EE 433 -- (the actual value is not important) 434 keyGenerators [6] SEQUENCE OF -- as required by RA/CA 435 KeyGenerator OPTIONAL, 436 minKeySize [7] SEQUENCE OF -- as required by RA/CA 437 KeySizeRequirement OPTIONAL, 438 maxKeySize [8] SEQUENCE OF -- as required by RA/CA 439 KeySizeRequirement OPTIONAL, 440 keyTypes [9] SEQUENCE OF -- all supported by RA/CA 441 KeyTypeRequirement OPTIONAL 442 } 444 PKI_EEIndividualParameters ::= SEQUENCE { 445 endEntityNamingInfo PKI_Entity, 446 sharedSecret BIT STRING OPTIONAL 447 } 449 PKI_EnrollmentInfo ::= SEQUENCE { 450 generalParameters PKI_GeneralParameters, 451 eeIndividualParameters PKI_EEIndividualParameters OPTIONAL 452 }