idnits 2.17.1 draft-nourse-scep-02.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 4 longer pages, the longest (page 25) being 115 lines == 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 10 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 852 has weird spacing: '... as the signe...' == Line 914 has weird spacing: '...content pkcsC...' == Line 1364 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 (4 February 2000) is 8841 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CERT-NONEXISTANT' is mentioned on line 539, but not defined == Missing Reference: 'CERT-REQ-PENDING' is mentioned on line 539, but not defined == Missing Reference: 'CERT-ISSUED' is mentioned on line 539, but not defined -- Looks like a reference, but probably isn't: '0' on line 1698 == Unused Reference: 'PKCS7' is defined on line 1595, but no explicit reference was found in the text == Unused Reference: 'PKCS10' is defined on line 1598, but no explicit reference was found in the text == Unused Reference: 'RFC2459' is defined on line 1601, 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: 8 errors (**), 0 flaws (~~), 12 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-02.txt Cheryl Madson 3 expires 04 August 2000 David McGrew 4 Andrew Nourse 5 Cisco Systems 7 Category: Informational 4 February 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. The Goal of SCEP . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 14 58 4.2 Signed Transaction Attributes . . . . . . . . . . . . . . 15 59 5. SCEP Transaction Specification . . . . . . . . . . . . . . 16 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. Obtaining CRL by LDAP Query . . . . . . . . . . . . 34 67 Appendix E. SCEP 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 Entity names which are specified as in the IPSEC profile (i.e., FQDN, IP 155 address and User FQDN) must be presented in certificate's SubjectAltName 156 extension. Multiple IPSEC entity names, (if any) are encoded as multiple 157 values of a single SubjectAltName extension. The CA has the authority 158 to assign a distinguished name to an end entity. The assigned DN should 159 contain the SCEP client names as the relative DN. 161 The attribute identifiers and an example of SCEP client subject name are 162 specified in Appendix A. Appendix B has an example from Cisco VPN Client 163 enrollment request. 165 2.1.1.1 Local Key/Certificate/CRL Storage and Certificate-name uniqueness 167 An end entity is required to generate asymmetric key pairs and to 168 provide storage to store its private keys. If the end entity does not 169 have enough permanent memory to save its certificate, the end entity 170 should be able to query its own certificate from the CA, once the 171 certificate has been issued. The public key pairs can be generated with 172 a specific key usage. The key usage are conveyed to the CA through the 173 certificate enrollment request. All current SCEP client implementations 174 expect that there will be only one pair of keys for a given subject name 175 and key usage combination, at any time. This property is called the 176 certificate-name uniqueness property, and it implies that a CA that 177 implements SCEP will enforce the unique mapping between a SCEP client 178 subject name and its key pairs with a given key usage. At any time, if 179 the subject name is changed, or if the key is updated, the existing 180 certificate would have to be revoked before a new one could be issued. 181 This is a good practice in any case, as a peer that cached an old, 182 but still valid certificate would try to use the wrong public key, 183 resulting in an authentication failure. 185 It is desirable that the CA enforce certificate-name uniqueness, but 186 it is not mandatory. However a CA that does not envorce uniqueness 187 must provide some other mechanism to prevent the re-transmission of an 188 enrollment request by a SCEP client from creating a second certificate 189 or certificate request, nor can the second request merely be rejected. 190 If a client times out from polling for a pending request it can 191 resynchronize by reissuing the original request with the original 192 subject name and transaction ID. This must return the status of the 193 original transaction, including the certificate if it was granted. 194 It must not create a new transaction. 196 Key update and certificate overlap are not specified by the protocol. 198 2.1.1.2 End entity authentication 200 As with every protocol that uses public-key cryptography, the 201 association between the public keys used in the protocol and the 202 identities with which they are associated must be authenticated in a 203 cryptographically secure manner. This requirement is needed to 204 prevent a "man in the middle" attack, in which an adversary that can 205 manipulate the data as it travels between the protocol participants 206 can subvert the security of the protocol. To satisfy this 207 requirement, SCEP provides two authentication methods: manual 208 authentication, and authentication based on pre-shared secret. In the 209 manual mode, the end entity submitting the request is required to wait 210 until its identity can be verified by the CA operator using any 211 reliable out-of-band method. To prevent a "man-in-the-middle" attack, 212 an MD5 `fingerprint' generated on the PKCS#10 (before PKCS #7 213 envloping and signing) must be compared out-of-band between the server 214 and the end entity. SCEP clients and CAs (or RAs, if appropriate) 215 must display this fingerprint to a user to enable this verification, 216 if manual mode is used. Failing to provide this information leaves 217 the protocol vulnerable to attack by sophisticated adversaries. When 218 utilizing a pre-shared secret scheme, the server should distribute a 219 shared secret to the end entity which can uniquely associate the 220 enrollment request with the given end entity. The distribution of the 221 secret must be private: only the end entity should know this 222 secret. The actual binding mechanism between the end entity and the 223 secret is subject to the server policy and implementation. When 224 creating enrollment request, the end entity is asked to provide a 225 challenge password. When using the pre-shared secret scheme, the end 226 entity must type in the re-distributed secret as the password. In the 227 manual authentication case, the challenge password is also required 228 since the server may challenge an end entity with the password before 229 any certificate can be revoked. Later on, this challenge password 230 will be included as a PKCS#10 attribute, and is sent to the server as 231 encrypted data. The PKCS#7 envelope protects the privacy of the 232 challenge password with DES encryption. 234 2.1.1.3 Self-Signed Certificates 236 In this protocol, the communication between the end entity and the 237 certificate authority is secured by using PKCS#7 as the messaging 238 protocol. PKCS#7, however, is a protocol which assumes the communicating 239 entities already possess the peer's certificates and requires both 240 parties use the issuer names and issuer assigned certificate serial 241 numbers to identify the certificate in order to verify the signature and 242 decrypt the message. When adopting PKCS#7 as a secure protocol for the 243 certificate enrollment, however, this assumption is not true, and it may 244 not be true in some cases for cert or CRL query. To solve this problem, 245 an end entity generates a self-signed certificate for its own public 246 key. In this self-signed certificate, the issuer name is the end entity 247 subject name (the same name later be used in PKCS#10), and the 248 transaction id (defined in 2.3.1) is used as the issuer assigned 249 certificate serial number. During the certificate enrollment, the end 250 entity will first post itself as the signing authority by attaching the 251 self-signed certificate to the signed certificate request. When the 252 Certificate Authority makes the envelope on the issued certificate using 253 the public key included in the self-signed certificate, it should use 254 the same issuer name and the serial number as conveyed in the 255 self-signed certificate to inform the end entity on which private key 256 should be used to open the envelope. 258 2.1.2 Certificate Authority 260 A Certificate Authority(CA) is an entity whose name is defined in the 261 certificate issuer name field. Before any PKI operations can begin, 262 the CA generates its own public key pair and creates a self-signed CA 263 certificate. Associated with the CA certificate is a fingerprint 264 which will be used by the end entity to authenticate the received CA 265 certificate. The fingerprint is created by calculating a MD5 hash on 266 the whole CA certificate. Before any end entity can start its 267 enrollment, this root certificate has to be configured at the entity 268 side securely. For IPSEC clients, the client certificates must have 269 SubjectAltName extension. To utilize LDAP as a CRL query protocol, 270 the certificates must have CRL Distribution Point. Key usage is 271 optional. Without key usage, the public key is assumed as a general 272 purpose public key and it can be used for all the purposes. 274 A Certificate Authority may enforce certain name policy. When using 275 X.500 directory name as the subject name, all the name attributes 276 specified in the PKCS#10 request should be included as Relative DN. All 277 the name attributes as defined in RFC2459 should be specified in the 278 SubjectAltName. An example is provided in Appendix A. 280 If there is no LDAP query protocol support, the Certificate Authority 281 should answer certificate and CRL queries, and to this end it should be 282 online all the time. 284 The updating of the CA's public key is not addressed within the SCEP 285 protocol. An SCEP client can remove its copy of a CA's public key and 286 re-enroll under the CA's new public key. 288 2.1.3 Registration Authorities 290 In the environment where a RA is present, an end entity performs 291 enrollment through the RA. In order to setup a secure channel with RA 292 using PKCS#7, the RA certificate(s) have to be obtained by the client 293 in addition to the CA certificate(s). 295 In the following, the CA and RA are specified as one entity in the 296 context of PKI operation definitions. 298 2.1.4 Trusted Root Store 300 To support interoperability between IPSEC peers whose certificates are 301 issued by different CA, SCEP allows the users to configure multiple 302 trusted roots. A root is a trusted root when its certificate has been 303 configured as such in the client. An SCEP client that supports multiple 304 roots must associate with each root the information needed to to query a 305 CRL from each root. 307 Once a trusted root is configured in the client, the client can verify 308 the signatures of the certificates issued by the given root. 310 2.2 SCEP Operations Overview 312 In this section, we give a high level overview of the PKI operations as 313 defined in SCEP. 315 2.2.1 End Entity Initialization 317 The end entity initialization includes the key pair generation and the 318 configuring of the required information to communicate with the 319 certificate authority. 321 2.2.1.1 Key Pair Generation 323 Before an end entity can start PKI transaction, it first generates 324 asymmetric key pairs, using the selected algorithm (the RSA algorithm is 325 required in SCEP, and is the only algorithm in current implementations). 327 An end entity can create one or more asymmetric key pairs, for different 328 key usage. The key pairs can be created for encryption only, signing 329 only, or for all purposes. For the same key usage, there can be only 330 one key pair at any time. 332 The key pairs are saved by the client in NVRAM or other non-volatile 333 media. The identification of a key pair is based on the FQDN assigned to 334 the client and the selected key usage. Every time a new key pair is 335 generated to replace the old key pair, the existing certificates have to 336 be revoked from the CA and a new enrollment has to be completed. 338 2.2.1.2 Required Information 340 An end entity is required to have the following information configured 341 before starting any PKI operations: 343 1. the certificate authority IP address or fully qualified domain name, 344 2. the certificate authority HTTP CGI script path, and 345 the HTTP proxy information in case there is no direct Internet 346 connection to the server, 347 3. the CRL query URL, if the CRL is to be obtained by from a directory 348 server by means of LDAP. 350 2.2.2 CA/RA Certificate Distribution 352 Before any PKI operation can be started, the end entity needs to get 353 the CA/RA certificates. At this time, since no public key has been 354 exchanged between the end entity and the CA/RA, the message to get the 355 CA/RA certificate can not be secured using PKCS#7 protocol. Instead, the 356 CA/RA certificate distribution is implemented as a clear HTTP Get 357 operation. After the end entity gets the CA certificate, it has to 358 authenticate the CA certificate by comparing the finger print with the 359 CA/RA operator. Since the RA certificates are signed by the CA, there is 360 no need to authenticate the RA certificates. 362 This operation is defined as a transaction consisting of one HTTP Get 363 message and one HTTP Response message: 365 END ENTITY CA SERVER 366 Get CA/RA Cert: HTTP Get message 367 -----------------------------> 368 CA/RA Cert download: HTTP Response message 369 <--------------------------------------- 370 Compute finger print and 371 call CA operator. 372 Receive call and check finger print 374 If an RA is in use, a degenerated PKCS#7 with a certificate chain 375 consisting of both RA and CA certificates is sent back to the end 376 entity. Otherwise the CA certificate is directly sent back as the 377 HTTP response payload. 379 2.2.3 Certificate Enrollment 381 An end entity starts an enrollment transaction by creating a certificate 382 request using PKCS#10 and send it to the CA/RA enveloped using the 383 PKCS#7. After the CA/RA receives the request, it will either 384 automatically approve the request and send the certificate back, or it 385 will require the end entity to wait until the operator can manually 386 authenticate the identity of the requesting end entity. Two attributes 387 (defined in PKCS#6) are included in the PKCS#10 certificate request - a 388 Challenge Password attribute and an optional ExtensionReq attribute 389 which will be a sequence of extensions the end entity would like to be 390 included in its V3 certificate extensions. The Challenge Password is 391 used for revocation and may be used (at the option of the CA/RA) 392 additionally as a one-time password for automatic enrollment. 394 In the automatic mode, the transaction consists of one PKCSReq PKI 395 Message, and one CertRep PKI message. In the manual mode, the end entity 396 enters into polling mode by periodically sending GetCertInitial PKI 397 message to the server, until the server operator completes the manual 398 authentication, after which the CA will respond to GetCertInitial by 399 returning the issued certificate. 401 The transaction in automatic mode: 403 END ENTITY CA SERVER 405 PKCSReq: PKI cert. enrollment msg 406 --------------------------------> CertRep: pkiStatus = GRANTED 407 certificate 408 attached 409 <------------------------------ 410 Receive issued certificate. 412 The transaction in manual mode: 414 END ENTITY CA SERVER 415 PKCSReq: PKI cert. enrollment msg 416 --------------------------------> CertRep: pkiStatus = PENDING 417 <------------------------------ 418 GetCertInitial: polling msg 419 --------------------------------> CertRep: pkiStatus = PENDING 420 <------------------------------ 421 ................. CertRep: pkiStatus = GRANTED 425 certificate 426 attached 427 <------------------------------ 428 Receive issued certificate. 430 2.2.4 End Entity Certificate Revocation 432 An end entity should be able to revoke its own certificate. Currently 433 the revocation is implemented as a manual process. In order to revoke a 434 certificate, the end entity make a phone call to the CA server 435 operator. The operator will come back asking the ChallangePassword 436 (which has been send to the server as an attribute of the PKCS#10 437 certificate request). If the ChallangePassword matches, the certificate 438 is revoked. The reason of the revocation is documented by CA/RA. 440 2.2.5 Certificate Access 442 There are two methods to query certificates. The first method is to use 443 LDAP as a query protocol. Using LDAP to query assumes the client 444 understand the LDAP scheme supported by the CA. The SCEP client assumes 445 that the subject DN name in the certificate is used as URL to query the 446 certificate. The standard attributes (userCertficiate and caCertificate) 447 are used as filter. 449 For the environment where LDAP is not available, a certificate query 450 message is defined to retrieve the certificates from CA. 452 To query a certificate from the certificate authority, an end entity 453 sends a request consisting of the certificate's issuer name and the 454 serial number. This assumes that the end entity has saved the issuer 455 name and the serial number of the issued certificate from the previous 456 enrollment transaction. The transaction to query a certificate consists 457 of one GetCert PKI message and one CertRep PKI message: 459 END ENTITY CA SERVER 460 GetCert: PKI cert query msg 461 -------------------------------> CertRep: pkiStatus = GRANTED 462 certificate 463 attached 464 <----------------------------- 465 Receive the certificate. 467 2.2.6 CRL Distribution 469 The CA/RA will not "push" the CRL to the end entities. The query of the 470 CRL can only be initialized by the end entity. 472 There are three methods to query CRL. 474 The CRL may be retrieved by a simple HTTP GET. If the CA supports this 475 method, it should encode the URL into a CRL Distribution Point extension 476 in the certificates it issues. Support for this method should be 477 incorporated in new and updated clients, but may not be in older 478 versions. 480 The second method is to query CRL using LDAP. This assumes the CA server 481 supports CRL LDAP publishing and issues the CRL Distribution Point in 482 the certificate. The CRL Distribution Point is encoded as a DN. Please 483 refer to Appendix D for the examples of CRL Distribution Point. 485 The third method is implemented for the CA which does not support LDAP 486 CRL publishing or does not implement the CRL Distribution Point. In this 487 case, a CRL query is composed by creating a message consists of the CA 488 issuer name and the CA's certificate serial number. This method is 489 deprecated because it does not scale well and requires the CA to be a 490 high-availability service. 492 The message is send to the CA in the same way as the other SCEP 493 requests: The transaction to query CRL consists of one GetCRL PKI 494 message and one CertRep PKI message which have no certificates but CRL. 496 END ENTITY CA SERVER 497 GetCRL: PKI CRL query msg 498 ----------------------------------> CertRep: CRL attached 499 <-------------------------------- 501 2.3 PKI Operation Transactional Behavior 503 As described before, a PKI operation is a transaction consisting of the 504 messages exchanged between an end entity and the CA/RA. This section 505 will specify the transaction behavior on both the end entity and the 506 certificate authority server. Because the protocol is basically a two 507 way communication protocol without a confirmation message from the 508 initiating side, state and state resynchronization rules have to be 509 defined, in case any error happens at either side. Before the state 510 transition can be defined, the notion of transaction identifier has to 511 be defined first. 513 2.3.1 Transaction Identifier 515 A transaction identifier is a string generated by the entity when 516 starting a transaction. Since all the PKI operations defined in this 517 protocol are initiated by the end entity, it is the responsibility of 518 the end entity to generate a unique string as the transaction 519 identifier. All the PKI messages exchanged for a given PKI operations 520 must carry the same transaction identifier. The transaction identifier 521 is generated as a MD5 hash on the public key value for which the 522 enrollment request is made. This allows the SCEP client to reuse the 523 same transaction identifier if it is reissuing a request for the same 524 certificate (i.e. a certificate with the same subject, issuer, and key). 525 The SCEP protocol requires that transaction identifiers be unique, so 526 that queries can be matched up with transactions. For this reason, in 527 those cases in which separate signing and encryption certificates are 528 issued to the same end entity, the keys must be different. 530 2.3.2 State Transitions in Certificate Enrollment 532 The end entity state transitions during enrollment operation is 533 indicated in the diagram below: 534 +-<------+ 535 | | 536 GetCertInitial triggered by timeout or 537 | | manual authentication 538 | | 539 [CERT-NONEXISTANT] ------> [CERT-REQ-PENDING] ---> [CERT-ISSUED] 540 | PKCSReq | CertRep with SUCCESS 541 | | 542 | | 543 +--------<-------------------+ 544 request rejected, timeout, or error 546 As described in the section 2.2.3, certificate enrollment starts at the 547 state CERT-NONEXISTANT. Sending PKCSReq changes the state to 548 CERT-REQ-PENDING. Receiving CertRep with SUCCESS status changes the 549 state to CERT-ISSUED. In the case the server sending back the response 550 with pending status, the end entity will keep polling certificate 551 response by sending GetCertInitial to the server, until either a CertRep 552 with SUCCESS status is received, or the maximum polling number has been 553 exceeded. 555 If an error or timeout occurs in the CERT-REQ-PENDING state, the end 556 entity will transition to the CERT-NONEXISTANT state. 558 The client administrator will, eventually, start up another enrollment 559 request. It is important to note that, as long as the end entity does 560 not change its subject name or keys, the same transaction id will be 561 used in the "new" transaction. This is important because based on this 562 transaction id, the certificate authority server can recognize this as 563 an existing transaction instead of a new one. 565 2.3.3 Transaction Behavior of Certificate/CRL Access 567 There is no state maintained during certificate access and CRL access 568 transaction. When using the certificate query and CRL query messages 569 defined in this protocol, the transaction identifier is still required 570 so that the end entity can match the response message with the 571 upstanding request message. When using LDAP to query the certificate and 572 the CRL, the behavior is specified by the LDAP protocol. 574 2.4 Security 576 The security goals of SCEP are that no adversary can: 578 o subvert the public key/identity binding from that intended, 579 o discover the identity information in the enrollment requests and 580 issued certificates, 581 o cause the revocation of certificates with any non-negligible 582 probability. 584 Here an adversary is any entity other than the end entity and the CA 585 (and optionally the RA) participating in the protocol that is 586 computationally limited, but that can manipulate data during 587 transmission (that is, a man-in-the-middle). The precise meaning of 588 'computationally limited' depends on the implementer's choice of 589 cryptographic hash functions and ciphers. The required algorithms are 590 RSA, DES, and MD5. 592 The first and second goals are met through the use of PKCS#7 and PKCS#10 593 encryption and digital signatures using authenticated public keys. The 594 CA's public key is authenticated via the checking of the CA fingerprint, 595 as specified in Section 2.1.2, and the SCEP client's public key is 596 authenticated through the manual authentication or pre-shared secret 597 authentication, as specified in Section 2.1.1.2. The third goal is met 598 through the use of a Challenge Password for revocation, that is chosen 599 by the SCEP client and communicated to the CA protected by the PKCS#7 600 encryption, as specified in Section 2.2.4. 602 The motivation of the first security goal is straightforward. The 603 motivation for the second security goal is to protect the identity 604 information in the enrollment requests and certificates. For example, 605 two IPSEC hosts behind a firewall may need to exchange certificates, and 606 may need to enroll certificates with a CA that is outside of a firewall. 607 Most networks with firewalls seek to prevent IP addresses and DNS 608 information from the trusted network leaving that network. The second 609 goal enables the hosts in this example to enroll with a CA outside the 610 firewall without revealing this information. The motivation for the 611 third security goal is to protect the SCEP clients from denial of 612 service attacks. 614 Section 3 Transport Protocol 616 In the SCEP protocol, HTTP is used as the transport protocol for the PKI 617 messages. 619 3.1 HTTP "GET" Message Format 621 In the PKI protocol, CA/RA certificates are send to the end entity in 622 clear, whereas the end entity certificates are send out using the PKCS#7 623 secure protocol. This results in two types of GET operations. The type 624 of GET operation is specified by augmenting the GET message with 625 OPERATION and MESSAGE parameters in the Request-URL. OPERATION 626 identifies the type of GET operation, and MESSAGE is actually the PKI 627 message encoded as a text string. 629 The following is the syntax definition of a HTTP GET message send from 630 an end entity to a certificate authority server: 632 Request = "GET " CGI-PATH "?operation=" OPERATION "&message=" MESSAGE 633 where: 634 CGI-PATH defines the actual CGI path to invoke the CGI program which 635 parses the request. 636 OPERATION is set to be the string "PKIOperation" when the GET message 637 carries a PKI message to request certificates or CRL; OPERATION is set 638 to be the string "GetCACert" when the GET operation is used to get 639 CA/RA certificate in the clear. 640 When OPERATION is "PKIOperation", MESSAGE is a base64-encoded PKI 641 message 642 when OPERATION is "GetCACert", MESSAGE is a string which represents 643 the certificate authority issuer identifier. 645 For example. An end entity may submit a message via HTTP to the server 646 as follows: 648 GET /cgi-bin/pkiclient.exe?operation=PKIOperation&message=MIAGCSqGSIb3D 649 QEHA6CAMIACAQAxgDCBzAIBADB2MGIxETAPBgNVBAcTCE ......AAAAAA== 651 3.2 Response Message Format 653 For each GET operation, the CA/RA server will return a MIME object via 654 HTTP. For a GET operation with PKIOperation as its type, the response is 655 tagged as having a Content Type of application/x-pki-message. The body 656 of this message is a BER encoded binary PKI message. The following is an 657 example of the response: 659 "Content-Type:application/x-pki-message\n\n" 661 In the case of GET operation with a type of GetCACert, the MIME content 662 type returned will depend on whether or not an RA is in use. If there 663 is no RA, only the CA certificate is send back in the response, and the 664 response has the content type tagged as application/x-x509-ca-cert. the 665 body of the response is a DER encoded binary X.509 certificate. For 666 example: 668 "Content-Type:application/x-x509-ca-cert\n\n" 670 If there is an RA, the RA certificates are send back together with the 671 CA certificates, a certificate-only PKCS#7 SignedData is send back in 672 the response where the SignerInfo is empty. Section 5 has the detailed 673 definition of the message format in this case. The content type is 674 application/x-x509-ca-ra-cert. 676 Section 4 Secure Transportation: PKCS#7 678 PKCS#7 is a general enveloping mechanism that enables both signed and 679 encrypted transmission of arbitrary data. It is widely implemented and 680 included in the RSA tool kit. 682 In this section, the general PKCS#7 enveloped PKI message format is 683 specified. The complete PKCS#7 message format for each PKI transaction 684 will be covered in Section 5. 686 4.1 SCEP Message Format 688 As a transaction message, a SCEP message has a set of transaction 689 specific attributes and an information portion. Employing PKCS#7 690 protocol, the transaction specific attributes are encoded as a set of 691 authenticated attributes of the SignedData. The information portion will 692 first be encrypted to become Enveloped Data, and then the digest of the 693 enveloped information portion is included as one of the message digest 694 attributes and being signed together with the other transaction specific 695 attributes. 697 By applying both enveloping and signing transformations, a SCEP message 698 is protected both for the integrity of its end-end-transition 699 information and the confidentiality of its information portion. The 700 advantage of this technique over the conventional transaction message 701 format is that, the signed transaction type information and the status 702 of the transaction can be determined prior to invoke security handling 703 procedures specific to the information portion being processed. 705 The following is an example of a SCEP message with its enveloped and 706 signed data portion represented by pkcsPKISigned and 707 pkcsPKIEnveloped. The out-most of any PKI message is a blob of 708 ContentInfo, with its content type set to SignedData and the actual 709 signed data as the content. 711 pkiMessage ContentInfo ::= { 712 contentType {pkcs-7 signedData(2)} 713 content pkcsPKISigned 714 } 715 pkcsPKISigned SignedData ::= { 716 version 1 717 digestAlgorithm { iso(1) member-body(2) US(840) rsadsi(113549) 718 digestAlgorithm(2) 5} 719 contentInfo { 720 contentType {pkcs-7 1} -- data content identifier 721 content pkcsPKIEnvelope -- enveloped information portion 722 } 723 certificates -- signer certificate chain 724 signerInfo -- including signed transaction info and the digest 725 -- of the enveloped information portion as the 726 -- authenticated attributes 727 } 728 pkcsPKIEnveloped EnvelopedData ::= { 729 version 0 730 recipientInfos -- information required to open the envelop 731 encryptedContentInfo { 732 contentType {pkcs-7 1} -- data content identifier 733 contentEncryptionAlgorithm 734 encryptedContent -- encrypted information portion 735 } 736 } 738 4.2 Signed Transaction Attributes 740 The following transaction attributes are encoded as authenticated 741 attributes. Please refer to Appendix B for the OID definitions. 743 transactionID PrintableString -- Decimal value as a string 744 messageType PrintableString -- Decimal value as a string 745 pkiStatus PrintableString -- Decimal value as a string 746 failinfo PrintableString -- Decimal value as a string 747 senderNonce Octet String 748 recipientNonce Octet String 750 where: 752 The transactionID is an attribute which uniquely identify a 753 transaction. This attribute is required in all PKI messages. 755 The messageType attribute specify the type of operation performed by the 756 transaction. This attribute is required in all PKI 757 messages. Currently, the following message types are defined: 759 PKCSReq (19) -- Permits use of PKCS#10 certificate request 760 CertRep (3) -- Response to certificate or CRL request 761 GetCertInitial (20) -- Certificate polling in manual enrollment 762 GetCert (21) -- Retrieve a certificate 763 GetCRL (22) -- Retrieve a CRL 765 All response message will include transaction status information which 766 is defined as pkiStatus attribute: 768 SUCCESS (0) -- request granted 769 FAILURE (2) -- request rejected 770 PENDING (3) -- request pending for manual approval. 772 If the status in the response is FAILURE, the failinfo attribute will 773 contain one of the following failure reasons: 775 badAlg (0) -- Unrecognized or unsupported algorithm ident 776 badMessageCheck (1) -- integrity check failed 777 badRequest (2) -- transaction not permitted or supported 778 badTime (3) -- Message time field was not sufficiently close 779 to the system time 780 badCertId (4) -- No certificate could be identified matching 781 the provided criteria 783 The attributes of senderNonce and recipientNonce are the 16 byte 784 random numbers generated for each transaction to prevent the replay 785 attack. 787 When an end entity sends a PKI message to the server, a senderNonce is 788 included in the message. After the server processes the request, it will 789 send back the end entity senderNonce as the recipientNonce and generates 790 another nonce as the senderNonce in the response message. Because the 791 proposed pki protocol is a two-way communication protocol, it is clear 792 that the nonce can only be used by the end entity to prevent the 793 replay. The server has to employ extra state related information to 794 prevent a replay attack. 796 Section 5. SCEP Transaction Specification 798 In this section each SCEP transaction is specified in terms of the 799 complete messages exchanged during the transaction. 801 5.1 Certificate Enrollment 803 The certificate enrollment transaction consists of one PKCSReq message 804 send to the certificate authority from an end entity, and one CertRep 805 message send back from the server. The pkiStatus returned in the 806 response message is either SUCCESS, or FAILURE, or PENDING. The 807 information portion of a PKCSReq message is a PKCS#10 certificate 808 request, which contains the subject Distinguished Name, the subject 809 public key, and two attributes, a ChallangePassword attribute to be used 810 for revocation, and an optional ExtensionReq attribute which will be a 811 sequence of extensions the end entity expects to be included in its V3 812 certificate extensions. One of the extension attribute specifies the key 813 usage. The pkiStatus is set to SUCCESS when the certificate is send 814 back in CertRep; the pkiStatus is set to FAILURE when the certificate 815 request is rejected; the pkiStatus is set to PENDING when the server has 816 decided to manually authenticate the end entity. The messages exchanged 817 in the manual authentication mode is further specified in Section 5.2. 819 Precondition: 820 Both the end entity and the certificate authority have completed their 821 initialization process. The end entity has already been configured 822 with the CA/RA certificate. 824 Postcondition: 825 Either the certificate is received by the end entity, or the end 826 entity is notified to do the manual authentication, or the request 827 is rejected. 829 5.1.1 PKCSReq Message Format 831 A PKCSReq message is created by following the steps defined below: 833 1. Create a PKCS#10 certificate request which is signed by the end 834 entity's private key, corresponding to the public key included in 835 the PKCS#10 certificate request. This constitutes the information 836 portion of PKCSReq. 838 2. Encrypt the PKCS#10 certificate request using a randomly generated 839 content-encryption key. This content-encryption key is then 840 encrypted by the CA's public key and included in the recipientInfo. 841 This step completes the "envelope" for the PKCS#10 certificate 842 request. 844 3. Generate a unique string as the transaction id. 846 4. Generate a 16 byte random number as senderNonce. 848 5. Generate message digest on the enveloped PKCS#10 certificate request 849 using the selected digest algorithm. 851 6. Create SignedData by adding the end entity's self-signed certificate 852 as the signer's public key certificate. Include the transaction id, 853 the senderNonce and the message digest as the authenticated 854 attributes and sign the attributes using the end entity's private 855 key. This completes the SignedData. 857 7. The SignedData is prepended with the ContenInfo blob which indicates 858 a SignedData object. This final step completes the create of a 859 complete PKCSReq PKI message. 861 In the following, the PKCSReq message is defined following the ASN.1 862 notation. 864 For readability, the values of a field is either represented by a quoted 865 string which specifies the intended value, or a constant when the value 866 is known. 868 -- PKCSReq information portion 869 pkcsCertReq CertificationRequest ::= { -- PKCS#10 870 version 0 871 subject "the end entity's subject name" 872 subjectPublicKeyInfo { 873 algorithm {pkcs-1 1} -- rsa encryption 874 subjectPublicKey "BER encoding of the end entity's public key" 875 } 876 attributes { 877 challengePassword {{pkcs-9 7} "password string" } 878 extensions 879 } 880 signatureAlgorithm {pkcs-1 4} -- MD5WithRSAEncryption 881 signature "bit string which is created by signing inner content 882 of the defined pkcsCertReq using end entity's private 883 key, corresponding to the public key included in 884 subjectPublicKeyInfo." 885 } 886 -- Enveloped information portion 887 pkcsCertReqEnvelope EnvelopeData ::= { -- PKCS#7 888 version 0 889 recipientInfo { 890 version 0 891 issuerAndSerialNumber { 892 issuer "the CA issuer name" 893 serialNumber "the CA certificate serial number" 894 } 895 keyEncryptionAlgorithm {pkcs-1 1} -- rsa encryption 896 encryptedKey "content-encryption key 897 encrypted by CA public key" 898 } 899 encryptedContentInfo { 900 contentType {pkcs-7 1} -- data content 901 contentEncryptionAlgorithm "object identifier 902 for DES encryption" 903 encryptedContent "encrypted pkcsCertReq using the content- 904 encryption key" 905 } 906 } 907 -- Signed PKCSReq 908 pkcsCertReqSigned SignedData ::= { -- PKCS#7 909 version 1 910 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 911 digestAlgorithm(2) 5} 912 contentInfo { 913 contentType {pkcs-7 1} -- data content identifier 914 content pkcsCertReqEnvelope 915 } 916 certificate { -- the end entity's self-signed certificate 917 version 3 918 serialNumber "the transaction id associated with enrollment" 919 signature {pkcs-1 4} -- md5WithRSAEncryption 921 issuer " the end entity's subject name" 922 validity { 923 notBefore "a UTC time" 924 notAfter "a UTC time" 925 } 926 subject "the end entity's subject name" 927 subjectPublicKeyInfo { 928 algorithm {pkcs-1 1} 929 subjectPublicKey "BER encoding of end entity's public key" 930 } 931 signatureAlgorithm {pkcs-1 4} 932 signature "the signature generated by using the end entity's 933 private key corresponding to the public key in 934 this certificate." 935 } 936 signerInfo { 937 version 1 938 issuerAndSerialNumber { 939 issuer "the end entity's subject name" 940 serialNumber "the transaction id associated 941 with the enrollment" 942 } 943 digestAlgorithm {iso(0) member-body(2) US(840) rsadsi(113549) 944 digestAlgorithm(2) 5} 945 authenticateAttributes { 946 contentType {{pkcs-9 3} {pkcs-7 1}} 947 messageDigest {{pkcs-9 4} "an octet string"} 948 transaction-id {{id-attributes transId(7)} "printable 949 string"} 950 -- this transaction id will be used 951 -- together with the subject name as 952 -- the identifier of the end entity's key 953 -- pair during enrollment 954 messageType {{id-attributes messageType(2)} "PKCSReq"} 955 senderNonce {{id-attributes senderNonce(5)} 956 "a random number encoded as a string"} 957 } 958 digestEncryptionAlgorithm {pkcs-1 1} -- rsa encryption 959 encryptedDigest "encrypted digest of the authenticated 960 attributes using end entity's private key" 961 } 962 } 963 pkcsReq PKIMessage ::= { 964 contentType {pkcs-7 2} 965 content pkcsCertRepSigned 966 } 968 5.1.2 CertRep Message Format 970 The response to an SCEP enrollment request is a CertRep message. 971 The status of the request is 972 5.1.2.1 PENDING Response 974 When the CA is configured to manually authenticate the end entity, 975 the CertRep is send back with the attribute pkiStatus set to PENDING. 976 The information portion for this message is empty. Only the transaction 977 required attributes are send back. 979 CertRepSigned SignedData ::= { -- PKCS#7 980 version 1 981 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 982 digestAlgorithm(2) 5} 983 contentInfo { -- empty content 984 contentType {pkcs-7 1} 985 } 986 signerInfo { 987 version 1 988 issuerAndSerialNumber { 989 issuer "the CA issuer name" 990 serialNumber "the CA certificate issuer serial number" 991 } 992 digestAlgorithm (iso(1) member-body(2) US(840) rsadsi(113549) 993 digestAlgorithm(2) 5} 994 authenticateAttributes { 995 contentType {{pkcs-9 3} {pkcs-7 1}} 996 messageDigest {{pkcs-9 4} NULL} 997 messageType {{id-attribute messageType(0)} "CertRep"} 998 transaction-id {{id-attributes transid(7)} "printable 999 string"} 1000 --- same transaction id used in PKCSReq 1001 pkiStatus {{id-attributes pkiStatus(1)} "PENDING"} 1002 recipientNonce {{id-attributes recipientNonce(3)}<16 bytes>} 1003 senderNonce {{id-attributes senderNonce(5)} <16 bytes>} 1004 } 1005 digestEncrytionAlgorithm {pkcs-1 1} 1006 encryptedDigest "encrypted message digest of the authenticate 1007 attributes using the CA's private key" 1008 } 1009 } 1010 CertRep PKIMessage ::= { 1011 contentType {pkcs-7 2} 1012 content CertRepSigned 1013 } 1015 5.1.2.2 Failure Response 1017 In this case, the CertRep send back to the end entity is same as the 1018 CertRep send back in the PENDING case, except that the pkiStatus 1019 attribute is set to FAILURE, and the failInfo attribute should be 1020 included: 1022 pkistatus {{id-attributes pkiStatus(1)} "FAILURE"} 1023 failInfo {{id-attributes pkiStatus(1)} "the reason to reject"} 1025 5.1.2.3 SUCCESS response 1027 In this case, the information portion of CertRep will be a degenerated 1028 PKCS#7 which contains the end entity's certificate. It is then enveloped 1029 and signed as below: 1031 pkcsCertRep SignedData ::= { -- PKCS#7 1032 version 1 1033 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1034 digestAlgorithm(2) 5} 1035 contentInfo { -- empty content since this is degenerated PKCS#7 1036 contentType {pkcs-7 1} 1037 } 1038 certificates { 1039 certificate { -- issued end entity's certificate 1040 version 3 1041 serialNumber "issued end entity's certificate serial number" 1042 signature {pkcs-1 4} -- md5WithRSAEncryption 1043 issuer "the certificate authority issuer name" 1044 validity { 1045 notBefore "UTC time" 1046 notAfter "UTC time" 1047 } 1048 subject "the end entity subject name as given in PKCS#10" 1049 subjectPublicKeyInfo { 1050 algorithm {pkcs-1 1} 1051 subjectPublicKey "a BER encoding of end entity public 1052 key as given in PKCS#10" 1053 } 1054 extensions " the extensions as given in PKCS#10" 1055 signatureAlgorithm {pkcs-1 4} 1056 signature " the certificate authority signature" 1057 } 1058 certificate "the certificate authority certificate" 1059 } 1060 } 1061 pkcsCertRepEnvelope EnvelopedData ::= { -- PKCS#7 1062 version 0 1063 recipientInfo { 1064 version 0 1065 issuerAndSerialNumber { -- use issuer name and serial number as 1066 -- conveyed in end entity's self-signed 1067 -- certificate, included in the PKCSReq 1068 issuer "the end entity's subject name" 1069 serialNumber "the serial number defined by the end entity in 1070 its self-signed certificate" 1071 } 1072 keyEncryptionAlgorithm {pkcs-1 1} 1073 encryptedKey "content-encrypt key encrypted by the end entity's 1074 public key which is same key as authenticated in 1075 the end entity's certificate" 1076 } 1077 encryptedContentInfo { 1078 contentType {pkcs-7 1} -- data content identifier 1079 contentEncryptionAlgorithm "OID for DES encryption" 1080 encryptedContent "encrypted pkcsCertRep using content encryption 1081 key" 1082 } 1083 } 1084 pkcsCertRepSigned SignedData ::= { -- PKCS#7 1085 version 1 1086 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1087 digestAlgorithm(2) 5} 1088 contentInfo { 1089 contentType {pkcs-7 1} 1090 content pkcsCertRepEnvelope 1091 } 1092 signerInfo { 1093 version 1 1094 issuerAndSerialNumber { 1095 issuer "the certificate authority issuer name" 1096 serialNumber "the CA certificate's serial number" 1097 } 1098 digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) 1099 digestAlgorithm(2) 5} 1100 authenticateAttributes { 1101 contentType {{pkcs-9 3} {pkcs-7 1}} 1102 messageDigest {{pkcs-9 4} "a octet string"} 1103 messageType {{id-attribute messageType(2)} "CertRep"} 1104 transaction-id {{id-attributes transId(7)} "printable 1105 string"} 1106 -- same transaction id as given in PKCSReq 1107 pkiStatus {{id-attributes pkiStatus(1) "SUCCESS"} 1108 recipientNonce {{id-attribute recipientNonce(4)}<16 bytes>} 1109 senderNonce {{ id-attributes senderNonce(5) <16 bytes>} 1110 } 1111 digestEncryptionAlgorithm {pkcs-1 1} 1112 encryptedDigest "encrypted digest of authenticate attributes 1113 using CA's private key " 1114 } 1115 } 1116 CertRep PKIMessage ::= { 1117 contentType {pkcs-7 2} 1118 content pkcsCertRepSigned 1119 } 1121 5.2 Poll for End Entity Initial Certificate 1123 Either triggered by the PENDING status received from the CertRep, or by 1124 the non-response timeout for the previous PKCSReq, an end entity will 1125 enter the polling state by periodically sending GetCertInitial to the 1126 server, until either the request is granted and the certificate is sent 1127 back, or the request is rejected, or the the configured time limit for 1128 polling is exceeded. 1130 Since GetCertInitial is part of the enrollment, the messages exchanged 1131 during the polling period should carries the same transaction identifier 1132 as the previous PKCSReq. 1134 PreCondition 1135 Either the end entity has received a CertRep with pkiStatus set to be 1136 PENDING, or the previous PKCSReq has timed out. 1138 PostContition 1139 The end entity has either received the certificate, or be rejected of 1140 its request, or the polling period ended as a failure. 1142 5.2.1 GetCertInitial Message Format 1144 Since at this time the certificate has not been issued, the end entity 1145 can only use the CA issuer name and the end entity's subject name to 1146 indicate the polled certificate. Combined with the transaction 1147 identifier, the certificate authority server should be able to uniquely 1148 identify the polled certificate request (a subject name can have more 1149 than one outstanding certificate request when the key usage attributes 1150 are selected). 1152 -- Information portion 1154 pkcsGetCertInitial issuerAndSubject ::= { 1155 issuer "the certificate authority issuer name" 1156 subject "the end entity subject name as given in PKCS#10" 1157 } 1158 pkcsGetCertInitialEnvelope EnvelopedData ::= { 1159 version 0 1160 recipientInfo { 1161 version 0 1162 issuerAndSerialNumber { 1163 issuer "the CA issuer name" 1164 serialNumber "the CA certificate serial number" 1165 } 1166 keyEncryptionAlgorithm {pkcs-1 1} 1167 encryptedKey "content-encrypt key encrypted by CA's public key" 1168 } 1169 encryptedContentInfo { 1170 contentType {pkcs-7 1} -- data content 1171 contentEncryptionAlgorithm "OID for DES encryption" 1172 encryptedContent "encrypted getCertInital" 1173 } 1174 } 1175 pkcsGetCertInitialSigned SignedData ::= { -- PKCS#7 1176 version 1 1177 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1178 digestAlgorithm(2) 5} 1179 contentInfo { 1180 contentType {pkcs-7 1} 1181 content pkcsGetCertIntialEnvelope 1182 } 1183 certificate { -- the end entity's self-signed certificate 1184 version 3 1185 serialNumber "the transaction id associated with enrollment" 1186 signature {pkcs-1 4} -- md5WithRSAEncryption 1187 issuer " the end entity's subject name" 1188 validity { 1189 notBefore "a UTC time" 1190 notAfter "a UTC time" 1191 } 1192 subject "the end entity's subject name" 1193 subjectPublicKeyInfo { 1194 algorithm {pkcs-1 1} 1195 subjectPublicKey "BER encoding of end entity's public key" 1196 } 1197 signatureAlgorithm {pkcs-1 4} 1198 signature "the signature generated by using the end entity's 1199 private key corresponding to the public key in 1200 this certificate." 1201 } 1202 signerInfo { 1203 version 1 1204 issuerAndSerialNumber { 1205 issuer "end entity's subject name" 1206 serialNumber "the transaction id used in previous PKCSReq" 1207 } 1208 digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) 1209 digestAlgorithm(2) 5} 1210 authenticateAttributes { 1211 contentType {{pkcs-9 3} {pkcs-7 1}} 1212 messageDigest {{pkcs-9 4} "an octet string"} 1213 -- digest of getCertInitial 1214 messageType {{id-attribute messageType(2)} "GetCertInitial"} 1215 transaction-id {{id-attributes transId(7)} "printable 1216 string"} 1217 -- same transaction idused in previous PKCSReq 1218 senderNonce {{id-attribute senderNonce(3)} 0x<16 bytes>} 1219 } 1220 digestEncryptionAlgorithm {pkcs-1 1} 1221 encryptedDigest "encrypted digest of authenticateAttributes" 1222 } 1223 } 1224 GetCertInitial PKIMessage ::= { 1225 contentType {pkcs-7 2} 1226 content pkcsGetCertInitialSigned 1227 } 1229 5.2.2 GetCertInitial Response Message Format 1231 The CertRep message in this case is same as defined for the case of PKCSReq. 1233 5.3 Certificate Access 1235 The certificate query message defined in this section is an option when 1236 the LDAP server is not available to provide the certificate query. An 1237 end entity should be able to query an issued certificate from the 1238 certificate authority, as long as the issuer name and the issuer 1239 assigned certificate serial number is known to the requesting end 1240 entity. This transaction is not intended to provide the service as a 1241 certificate directory service. More complicated query mechanism has to 1242 be defined in order to allow an end entity to query a certificate using 1243 various different fields. 1245 This transaction consists of one GetCert message send to the server by 1246 an end entity, and one CertRep message send back from the server. 1248 PreCondition 1249 The queried certificate have been issued by the certificate authority 1250 and the issuer assigned serial number is known. 1252 PostContition 1253 Either the certificate is send back or the request is rejected. 1255 5.3.1 GetCert Message Format 1257 The queried certificate is identified by its issuer name and the issuer 1258 assigned serial number. If this is a query for an arbitrary end entity's 1259 certificate, the requesting end entity should includes its own CA issued 1260 certificate in the signed envelope. If this is a query for its own 1261 certificate (assume the end entity lost the issued certificate, or does 1262 not have enough non-volatile memory to save the certificate), then the 1263 self-signed certificate has to be included in the signed envelope. 1265 pkcsGetCert issuerAndSerialNumber ::= { 1266 issuer "the certificate issuer name" 1267 serialNumber "the certificate serial number" 1268 } 1269 pkcsGetCertEnvelope EnvelopedData ::= { 1270 version 0 1271 recipientInfo { 1272 version 0 1273 issuerAndSerialNumber { 1274 issuer "the CA issuer name" 1275 serialNumber "the CA certificate serial number" 1276 } 1277 keyEncryptionAlgorithm {pkcs-1 1} 1278 encryptedKey "content-encrypt key encrypted by CA public key" 1279 } 1280 encryptedContentInfo { 1281 contentType {pkcs-7 1} -- data content 1282 contentEncryptionAlgorithm "OID for DES encryption" 1283 encryptedContent "encrypted pkcsGetCert using the content 1284 encryption key" 1285 } 1286 } 1287 pkcsGetCertSigned SignedData ::= { 1288 version 1 1289 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1290 digestAlgorithm(2) 5} 1291 contentInfo { 1292 contentType {pkcs-7 1} 1293 content pkcsGetCertEnvelope 1294 } 1295 certificates { 1296 certificate "CA issued certificate" 1297 or "self-signed certificate" 1298 } 1299 signerInfo { 1300 version 1 1301 issuerAndSerialNumber { 1302 issuer "the end entity's subject name" 1303 serialNumber "end entity's certificate serial number" 1304 } 1305 digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) 1306 digestAlgorithm(2) 5} 1307 authenticateAttributes { 1308 contentType {{pkcs-9 3} {pkcs-7 1}} 1309 messageDigest {{pkcs-9 4} "an octet string"} 1310 -- digest of pkcsGetCertEnvelope 1311 messageType {{id-attribute messageType(2)} "GetCert"} 1312 transaction-id {{id-attributes transId(7)} "printable 1313 string"} 1314 senderNonce {{id-attribute senderNonce(3)} <16 bytes>} 1315 } 1316 digestEncryptionAlgorithm {pkcs-1 1} 1317 encryptedDigest "encrypted digest of authenticateAttributes" 1318 } 1319 } 1320 GetCert PKIMessage ::= { 1321 contentType {pkcs-7 2} 1322 content pkcsGetCertSigned 1323 } 1325 5.3.2 CertRep Message Format 1327 In this case, the CertRep from the server is same as the CertRep for the 1328 PKCSReq, except that the server will only either grant the request or 1329 reject the request. Also, the recipientInfo should use the CA issuer 1330 name and CA assigned serial number to identify the end entity's key pair 1331 since at this time, the end entity has received its own certificate. 1333 5.4 CRL Access 1335 The CRL query message defined in this section is an option when the LDAP 1336 server is not available to provide the CRL query. In the PKI protocol 1337 proposed here, only the end entity can initiate the transaction to 1338 download CRL. An end entity send GetCRL request to the server and the 1339 server send back CertRep whose information portion is a degenerated 1340 PKCS#7 which contains only the most recent CRL. The size of CRL included 1341 in the CertRep should be determined by the implementation. 1343 PreCondition 1344 The certificate authority certificate has been downloaded to the end 1345 entity. 1347 PostCondition 1348 CRL send back to the end entity. 1350 5.4.1 GetCRL Message format 1352 The CRL is identified by using both CA's issuer name and the CA 1353 certificate's serial number: 1355 pkcsGetCRL issuerAndSerialNumber { 1356 issuer "the certificate authority issuer name" 1357 serialNumber "certificate authority certificate's serial number" 1358 } 1360 When the CRLDistributionPoint is supported, the pkcsGetCRL is defined as 1361 the following: 1363 pkcsGetCRL SEQUENCE { 1364 crlIssuer issuerAndSerialNumber 1365 distributionPoint CE-CRLDistPoints 1366 } 1368 where CE-CRLDisPoints is defined in X.509, but must contain only one 1369 CRL distribution point. 1371 pkcsGetCRLEnvelope EnvelopedData ::= { 1372 version 0 1373 recipientInfo { 1374 version 0 1375 issuerAndSerialNumber { 1376 issuer "the certificate authority issuer name" 1377 serialNumber "the CA certificate's serial number" 1378 } 1379 keyEncryptionAlgorithm {pkcs-1 1} 1380 encryptedKey "content-encrypt key encrypted by CA public key" 1381 } 1382 encryptedContentInfo { 1383 contentType {pkcs-7 1} -- data content 1384 contentEncryptionAlgorithm "OID for DES encryption" 1385 encryptedContent "encrypted pkcsGetCRL" 1386 } 1387 } 1388 pkcsGetCRLSigned SignedData ::= { 1389 version 1 1390 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1391 digestAlgorithm(2) 5} 1392 contentInfo { 1393 contentType {pkcs-7 1} 1394 content pkcsGetCRLEnvelope 1395 } 1396 certificates { 1397 certificate "the CA issued or self-signed end entity's certificate" 1398 } 1399 signerInfo { 1400 version 1 1401 issuerAndSerialNumber { 1402 issuer "the end entity's issuer name" 1403 serialNumber "the end entity's certificate serial number" 1404 } 1405 digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) 1406 digestAlgorithm(2) 5} 1407 authenticateAttributes { 1408 contentType {{pkcs-9 3} {pkcs-7 1}} 1409 messageDigest {{pkcs-9 4} 0x<16/20 bytes>} 1410 -- digest of pkcsGetCRLEnvelope 1411 messageType {{id-attribute messageType(2)} "CertCRL"} 1412 transaction-id {{id-attributes transId(7)} "printable 1413 string"} 1414 senderNonce {{id-attribute senderNonce(3)} <16 bytes>} 1415 } 1416 digestEncryptionAlgorithm {pkcs-1 1} 1417 encryptedDigest "encrypted digest of authenticateAttributes" 1418 } 1419 } 1420 GetCRL PKIMessage ::= { 1421 contentType {pkcs-7 2} 1422 content pkcsGetCRLSigned 1423 } 1425 5.4.2 CertRep Message Format 1427 The CRL is send back to the end entity through CertRep message. The 1428 information portion of this message is a degenerated PKCS#7 SignedData 1429 which contains only a CRL. 1431 pkcsCertRep SignedData ::= { 1432 version 1 1433 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1434 digestAlgorithm(2) 5} 1435 contentInfo { 1436 contentType {pkcs-7 1} 1437 } 1438 crl { 1439 signature {pkcs-1 4} 1440 issuer "the certificate authority issuer name" 1441 lastUpdate "UTC time" 1442 nextUpdate "UTC time" 1443 revokedCertificate { 1444 -- the first entry 1445 userCertificate "certificate serial number" 1446 revocationData "UTC time" 1447 .... 1448 -- last entry 1449 userCertificate "certificate serial number" 1450 revocationData "UTC time" 1451 } 1452 } 1453 pkcsCertRepEnvelope EnvelopedData ::= { 1454 version 0 1455 recipientInfo { 1456 version 0 1457 issuerAndSerialNumber { 1458 issuer "the end entity's issuer name" 1459 serialNumber "the end entity certificate serial number" 1460 } 1461 keyEncryptionAlgorithm {pkcs-1 1} 1462 encryptedKey "content-encrypt key encrypted by end entity's 1463 public key " 1464 } 1465 encryptedContentInfo { 1466 contentType {pkcs-7 1} -- data content 1467 contentEncryptionAlgorithm "OID for DES encryption" 1468 encryptedContent "encrypted pkcsCertRep using end entity's 1469 public key" 1470 } 1471 } 1472 pkcsCertRepSigned SignedData ::= { -- PKCS#7 1473 version 1 1474 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1475 digestAlgorithm(2) 5} 1476 contentInfo { 1477 contentType {pkcs-7 1} 1478 content pkcsCertRepEnvelope 1479 } 1480 signerInfo { 1481 version 1 1482 issuerAndSerialNumber { 1483 issuer "the certificate authority issuer name" 1484 serialNumber "the CA certificate's serial number" 1485 } 1486 digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) 1487 digestAlgorithm(2) 5} 1488 authenticateAttributes { 1489 contentType {{pkcs-9 3} {pkcs-7 1}} 1490 messageDigest {{pkcs-9 4} "an octet string"} 1491 -- digest of pkcsCertRepEnvelope 1492 messageType {{id-attribute messageType(2)} "CertRep"} 1493 transaction-id {{id-attributes transId(7)} "printable 1494 string"} 1495 -- same transaction id as given in PKCSReq 1496 pkiStatus {{id-attributes pkiStatus(1) "GRANT"} 1497 recipientNonce{{id-attribute recipientNonce(4)}<16 bytes>} 1498 senderNonce {{id-attribute senderNonce (5) 0x<16 bytes>} 1499 } 1500 digestEncryptionAlgorithm {pkcs-1 1} 1501 encryptedDigest "encrypted digest of authenticatedAttributes 1502 using CA private key" 1503 } 1504 } 1506 NOTE:The PKCS#7 EncryptedContent is specified as an octet string, but 1507 SCEP entities must also accept a sequence of octet strings as a valid 1508 alternate encoding. 1510 This alternate encoding must be accepted wherever PKCS #7 Enveloped 1511 Data is specified in this document. 1513 5.5 Get Certificate Authority Certificate 1515 Before any transaction begins, end entities have to get the CA (and 1516 possibly RA) certificate(s) first. Since no public keys have been 1517 exchanged, the message can not be encrypted and the response must be 1518 authenticated by out-of-band means. These certs are obtained by means 1519 of an HTTP GET message. To get the CA certificate, the end entity does a 1520 "HTTP GET" and receives a plan X.509 certificate in response. In the 1521 request, the URL identifies a CGI script on the server and passes the CA 1522 issuer identifier as the parameter to the CGI script. Once the CA 1523 certificate is received by the end entity, a fingerprint is generated 1524 using MD5 hash algorithm on the whole CA certificate. This fingerprint 1525 is verified by some positive out-of-band means, such as a phone call. 1527 5.5.1 GetCACert HTTP Message Format 1528 "GET" CGI-SCRIPT "?" "operation=GetCACert" "&" "message" CA-IDENT 1529 where: 1530 CGI-SCRIPT is the path and the cgi script to process the rest of 1531 the message. For example: /cgi-bin/pkiclient.exe. 1532 CA-IDENT is any string which is understood by the CA. 1533 For example, it could be a domain name like ietf.org. 1534 If a certificate authority has multiple root certificates 1535 this field can be used to distinguish which is required. 1536 Otherwise it may be ignored. 1538 5.5.2 Response 1540 The response for GetCACert is different between a case where the CA 1541 directly communicated with the end entity during the enrollment, and the 1542 case where a RA exists and the end entity communicates with the RA 1543 during the enrollment. 1545 5.5.2.1 CA Certificate Only Response 1547 A binary X.509 CA certificate is send back as a MIME object with a 1548 Content-Type of application/x-x509-ca-cert. 1550 5.5.2.2 CA and RA Certificates Response 1552 When an RA exists, both CA and RA certificates must be sent back in 1553 the response to the GetCACert request. The RA certificate(s) must be 1554 signed by the CA. A certificates-only PKCS#7 SignedData is used to 1555 carry the certificates to the end entity, with a Content-Type of 1556 application/x-x509-ca-ra-cert. 1558 The following is the ASN.1 definition of Cert-Only PKCS#7: 1560 certOnly SignedData ::= { 1561 version 1 1562 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1563 digestAlgorithm(2) 5} 1565 contentInfo { 1566 contentType {pkcs-7 1} -- data content identifier 1567 content -- NULL 1568 } 1569 certificates -- the RA and CA certificates. 1570 } 1572 CARACerts PKIMessage ::= { -- special pki message sent in the clear 1573 contentType {pkcs-7 2} 1574 content certOnly 1575 } 1577 6.0 Security Considerations 1579 This entire document is about security. Common security considerations 1580 such as keeping private keys truly private and using adequate lengths 1581 for symmetric and asymmetric keys must be followed in order to maintain 1582 the security of this protocol. 1584 7.0 Intellectual Property 1586 This protcol includes the optional use of Certificate Revocation List 1587 Distribution Point (CRLDP) technology, which is a patented technology 1588 of Entrust Technologies, Inc. (Method for Efficient Management of 1589 Certificate Revocation Lists and Update Information (U.S. Patent 1590 5,699,431)). Please contact Entrust Technologies, Inc. 1591 (www.entrust.com) for more information on licensing CRLDP technology. 1593 8.0 References 1595 [PKCS7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1596 1.5", RFC 2315, March 1998. 1598 [PKCS10] Kaliski, B., "PKCS #10: Certification Request Syntax Version 1599 1.5", RFC 2314, March 1998. 1601 [RFC2459] Housley, R., ec. al., "Internet X.509 Public Key 1602 Infrastructure Certificate and CRL Profile", RFC 2459, January 1999. 1604 Appendix A: Cisco End Entity Subject Name Definition 1606 As an end entity, a SCEP client has its subject name defined as a set of 1607 name attributes: 1609 CiscoSubjectName ::= { 1610 SEQUENCE OF { 1611 SET OF { 1612 SEQUENCE { -- required attribute 1613 unStructuredName OID 1614 name IA5String} 1615 } 1616 SET OF { 1617 SEQUENCE { -- optional attribute 1618 unStructuredAddress OID 1619 address PrintableString} 1620 } 1621 SET OF { 1622 SEQUENCE { -- optional attribute 1623 serialNumber OID 1624 number PrintableString} 1625 } 1626 } 1627 } 1629 where the OIDs are defined in the following standards: 1630 OIDs defined in PKCS#9: 1632 pkcs_prefix {iso(1),member-body(2),US(840),rsadsi(113549),pkcs(1)} 1633 unStructuredName {pkcs_prefix, 9, 2} 1634 unStructuredAddress {pkcs_prefix, 9, 8} 1636 OID defined in X.520: 1637 serialNumber 1639 An example of the instantiated name definition is given below: 1640 ciscoRouterAlice CiscoSubjectName ::= { 1641 { 1642 { unstrcutedNameOid, "alice.cisco.com"} 1643 { unstructuredAddrresOid, "172.21.114.67"} 1644 { serialNumberOid, "22334455"} 1645 } 1646 } 1648 Alternatively, the ip address and the FQDN of a SCEP client can also be 1649 included in the V3 extension subjectAltName. When the subjectAltName 1650 extension attribute is present, both the subjectAltName fields and the 1651 subjectName field could have the IP address and the FQDN information. 1652 When the X.500 directory is used by the CA to define the name space, the 1653 subject name defined above become a RDN which is part of DN binded to 1654 the end entity's public key in the certificate. 1656 A sample of DN assigned by Entrust CA is given below (assume the same 1657 ciscoRouterAlice is used as the end entity defined subject name): 1659 OU = InteropTesting, O = Entrust Technologies, C = CA 1660 RDN = {"alice.cisco.com", "172.21.114.67", "22334455"} 1662 Appendix B: IPSEC Client Enrollment Certificate Request 1664 The following is the certificate enrollment request (PKCS#10) as created 1665 by Cisco VPN Client: 1667 -----END NEW CERTIFICATE REQUEST----- 1668 0 30 439: SEQUENCE { 1669 4 30 288: SEQUENCE { 1670 8 02 1: INTEGER 0 1671 11 30 57: SEQUENCE { 1672 13 31 55: SET { 1673 15 30 53: SEQUENCE { 1674 17 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 1675 22 13 46: PrintableString 1676 : 'For Xiaoyi, IPSEC attrs in alternate name 1677 extn' 1678 : } 1679 : } 1680 : } 1681 70 30 158: SEQUENCE { 1682 73 30 13: SEQUENCE { 1683 75 06 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1684 1 1) 1685 86 05 0: NULL 1686 : } 1687 88 03 140: BIT STRING 0 unused bits 1688 : 30 81 88 02 81 80 73 DB 1D D5 65 AA EF C7 D4 8E 1689 : AA 6E EB 46 AC 91 2A 0F 50 51 17 AD 50 A2 2A F2 1690 : CE BE F1 E4 22 8C D7 61 A1 6C 87 61 62 92 CB A6 1691 : 80 EA B4 0F 09 9D 18 5F 39 A3 02 0E DB 38 4C E4 1692 : 8A 63 2E 72 8B DC BE 9E ED 6C 1A 47 DE 13 1B 0F 1693 : 83 29 4D 3E 08 86 FF 08 2B 43 09 EF 67 A7 6B EA 1694 : 77 62 30 35 4D A9 0F 0F DF CC 44 F5 4D 2C 2E 19 1695 : E8 63 94 AC 84 A4 D0 01 E1 E3 97 16 CD 86 64 18 1696 : [ Another 11 bytes skipped ] 1697 : } 1698 231 A0 63: [0] { 1699 233 30 61: SEQUENCE { 1700 235 06 9: OBJECT IDENTIFIER extensionReq (1 2 840 113549 1 9 1701 14) 1702 246 31 48: SET { 1703 248 30 46: SEQUENCE { 1704 250 30 44: SEQUENCE { 1705 252 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 1706 257 04 37: OCTET STRING 1707 30 23 87 04 01 02 03 04 81 0D 65 6D 61 69 1708 6C 40 69 72 65 2E 63 6F 6D 82 0C 66 71 64 1709 6E 2E 69 72 65 2E 63 6F 6D 1710 : } 1711 : } 1712 : } 1713 : } 1714 : } 1715 : } 1717 296 30 13: SEQUENCE { 1718 298 06 9: OBJECT IDENTIFIER md5withRSAEncryption (1 2 840 113549 1719 1 1 4) 1720 309 05 0: NULL 1721 : } 1722 311 03 129: BIT STRING 0 unused bits 1723 : 19 60 55 45 7F 72 FD 4E E5 3F D2 66 B0 77 13 9A 1724 : 87 86 75 6A E1 36 C6 B6 21 71 68 BD 96 F0 B4 60 1725 : 95 8F 12 F1 65 33 16 FD 46 8A 63 19 90 40 B4 B7 1726 : 2C B5 AC 63 17 50 28 F0 CD A4 F0 00 4E D2 DE 6D 1727 : C3 4F F5 CB 03 4D C8 D8 31 5A 7C 01 47 D2 2B 91 1728 : B5 48 55 C8 A7 0B DD 45 D3 4A 8D 94 04 3A 6C B0 1729 : A7 1D 64 74 AB 8A F7 FF 82 C7 22 0A 2A 95 FB 24 1730 : 88 AA B6 27 83 C1 EC 5E A0 BA 0C BA 2E 6D 50 C7 1731 : } 1733 Appendix C: Private OID Definitions 1735 The OIDs used in defining pkiStatus are VeriSign self-maintained 1736 OIDs. Please note, work is in progress to replace the VeriSign owned 1737 object identifiers with the standard object identifiers. Once the 1738 standarlization is completed, this documentation will be updated. 1740 id-VeriSign OBJECT_IDENTIFIER ::= {2 16 US(840) 1 VeriSign(113733)} 1741 id-pki OBJECT_IDENTIFIER ::= {id-VeriSign pki(1)} 1742 id-attributes OBJECT_IDENTIFIER ::= {id-pki attributes(9)} 1743 id-messageType OBJECT_IDENTIFIER ::= {id-attributes messageType(2)} 1744 id-pkiStatus OBJECT_IDENTIFIER ::= {id-attributes pkiStatus(3)} 1745 id-failInfo OBJECT_IDENTIFIER ::= {id-attributes failInfo(4)} 1746 id-senderNonce OBJECT_IDENTIFIER ::= {id-attributes senderNonce(5)} 1747 id-recipientNonce OBJECT_IDENTIFIER ::= {id-attributes recipientNonce(6)} 1748 id-transId OBJECT_IDENTIFIER ::= {id-attributes transId(7)} 1749 id-extensionReq OBJECT_IDENTIFIER ::= {id-attributes extensionReq(8)} 1751 Appendix D: CRL Query by means of LDAP 1753 In order to retrieve the CRL by means of LDAP, the client needs to know 1754 where in the directory it is stored. The certificate must contain a 1755 CRL Distribution Point extension encoded as a DN. 1757 For example, the certificate issued by Entrust VPN contains 1758 the following DN as the CRL distribution point: 1760 CN = CRL1, O = cisco, C = US. 1762 The asn.1 encoding of this distribution point is: 1764 30 2C 31 0B 30 09 06 03 55 04 06 13 02 55 53 31 0E 30 0C 06 1765 03 55 04 0A 13 05 63 69 73 63 6F 31 0D 30 0B 06 03 55 04 03 1766 13 04 43 52 4C 31 1768 Appendix E: SCEP State Transitions 1770 SCEP state transitions are based on transaction identifier. The design 1771 goal is to ensure the synchronization between the CA and the end entity 1772 under various error situations. 1774 An identity is defined by the combination of FQDN, the IP address and 1775 the client serial number. FQDN is the required name attribute. It is 1776 important to notice that, a client named as Alice@cisco.com is different 1777 from the client named as Alice@cisco.com plus IPAddress 171.69.1.129. 1779 Each enrollment transaction is uniquely associated with a transaction 1780 identifier. Because the enrollment transaction could be interrupted by 1781 various errors, including network connection errors or client reboot, 1782 the SCEP client generates a transaction identifier by calculating MD5 1783 hash on the public key value for which the enrollment is requested. This 1784 retains the same transaction identifier throughout the enrollment 1785 transaction, even if the client has rebooted or timed out, and issues a 1786 new enrollment request for the same key pair. It also provides the way 1787 for the CA to uniquely identify a transaction in its database. At the 1788 end entity side, it generates a transaction identifier which is included 1789 in PKCSReq. If the CA returns a response of PENDING, the end entity 1790 will poll by periodically sending out GetCertInitial with the same 1791 transaction identifier until either a response other than PENDING is 1792 obtained, or the configured maximum time has elapsed. 1794 If the client times out or the client reboots, the client administrator 1795 will start another enrollment transaction with the same key pair. The 1796 second enrollment will have the transaction idenifier. At the server 1797 side, instead of accepting the PKCSReq as a new enrollment request, it 1798 should respond as if another GetCertInitial message had been sent with 1799 that transaction ID. In another word, the second PKCSReq should be 1800 taken as a resynchronization message to allow the enrollment resume as 1801 the same transaction. 1803 It is important to keep the transaction id unique since CEP requires the 1804 same policy and same identity be applied to the same subject name and 1805 key pair binding. In the current implementation, an SCEP client can 1806 only assume one identity. At any time, only one key pair, with a given 1807 key usage, can be associated with the same identity. 1809 The following gives several example of client to CA transactions. 1811 Client actions are indicated in the left column, CA actions are 1812 indicated in the right column. A blank action signifies that no message 1813 was received. Note that these examples assume that the CA enforces the 1814 certificate-name uniqueness property defined in Section 2.1.1.1. 1816 The first transaction, for example, would read like this: 1817 "Client Sends PKCSReq message with transaction ID 1 to the 1818 CA. The CA signs the certificate and constructs a CertRep Message 1819 containing the signed certificate with a transaction ID 1. The client 1820 receives the message and installs the cert locally." 1822 Successful Enrollment Case: no manual authentication 1823 PKCSReq (1) ----------> CA Signs Cert 1824 Client Installs Cert <---------- CertRep (1) SIGNED CERT 1826 Successful Enrollment Case: manual authentication required 1827 PKCSReq (10) ----------> Cert Request goes into Queue 1828 Client Polls <---------- CertRep (10) PENDING 1829 GetCertInitial (10) ----------> Still pending 1830 Client Polls <---------- CertRep (10) PENDING 1831 GetCertInitial (10) ----------> Still pending 1832 Client Polls <---------- CertRep (10) PENDING 1833 GetCertInitial (10) ----------> Still pending 1834 Client Polls <---------- CertRep (10) PENDING 1835 GetCertInitial (10) ----------> Cert has been signed 1836 Client Installs Cert <---------- CertRep (10) SIGNED CERT 1838 Resync Case - CA Receive and Signs PKCSReq, Client Did not receive 1839 CertRep: 1841 PKCSReq (3) ----------> Cert Request goes into queue 1842 <---------- CertRep (3) PENDING 1843 GetCertInitial (3) ----------> 1844 <---------- CertRep (3) PENDING 1845 GetCertInitial (3) -----------> 1846 <----------- CA signed Cert and send back 1847 CertRep(3) 1848 (Time Out) 1849 PKCSReq (3) ----------> Cert already signed, send back to 1850 client 1851 Client Installs Cert <---------- CertRep (3) SIGNED CERT 1852 Case when NVRAM is lost and client has to generate a new key pair, there 1853 is no change of name information: 1855 PKCSReq (4) ----------> CA Signs Cert 1856 Client Installs Cert <---------- CertRep (4) SIGNED CERT 1857 (Client looses Cert) 1858 PKCSReq (5) ----------> There is already a valid cert with 1859 this DN. 1860 Client Admin Revokes <---------- CertRep (5) OVERLAPPING CERT ERROR 1861 PKCSReq (5) ----------> CA Signs Cert 1862 Client Installs Cert <---------- CertRep (5) SIGNED CERT 1864 Case when client admin resync the enrollment using a different PKCS#10: 1865 PKCSReq (6) ----------> CA Signs Cert 1866 <---------- CertRep (6) SIGNED CERT 1867 (Client timeout and admin starts another enrollment with a different 1868 PKCS#10, but the same transaction id) 1869 PKCSReq (6) with different PKCS#10 1870 ----------> There is already a valid cert with 1871 this entity (by checking FQDN). 1872 <---------- CertRep (6) INVALID PKCS#10 CERT 1873 ERROR 1874 Client admin either revokes the existing cert 1875 or corrects the error by enrolling with 1876 the same PKCS#10 as the first PKCSReq(6) 1877 PKCSReq (6) ----------> CA find the existing Cert 1878 Client Installs Cert <---------- CertRep (6) SIGNED CERT 1880 Resync case when server is slow in response: 1881 PKCSReq (13) ----------> Cert Request goes into Queue 1882 <---------- CertRep (13) PENDING 1883 GetCertInitial ----------> Still pending 1884 <---------- CertRep (13) PENDING 1885 GetCertInitial ----------> Still pending 1886 <---------- CertRep (13) PENDING 1887 GetCertInitial ----------> Still pending 1888 <---------- CertRep (13) PENDING 1889 GetCertInitial ----------> Still pending 1890 (TimeOut) <---------- CertRep (13) PENDING 1891 * Case 1 1892 PKCSReq (13) ----------> Still pending 1893 Client polls <---------- CertRep (13) PENDING 1894 CertCertInitial ----------> Cert has been signed 1895 Client Installs Cert <---------- CertRep (13) SIGNED CERT 1896 * Case 2 1897 PKCSReq (13) ----------> Cert has been signed 1898 Client Installs Cert <---------- CertRep (13) SIGNED CERT 1899 Appendix F. Author Contact Information 1901 Xiaoyi Liu 1902 Cisco 1903 170 West Tasman Drive 1904 San Jose, CA 94134 1905 xliu@cisco.com 1907 Cheryl Madson 1908 Cisco 1909 170 West Tasman Drive 1910 San Jose, CA 94134 1911 cmadson@cisco.com 1913 David McGrew 1914 Cisco 1915 170 West Tasman Drive 1916 San Jose, CA 94134 1917 mcgrew@cisco.com 1919 Andrew Nourse 1920 Cisco 1921 101 Cooper Street 1922 Santa Cruz, CA 95060 1923 nourse@cisco.com 1925 Appendix G. Copyright Section 1927 Copyright (C) The Internet Society (2000). All Rights Reserved. 1929 This document and translations of it may be copied and furnished 1930 to others, and derivative works that comment on or otherwise 1931 explain it or assist in its implmentation may be prepared, copied, 1932 published and distributed, in whole or in part, without 1933 restriction of any kind, provided that the above copyright notice 1934 and this paragraph are included on all such copies and derivative 1935 works. However, this document itself may not be modified in any 1936 way, such as by removing the copyright notice or references to the 1937 Internet Society or other Internet organizations, except as needed 1938 for the purpose of developing Internet standards in which case the 1939 procedures for copyrights defined in the Internet Standards 1940 process must be followed, or as required to translate it into 1941 languages other than English. 1943 The limited permissions granted above are perpetual and will not 1944 be revoked by the Internet Society or its successors or assigns. 1946 This document and the information contained herein is provided on 1947 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1948 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1949 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1950 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1951 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 1952 PURPOSE. 1954 This draft expires 04 August 2000. 1956 [End of draft-nourse-scep-02.txt]