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