idnits 2.17.1 draft-adams-cmpaltcert-06.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 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 821. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 839. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 845. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 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.) ** There are 13 instances of too long lines in the document, the longest one being 5 characters in excess of 72. 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 (20 April 2005) is 6945 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 512 -- Looks like a reference, but probably isn't: '2' on line 514 -- Looks like a reference, but probably isn't: '1' on line 513 -- Looks like a reference, but probably isn't: '3' on line 515 -- Possible downref: Non-RFC (?) normative reference: ref. 'ASN1' ** Obsolete normative reference: RFC 3281 (ref. 'ATTCERT') (Obsoleted by RFC 5755) ** Obsolete normative reference: RFC 2797 (ref. 'CMC') (Obsoleted by RFC 5272) ** Obsolete normative reference: RFC 3369 (ref. 'CMS') (Obsoleted by RFC 3852) == Outdated reference: A later version (-09) exists of draft-ietf-pkix-rfc2510bis-08 == Outdated reference: A later version (-09) exists of draft-ietf-pkix-rfc2511bis-06 ** Obsolete normative reference: RFC 2440 (ref. 'OPENPGP') (Obsoleted by RFC 4880) Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Blinov 3 Internet Draft Guardeonic Solutions 4 Expires: 20 October 2005 C. Adams 5 University of Ottawa 6 20 April 2005 8 Alternative Certificate Formats 9 for the PKIX Certificate Management Protocols 10 12 Status of This Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 or will be disclosed, and any of which I become aware will be 17 disclosed, in accordance with RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Abstract 37 The PKIX (Public-Key Infrastructure (X.509)) Working Group of the 38 IETF (The Internet Engineering Task Force) has defined a number of 39 certificate management protocols. These protocols are primarily 40 focused on X.509v3 public-key certificates. However, it is sometimes 41 desirable to manage certificates in alternative formats as well. 42 This document specifies how such certificates may be requested using 43 the CRMF (Certificate Request Message Format) syntax that is used by 44 several different protocols. It also explains how alternative 45 certificate formats may be incorporated into such popular protocols 46 as PKIX-CMP (PKIX Certificate Management Protocol) and CMC 47 (Certificate Management Messages over CMS). 49 1. Introduction 51 Full certificate life-cycle management in a Public-Key Infrastructure 52 (PKI) requires protocol support in order to achieve automated 53 processing and end user transparency. Such protocols require 54 standardization in order to allow more than one vendor to supply 55 various pieces -- End Entity (EE), Certification Authority (CA), 56 Registration Authority (RA) -- in the PKI deployment of a single 57 organization, or to allow multiple, independently-deployed PKIs to be 58 interconnected usefully. 60 The IETF PKIX (Public-Key Infrastructure (X.509)) Working Group 61 currently has several certificate management protocols and 62 certificate request syntax specifications on the standards track. 63 Although these specifications are primarily focused on X.509v3 64 public-key certificates, some of them can be easily extended to 65 handle certificates in alternative formats as well. 67 This document focuses on a popular certificate request syntax called 68 CRMF (Certificate Request Message Format) [CRMF]. Although the 69 original specification of CRMF is X509 specific, extensions have 70 already been proposed to allow for alternative certificate templates 71 [CMP]. However, those extensions have only defined a framework, they 72 did not define the exact format to be used for various certificate 73 types. 75 This document builds on top of the framework mentioned above and 76 defines how CRMF can be used to request certificates of the following 77 types: 79 - X.509 attribute certificates [ATTCERT] 81 - OpenPGP certificates [OPENPGP] 83 The CRMF syntax is used by such popular protocols as PKIX-CMP (PKIX 84 Certificate Management Protocol) [CMP] and CMC (Certificate 85 Management Messages over CMS) [CMC]. This means that CRMF extensions 86 proposed in this document enable these protocols to request 87 certificates of the above types. However, it is not enough to be able 88 to request a certificate. The protocol should be prepared to handle 89 certificates of a particular type and, for example, return them to 90 the user. 92 This document proposes extensions to the PKIX-CMP and CMC protocols 93 that are required to manage certificates in alternative formats. 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [RFC2119]. 99 2. Certificate Template 101 One of the features of the CRMF format is its use of the CertTemplate 102 construct, which allows a requester (EE, or RA acting on behalf of an 103 EE) to specify as much or as little as they wish regarding the 104 content of the requested certificate. It is explicitly noted that 105 the CA has final authority over the actual certificate content; that 106 is, the CA may alter certificate fields or may add, delete, or alter 107 extensions according to its operating policy (if the resulting 108 certificate is unacceptable to the EE or RA, then that certificate 109 may be rejected and/or revoked prior to any publication/use). 111 A similar flexibility in the request must be available for 112 alternative certificate types as well. For this purpose, an 113 AltCertTemplate extension was introduced in [CMP] as follows 114 (where id-regCtrl = {1 3 6 1 5 5 7 5 1} as defined in [CRMF]). 116 CertRequest ::= SEQUENCE { 117 certReqId INTEGER, 118 certTemplate CertTemplate, 119 controls Controls OPTIONAL } 120 -- If certTemplate is an empty SEQUENCE (i.e., all fields 121 -- omitted), then controls MAY contain the 122 -- id-regCtrl-altCertTemplate control, specifying a template 123 -- for a certificate other than an X.509v3 public-key 124 -- certificate. Conversely, if certTemplate is not empty 125 -- (i.e., at least one field is present), then controls 126 -- MUST NOT contain id-regCtrl-altCertTemplate. The new 127 -- control is defined as follows: 128 id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= {id-regCtrl 7} 129 AltCertTemplate ::= AttributeTypeAndValue 131 In this section, an AltCertTemplate is specified for each of the 132 alternative certificate types defined in Section 1. 134 2.1. X.509 Attribute Certificate CertTemplate 136 A CertTemplate for an X.509 attribute certificate can be used by 137 simply defining an object identifier (OID) and corresponding value 138 for use in the id-regCtrl-altCertTemplate control. These are 139 specified as follows. 141 OID: 143 id-acTemplate OBJECT IDENTIFIER ::= 144 {id-regCtrl-altCertTemplate xx} 146 Value: 148 AttCertTemplate ::= SEQUENCE { 149 version AttCertVersion OPTIONAL, 150 holder Holder OPTIONAL, 151 issuer AttCertIssuer OPTIONAL, 152 signature AlgorithmIdentifier OPTIONAL, 153 serialNumber CertificateSerialNumber OPTIONAL, 154 attrCertValidityPeriod OptionalAttCertValidity OPTIONAL, 155 attributes SEQUENCE OF Attribute OPTIONAL, 156 issuerUniqueID UniqueIdentifier OPTIONAL, 157 extensions Extensions OPTIONAL 158 } 159 OptionalAttCertValidity ::= SEQUENCE { 160 notBeforeTime GeneralizedTime OPTIONAL, 161 notAfterTime GeneralizedTime OPTIONAL 162 } -- at least one must be present 164 2.2. OpenPGP Certificate CertTemplate 166 Similar to certificate templates defined above, a CertTemplate for an 167 OpenPGP certificate can be used by defining an object identifier 168 (OID) and corresponding value for use in the 169 id-regCtrl-altCertTemplate control. These are specified as follows: 171 OID: 173 id-openPGPCertTemplateExt OBJECT IDENTIFIER ::= 174 {id-regCtrl-altCertTemplate zz} 176 Value: 178 OpenPGPCertTemplateExtended ::= SEQUENCE { 179 nativeTemplate OpenPGPCertTemplate, 180 controls Controls OPTIONAL } 182 OpenPGPCertTemplate ::= OCTET STRING 183 -- contains the OpenPGP CertTemplate data structure defined 184 -- below (binary format without Radix-64 conversions) 185 -- encoded as an ASN.1 OCTET STRING 187 2.2.1. OpenPGP CertTemplate Data Structure 189 Similar to the X.509 CertTemplate, the OpenPGP CertTemplate is an 190 OpenPGP certificate (OpenPGP Transferable Public Key) [OPENPGP] with 191 all fields optional. The essential elements of an OpenPGP 192 CertTemplate are: 194 - Zero or one Public Key packet. 196 - Zero or more Direct Key Self Signature packets. 198 - Zero or more Certification Signature packets [only if no User ID 199 packets are present]. 201 - Zero or more User ID packets. 203 - After each User ID packet, zero or more Certification Signature 204 packets. 206 - Zero or more Subkey packets. 208 - After each Subkey packet, zero or one Subkey Binding Signature 209 packet. 211 Each packet in the OpenPGP CertTemplate MUST be a syntactically 212 correct OpenPGP packet. This will enable conformant implementations 213 to use existing PGP libraries for building and parsing OpenPGP 214 CertTemplates. 216 The following implications of this rule should be explicitly noted: 218 - Fields for which the OpenPGP specification defines a set of 219 permitted values (e.g. the signature type or the public key 220 algorithm fields of the Signature packet) MUST have a value from 221 the defined set. Even if the requester does not have any 222 particular preferences for, for example, the signature algorithm, 223 it MUST choose one value that is the most desirable. 225 Rationale: An alternative solution could be to define extra "any" 226 values, but this would be a modification of the OpenPGP syntax 227 which is not considered to be appropriate in this document. 229 - All subpackets of the Signature packet defined by the OpenPGP 230 specification as mandatory (e.g. the creation time and the 231 issuer's key id subpackets) MUST be present even though they do 232 not make much sense in the context of a certificate request. 234 - The number of MPIs at the end of the Key Material and the 235 Signature packets MUST match the number defined by the OpenPGP 236 specification for the given algorithm (the algorithm is controlled 237 by the value of the "algorithm" field). For example, there should 238 be 2 MPIs for DSA signatures. Note that the OpenPGP specification 239 does not define validation rules for the content of those MPIs. 241 Though it is not considered appropriate here to define extra "any" 242 values for fields of enumerated types, such values can still be 243 defined for some other fields where the OpenPGP specification is not 244 that strict. 246 The following extra values are defined in the context of the OpenPGP 247 CertTemplate. Note that these definitions do not modify the syntax 248 of OpenPGP packets and existing PGP libraries can still be used to 249 generate and parse them. 251 - For fields representing time (e.g. signature creation time): the 252 value of zero means "any time". 254 - For fields holding key IDs: the value of 0xFFFFFFFFFFFFFFFF means 255 "any key id". 257 - For signature fields: the "any signature" value is encoded as a 258 sequence of MPIs such that: 260 * the number of MPIs matches the number of MPIs defined by the 261 OpenPGP specification for the given algorithm, and 263 * the value of each MPI is 0xFF. 265 A Signature packet with the "any" value in the signature fields is 266 called a Signature Template. 268 Example: The "any signature" value for a DSA signature would 269 look like [00 08 FF 00 08 FF] 271 - For key material fields: the "any key" value is encoded as a 272 sequence of MPIs such that: 274 * the number of MPIs matches the number of MPIs defined by the 275 OpenPGP specification for the given algorithm, and 277 * the value of at least one of the MPIs is a bit string with all 278 its bits set to 1. 280 A Key Material packet with the "any" value in the key material 281 fields is called a Key Template. (See Key Template section for 282 further details.) 284 Example: The "any key" value for a DSA public key may look like 285 [00 08 FF 00 10 FF FF 00 10 85 34 00 08 FF] 287 The following rules apply to the sequence of packets within the 288 OpenPGP CertTemplate: 290 - If the Public Key packet is omitted from the OpenPGP CertTemplate 291 then this CertTemplate does not constrain the value of the public 292 key, i.e. it refers to "any" public key. 294 - The order of Signature packets following a User ID packet and the 295 order of User ID packets within the CertTemplate are not 296 important. 298 - If an OpenPGP CertTemplate does not contain any User ID packets 299 then it refers to "any" user ids that are relevant to a given 300 request. 302 2.2.2. OpenPGP CertTemplate in Certificate Requests 304 Since an OpenPGP certificate can have several certification 305 signatures, the OpenPGP CertTemplate uses Signature Templates to 306 define where certification signatures should occur. The values of 307 the fields of the Signature Templates define the parameters of the 308 new certification signatures. The following rules apply: 310 - A Signature Template that is present in the list of signatures 311 following a User ID packet requests the CA to certify this User ID 312 and the public key and replace the Signature Template with the new 313 certification signature. The Signature Template does not mandate 314 the exact place of the certification signature within the list. 315 The certification signature may be inserted at any position within 316 the list of signatures (following the certified User ID packet). 318 - A Signature Template may be present in the OpenPGP CertTemplate 319 without any preceding User ID packet. In this case it is assumed 320 that the CA knows the ID(s) of the user by some other means. A 321 Signature Template without a preceding User ID requests the CA to 322 insert all known User IDs of the user to the OpenPGP certificate 323 and certify each of them. The Signature Template defines the 324 parameters of these certification signatures. 326 - If an OpenPGP CertTemplate contains no Signature Templates then 327 the CA is requested to certify all User IDs that are present in 328 the OpenPGP CertTemplate. Such a CertTemplate does not define 329 parameters of the certification signatures explicitly, but the CA 330 SHOULD use parameters of the certification self-signatures (if 331 present in the CertTemplate) as a guidance (e.g. key flags 332 fields). 334 - If neither Signature Templates nor User IDs are present in the 335 OpenPGP CertTemplate then the CA is expected to know the ID(s) of 336 the user by some other means. In this case the CertTemplate 337 requests the CA to insert these User IDs into the OpenPGP 338 certificate and certify each of them. The parameters of the 339 certification signatures are left to the CA. 341 If several certification signatures have to be produced according to 342 an OpenPGP CertTemplate and any of them can not be granted (even with 343 modifications) for whatever reason then the whole request with this 344 OpenPGP CertTemplate MUST be rejected. 346 The client SHOULD provide enough information in its request so that 347 the CA could produce a complete OpenPGP certificate. For example, 348 the client SHOULD include in the template all relevant subkeys with 349 their binding signatures so that the CA can include them in the 350 resultant OpenPGP certificate as well. Rationale: In some 351 environments the CA/RA is responsible for publishing certificates. 353 2.2.3. Key Templates and Central Key Generation 355 The OpenPGP CertTemplate can also be used to request certification of 356 centrally-generated keys. This is accomplished by using Key 357 Templates. 359 If the Public Key packet of an OpenPGP CertTemplate is a Key Template 360 then this OpenPGP CertTemplate requests the CA/RA to generate the key 361 pair prior to certifying it. Fields of the Key Template define 362 parameters of the new key pair as follows (see examples in the 363 Appendix): 365 - The "public key algorithm" field specifies the algorithm to be 366 used for the key generation. 368 - MPI fields with the value of 0xFF ([00 08 FF]) specify that no 369 constraint is placed on the corresponding part of the key. 371 - MPI fields that contain any other bit strings with all bits set to 372 1 specify that the corresponding part of the key should be of the 373 same length as the length of the MPI (e.g. the length of the 374 public modulus n of the RSA key). 376 - MPI fields that contain any other values specify that the 377 corresponding part of the key should be of the given value (key 378 generation parameters). 380 In order to return a complete OpenPGP certificate, in addition to 381 certifying the new key and the User ID, the CA (or RA) SHOULD also 382 create a self-signature (i.e. sign the new public key and the User ID 383 with the new private key) and include it after the User ID packet. 384 This SHOULD be done for all User IDs certified by the CA. 386 If a Subkey packet of an OpenPGP CertTemplate is a Key Template then 387 this OpenPGP CertTemplate requests the CA/RA to generate a subkey. 388 Fields of the Key Template define parameters of the new subkey. The 389 new subkey obviously does not have to be certified. However, the 390 CA/RA SHOULD produce the binding signature and include it after the 391 subkey, if the CA/RA knows the user's primary private key (e.g. it 392 was centrally generated as well). Note that if the CA/RA does not 393 know the user's primary private key then the resultant OpenPGP 394 certificate returned from the CA/RA to the client will be incomplete 395 (i.e. there will be no binding signature for the subkey). It will be 396 the responsibility of the client to produce and add the binding 397 signature and to publish the final OpenPGP certificate. 399 If an OpenPGP CertTemplate contains neither PublicKey/Subkey packets 400 nor Key Template packets then it requests the CA to generate 401 keys/subkeys according to the CA's policies. 403 2.2.4. OpenPGPCertTemplateExtended 405 The OpenPGPCertTemplateExtended structure enables additional 406 extensions and controls to be added to the basic OpenPGP 407 CertTemplate. 409 2.2.5. OpenPGP CertTemplate Required Profile 411 A conformant implementation is REQUIRED to support OpenPGP 412 CertTemplates that are valid OpenPGP certificates, i.e. that have the 413 following structure (see examples in the Appendix): 415 - One Public Key packet (not a Key Template). 417 - Zero or more Direct Key Self Signature packets (without Signature 418 Templates). 420 - One or more User ID packets. 422 - After each User ID packet, zero or more Certification Signature 423 packets (without Signature Templates). 425 - Zero or more Subkey packets (without Key Templates). 427 - After each Subkey packet, one Subkey Binding Signature packet (not 428 a Signature Template). 430 A conformant implementation is REQUIRED to recognise Key Templates 431 and Signature Templates and is REQUIRED to either support them or 432 reject requests containing them if it does not. 434 3. Proof of Possession 436 A CRMF request includes a Proof of Possession (POP) field that 437 contains proof that an End Entity has possession of the private key 438 corresponding to the public key for which a certificate is requested. 440 The following rule applies to this field (with modifications from 441 [CMP]): 443 * NOTE: If CertReqMsg certReq certTemplate 444 * (or the altCertTemplate control) contains the subject and publicKey 445 * values, then poposkInput MUST be omitted and the signature MUST be 446 * computed on the DER-encoded value of CertReqMsg certReq (or the DER- 447 * encoded value of AltCertTemplate). 449 It is considered that an OpenPGP CertTemplate satisfies the 450 conditions of this note if it has a Public Key packet (not a Key 451 Template) and at least one User ID packet. 453 4. Protocol-specific Issues 455 This section explains how alternative certificate formats may be 456 incorporated into such popular protocols as PKIX-CMP and CMC. 458 4.1. PKIX-CMP 460 In PKIX-CMP, the ASN.1 [ASN1] construct, and corresponding comment, 461 for a certificate is given as follows. 463 CMPCertificate ::= CHOICE { 464 x509v3PKCert Certificate 465 } 467 -- This syntax, while bits-on-the-wire compatible with the standard 468 -- X.509 definition of "Certificate", allows the possibility of future 469 -- certificate types (such as X.509 attribute certificates, WAP WTLS 470 -- certificates, or other kinds of certificates) within this 471 -- certificate management protocol, should a need ever arise to support 472 -- such generality. 474 Building on this framework, then, this document expands the above 475 CHOICE construct as follows. 477 CMPCertificate ::= CHOICE { 478 x509v3PKCert Certificate, 479 x509v2AttCert [0] AttributeCertificate, 480 -- defined in [ATTCERT] 481 openPGPCert [2] OpenPGPCert 482 } 484 OpenPGPCert ::= OCTET STRING 485 -- contains the OpenPGP certificate (OpenPGP Transferable 486 -- Public Key) data structure from the OpenPGP specification 487 -- [OPENPGP] (binary format without Radix-64 conversions), 488 -- encoded as an ASN.1 OCTET STRING 490 Expanding the CHOICE construct as above allows X.509 attribute 491 certificates and OpenPGP certificates to be used within the PKIX-CMP 492 management messages. In the future, this construct may be expanded 493 further (in subsequent revisions of this document) to accommodate 494 other certificate types if this is found to be necessary. 496 4.2. CMC 498 CMC protocol uses the CMS (Cryptographic Message Syntax) syntax 499 [CMS], which defines the certificate type as 501 CertificateChoices ::= CHOICE { 502 certificate Certificate, 503 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 504 v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete 505 v2AttrCert [2] IMPLICIT AttributeCertificateV2 } 507 Similarly to PKIX-CMP, this CHOICE can be extended to include 508 additional types of certificates as follows. 510 CertificateChoices ::= CHOICE { 511 certificate Certificate, 512 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 513 v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete 514 v2AttrCert [2] IMPLICIT AttributeCertificateV2, 515 openPGPCert [3] IMPLICIT OpenPGPCert } 517 This allows both X.509 attribute certificates and OpenPGP 518 certificates to be used within the CMC management messages. In the 519 future, this construct may be expanded further (in subsequent 520 revisions of this document) to accommodate other certificate types if 521 this is found to be necessary. 523 The CMC specification defines certain constraints on the subject and 524 publicKey fields of the CRMF's CertTemplate structure. The same 525 constraints should apply to the AltCertTemplate structure if 526 alternative certificate types are used. For example, the CMC 527 specification mandates that 529 When CRMF message bodies are used in the Full Enrollment Request 530 message, each CRMF message MUST include both the subject and 531 publicKey fields in the CertTemplate. 533 If alternative certificate types are used, this should be extended as 535 When CRMF message bodies are used in the Full Enrollment Request 536 message, each CRMF message MUST include both the subject and 537 publicKey fields in the CertTemplate (or in the altCertTemplate 538 control). 540 5. Security Considerations 542 5.1. Protection of Alternative Certificate Templates 544 This document defines extensions to the CRMF format, so security 545 considerations from the CRMF specification [CRMF] apply here as well. 546 In particular, the security of alternative certificate templates 547 relies upon the security mechanisms of the protocol or process used 548 to communicate with CAs. 550 Exact security requirements depend on a particular PKI deployment, 551 but integrity protection and message origin authentication are 552 typically required for certification requests. The CMP and CMC 553 certificate management protocols mentioned in this document provide 554 both integrity protection and message origin authentication for 555 request messages (which includes certificate templates as well). 557 Confidentiality may also be required where alternative certificate 558 templates contain subscriber-sensitive information. The CMC protocol 559 allows the content of request messages to be encrypted. CMP does not 560 include confidentiality mechanisms for certification requests, but if 561 confidentiality is needed, it can be achieved with a lower-layer 562 security protocol (e.g. TLS or IPsec). 564 5.2. Request Authorisation 566 In order to make a decision as to whether a request should be 567 accepted, a CA should normally be able to compare the (authenticated) 568 name of the sender of the request with the request subject name. 570 For example, an End Entity may be allowed to request additional 571 certificates for himself/herself. In this case, the CA will accept a 572 request if the Sender is equal to the Subject (of course, other 573 conditions will have to be checked as well before the certificate is 574 granted). 576 If a PGP certificate is requested using the extensions proposed here, 577 the Sender field of the request will be encoded as an ASN.1 578 GeneralName (in both CMP and CMC) while the Subject will be 579 represented as a PGP UserID. Since the PGP UserID is effectively an 580 unrestricted octet string, it is not always trivial to compare these 581 two types. It is possible that an attacker may try to submit 582 requests with specially crafted UserIDs (e.g. that include obscure 583 characters) in order to trick the CA comparison algorithm and obtain 584 a PGP certificate with a UserID that belongs to someone else. 586 In these circumstances, it is safer for the CA, when building the PGP 587 certificate's UserID, to completely rebuild the UserID based on the 588 content of the authenticated Sender name rather than taking the 589 UserID from the request. To achieve this, additional information 590 about the End Entity may be required at the CA (e.g. the EE's email 591 address). 593 5.3. PGP Parser 595 Software components that implement the proposed extensions (e.g. CMP 596 or CMC servers) will necesarily increase in complexity. If a 597 "standard" server is expected to be able to parse ASN.1 streams, the 598 "extended" server is required to be able to parse PGP streams as 599 well. PGP parser code may introduce new security vulnerabilities 600 that can be exploited by an attacker to mount a DoS attack or gain 601 access to the server. 603 In order to reduce the consequences of a successful attack, it is 604 recommended to run the CMP or CMC servers on a separate machine from 605 the main CA server. These protocol servers should not have access to 606 the main CA key and should not have write access to the CA store. 608 Appendix A. Examples of OpenPGP CertTemplates 610 This Appendix presents examples of OpenPGP CertTemplates that are 611 used for requesting OpenPGP certificates from a CA. 613 A1. Simple Certificate Request 615 Alice requests an OpenPGP certificate for her public key accompanied 616 by a subkey. 618 The content of the OpenPGP CertTemplate in the request is as follows. 619 This CertTemplate conforms to the OpenPGP CertTemplate Required 620 Profile. 622 0000: 99 01 A2 === Pub Key packet === 623 0003: 04 3C 58 27 A2 11 ver 4, created 30 Jan 2002, DSA 624 0009: 00 E3 FB 9D .. 2B EF DSA prime p 625 008B: 00 A0 FF 7E .. BA 71 DSA group order q 626 00A1: 03 FF 68 BC .. 56 71 DSA group generator g 627 0123: 03 FE 38 1F .. F2 63 DSA public key value y 628 01A5: B4 19 === User ID packet === 629 01A7: 41 6C .. 6D 3E "Alice " 630 01C0: 89 00 49 === Signature packet (self-signature) === 631 01C3: 04 10 11 02 ver 4, gen cert, DSA, SHA1 632 01C7: 00 09 05 02 3C 58 27 A2 02 1B 03 633 created 30 Jan 2002, key usage: 634 sign data and certify other keys 635 01D2: 00 0A 09 10 43 5C .. 06 77 issuer key id 636 01DE: 5A C2 left 16 bits of signed hash value 637 01E0: 00 A0 EB 00 .. 1B 75 DSA value r 638 01F6: 00 A0 F4 E4 .. A8 3D DSA value s 639 020C: B9 02 0D === Public Subkey packet === 640 020F: 04 3C 58 27 A2 10 ver 4, created 30 Jan 2002, 641 Elgamal (encrypt-only) algorithm 642 0215: 08 00 F6 42 .. 0B 3B Elgamal prime p 643 0317: 00 02 02 Elgamal group generator g 644 031A: 07 FE 37 BA .. DF 21 Elgamal public key value y 645 041C: 89 00 49 === Signature packet (subkey binding) === 646 041F: 04 18 11 02 ver 4, subkey binding, DSA, SHA1 647 0423: 00 09 05 02 3C 58 27 A2 02 1B 0C 648 created 30 Jan 2002, key usage: 649 encrypt communications and storage 650 042E: 00 0A 09 10 43 5C .. 06 77 issuer key id 651 043A: C7 DE left 16 bits of signed hash value 652 043C: 00 9E 21 33 .. 39 1B DSA value r 653 0452: 00 9F 64 D7 .. 63 08 DSA value s 654 0468: 656 CA certifies Alice's User ID and the public key and creates the 657 following OpenPGP certificate: 659 0000: 99 01 A2 === Pub Key packet === 660 0003: 661 01A5: B4 19 === User ID packet === 662 01A7: 663 01C0: 89 00 49 === Signature packet (self-signature) === 664 01C3: 665 020C: 89 00 49 === Signature packet (certification) === 666 020F: 04 13 11 02 ver 4, positive cert, DSA, SHA1 667 0213: 00 09 05 02 3C 58 28 1A 02 1B 03 668 created 30 Jan 2002, key usage: 669 sign data and certify other keys 670 021E: 00 0A 09 10 F0 0D .. 1F CA issuer key id 671 022A: 06 DF left 16 bits of signed hash value 672 022C: 00 9F 57 2D .. 26 E3 DSA value r 673 0242: 00 A0 B3 02 .. CE 65 DSA value s 674 0258: B9 02 0D === Public Subkey packet === 675 025B: 676 0468: 89 00 49 === Signature packet (subkey binding) === 677 046B: 678 04B4: 680 A2. Certificate Request with Central Key Generation 682 Alice requests the CA to generate an RSA key pair that will be used 683 for signing and another RSA key pair that will be used for encryption 684 and to certify these keys. The RSA keys are requested to be 2048 685 bits long with the public exponent 65537. 687 The content of the OpenPGP CertTemplate in the request is as follows: 689 0000: 99 01 0D === Pub Key packet (Template) === 690 0003: 04 FF FF FF FF 01 ver 4, any creation date, RSA 691 0009: 08 00 FF FF .. FF FF RSA public modulus n - given length 692 010B: 00 11 01 00 01 RSA public exponent e 693 0110: B4 19 === User ID packet === 694 0112: 41 6C .. 6D 3E "Alice " 695 012B: 89 00 23 === Signature packet (Template) === 696 012E: 04 10 11 02 ver 4, gen cert, DSA, SHA1 697 0132: 00 09 05 02 FF FF FF FF 02 1B 03 698 any creation date, key usage: 699 sign data and certify other keys 700 013D: 00 0A 09 10 FF FF .. FF FF issuer key id - any 701 0149: 05 3A left 16 bits of signed hash value 702 014B: 00 08 FF DSA value r - any 703 014E: 00 08 FF DSA value s - any 704 0151: 99 01 0D === Public Subkey packet (Template) === 705 0154: 04 FF FF FF FF 01 ver 4, any creation date, RSA 706 015A: 08 00 FF FF .. FF FF RSA public modulus n - given length 707 025C: 00 11 01 00 01 RSA public exponent e 708 0261: 89 00 20 === Signature packet (Template) === 709 0264: 04 18 01 02 ver 4, subkey binding, RSA, SHA1 710 0268: 00 09 05 02 FF FF FF FF 02 1B 0C 711 any creation date, key usage: 712 encrypt communications and storage 714 0273: 00 0A 09 10 FF FF .. FF FF issuer key id - any 715 027F: 12 E6 left 16 bits of signed hash value 716 0281: 00 08 FF RSA signature value - any 717 0284: 719 CA generates keys, certifies Alice's User ID and the public key and 720 creates the following OpenPGP certificate: 722 0000: 99 01 0D === Pub Key packet === 723 0003: 04 3C 5A A5 BB 01 ver 4, created 01 Feb 2002, RSA 724 0009: 08 00 C7 21 .. 5B EB RSA public modulus n 725 010B: 00 11 01 00 01 RSA public exponent e 726 0110: B4 19 === User ID packet === 727 0112: 41 6C .. 6D 3E "Alice " 728 012B: 89 01 1F === Signature packet (self-signature) === 729 012E: 04 10 01 02 ver 4, gen cert, RSA, SHA1 730 0132: 00 09 05 02 3C 5A A5 BB 02 1B 03 731 created 01 Feb 2002, key usage: 732 sign data and certify other keys 733 014D: 00 0A 09 10 8E AF .. 1A 18 issuer key id 734 0149: 3B 21 left 16 bits of signed hash value 735 014B: 07 FE 2F 1D .. C0 81 RSA signature value 736 024D: 89 00 49 === Signature packet (certification) === 737 0250: 04 13 11 02 ver 4, positive cert, DSA, SHA1 738 0254: 00 09 05 02 3C 5A A5 DC 02 1B 03 739 created 01 Feb 2002, key usage: 740 sign data and certify other keys 741 025F: 00 0A 09 10 F0 0D .. 1F CA issuer key id 742 026B: BA C2 left 16 bits of signed hash value 743 026D: 00 9F 5E 58 .. 30 B3 DSA value r 744 0283: 00 A0 D1 D7 .. 5A AF DSA value s 745 0299: 99 01 0D === Public Subkey packet === 746 029C: 04 3C 5A A5 C5 01 ver 4, created 01 Feb 2002, RSA 747 02A2: 08 00 C3 03 .. 8C 53 RSA public modulus n 748 03A4: 00 11 01 00 01 RSA public exponent e 749 03A9: 89 01 1F === Signature packet (subkey binding) === 750 03AC: 04 18 01 02 ver 4, subkey binding, RSA, SHA1 751 03B0: 00 09 05 02 3C 5A A5 C5 05 1B 0C 752 created 01 Feb 2002, key usage: 753 encrypt communications and storage 754 03BB: 00 0A 09 10 8E AF .. 1A 18 issuer key id 755 03C7: C8 44 left 16 bits of signed hash value 756 03C9: 07 FB 04 D7 .. 75 BE RSA signature value 757 04CB: 759 Normative references 761 [ASN1] CCITT Recommendation X.208: Specification of Abstract 762 Syntax Notation One (ASN.1), 1988. 764 [ATTCERT] Farrell, S. and R. Housley, "An Internet Attribute 765 Certificate: Profile for Authorization", RFC 3281, April 766 2002. 768 [CMC] Myers, M., Liu, X., Schaad, J., and J. Weinstein, 769 "Certificate Management Messages over CMS", RFC 2797, 770 April 2000. 772 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 773 3369, August 2002. 775 [CMP] Adams, C. and S. Farrell, "Internet X.509 Public Key 776 Infrastructure: Certificate Management Protocols", 777 Internet Draft draft-ietf-pkix-rfc2510bis-08.txt, Work in 778 progress. 780 [CRMF] Myers, M., Adams, C., Solo, D., and D. Kemp, "Internet 781 X.509 Public Key Infrastructure: Certificate Request 782 Message Format (CRMF)", Internet Draft 783 draft-ietf-pkix-rfc2511bis-06.txt, Work in progress. 785 [OPENPGP] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, 786 "OpenPGP Message Format", RFC 2440, November 1998. 788 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 789 Requirement Levels", RFC 2119, March 1997. 791 Author's Address 793 Questions about this memo can be directed to: 795 Mikhail Blinov 796 Guardeonic Solutions 797 Fitzwilliam Court, Leeson Close 798 Dublin 2, Ireland 799 e-mail: mikblinov@online.ie 801 Carlisle Adams 802 School of Information Technology and Engineering (SITE) 803 University of Ottawa 804 800 King Edward Avenue 805 P.O. Box 450, Stn A 806 Ottawa, Ontario, Canada K1N 6N5 807 e-mail: cadams@site.uottawa.ca 809 Full Copyright Statement 811 Copyright (C) The Internet Society (2005). This document is subject 812 to the rights, licenses and restrictions contained in BCP 78, and 813 except as set forth therein, the authors retain all their rights. 815 This document and the information contained herein are provided on an 816 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 817 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 818 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 819 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 820 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 821 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 823 Intellectual Property 825 The IETF takes no position regarding the validity or scope of any 826 Intellectual Property Rights or other rights that might be claimed 827 pertain to the implementation or use of the technology described in 828 this document or the extent to which any license under such rights 829 might or might not be available; nor does it represent that it has 830 made any independent effort to identify any such rights. Information 831 on the ISOC's procedures with respect to rights in ISOC Documents can 832 be found in BCP 78 and BCP 79. 834 Copies of IPR disclosures made to the IETF Secretariat and any 835 assurances of licenses to be made available, or the result of an 836 attempt made to obtain a general license or permission for the use of 837 such proprietary rights by implementers or users of this 838 specification can be obtained from the IETF on-line IPR repository at 839 http://www.ietf.org/ipr. 841 The IETF invites any interested party to bring to its attention any 842 copyrights, patents or patent applications, or other proprietary 843 rights that may cover technology that may be required to implement 844 this standard. Please address the information to the IETF at ietf- 845 ipr@ietf.org.