idnits 2.17.1 draft-nourse-scep-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 page length should not exceed 58 lines per page, but there was 17 longer pages, the longest (page 2) being 86 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 41 pages 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. ** There are 8 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 6 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 859 has weird spacing: '... as the signe...' == Line 921 has weird spacing: '...content pkcsC...' == Line 1350 has weird spacing: '...lIssuer issue...' -- 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 (January 2000) is 8840 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'CERT-NONEXISTANT' on line 547 looks like a reference -- Missing reference section? 'CERT-REQ-PENDING' on line 547 looks like a reference -- Missing reference section? 'CERT-ISSUED' on line 547 looks like a reference -- Missing reference section? '0' on line 1650 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Xiaoyi Liu 2 draft-nourse-scep-00.txt Cheryl Madson 3 expires 30 June 2000 David McGrew 4 Andrew Nourse 5 Cisco Systems 6 Category: Informational January 2000 8 SCEP: The Simple Certificate Enrollment Protocol 10 Status of this Memo 12 This document is an Internet-Draft and is NOT offered in 13 accordance with Section 10 of RFC2026, and the author does not 14 provide the IETF with any rights other than to publish as an 15 Internet-Draft 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 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet- 25 Drafts as reference material or to cite them other than as 26 "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This memo provides information for the Internet community. This memo 35 does not specify an Internet standard of any kind. Distribution of 36 this memo is unlimited. 38 Copyright Notice 40 Copyright (C) Cisco Systems 2000. All Rights Reserved. 42 This protcol includes the optional use of Certificate Revocation List 43 Distribution Point (CRLDP) technology, which is a patented technology 44 of Entrust Technologies, Inc. (Method for Efficient Management of 45 Certificate Revocation Lists and Update Information (U.S. Patent 46 5,699,431)). Please contact Entrust Technologies, Inc. 47 (www.entrust.com) for more information on licensing CRLDP technology. 49 Abstract 51 This document specifies the Simple Certificate Enrollment Protocol, a 52 PKI communication protocol which leverages existing technology by using 53 PKCS#7 and PKCS#10, while following the general structure defined both 54 by NIST and by the IETF PKIX Working Group. SCEP is the evolution of 55 the enrollment protocol developed by Verisign, Inc. for Cisco Systems, 56 Inc. It now enjoys wide support in both client and CA implementations. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. SCEP Protocol Overview . . . . . . . . . . . . . . . . . . 3 62 2.1 SCEP Entity types . . . . . . . . . . . . . . . . . . . . 3 63 2.2 SCEP Operations Overview . . . . . . . . . . . . . . . . . 8 64 2.3 PKI Operation Transactional Behavior . . . . . . . . . . . 12 65 2.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 3. Transport Protocol . . . . . . . . . . . . . . . . . . . . 15 67 4. Secure Transportation: PKCS #7 . . . . . . . . . . . . . . 16 68 4.1 SCEP Message Format . . . . . . . . . . . . . . . . . . . 17 69 4.2 Signed Transaction Attributes . . . . . . . . . . . . . . 18 70 5. SCEP Transaction Specification . . . . . . . . . . . . . . 19 71 Appendix A. Cisco End Entity Subject Name Definition . . . . . 34 72 Appendix B. IPSEC Client Enrollment Certificate Request . . . . 35 73 Appendix C. Private OID Definitions . . . . . . . . . . . . . 37 74 Appendix D. Sample DAP Query URL . . . . . . . . . . . . . . . 37 75 Appendix E. CEP State Transitions . . . . . . . . . . . . . . . 38 76 Appendix F. Copyright Section . . . . . . . . . . . . . . . . . 41 78 Section 1. Introduction 80 Public key technology is becoming more widely deployed and is becoming 81 the basis for standards based security, such as the Internet Engineering 82 Task Force's IPSEC and IKE protocols. With the use of public key 83 certificates in network security protocols comes the need for a 84 certificate management protocol that Public Key Infrastructure (PKI) 85 clients and Certificate Authority servers can use to support certificate 86 life cycle operations such as certificate enrollment and revocation, and 87 certificate and CRL access. 89 In the following, Section 2 gives an overview of the PKI operations, and 90 Section 2.4 describes the security goals of the protocol and the 91 mechanisms used to achieve them. The transport protocol and the 92 security protocol PKCS#7 are described at Section 3 and Section 4, 93 respectively. The last section, Section 5, specifies each PKI operation 94 in terms of the message formats and the data structures of each 95 operation. 97 The appendices provide detailed specifications and examples. End entity 98 subject names are specified in Appendix A, attribute OIDs are specified 99 in Appendix C , and the SCEP state transitions are described in Appendix 100 E. An example of a certificate enrollment request is provided in 101 Appendix B, and an example LDAP query URL encoding is provided in 102 Appendix D. 104 The authors would like to thank Peter William of ValiCert, Inc. 105 (formerly of Verisign, Inc) and Alex Deacon of Verisign, Inc. and 106 Christopher Welles of IRE, Inc. for their contributions to this protocol 107 and to this document. 109 Section 2. SCEP Protocol Overview 111 The goal of SCEP is to support the secure issuance of certificates to 112 network devices in a scalable manner, using existing technology whenever 113 possible. The protocol supports the following operations: 115 CA and RA public key distribution 116 Certificate enrollment 117 Certificate revocation 118 Certificate query 119 CRL query 121 Certificate and CRL access can be achieved by using the LDAP protocol 122 (as specified in Appendix D), or by using the query messages defined in 123 SCEP. The use of HTTP certificate and CRL access, and the support of 124 CDP as specified in RFC2459, will be specified in a future version of 125 this document. In Section 2.1, we first define PKI entity types as well 126 as the properties of each entity type. In Section 2.2, the PKI 127 operations are described at functional level. Section 2.3 describes the 128 transaction behavior of each PKI operations. The complete PKI messages 129 are covered in Section 5. 131 2.1 SCEP Entity types 133 The entity types defined in SCEP are the end entity type (i.e., IPSEC 134 clients), the Certificate Authority (CA) entity type, and the 135 Registration Authority entity type (RA). An end entity is sometimes 136 called a "SCEP client" in the following. 138 2.1.1 End Entities 140 An end entity is an entity whose name is defined in a certificate 141 subject name field and optionally, in SubjectAltName, a X.509 142 certificate V3 extension. As an end entity, a SCEP client is identified 143 by a subject name consisting of the following naming attributes: 145 Fully qualified domain name, for example, router@cisco.com 146 IP address, or 147 Serial number. 149 In the paragraph above , the fully qualified domain name is required for 150 each SCEP client, the IP address and the serial number are optional name 151 attributes. In the certificate enrollment request, the PKCS#10 subject 152 field contains the required and optional name attributes. Based on the 153 PKCS#10 subject name information, the certificate issued to the SCEP 154 client must have the same name attributes set both in the subjectName 155 field and in the SubjectAltName extension. 157 It is important to note that a client named as Alice@cisco.com is 158 different than a client named as Alice@cisco.com plus the IP address 159 name attribute 171.69.1.129. From CA point of view, the Distinguished 160 names assigned in these two cases are distinct names. 162 For end entities which are not SCEP clients, the IPSEC profile specified 163 in RFC2459 defines the entity naming requirement. In the certificate 164 enrollment request, the entity names can either be defined in PKCS#10 165 subject name fields, or be defined in the SubjectAltName, encoded as one 166 of PKCS#10 extensions. To interoperate with IPSEC peers, the entity 167 names which are specified as in the IPSEC profile (for example, FQDN, IP 168 address and User FQDN) must be presented in certificate's SubjectAltName 169 extension. Multiple IPSEC entity names, if any, are encoded as multiple 170 values of a single SubjectAltName extension. The CA has the authority 171 to assign a distinguished name to an end entity. For SCEP clients, the 172 assigned DN should contain the SCEP client names as the relative DN. For 173 the end entities other than SCEP clients, RFC2459 provides the generic 174 guidelines. 176 The attribute identifiers and an example of SCEP client subject name are 177 specified in Appendix A. Appendix B has an example from Cisco VPN Client 178 enrollment request. 180 2.1.1.1 Local Key/Certificate/CRL Storage and Certificate-name uniqueness 182 An end entity is required to generate asymmetric key pairs and to 183 provide storage to store its private keys. If the end entity does not 184 have enough permanent memory to save its certificate, the end entity 185 should be able to query its own certificate from the CA, once the 186 certificate has been issued. The public key pairs can be generated with 187 a specific key usage. The key usage are conveyed to the CA through the 188 certificate enrollment request. All current SCEP client implementations 189 expect that there is only one pair of keys for a given subject name and 190 key usage combination, at any time. This property is called the 191 certificate-name uniqueness property, and it requires that a CA that 192 implements SCEP should enforce the unique mapping between a SCEP client 193 subject name and its key pairs with a given key usage. At any time, if 194 the subject name is changed, or if the key is updated, the existing 195 certificate should be revoked. The certificate-name uniqueness property 196 does not limit the usefulness of many applications, notably IPSEC. 197 However, it may limit the usability of other applications, or the use of 198 other applications in conjunction with IPSEC. In addition, it may be 199 difficult for a CA to enforce this property, due to design 200 considerations. To accommodate these cases, a CA may implement SCEP 201 without enforcing the certificate-name uniqueness property. Such CAs 202 must provide some other mechanism to prevent the re-transmission of an 203 enrollment request by a SCEP client (which will happen if the 204 certificate issuance message is lost or delayed in transit) from 205 creating a redundant certificate. Key update and certificate overlap is 206 not specified by the protocol. 208 2.1.1.2 End entity authentication 210 As with every protocol that uses public-key cryptography, the 211 association between the public keys used in the protocol and the 212 identities with which they are associated must be authenticated in a 213 cryptographically secure manner. This requirement is needed to 214 prevent the "man in the middle" attack, in which an adversary that can 215 manipulate the data as it travels between the protocol participants 216 can subvert the security of the protocol. To satisfy this 217 requirement, SCEP provides two authentication methods: manual 218 authentication, and authentication based on pre-shared secret. In the 219 manual mode, the end entity submitting the request is required to wait 220 until its identity can be verified by the CA operator using any 221 reliable out-of-band method. To prevent a "man-in-the-middle" attack, 222 an MD5 `fingerprint' generated on the PKCS#10 (before PKCS #7 223 envloping and signing) must be compared out-of-band between the server 224 and the end entity. SCEP clients and CAs (or RAs, if appropriate) 225 must display this fingerprint to a user to enable this verification, 226 if manual mode is used. Failing to provide this information leaves 227 the protocol vulnerable to attack by sophisticated adversaries. When 228 utilizing a pre-shared secret scheme, the server should distribute a 229 shared secret to the end entity which can uniquely associate the 230 enrollment request with the given end entity. The distribution of the 231 secret must be private: only the end entity should know this 232 secret. The actual binding mechanism between the end entity and the 233 secret is subject to the server policy and implementation. When 234 creating enrollment request, the end entity is asked to provide a 235 challenge password. When using the pre-shared secret scheme, the end 236 entity must type in the re-distributed secret as the password. In the 237 manual authentication case, the challenge password is also required 238 since the server may challenge an end entity with the password before 239 any certificate can be revoked. Later on, this challenge password 240 will be included as a PKCS#10 attribute, and is sent to the server as 241 encrypted data. The PKCS#7 envelope protects the privacy of the 242 challenge password with DES encryption. 244 2.1.1.3 Self-Signed Certificates 246 In this protocol, the communication between the end entity and the 247 certificate authority is secured by using PKCS#7 as the messaging 248 protocol. PKCS#7, however, is a protocol which assumes the communicating 249 entities already possess the peer's certificates and requires both 250 parties use the issuer names and issuer assigned certificate serial 251 numbers to identify the certificate in order to verify the signature and 252 decrypt the message. When adopting PKCS#7 as a secure protocol for the 253 certificate enrollment, however, this assumption is not true, and it may 254 not be true in some cases for cert or CRL query. To solve this problem, 255 an end entity generates a self-signed certificate for its own public 256 key. In this self-signed certificate, the issuer name is the end entity 257 subject name (the same name later be used in PKCS#10), and the 258 transaction id (defined in 2.3.1) is used as the issuer assigned 259 certificate serial number. During the certificate enrollment, the end 260 entity will first post itself as the signing authority by attaching the 261 self-signed certificate to the signed certificate request. When the 262 Certificate Authority makes the envelope on the issued certificate using 263 the public key included in the self-signed certificate, it should use 264 the same issuer name and the serial number as conveyed in the 265 self-signed certificate to inform the end entity on which private key 266 should be used to open the envelope. 268 2.1.2 Certificate Authority 270 A Certificate Authority(CA) is an entity whose name is defined in the 271 certificate issuer name field. Before any PKI operations can begin, the 272 CA generates its own public key pair and creates a self-signed CA 273 certificate. Associated with the CA certificate is a fingerprint which 274 will be used by the end entity to authenticate the received CA 275 certificate. The fingerprint is created by calculating a MD5 hash on 276 the whole CA certificate. This corresponds to the ultimate root 277 certificate, in the case where multiple level of CA exists. Before any 278 end entity can start its enrollment, this root certificate has to be 279 configured at the entity side securely. For IPSEC clients, the client 280 certificates must have SubjectAltName extension. To utilize LDAP as a 281 CRL query protocol, the certificates must have CRL Distribution 282 Point. Key usage is optional. Without key usage, the public key is 283 assumed as a general purpose public key and it can be used for all the 284 purposes. 286 A Certificate Authority may enforce certain name policy. When using 287 X.500 directory name as the subject name, all the name attributes 288 specified in the PKCS#10 request should be included as Relative DN. All 289 the name attributes as defined in RFC2459 should be specified in the 290 SubjectAltName. An example is provided in Appendix A. 292 If there is no LDAP query protocol support, the Certificate Authority 293 should answer certificate and CRL queries, and to this end it should be 294 online all the time. 296 The updating of the CA's public key is not addressed within the SCEP 297 protocol. An SCEP client can remove its copy of a CA's public key and 298 re-enroll under the CA's new public key. 300 2.1.3 Registration Authorities 302 In the environment where a RA is present, an end entity performs 303 enrollment through the RA. In order to setup a secure channel with RA 304 using PKCS#7, the RA certificate(s) have to be obtained by the client 305 in addition to the CA certificate(s). 307 In the following, the CA and RA are specified as one entity in the 308 context of PKI operation definitions. 310 2.1.4 Trusted Root Store 312 To support interoperability between IPSEC peers whose certificates are 313 issued by different CA, SCEP allows the users to configure multiple 314 trusted roots. A root is a trusted root when its certificate has been 315 configured as such in the client. An SCEP client that supports multiple 316 roots must associate with each root the information needed to to query a 317 CRL from each root. 319 Once a trusted root is configured in the client, the client can verify 320 the signatures of the certificates issued by the given root. 322 2.2 SCEP Operations Overview 324 In this section, we give a high level overview of the PKI operations as 325 defined in SCEP. 327 2.2.1 End Entity Initialization 329 The end entity initialization includes the key pair generation and the 330 configuring of the required information to communicate with the 331 certificate authority. 333 2.2.1.1 Key Pair Generation 335 Before an end entity can start PKI transaction, it first generates 336 asymmetric key pairs, using the selected algorithm (the RSA algorithm is 337 required in SCEP, and is the only algorithm in current implementations). 339 An end entity can create one or more asymmetric key pairs, for different 340 key usage. The key pairs can be created for encryption only, signing 341 only, or for all purposes. For the same key usage, there can be only 342 one key pair at any time. 344 The key pairs are saved by the client in NVRAM or other non-volatile 345 media. The identification of a key pair is based on the FQDN assigned to 346 the client and the selected key usage. Every time a new key pair is 347 generated to replace the old key pair, the existing certificates have to 348 be revoked from the CA and a new enrollment has to be completed. 350 2.2.1.2 Required Information 352 An end entity is required to have the following information configured 353 before starting any PKI operations: 355 1. the certificate authority IP address or fully qualified domain name, 356 2. the certificate authority HTTP CGI script path, and 357 the HTTP proxy information in case there is no direct Internet 358 connection to the server, 359 3. the certificate and CRL query URL, if the CRL is to be obtained by 360 from a directory server by means of LDAP. 362 2.2.2 CA/RA Certificate Distribution 364 Before any PKI operation can be started, the end entity need to get the 365 CA/RA certificates. At this time, since there has no public key 366 exchanged between the end entity and the CA/RA, the message to get the 367 CA/RA certificate can not be secured using PKCS#7 protocol. Instead, the 368 CA/RA certificate distribution is implemented as a clear HTTP Get 369 operation. After the end entity gets the CA certificate, it has to 370 authenticate the CA certificate by comparing the finger print with the 371 CA/RA operator. Since the RA certificates are signed by the CA, there is 372 no need to authenticate the RA certificates. 374 This operation is defined as a transaction consisting of one HTTP Get 375 message and one HTTP Response message: 377 END ENTITY CA SERVER 378 Get CA/RA Cert: HTTP Get message 379 -----------------------------> 380 CA/RA Cert download: HTTP Response message 381 <--------------------------------------- 382 Compute finger print and 383 call CA operator. 384 Receive call and check finger print 386 In the case of only sending CA certificate to the end entity, the CA 387 certificate is directly send back as the HTTP response payload. In the 388 case of RA presented, a degenerated PKCS#7, whose certificate chain 389 consists of both RA and CA certificates, is send back to the end entity. 391 2.2.3 Certificate Enrollment 393 An end entity starts an enrollment transaction by creating a certificate 394 request using PKCS#10 and send it to the CA/RA enveloped using the 395 PKCS#7. After the CA/RA receives the request, it will either 396 automatically approve the request and send the certificate back, or it 397 will require the end entity to wait until the operator can manually 398 authenticate the identity of the requesting end entity. Two attributes 399 (defined in PKCS#6) are included in the PKCS#10 certificate request - a 400 Challenge Password attribute and an optional ExtensionReq attribute 401 which will be a sequence of extensions the end entity would like to be 402 included in its V3 certificate extensions. The Challenge Password is 403 used for revocation and may be used (at the option of the CA/RA) 404 additionally as a one-time password for automatic enrollment. 406 In the automatic mode, the transaction consists of one PKCSReq PKI 407 Message, and one CertRep PKI message. In the manual mode, the end entity 408 enters into polling mode by periodically sending GetCertInitial PKI 409 message to the server, until the server operator completes the manual 410 authentication, after which the CA will respond to GetCertInitial by 411 returning the issued certificate. 413 The transaction in automatic mode: 415 END ENTITY CA SERVER 416 PKCSReq: PKI cert. enrollment msg 417 --------------------------------> CertRep: pkiStatus = GRANTED 418 certificate attached 419 <------------------------------ 420 Receive issued certificate. 422 The transaction in manual mode: 424 END ENTITY CA SERVER 425 PKCSReq: PKI cert. enrollment msg 426 --------------------------------> CertRep: pkiStatus = PENDING 427 <------------------------------ 428 GetCertInitial: polling msg 429 --------------------------------> CertRep: pkiStatus = PENDING 430 <------------------------------ 431 ................. CertRep: pkiStatus = GRANTED 435 certificate attached 436 <------------------------------ 437 Receive issued certificate. 439 2.2.4 End Entity Certificate Revocation 441 An end entity should be able to revoke its own certificate. Currently 442 the revocation is implemented as a manual process. In order to revoke a 443 certificate, the end entity make a phone call to the CA server 444 operator. The operator will come back asking the ChallangePassword 445 (which has been send to the server as an attribute of the PKCS#10 446 certificate request). If the ChallangePassword matches, the certificate 447 is revoked. The reason of the revocation is documented by CA/RA. 449 2.2.5 Certificate Access 451 There are two methods to query certificates. The first method is to use 452 LDAP as a query protocol. Using LDAP to query assumes the client 453 understand the LDAP scheme supported by the CA. The SCEP client assumes 454 that the subject DN name in the certificate is used as URL to query the 455 certificate. The standard attributes (userCertficiate and caCertificate) 456 are used as filter. 458 For the environment where LDAP is not available, a certificate query 459 message is defined to retrieve the certificates from CA. 461 To query a certificate from the certificate authority, an end entity 462 sends a request consisting of the certificate's issuer name and the 463 serial number. This assumes that the end entity has saved the issuer 464 name and the serial number of the issued certificate from the previous 465 enrollment transaction. The transaction to query a certificate consists 466 of one GetCert PKI message and one CertRep PKI message: 468 END ENTITY CA SERVER 469 GetCert: PKI cert query msg 470 -------------------------------> CertRep: pkiStatus = GRANTED 471 certificate attached 472 <----------------------------- 473 Receive the certificate. 475 2.2.6 CRL Distribution 477 The CA/RA will not "push" the CRL to the end entities. The query of the 478 CRL can only be initialized by the end entity. 480 There are three methods to query CRL. 482 The CRL may be retrieved by a simple HTTP GET. If the CA supports this 483 method, it should encode the URL into a CRL Distribution Point extension 484 in the certificates it issues. Support for this method should be 485 incorporated in new and updated clients, but may not be in older 486 versions. 488 The second method is to query CRL using LDAP. This assumes the CA server 489 supports CRL LDAP publishing and issues the CRL Distribution Point in 490 the certificate. The CRL Distribution Point is encoded as a DN. Please 491 refer to Appendix D for the examples of CRL Distribution Point. 493 The third method is implemented for the CA which does not support LDAP 494 CRL publishing or does not implement the CRL Distribution Point. In this 495 case, a CRL query is composed by creating a message consists of the CA 496 issuer name and the CA's certificate serial number. This method is 497 deprecated because it does not scale well and requires the CA to be a 498 high-availability service. 500 The message is send to the CA in the same way as the other SCEP 501 requests: The transaction to query CRL consists of one GetCRL PKI 502 message and one CertRep PKI message which have no certificates but CRL. 504 END ENTITY CA SERVER 505 GetCRL: PKI CRL query msg 506 ----------------------------------> CertRep: CRL attached 507 <-------------------------------- 509 2.3 PKI Operation Transactional Behavior 511 As described before, a PKI operation is a transaction consisting of the 512 messages exchanged between an end entity and the CA/RA. This section 513 will specify the transaction behavior on both the end entity and the 514 certificate authority server. Because the protocol is basically a two 515 way communication protocol without a confirmation message from the 516 initiating side, state and state resynchronization rules have to be 517 defined, in case any error happens at either side. Before the state 518 transition can be defined, the notion of transaction identifier has to 519 be defined first. 521 2.3.1 Transaction Identifier 523 A transaction identifier is a string generated by the entity when 524 starting a transaction. Since all the PKI operations defined in this 525 protocol are initiated by the end entity, it is the responsibility of 526 the end entity to generate a unique string as the transaction 527 identifier. All the PKI messages exchanged for a given PKI operations 528 must carry the same transaction identifier. The transaction identifier 529 is generated as a MD5 hash on the public key value for which the 530 enrollment request is made. This allows the SCEP client to reuse the 531 same transaction identifier if it is reissuing a request for the same 532 certificate (i.e. a certificate with the same subject, issuer, and key). 533 The SCEP protocol requires that transaction identifiers be unique, so 534 that queries can be matched up with transactions. For this reason, in 535 those cases in which separate signing and encryption certificates are 536 issued to the same end entity, the keys must be different. 538 2.3.2 State Transitions in Certificate Enrollment 540 The end entity state transitions during enrollment operation is 541 indicated in the diagram below: 542 +-<------+ 543 | | 544 GetCertInitial triggered by timeout or 545 | | manual authentication 546 | | 547 [CERT-NONEXISTANT] ------> [CERT-REQ-PENDING] ---> [CERT-ISSUED] 548 | PKCSReq | CertRep with SUCCESS 549 | | 550 | | 551 +--------<-------------------+ 552 request rejected, timeout, or error 554 As described in the section 2.2.3, certificate enrollment starts at the 555 state CERT-NONEXISTANT. Sending PKCSReq changes the state to 556 CERT-REQ-PENDING. Receiving CertRep with SUCCESS status changes the 557 state to CERT-ISSUED. In the case the server sending back the response 558 with pending status, the end entity will keep polling certificate 559 response by sending GetCertInitial to the server, until either a CertRep 560 with SUCCESS status is received, or the maximum polling number has been 561 exceeded. 563 If an error or timeout occurs in the CERT-REQ-PENDING state, the end 564 entity will transition to the CERT-NONEXISTANT state. 566 The client administrator will, eventually, start up another enrollment 567 request. It is important to note that, as long as the end entity does 568 not change its subject name or keys, the same transaction id will be 569 used in the "new" transaction. This is important because based on this 570 transaction id, the certificate authority server can recognize this as 571 an existing transaction instead of a new one. 573 2.3.3 Transaction Behavior of Certificate/CRL Access 575 There is no state maintained during certificate access and CRL access 576 transaction. When using the certificate query and CRL query messages 577 defined in this protocol, the transaction identifier is still required 578 so that the end entity can match the response message with the 579 upstanding request message. When using LDAP to query the certificate and 580 the CRL, the behavior is specified by the LDAP protocol. 582 2.4 Security 584 The security goals of SCEP are that no adversary can: 586 o subvert the public key/identity binding from that intended, 587 o discover the identity information in the enrollment requests and 588 issued certificates, 589 o cause the revocation of certificates with any non-negligible 590 probability. 592 Here an adversary is any entity other than the end entity and the CA 593 (and optionally the RA) participating in the protocol that is 594 computationally limited, but that can manipulate data during 595 transmission (that is, a man-in-the-middle). The precise meaning of 596 'computationally limited' depends on the implementer's choice of 597 cryptographic hash functions and ciphers. The required algorithms are 598 RSA, DES, and MD5. 600 The first and second goals are met through the use of PKCS#7 and PKCS#10 601 encryption and digital signatures using authenticated public keys. The 602 CA's public key is authenticated via the checking of the CA fingerprint, 603 as specified in Section 2.1.2, and the SCEP client's public key is 604 authenticated through the manual authentication or pre-shared secret 605 authentication, as specified in Section 2.1.1.2. The third goal is met 606 through the use of a Challenge Password for revocation, that is chosen 607 by the SCEP client and communicated to the CA protected by the PKCS#7 608 encryption, as specified in Section 2.2.4. 610 The motivation of the first security goal is straightforward. The 611 motivation for the second security goal is to protect the identity 612 information in the enrollment requests and certificates. For example, 613 two IPSEC hosts behind a firewall may need to exchange certificates, and 614 may need to enroll certificates with a CA that is outside of a firewall. 615 Most networks with firewalls seek to prevent IP addresses and DNS 616 information from the trusted network leaving that network. The second 617 goal enables the hosts in this example to enroll with a CA outside the 618 firewall without revealing this information. The motivation for the 619 third security goal is to protect the SCEP clients from denial of 620 service attacks. 622 Section 3 Transport Protocol 624 In the SCEP protocol, HTTP is used as the transport protocol for the PKI 625 messages. 627 3.1 HTTP "GET" Message Format 629 In the PKI protocol, CA/RA certificates are send to the end entity in 630 clear, whereas the end entity certificates are send out using the PKCS#7 631 secure protocol. This results in two types of GET operations. The type 632 of GET operation is specified by augmenting the GET message with 633 OPERATION and MESSAGE parameters in the Request-URL. OPERATION 634 identifies the type of GET operation, and MESSAGE is actually the PKI 635 message encoded as a text string. 637 The following is the syntax definition of a HTTP GET message send from 638 an end entity to a certificate authority server: 640 Request = "GET " CGI-PATH "?operation=" OPERATION "&message=" MESSAGE 641 where: 642 CGI-PATH defines the actual CGI path to invoke the CGI program which 643 parses the request. 644 OPERATION is set to be the string "PKIOperation" when the GET message 645 carries a PKI message to request certificates or CRL; OPERATION is set 646 to be the string "GetCACert" when the GET operation is used to get 647 CA/RA certificate in the clear. 648 When OPERATION is "PKIOperation", MESSAGE is a base64-encoded PKI 649 message 650 when OPERATION is "GetCACert", MESSAGE is a string which represents 651 the certificate authority issuer identifier. 653 For example. An end entity may submit a message via HTTP to the server 654 as follows: 656 GET /cgi-bin/pkiclient.exe?operation=PKIOperation&message=MIAGCSqGSIb3D 657 QEHA6CAMIACAQAxgDCBzAIBADB2MGIxETAPBgNVBAcTCE ......AAAAAA== 658 3.2 Response Message Format 660 For each GET operation, the CA/RA server will return a MIME object via 661 HTTP. For a GET operation with PKIOperation as its type, the response is 662 tagged as having a Content Type of application/x-pki-message. The body 663 of this message is a BER encoded binary PKI message. The following is an 664 example of the response: 666 "Content-Type:application/x-pki-message\n\n" 668 In the case of GET operation with a type of GetCACert, the MIME content 669 type returned will depend on whether or not an RA is in use. If there 670 is no RA, only the CA certificate is send back in the response, and the 671 response has the content type tagged as application/x-x509-ca-cert. the 672 body of the response is a DER encoded binary X.509 certificate. For 673 example: 675 "Content-Type:application/x-x509-ca-cert\n\n" 677 If there is an RA, the RA certificates are send back together with the 678 CA certificates, a certificate-only PKCS#7 SignedData is send back in 679 the response where the SignerInfo is empty. Section 5 has the detailed 680 definition of the message format in this case. The content type is 681 application/x-x509-ca-ra-cert. 683 Section 4 Secure Transportation: PKCS#7 685 PKCS#7 is a general enveloping mechanism that enables both signed and 686 encrypted transmission of arbitrary data. It is widely implemented and 687 included in the RSA tool kit. 689 In this section, the general PKCS#7 enveloped PKI message format is 690 specified. The complete PKCS#7 message format for each PKI transaction 691 will be covered in Section 5. 693 4.1 SCEP Message Format 695 As a transaction message, a SCEP message has a set of transaction 696 specific attributes and an information portion. Employing PKCS#7 697 protocol, the transaction specific attributes are encoded as a set of 698 authenticated attributes of the SignedData. The information portion will 699 first be encrypted to become Enveloped Data, and then the digest of the 700 enveloped information portion is included as one of the message digest 701 attributes and being signed together with the other transaction specific 702 attributes. 704 By applying both enveloping and signing transformations, a SCEP message 705 is protected both for the integrity of its end-end-transition 706 information and the confidentiality of its information portion. The 707 advantage of this technique over the conventional transaction message 708 format is that, the signed transaction type information and the status 709 of the transaction can be determined prior to invoke security handling 710 procedures specific to the information portion being processed. 712 The following is an example of a SCEP message with its enveloped and 713 signed data portion represented by pkcsPKISigned and 714 pkcsPKIEnveloped. The out-most of any PKI message is a blob of 715 ContentInfo, with its content type set to SignedData and the actual 716 signed data as the content. 718 pkiMessage ContentInfo ::= { 719 contentType {pkcs-7 signedData(2)} 720 content pkcsPKISigned 721 } 722 pkcsPKISigned SignedData ::= { 723 version 1 724 digestAlgorithm { iso(1) member-body(2) US(840) rsadsi(113549) 725 digestAlgorithm(2) 5} 726 contentInfo { 727 contentType {pkcs-7 1} -- data content identifier 728 content pkcsPKIEnvelope -- enveloped information portion 729 } 730 certificates -- signer certificate chain 731 signerInfo -- including signed transaction info and the digest 732 -- of the enveloped information portion as the 733 -- authenticated attributes 734 } 735 pkcsPKIEnveloped EnvelopedData ::= { 736 version 0 737 recipientInfos -- information required to open the envelop 738 encryptedContentInfo { 739 contentType {pkcs-7 1} -- data content identifier 740 contentEncryptionAlgorithm 741 encryptedContent -- encrypted information portion 742 } 743 } 745 4.2 Signed Transaction Attributes 747 The following transaction attributes are encoded as authenticated 748 attributes. Please refer to Appendix B for the OID definitions. 750 transactionID PrintableString -- Decimal value as a string 751 messageType PrintableString -- Decimal value as a string 752 pkiStatus PrintableString -- Decimal value as a string 753 failinfo PrintableString -- Decimal value as a string 754 senderNonce Octet String 755 recipientNonce Octet String 757 where: 759 The transactionID is an attribute which uniquely identify a 760 transaction. This attribute is required in all PKI messages. 762 The messageType attribute specify the type of operation performed by the 763 transaction. This attribute is required in all PKI 764 messages. Currently, the following message types are defined: 766 PKCSReq (19) -- Permits use of PKCS#10 certificate request 767 CertRep (3) -- Response to certificate or CRL request 768 GetCertInitial (20) -- Certificate polling in manual enrollment 769 GetCert (21) -- Retrieve a certificate 770 GetCRL (22) -- Retrieve a CRL 772 All response message will include transaction status information which 773 is defined as pkiStatus attribute: 775 SUCCESS (0) -- request granted 776 FAILURE (2) -- request rejected 777 PENDING (3) -- request pending for manual approval. 779 If the status in the response is FAILURE, the failinfo attribute will 780 contain one of the following failure reasons: 782 badAlg (0) -- Unrecognized or unsupported algorithm ident 783 badMessageCheck (1) -- integrity check failed 784 badRequest (2) -- transaction not permitted or supported 785 badTime (3) -- Message time field was not sufficiently close 786 to the system time 787 badCertId (4) -- No certificate could be identified matching 788 the provided criteria 790 The attributes of senderNonce and recipientNonce are the 16 byte 791 random numbers generated for each transaction to prevent the replay 792 attack. 794 When an end entity sends a PKI message to the server, a senderNonce is 795 included in the message. After the server processes the request, it will 796 send back the end entity senderNonce as the recipientNonce and generates 797 another nonce as the senderNonce in the response message. Because the 798 proposed pki protocol is a two-way communication protocol, it is clear 799 that the nonce can only be used by the end entity to prevent the 800 replay. The server has to employ extra state related information to 801 prevent a replay attack. 803 Section 5. SCEP Transaction Specification 805 In this section each SCEP transaction is specified in terms of the 806 complete messages exchanged during the transaction. 808 5.1 Certificate Enrollment 810 The certificate enrollment transaction consists of one PKCSReq message 811 send to the certificate authority from an end entity, and one CertRep 812 message send back from the server. The pkiStatus returned in the 813 response message is either SUCCESS, or FAILURE, or PENDING. The 814 information portion of a PKCSReq message is a PKCS#10 certificate 815 request, which contains the subject Distinguished Name, the subject 816 public key, and two attributes, a ChallangePassword attribute to be used 817 for revocation, and an optional ExtensionReq attribute which will be a 818 sequence of extensions the end entity expects to be included in its V3 819 certificate extensions. One of the extension attribute specifies the key 820 usage. The pkiStatus is set to SUCCESS when the certificate is send 821 back in CertRep; the pkiStatus is set to FAILURE when the certificate 822 request is rejected; the pkiStatus is set to PENDING when the server has 823 decided to manually authenticate the end entity. The messages exchanged 824 in the manual authentication mode is further specified in Section 5.2. 826 Precondition: 827 Both the end entity and the certificate authority have completed their 828 initialization process. The end entity has already been configured 829 with the CA/RA certificate. 831 Postcondition: 832 Either the certificate is received by the end entity, or the end 833 entity is notified to do the manual authentication, or the request 834 is rejected. 836 5.1.1 PKCSReq Message Format 838 A PKCSReq message is created by following the steps defined below: 840 1. Create a PKCS#10 certificate request which is signed by the end 841 entity's private key, corresponding to the public key included in 842 the PKCS#10 certificate request. This constitutes the information 843 portion of PKCSReq. 845 2. Encrypt the PKCS#10 certificate request using a randomly generated 846 content-encryption key. This content-encryption key is then 847 encrypted by the CA's public key and included in the recipientInfo. 848 This step completes the "envelope" for the PKCS#10 certificate 849 request. 851 3. Generate a unique string as the transaction id. 853 4. Generate a 16 byte random number as senderNonce. 855 5. Generate message digest on the enveloped PKCS#10 certificate request 856 using the selected digest algorithm. 858 6. Create SignedData by adding the end entity's self-signed certificate 859 as the signer's public key certificate. Include the transaction id, 860 the senderNonce and the message digest as the authenticated 861 attributes and sign the attributes using the end entity's private 862 key. This completes the SignedData. 864 7. The SignedData is prepended with the ContenInfo blob which indicates 865 a SignedData object. This final step completes the create of a 866 complete PKCSReq PKI message. 868 In the following, the PKCSReq message is defined following the ASN.1 869 notation. 871 For readability, the values of a field is either represented by a quoted 872 string which specifies the intended value, or a constant when the value 873 is known. 875 -- PKCSReq information portion 876 pkcsCertReq CertificationRequest ::= { -- PKCS#10 877 version 0 878 subject "the end entity's subject name" 879 subjectPublicKeyInfo { 880 algorithm {pkcs-1 1} -- rsa encryption 881 subjectPublicKey "BER encoding of the end entity's public key" 882 } 883 attributes { 884 challengePassword {{pkcs-9 7} "password string" } 885 extensions 886 } 887 signatureAlgorithm {pkcs-1 4} -- MD5WithRSAEncryption 888 signature "bit string which is created by signing inner content 889 of the defined pkcsCertReq using end entity's private 890 key, corresponding to the public key included in 891 subjectPublicKeyInfo." 892 } 893 -- Enveloped information portion 894 pkcsCertReqEnvelope EnvelopeData ::= { -- PKCS#7 895 version 0 896 recipientInfo { 897 version 0 898 issuerAndSerialNumber { 899 issuer "the CA issuer name" 900 serialNumber "the CA certificate serial number" 901 } 902 keyEncryptionAlgorithm {pkcs-1 1} -- rsa encryption 903 encryptedKey "content-encryption key 904 encrypted by CA public key" 905 } 906 encryptedContentInfo { 907 contentType {pkcs-7 1} -- data content 908 contentEncryptionAlgorithm "object identifier 909 for DES encryption" 910 encryptedContent "encrypted pkcsCertReq using the content- 911 encryption key" 912 } 913 } 914 -- Signed PKCSReq 915 pkcsCertReqSigned SignedData ::= { -- PKCS#7 916 version 1 917 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 918 digestAlgorithm(2) 5} 919 contentInfo { 920 contentType {pkcs-7 1} -- data content identifier 921 content pkcsCertReqEnvelope 922 } 923 certificate { -- the end entity's self-signed certificate 924 version 3 925 serialNumber "the transaction id associated with enrollment" 926 signature {pkcs-1 4} -- md5WithRSAEncryption 927 issuer " the end entity's subject name" 928 validity { 929 notBefore "a UTC time" 930 notAfter "a UTC time" 931 } 932 subject "the end entity's subject name" 933 subjectPublicKeyInfo { 934 algorithm {pkcs-1 1} 935 subjectPublicKey "BER encoding of end entity's public key" 936 } 937 signatureAlgorithm {pkcs-1 4} 938 signature "the signature generated by using the end entity's 939 private key corresponding to the public key in 940 this certificate." 941 } 942 signerInfo { 943 version 1 944 issuerAndSerialNumber { 945 issuer "the end entity's subject name" 946 serialNumber "the transaction id associated 947 with the enrollment" 948 } 949 digestAlgorithm {iso(0) member-body(2) US(840) rsadsi(113549) 950 digestAlgorithm(2) 5} 951 authenticateAttributes { 952 contentType {{pkcs-9 3} {pkcs-7 1}} 953 messageDigest {{pkcs-9 4} "an octet string"} 954 transaction-id {{id-attributes transId(7)} "printable 955 string"} 956 -- this transaction id will be used 957 -- together with the subject name as 958 -- the identifier of the end entity's key 959 -- pair during enrollment 960 messageType {{id-attributes messageType(2)} "PKCSReq"} 961 senderNonce {{id-attributes senderNonce(5)} 962 "a random number encoded as a string"} 963 } 964 digestEncryptionAlgorithm {pkcs-1 1} -- rsa encryption 965 encryptedDigest "encrypted digest of the authenticated 966 attributes using end entity's private key" 967 } 968 } 969 pkcsReq PKIMessage ::= { 970 contentType {pkcs-7 2} 971 content pkcsCertRepSigned 972 } 974 5.1.2 CertRep Message Format 976 The response to an SCEP enrollment request is a CertRep message. 977 The status of the request is 979 5.1.2.1 PENDING Response 981 When the CA is configured to manually authenticate the end entity, 982 the CertRep is send back with the attribute pkiStatus set to PENDING. 983 The information portion for this message is empty. Only the transaction 984 required attributes are send back. 986 CertRepSigned SignedData ::= { -- PKCS#7 987 version 1 988 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 989 digestAlgorithm(2) 5} 990 contentInfo { -- empty content 991 contentType {pkcs-7 1} 992 } 993 signerInfo { 994 version 1 995 issuerAndSerialNumber { 996 issuer "the CA issuer name" 997 serialNumber "the CA certificate issuer serial number" 998 } 999 digestAlgorithm (iso(1) member-body(2) US(840) rsadsi(113549) 1000 digestAlgorithm(2) 5} 1001 authenticateAttributes { 1002 contentType {{pkcs-9 3} {pkcs-7 1}} 1003 messageDigest {{pkcs-9 4} NULL} 1004 messageType {{id-attribute messageType(0)} "CertRep"} 1005 transaction-id {{id-attributes transid(7)} "printable 1006 string"} 1007 --- same transaction id used in PKCSReq 1008 pkiStatus {{id-attributes pkiStatus(1)} "PENDING"} 1009 recipientNonce {{id-attributes recipientNonce(3)}<16 bytes>} 1010 senderNonce {{id-attributes senderNonce(5)} <16 bytes>} 1011 } 1012 digestEncrytionAlgorithm {pkcs-1 1} 1013 encryptedDigest "encrypted message digest of the authenticate 1014 attributes using the CA's private key" 1015 } 1016 } 1017 CertRep PKIMessage ::= { 1018 contentType {pkcs-7 2} 1019 content CertRepSigned 1020 } 1021 5.1.2.2 Failure Response 1023 In this case, the CertRep send back to the end entity is same as the 1024 CertRep send back in the PENDING case, except that the pkiStatus 1025 attribute is set to FAILURE, and the failInfo attribute should be 1026 included: 1028 pkistatus {{id-attributes pkiStatus(1)} "FAILURE"} 1029 failInfo {{id-attributes pkiStatus(1)} "the reason to reject"} 1031 5.1.2.3 SUCCESS response 1033 In this case, the information portion of CertRep will be a degenerated 1034 PKCS#7 which contains the end entity's certificate. It is then enveloped 1035 and signed as below: 1037 pkcsCertRep SignedData ::= { -- PKCS#7 1038 version 1 1039 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1040 digestAlgorithm(2) 5} 1041 contentInfo { -- empty content since this is degenerated PKCS#7 1042 contentType {pkcs-7 1} 1043 } 1044 certificates { 1045 certificate { -- issued end entity's certificate 1046 version 3 1047 serialNumber "issued end entity's certificate serial number" 1048 signature {pkcs-1 4} -- md5WithRSAEncryption 1049 issuer "the certificate authority issuer name" 1050 validity { 1051 notBefore "UTC time" 1052 notAfter "UTC time" 1053 } 1054 subject "the end entity subject name as given in PKCS#10" 1055 subjectPublicKeyInfo { 1056 algorithm {pkcs-1 1} 1057 subjectPublicKey "a BER encoding of end entity public 1058 key as given in PKCS#10" 1059 } 1060 extensions " the extensions as given in PKCS#10" 1061 signatureAlgorithm {pkcs-1 4} 1062 signature " the certificate authority signature" 1063 } 1064 certificate "the certificate authority certificate" 1065 } 1066 } 1067 pkcsCertRepEnvelope EnvelopedData ::= { -- PKCS#7 1068 version 0 1069 recipientInfo { 1070 version 0 1071 issuerAndSerialNumber { -- use issuer name and serial number as 1072 -- conveyed in end entity's self-signed 1073 -- certificate, included in the PKCSReq 1074 issuer "the end entity's subject name" 1075 serialNumber "the serial number defined by the end entity in 1076 its self-signed certificate" 1077 } 1078 keyEncryptionAlgorithm {pkcs-1 1} 1079 encryptedKey "content-encrypt key encrypted by the end entity's 1080 public key which is same key as authenticated in 1081 the end entity's certificate" 1082 } 1083 encryptedContentInfo { 1084 contentType {pkcs-7 1} -- data content identifier 1085 contentEncryptionAlgorithm "OID for DES encryption" 1086 encryptedContent "encrypted pkcsCertRep using content encryption 1087 key" 1088 } 1089 } 1090 pkcsCertRepSigned SignedData ::= { -- PKCS#7 1091 version 1 1092 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1093 digestAlgorithm(2) 5} 1094 contentInfo { 1095 contentType {pkcs-7 1} 1096 content pkcsCertRepEnvelope 1097 } 1098 signerInfo { 1099 version 1 1100 issuerAndSerialNumber { 1101 issuer "the certificate authority issuer name" 1102 serialNumber "the CA certificate's serial number" 1103 } 1104 digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) 1105 digestAlgorithm(2) 5} 1106 authenticateAttributes { 1107 contentType {{pkcs-9 3} {pkcs-7 1}} 1108 messageDigest {{pkcs-9 4} "a octet string"} 1109 messageType {{id-attribute messageType(2)} "CertRep"} 1110 transaction-id {{id-attributes transId(7)} "printable 1111 string"} 1112 -- same transaction id as given in PKCSReq 1113 pkiStatus {{id-attributes pkiStatus(1) "SUCCESS"} 1114 recipientNonce {{id-attribute recipientNonce(4)}<16 bytes>} 1115 senderNonce {{ id-attributes senderNonce(5) <16 bytes>} 1116 } 1117 digestEncryptionAlgorithm {pkcs-1 1} 1118 encryptedDigest "encrypted digest of authenticate attributes 1119 using CA's private key " 1120 } 1121 } 1122 CertRep PKIMessage ::= { 1123 contentType {pkcs-7 2} 1124 content pkcsCertRepSigned 1125 } 1127 5.2 Poll for End Entity Initial Certificate 1129 Either triggered by the PENDING status received from the CertRep, or by 1130 the non-response timeout for the previous PKCSReq, an end entity will 1131 enter the polling state by periodically sending GetCertInitial to the 1132 server, until either the request is granted and the certificate is sent 1133 back, or the request is rejected, or the the configured time limit for 1134 polling is exceeded. 1136 Since GetCertInitial is part of the enrollment, the messages 1137 exchanged during the polling period should carries the same transaction 1138 identifier as the previous PKCSReq. 1140 PreCondition 1141 Either the end entity has received a CertRep with pkiStatus set to be 1142 PENDING, or the previous PKCSReq has timed out. 1144 PostContition 1145 The end entity has either received the certificate, or be rejected of 1146 its request, or the polling period ended as a failure. 1148 5.2.1 GetCertInitial Message Format 1150 Since at this time the certificate has not been issued, the end entity 1151 can only use the CA issuer name and the end entity's subject name to 1152 indicate the polled certificate. Combined with the transaction 1153 identifier, the certificate authority server should be able to uniquely 1154 identify the polled certificate request (a subject name can have more 1155 than one outstanding certificate request when the key usage attributes 1156 are selected). 1158 -- Information portion 1160 pkcsGetCertInitial issuerAndSubject ::= { 1161 issuer "the certificate authority issuer name" 1162 subject "the end entity subject name as given in PKCS#10" 1163 } 1164 pkcsGetCertInitialEnvelope EnvelopedData ::= { 1165 version 0 1166 recipientInfo { 1167 version 0 1168 issuerAndSerialNumber { 1169 issuer "the CA issuer name" 1170 serialNumber "the CA certificate serial number" 1171 } 1172 keyEncryptionAlgorithm {pkcs-1 1} 1173 encryptedKey "content-encrypt key encrypted by CA's public key" 1174 } 1175 encryptedContentInfo { 1176 contentType {pkcs-7 1} -- data content 1177 contentEncryptionAlgorithm "OID for DES encryption" 1178 encryptedContent "encrypted getCertInital" 1179 } 1180 } 1181 pkcsGetCertInitialSigned SignedData ::= { -- PKCS#7 1182 version 1 1183 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1184 digestAlgorithm(2) 5} 1185 contentInfo { 1186 contentType {pkcs-7 1} 1187 content pkcsGetCertIntialEnvelope 1188 } 1189 signerInfo { 1190 version 1 1191 issuerAndSerialNumber { 1192 issuer "end entity's subject name" 1193 serialNumber "the transaction id used in previous PKCSReq" 1194 } 1195 digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) 1196 digestAlgorithm(2) 5} 1197 authenticateAttributes { 1198 contentType {{pkcs-9 3} {pkcs-7 1}} 1199 messageDigest {{pkcs-9 4} "an octet string"} 1200 -- digest of getCertInitial 1201 messageType {{id-attribute messageType(2)} "GetCertInitial"} 1202 transaction-id {{id-attributes transId(7)} "printable 1203 string"} 1204 -- same transaction idused in previous PKCSReq 1205 senderNonce {{id-attribute senderNonce(3)} 0x<16 bytes>} 1206 } 1207 digestEncryptionAlgorithm {pkcs-1 1} 1208 encryptedDigest "encrypted digest of authenticateAttributes" 1209 } 1210 } 1211 GetCertInitial PKIMessage ::= { 1212 contentType {pkcs-7 2} 1213 content pkcsGetCertInitialSigned 1214 } 1215 5.2.2 GetCertInitial Response Message Format 1217 The CertRep message in this case is same as defined for the case of PKCSReq. 1219 5.3 Certificate Access 1221 The certificate query message defined in this section is an option when 1222 the LDAP server is not available to provide the certificate query. An 1223 end entity should be able to query an issued certificate from the 1224 certificate authority, as long as the issuer name and the issuer 1225 assigned certificate serial number is known to the requesting end 1226 entity. This transaction is not intended to provide the service as a 1227 certificate directory service. More complicated query mechanism has to 1228 be defined in order to allow an end entity to query a certificate using 1229 various different fields. 1231 This transaction consists of one GetCert message send to the server by 1232 an end entity, and one CertRep message send back from the server. 1234 PreCondition 1235 The queried certificate have been issued by the certificate authority 1236 and the issuer assigned serial number is known. 1238 PostContition 1239 Either the certificate is send back or the request is rejected. 1241 5.3.1 GetCert Message Format 1243 The queried certificate is identified by its issuer name and the issuer 1244 assigned serial number. If this is a query for an arbitrary end entity's 1245 certificate, the requesting end entity should includes its own CA issued 1246 certificate in the signed envelope. If this is a query for its own 1247 certificate (assume the end entity lost the issued certificate, or does 1248 not have enough non-volatile memory to save the certificate), then the 1249 self-signed certificate has to be included in the signed envelope. 1251 pkcsGetCert issuerAndSerialNumber ::= { 1252 issuer "the certificate issuer name" 1253 serialNumber "the certificate serial number" 1254 } 1255 pkcsGetCertEnvelope EnvelopedData ::= { 1256 version 0 1257 recipientInfo { 1258 version 0 1259 issuerAndSerialNumber { 1260 issuer "the CA issuer name" 1261 serialNumber "the CA certificate serial number" 1262 } 1263 keyEncryptionAlgorithm {pkcs-1 1} 1264 encryptedKey "content-encrypt key encrypted by CA public key" 1265 } 1266 encryptedContentInfo { 1267 contentType {pkcs-7 1} -- data content 1268 contentEncryptionAlgorithm "OID for DES encryption" 1269 encryptedContent "encrypted pkcsGetCert using the content 1270 encryption key" 1271 } 1272 } 1273 pkcsGetCertSigned SignedData ::= { 1274 version 1 1275 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1276 digestAlgorithm(2) 5} 1277 contentInfo { 1278 contentType {pkcs-7 1} 1279 content pkcsGetCertEnvelope 1280 } 1281 certificates { 1282 certificate "CA issued certificate" 1283 or "self-signed certificate" 1284 } 1285 signerInfo { 1286 version 1 1287 issuerAndSerialNumber { 1288 issuer "the end entity's subject name" 1289 serialNumber "end entity's certificate serial number" 1290 } 1291 digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) 1292 digestAlgorithm(2) 5} 1293 authenticateAttributes { 1294 contentType {{pkcs-9 3} {pkcs-7 1}} 1295 messageDigest {{pkcs-9 4} "an octet string"} 1296 -- digest of pkcsGetCertEnvelope 1297 messageType {{id-attribute messageType(2)} "GetCert"} 1298 transaction-id {{id-attributes transId(7)} "printable 1299 string"} 1300 senderNonce {{id-attribute senderNonce(3)} <16 bytes>} 1301 } 1302 digestEncryptionAlgorithm {pkcs-1 1} 1303 encryptedDigest "encrypted digest of authenticateAttributes" 1304 } 1305 } 1306 GetCert PKIMessage ::= { 1307 contentType {pkcs-7 2} 1308 content pkcsGetCertSigned 1309 } 1311 5.3.2 CertRep Message Format 1313 In this case, the CertRep from the server is same as the CertRep for the 1314 PKCSReq, except that the server will only either grant the request or 1315 reject the request. Also, the recipientInfo should use the CA issuer 1316 name and CA assigned serial number to identify the end entity's key pair 1317 since at this time, the end entity has received its own certificate. 1319 5.4 CRL Access 1321 The CRL query message defined in this section is an option when the LDAP 1322 server is not available to provide the CRL query. In the PKI protocol 1323 proposed here, only the end entity can initiate the transaction to 1324 download CRL. An end entity send GetCRL request to the server and the 1325 server send back CertRep whose information portion is a degenerated 1326 PKCS#7 which contains only the most recent CRL. The size of CRL included 1327 in the CertRep should be determined by the implementation. 1329 PreCondition 1330 The certificate authority certificate has been downloaded to the end 1331 entity. 1333 PostCondition 1334 CRL send back to the end entity. 1336 5.4.1 GetCRL Message format 1338 The CRL is identified by using both CA's issuer name and the CA 1339 certificate's serial number: 1341 pkcsGetCRL issuerAndSerialNumber { 1342 issuer "the certificate authority issuer name" 1343 serialNumber "certificate authority certificate's serial number" 1344 } 1346 When the CRLDistributionPoint is supported, the pkcsGetCRL is defined as 1347 the following: 1349 pkcsGetCRL SEQUENCE { 1350 crlIssuer issuerAndSerialNumber 1351 distributionPoint CE-CRLDistPoints 1352 } 1353 where CE-CRLDisPoints is defined in X.509. 1355 pkcsGetCRLEnvelope EnvelopedData ::= { 1356 version 0 1357 recipientInfo { 1358 version 0 1359 issuerAndSerialNumber { 1360 issuer "the certificate authority issuer name" 1361 serialNumber "the CA certificate's serial number" 1362 } 1363 keyEncryptionAlgorithm {pkcs-1 1} 1364 encryptedKey "content-encrypt key encrypted by CA public key" 1365 } 1366 encryptedContentInfo { 1367 contentType {pkcs-7 1} -- data content 1368 contentEncryptionAlgorithm "OID for DES encryption" 1369 encryptedContent "encrypted pkcsGetCRL" 1370 } 1371 } 1372 pkcsGetCRLSigned SignedData ::= { 1373 version 1 1374 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1375 digestAlgorithm(2) 5} 1376 contentInfo { 1377 contentType {pkcs-7 1} 1378 content pkcsGetCRLEnvelope 1379 } 1380 certificates { 1381 certificate "the CA issued end entity's certificate" 1382 } 1383 signerInfo { 1384 version 1 1385 issuerAndSerialNumber { 1386 issuer "the end entity's issuer name" 1387 serialNumber "the end entity's certificate serial number" 1388 } 1389 digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) 1390 digestAlgorithm(2) 5} 1391 authenticateAttributes { 1392 contentType {{pkcs-9 3} {pkcs-7 1}} 1393 messageDigest {{pkcs-9 4} 0x<16/20 bytes>} 1394 -- digest of pkcsGetCRLEnvelope 1395 messageType {{id-attribute messageType(2)} "CertCRL"} 1396 transaction-id {{id-attributes transId(7)} "printable 1397 string"} 1398 senderNonce {{id-attribute senderNonce(3)} <16 bytes>} 1399 } 1400 digestEncryptionAlgorithm {pkcs-1 1} 1401 encryptedDigest "encrypted digest of authenticateAttributes" 1402 } 1403 } 1404 GetCRL PKIMessage ::= { 1405 contentType {pkcs-7 2} 1406 content pkcsGetCRLSigned 1407 } 1409 5.4.2 CertRep Message Format 1411 The CRL is send back to the end entity through CertRep message. The 1412 information portion of this message is a degenerated PKCS#7 SignedData 1413 which contains only a CRL. 1415 pkcsCertRep SignedData ::= { 1416 version 1 1417 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1418 digestAlgorithm(2) 5} 1419 contentInfo { 1420 contentType {pkcs-7 1} 1421 } 1422 crl { 1423 signature {pkcs-1 4} 1424 issuer "the certificate authority issuer name" 1425 lastUpdate "UTC time" 1426 nextUpdate "UTC time" 1427 revokedCertificate { 1428 -- the first entry 1429 userCertificate "certificate serial number" 1430 revocationData "UTC time" 1431 .... 1432 -- last entry 1433 userCertificate "certificate serial number" 1434 revocationData "UTC time" 1435 } 1436 } 1437 pkcsCertRepEnvelope EnvelopedData ::= { 1438 version 0 1439 recipientInfo { 1440 version 0 1441 issuerAndSerialNumber { 1442 issuer "the end entity's issuer name" 1443 serialNumber "the end entity certificate serial number" 1444 } 1445 keyEncryptionAlgorithm {pkcs-1 1} 1446 encryptedKey "content-encrypt key encrypted by end entity's 1447 public key " 1448 } 1449 encryptedContentInfo { 1450 contentType {pkcs-7 1} -- data content 1451 contentEncryptionAlgorithm "OID for DES encryption" 1452 encryptedContent "encrypted pkcsCertRep using end entity's 1453 public key" 1454 } 1455 } 1456 pkcsCertRepSigned SignedData ::= { -- PKCS#7 1457 version 1 1458 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1459 digestAlgorithm(2) 5} 1460 contentInfo { 1461 contentType {pkcs-7 1} 1462 content pkcsCertRepEnvelope 1463 } 1464 signerInfo { 1465 version 1 1466 issuerAndSerialNumber { 1467 issuer "the certificate authority issuer name" 1468 serialNumber "the CA certificate's serial number" 1469 } 1470 digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) 1471 digestAlgorithm(2) 5} 1472 authenticateAttributes { 1473 contentType {{pkcs-9 3} {pkcs-7 1}} 1474 messageDigest {{pkcs-9 4} "an octet string"} 1475 -- digest of pkcsCertRepEnvelope 1476 messageType {{id-attribute messageType(2)} "CertRep"} 1477 transaction-id {{id-attributes transId(7)} "printable 1478 string"} 1479 -- same transaction id as given in PKCSReq 1480 pkiStatus {{id-attributes pkiStatus(1) "GRANT"} 1481 recipientNonce{{id-attribute recipientNonce(4)}<16 bytes>} 1482 senderNonce {{id-attribute senderNonce (5) 0x<16 bytes>} 1483 } 1484 digestEncryptionAlgorithm {pkcs-1 1} 1485 encryptedDigest "encrypted digest of authenticatedAttributes 1486 using CA private key" 1487 } 1488 } 1490 NOTE:The PKCS#7 EncryptedContent is specified as an octet string, but 1491 SCEP entities must also accept a sequence of octet strings as a valid 1492 alternate encoding. 1493 This alternate encoding must be accepted wherever PKCS #7 Enveloped 1494 Data is specified in this document. 1496 5.5 Get Certificate Authority Certificate 1498 Before any transaction begins, end entities have to get the CA (and 1499 possibly RA) certificate(s) first. Since no public keys have been 1500 exchanged, the message can not be encrypted and the response must be 1501 authenticated by out-of-band means. These certs are obtained by means 1502 of an HTTP GET message. To get the CA certificate, the end entity does a 1503 "HTTP GET" and receives a plan X.509 certificate in response. In the 1504 request, the URL identifies a CGI script on the server and passes the CA 1505 issuer identifier as the parameter to the CGI script. Once the CA 1506 certificate is received by the end entity, a fingerprint is generated 1507 using MD5 hash algorithm on the whole CA certificate. This fingerprint 1508 is verified by some positive out-of-band means, such as a phone call. 1510 5.5.1 GetCACert HTTP Message Format 1511 "GET" CGI-SCRIPT "?" "operation=GetCACert" "&" "message" CA-IDENT 1512 where: 1513 CGI-SCRIPT is the path and the cgi script to process the rest of 1514 the message. For example: /cgi-bin/pkiclient.exe. 1515 CA-IDENT is any string which is understood by the CA. 1516 For example, it could be a domain name like ietf.org 1518 5.5.2 Response 1520 The response for GetCACert is different between a case where the CA 1521 directly communicated with the end entity during the enrollment, and the 1522 case where a RA exists and the end entity communicates with the RA 1523 during the enrollment. 1525 5.5.2.1 CA Certificate Only Response 1527 A binary X.509 CA certificate is send back as a MIME object with a 1528 Content-Type of application/x-x509-ca-cert. 1530 5.5.2.2 CA and RA Certificates Response 1532 When an RA exists, both CA and RA certificates must be sent back in 1533 the response to the GetCACert request. The RA certificate(s) must be 1534 signed by the CA. A certificates-only PKCS#7 SignedData is used to 1535 carry the certificates to the end entity, with a Content-Type of 1536 application/x-x509-ca-ra-cert. 1538 The following is the ASN.1 definition of Cert-Only PKCS#7: 1540 certOnly SignedData ::= { 1541 version 1 1542 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1543 digestAlgorithm(2) 5} 1544 contentInfo { 1545 contentType {pkcs-7 1} -- data content identifier 1546 content -- NULL 1547 } 1548 certificates -- the RA and CA certificates. 1549 } 1551 CARACerts PKIMessage ::= { -- special pki message sent in the clear 1552 contentType {pkcs-7 2} 1553 content certOnly 1554 } 1556 Appendix A: Cisco End Entity Subject Name Definition 1558 As an end entity, a SCEP client has its subject name defined as a set of 1559 name attributes: 1561 CiscoSubjectName ::= { 1562 SEQUENCE OF { 1563 SET OF { 1564 SEQUENCE { -- required attribute 1565 unStructuredName OID 1566 name IA5String} 1567 } 1568 SET OF { 1569 SEQUENCE { -- optional attribute 1570 unStructuredAddress OID 1571 address PrintableString} 1572 } 1573 SET OF { 1574 SEQUENCE { -- optional attribute 1575 serialNumber OID 1576 number PrintableString} 1577 } 1578 } 1579 } 1581 where the OIDs are defined in the following standards: 1582 OIDs defined in PKCS#9: 1584 pkcs_prefix {iso(1),member-body(2),US(840),rsadsi(113549),pkcs(1)} 1585 unStructuredName {pkcs_prefix, 9, 2} 1586 unStructuredAddress {pkcs_prefix, 9, 8} 1588 OID defined in X.520: 1589 serialNumber 1591 An example of the instantiated name definition is given below: 1592 ciscoRouterAlice CiscoSubjectName ::= { 1593 { 1594 { unstrcutedNameOid, "alice.cisco.com"} 1595 { unstructuredAddrresOid, "172.21.114.67"} 1596 { serialNumberOid, "22334455"} 1597 } 1598 } 1600 Alternatively, the ip address and the FQDN of a SCEP client can also be 1601 included in the V3 extension subjectAltName. When the subjectAltName 1602 extension attribute is present, both the subjectAltName fields and the 1603 subjectName field could have the IP address and the FQDN information. 1604 When the X.500 directory is used by the CA to define the name space, the 1605 subject name defined above become a RDN which is part of DN binded to 1606 the end entity's public key in the certificate. 1608 A sample of DN assigned by Entrust CA is given below (assume the same 1609 ciscoRouterAlice is used as the end entity defined subject name): 1611 OU = InteropTesting, O = Entrust Technologies, C = CA 1612 RDN = {"alice.cisco.com", "172.21.114.67", "22334455"} 1614 Appendix B: IPSEC Client Enrollment Certificate Request 1616 The following is the certificate enrollment request (PKCS#10) as created 1617 by Cisco VPN Client: 1619 -----END NEW CERTIFICATE REQUEST----- 1620 0 30 439: SEQUENCE { 1621 4 30 288: SEQUENCE { 1622 8 02 1: INTEGER 0 1623 11 30 57: SEQUENCE { 1624 13 31 55: SET { 1625 15 30 53: SEQUENCE { 1626 17 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 1627 22 13 46: PrintableString 1628 : 'For Xiaoyi, IPSEC attrs in alternate name 1629 extn' 1630 : } 1631 : } 1632 : } 1633 70 30 158: SEQUENCE { 1634 73 30 13: SEQUENCE { 1635 75 06 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1636 1 1) 1637 86 05 0: NULL 1638 : } 1639 88 03 140: BIT STRING 0 unused bits 1640 : 30 81 88 02 81 80 73 DB 1D D5 65 AA EF C7 D4 8E 1641 : AA 6E EB 46 AC 91 2A 0F 50 51 17 AD 50 A2 2A F2 1642 : CE BE F1 E4 22 8C D7 61 A1 6C 87 61 62 92 CB A6 1643 : 80 EA B4 0F 09 9D 18 5F 39 A3 02 0E DB 38 4C E4 1644 : 8A 63 2E 72 8B DC BE 9E ED 6C 1A 47 DE 13 1B 0F 1645 : 83 29 4D 3E 08 86 FF 08 2B 43 09 EF 67 A7 6B EA 1646 : 77 62 30 35 4D A9 0F 0F DF CC 44 F5 4D 2C 2E 19 1647 : E8 63 94 AC 84 A4 D0 01 E1 E3 97 16 CD 86 64 18 1648 : [ Another 11 bytes skipped ] 1649 : } 1650 231 A0 63: [0] { 1651 233 30 61: SEQUENCE { 1652 235 06 9: OBJECT IDENTIFIER extensionReq (1 2 840 113549 1 9 1653 14) 1654 246 31 48: SET { 1655 248 30 46: SEQUENCE { 1656 250 30 44: SEQUENCE { 1657 252 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 1658 257 04 37: OCTET STRING 1659 30 23 87 04 01 02 03 04 81 0D 65 6D 61 69 1660 6C 40 69 72 65 2E 63 6F 6D 82 0C 66 71 64 1661 6E 2E 69 72 65 2E 63 6F 6D 1662 : } 1663 : } 1664 : } 1665 : } 1666 : } 1667 : } 1669 296 30 13: SEQUENCE { 1670 298 06 9: OBJECT IDENTIFIER md5withRSAEncryption (1 2 840 113549 1671 1 1 4) 1672 309 05 0: NULL 1673 : } 1674 311 03 129: BIT STRING 0 unused bits 1675 : 19 60 55 45 7F 72 FD 4E E5 3F D2 66 B0 77 13 9A 1676 : 87 86 75 6A E1 36 C6 B6 21 71 68 BD 96 F0 B4 60 1677 : 95 8F 12 F1 65 33 16 FD 46 8A 63 19 90 40 B4 B7 1678 : 2C B5 AC 63 17 50 28 F0 CD A4 F0 00 4E D2 DE 6D 1679 : C3 4F F5 CB 03 4D C8 D8 31 5A 7C 01 47 D2 2B 91 1680 : B5 48 55 C8 A7 0B DD 45 D3 4A 8D 94 04 3A 6C B0 1681 : A7 1D 64 74 AB 8A F7 FF 82 C7 22 0A 2A 95 FB 24 1682 : 88 AA B6 27 83 C1 EC 5E A0 BA 0C BA 2E 6D 50 C7 1683 : } 1685 Appendix C: Private OID Definitions 1687 The OIDs used in defining pkiStatus are VeriSign self-maintained 1688 OIDs. Please note, work is in progress to replace the VeriSign owned 1689 object identifiers with the standard object identifiers. Once the 1690 standarlization is completed, this documentation will be updated. 1692 id-VeriSign OBJECT_IDENTIFIER ::= {2 16 US(840) 1 VeriSign(113733)} 1693 id-pki OBJECT_IDENTIFIER ::= {id-VeriSign pki(1)} 1694 id-attributes OBJECT_IDENTIFIER ::= {id-pki attributes(9)} 1695 id-messageType OBJECT_IDENTIFIER ::= {id-attributes messageType(2)} 1696 id-pkiStatus OBJECT_IDENTIFIER ::= {id-attributes pkiStatus(3)} 1697 id-failInfo OBJECT_IDENTIFIER ::= {id-attributes failInfo(4)} 1698 id-senderNonce OBJECT_IDENTIFIER ::= {id-attributes senderNonce(5)} 1699 id-recipientNonce OBJECT_IDENTIFIER ::= {id-attributes recipientNonce(6)} 1700 id-transId OBJECT_IDENTIFIER ::= {id-attributes transId(7)} 1701 id-extensionReq OBJECT_IDENTIFIER ::= {id-attributes extensionReq(8)} 1703 Appendix D: Sample LDAP Query URL 1705 In SCEP, the CRL distribution point is encoded as a DN. In the future 1706 release, we are going to support the CRL DistributionPoint as defined in 1707 RFC2459. For example, the certificate issued by Entrust VPN contains 1708 the following DN as the CRL distribution point: 1710 CN = CRL1, O = cisco, C = US. 1712 The asn.1 encoding of this distribution point is: 1714 30 2C 31 0B 30 09 06 03 55 04 06 13 02 55 53 31 0E 30 0C 06 1715 03 55 04 0A 13 05 63 69 73 63 6F 31 0D 30 0B 06 03 55 04 03 1716 13 04 43 52 4C 31 1718 Appendix E: CEP State Transitions 1720 SCEP state transitions are based on transaction identifier. The design 1721 goal is to ensure the synchronization between the CA and the end entity 1722 under various error situations. 1724 An identity is defined by the combination of FQDN, the IP address and 1725 the client serial number. FQDN is the required name attribute. It is 1726 important to notice that, a client named as Alice@cisco.com is different 1727 from the client named as Alice@cisco.com plus IPAddress 171.69.1.129. 1729 Each enrollment transaction is uniquely associated with a transaction 1730 identifier. Because the enrollment transaction could be interrupted by 1731 various errors, including network connection errors or client reboot, 1732 the SCEP client generates a transaction identifier by calculating MD5 1733 hash on the public key value for which the enrollment is requested. This 1734 retains the same transaction identifier throughout the enrollment 1735 transaction, even if the client has rebooted or timed out, and issues a 1736 new enrollment request for the same key pair. It also provides the way 1737 for the CA to uniquely identify a transaction in its database. At the 1738 end entity side, it generates a transaction identifier which is included 1739 in PKCSReq. If the CA returns a response of PENDING, the end entity 1740 will poll by periodically sending out GetCertInitial with the same 1741 transaction identifier until either a response other than PENDING is 1742 obtained, or the configured maximum time has elapsed. 1744 If the client times out or the client reboots, the client administrator 1745 will start another enrollment transaction with the same key pair. The 1746 second enrollment will have the transaction idenifier. At the server 1747 side, instead of accepting the PKCSReq as a new enrollment request, it 1748 should respond as if another GetCertInitial message had been sent with 1749 that transaction ID. In another word, the second PKCSReq should be 1750 taken as a resynchronization message to allow the enrollment resume as 1751 the same transaction. 1753 It is important to keep the transaction id unique since CEP requires the 1754 same policy and same identity be applied to the same subject name and 1755 key pair binding. In the current implementation, an SCEP client can 1756 only assume one identity. At any time, only one key pair, with a given 1757 key usage, can be associated with the same identity. 1759 The following gives several example of client to CA transactions. 1760 Client actions are indicated in the left column, CA actions are 1761 indicated in the right column. A blank action signifies that no message 1762 was received. Note that these examples assume that the CA enforces the 1763 certificate-name uniqueness property defined in Section 2.1.1.1. 1765 The first transaction, for example, would read like this: 1766 "Client Sends PKCSReq message with transaction ID 1 to the 1767 CA. The CA signs the certificate and constructs a CertRep Message 1768 containing the signed certificate with a transaction ID 1. The client 1769 receives the message and installs the cert locally." 1771 Successful Enrollment Case: no manual authentication 1772 PKCSReq (1) ----------> CA Signs Cert 1773 Client Installs Cert <---------- CertRep (1) SIGNED CERT 1775 Successful Enrollment Case: manual authentication required 1776 PKCSReq (10) ----------> Cert Request goes into Queue 1777 Client Polls <---------- CertRep (10) PENDING 1778 GetCertInitial (10) ----------> Still pending 1779 Client Polls <---------- CertRep (10) PENDING 1780 GetCertInitial (10) ----------> Still pending 1781 Client Polls <---------- CertRep (10) PENDING 1782 GetCertInitial (10) ----------> Still pending 1783 Client Polls <---------- CertRep (10) PENDING 1784 GetCertInitial (10) ----------> Cert has been signed 1785 Client Installs Cert <---------- CertRep (10) SIGNED CERT 1787 Resync Case - CA Receive and Signs PKCSReq, Client Did not receive 1788 CertRep: 1790 PKCSReq (3) ----------> Cert Request goes into queue 1791 <---------- CertRep (3) PENDING 1792 GetCertInitial (3) ----------> 1793 <---------- CertRep (3) PENDING 1794 GetCertInitial (3) -----------> 1795 <----------- CA signed Cert and send back 1796 CertRep(3) 1797 (Time Out) 1798 PKCSReq (3) ----------> Cert already signed, send back to 1799 client 1800 Client Installs Cert <---------- CertRep (3) SIGNED CERT 1802 Case when NVRAM is lost and client has to generate a new key pair, there 1803 is no change of name information: 1805 PKCSReq (4) ----------> CA Signs Cert 1806 Client Installs Cert <---------- CertRep (4) SIGNED CERT 1807 (Client looses Cert) 1808 PKCSReq (5) ----------> There is already a valid cert with 1809 this DN. 1810 Client Admin Revokes <---------- CertRep (5) OVERLAPPING CERT ERROR 1811 PKCSReq (5) ----------> CA Signs Cert 1812 Client Installs Cert <---------- CertRep (5) SIGNED CERT 1813 Case when client admin resync the enrollment using a different PKCS#10: 1814 PKCSReq (6) ----------> CA Signs Cert 1815 <---------- CertRep (6) SIGNED CERT 1816 (Client timeout and admin starts another enrollment with a different 1817 PKCS#10, but the same transaction id) 1818 PKCSReq (6) with different PKCS#10 1819 ----------> There is already a valid cert with 1820 this entity (by checking FQDN). 1821 <---------- CertRep (6) INVALID PKCS#10 CERT 1822 ERROR 1823 Client admin either revokes the existing cert 1824 or corrects the error by enrolling with 1825 the same PKCS#10 as the first PKCSReq(6) 1826 PKCSReq (6) ----------> CA find the existing Cert 1827 Client Installs Cert <---------- CertRep (6) SIGNED CERT 1829 Resync case when server is slow in response: 1830 PKCSReq (13) ----------> Cert Request goes into Queue 1831 <---------- CertRep (13) PENDING 1832 GetCertInitial ----------> Still pending 1833 <---------- CertRep (13) PENDING 1834 GetCertInitial ----------> Still pending 1835 <---------- CertRep (13) PENDING 1836 GetCertInitial ----------> Still pending 1837 <---------- CertRep (13) PENDING 1838 GetCertInitial ----------> Still pending 1839 (TimeOut) <---------- CertRep (13) PENDING 1840 * Case 1 1841 PKCSReq (13) ----------> Still pending 1842 Client polls <---------- CertRep (13) PENDING 1843 CertCertInitial ----------> Cert has been signed 1844 Client Installs Cert <---------- CertRep (13) SIGNED CERT 1845 * Case 2 1846 PKCSReq (13) ----------> Cert has been signed 1847 Client Installs Cert <---------- CertRep (13) SIGNED CERT 1848 Appendix F. Copyright Section 1850 "Copyright (C) The Internet Society (date). All Rights Reserved. 1852 This document and translations of it may be copied and furnished 1853 to others, and derivative works that comment on or otherwise 1854 explain it or assist in its implmentation may be prepared, copied, 1855 published and distributed, in whole or in part, without 1856 restriction of any kind, provided that the above copyright notice 1857 and this paragraph are included on all such copies and derivative 1858 works. However, this document itself may not be modified in any 1859 way, such as by removing the copyright notice or references to the 1860 Internet Society or other Internet organizations, except as needed 1861 for the purpose of developing Internet standards in which case the 1862 procedures for copyrights defined in the Internet Standards 1863 process must be followed, or as required to translate it into 1864 languages other than English. 1866 The limited permissions granted above are perpetual and will not 1867 be revoked by the Internet Society or its successors or assigns. 1869 This document and the information contained herein is provided on 1870 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1871 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1872 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1873 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1874 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 1875 PURPOSE." 1877 This draft expires 30 June 2000. 1879 [End of draft-nourse-scep-00.txt]