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