idnits 2.17.1 draft-nourse-scep-08.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 20 instances of too long lines in the document, the longest one being 6 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 861 has weird spacing: '... as the signe...' == Line 923 has weird spacing: '...content pkcsC...' == Line 1372 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 1286, but not defined -- Looks like a reference, but probably isn't: '0' on line 1708 == Unused Reference: 'PKCS7' is defined on line 1646, but no explicit reference was found in the text == Unused Reference: 'PKCS10' is defined on line 1649, but no explicit reference was found in the text == Unused Reference: 'RFC2459' is defined on line 1652, 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-08.txt Cheryl Madson 3 expires 26-March-2004 David McGrew 4 Andrew Nourse 5 Cisco Systems 7 Category: Informational 26-Sep-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=" MESSAGE 639 where: 640 CGI-PATH defines the actual CGI path to invoke the CGI program which 641 parses the request. 642 | CGI-PROG is set to be the string "pkiclient.exe". This is intended 643 | to be the program that the CA will use to handle the SCEP transactions, 644 | though the CA may ignore CGI-PROG and use only the CGI-PATH. 645 OPERATION is set to be the string "PKIOperation" when the GET message 646 carries a PKI message to request certificates or CRL; OPERATION is set 647 | to be the string "GetCACert" or "GetCACertChain" when the GET operation 648 | is used to get CA/RA certificate or the CA Cert chain (respectively). 649 When OPERATION is "PKIOperation", MESSAGE is a base64-encoded PKI 650 message 651 | when OPERATION is "GetCACert" or "GetCACertChain", MESSAGE is a string 652 | which represents the certificate authority issuer identifier. 654 For example. An end entity may submit a message via HTTP to the server 655 as follows: 657 GET /cgi-bin/pkiclient.exe?operation=PKIOperation&message=MIAGCSqGSIb3D 658 QEHA6CAMIACAQAxgDCBzAIBADB2MGIxETAPBgNVBAcTCE ......AAAAAA== 660 3.2 Response Message Format 662 For each GET operation, the CA/RA server will return a MIME object via 663 HTTP. For a GET operation with PKIOperation as its type, the response is 664 tagged as having a Content Type of application/x-pki-message. The body 665 of this message is a BER encoded binary PKI message. The following is an 666 example of the response: 668 "Content-Type:application/x-pki-message\n\n" 670 In the case of GET operation with a type of GetCACert, the MIME content 671 type returned will depend on whether or not an RA is in use. If there 672 is no RA, only the CA certificate is send back in the response, and the 673 response has the content type tagged as application/x-x509-ca-cert. the 674 body of the response is a DER encoded binary X.509 certificate. For 675 example: 677 "Content-Type:application/x-x509-ca-cert\n\n" 679 If there is an RA, the RA certificates are send back together with the 680 CA certificates, a certificate-only PKCS#7 SignedData is send back in 681 the response where the SignerInfo is empty. Section 5 has the detailed 682 definition of the message format in this case. The content type is 683 application/x-x509-ca-ra-cert. 685 Section 4 Secure Transportation: PKCS#7 687 PKCS#7 is a general enveloping mechanism that enables both signed and 688 encrypted transmission of arbitrary data. It is widely implemented and 689 included in the RSA tool kit. 691 In this section, the general PKCS#7 enveloped PKI message format is 692 specified. The complete PKCS#7 message format for each PKI transaction 693 will be covered in Section 5. 695 4.1 SCEP Message Format 697 As a transaction message, a SCEP message has a set of transaction 698 specific attributes and an information portion. Employing PKCS#7 699 protocol, the transaction specific attributes are encoded as a set of 700 authenticated attributes of the SignedData. The information portion will 701 first be encrypted to become Enveloped Data, and then the digest of the 702 enveloped information portion is included as one of the message digest 703 attributes and being signed together with the other transaction specific 704 attributes. 706 By applying both enveloping and signing transformations, a SCEP message 707 is protected both for the integrity of its end-end-transition 708 information and the confidentiality of its information portion. The 709 advantage of this technique over the conventional transaction message 710 format is that, the signed transaction type information and the status 711 of the transaction can be determined prior to invoke security handling 712 procedures specific to the information portion being processed. 714 The following is an example of a SCEP message with its enveloped and 715 signed data portion represented by pkcsPKISigned and 716 pkcsPKIEnveloped. The out-most of any PKI message is a blob of 717 ContentInfo, with its content type set to SignedData and the actual 718 signed data as the content. 720 pkiMessage ContentInfo ::= { 721 contentType {pkcs-7 signedData(2)} 722 content pkcsPKISigned 723 } 724 pkcsPKISigned SignedData ::= { 725 version 1 726 digestAlgorithm { iso(1) member-body(2) US(840) rsadsi(113549) 727 digestAlgorithm(2) 5} 728 contentInfo { 729 contentType {pkcs-7 1} -- data content identifier 730 content pkcsPKIEnvelope -- enveloped information portion 731 } 732 certificates -- signer certificate chain 733 signerInfo -- including signed transaction info and the digest 734 -- of the enveloped information portion as the 735 -- authenticated attributes 736 } 737 pkcsPKIEnveloped EnvelopedData ::= { 738 version 0 739 recipientInfos -- information required to open the envelop 740 encryptedContentInfo { 741 contentType {pkcs-7 1} -- data content identifier 742 contentEncryptionAlgorithm 743 encryptedContent -- encrypted information portion 744 } 745 } 747 4.2 Signed Transaction Attributes 749 The following transaction attributes are encoded as authenticated 750 attributes. Please refer to Appendix B for the OID definitions. 752 transactionID PrintableString -- Decimal value as a string 753 messageType PrintableString -- Decimal value as a string 754 pkiStatus PrintableString -- Decimal value as a string 755 failinfo PrintableString -- Decimal value as a string 756 senderNonce Octet String 757 recipientNonce Octet String 759 where: 761 The transactionID is an attribute which uniquely identify a 762 transaction. This attribute is required in all PKI messages. 764 The messageType attribute specify the type of operation performed by the 765 transaction. This attribute is required in all PKI 766 messages. Currently, the following message types are defined: 768 PKCSReq (19) -- Permits use of PKCS#10 certificate request 769 CertRep (3) -- Response to certificate or CRL request 770 GetCertInitial (20) -- Certificate polling in manual enrollment 771 GetCert (21) -- Retrieve a certificate 772 GetCRL (22) -- Retrieve a CRL 774 All response message will include transaction status information which 775 is defined as pkiStatus attribute: 777 SUCCESS (0) -- request granted 778 FAILURE (2) -- request rejected 779 PENDING (3) -- request pending for manual approval. 781 If the status in the response is FAILURE, the failinfo attribute will 782 contain one of the following failure reasons: 784 badAlg (0) -- Unrecognized or unsupported algorithm ident 785 badMessageCheck (1) -- integrity check failed 786 badRequest (2) -- transaction not permitted or supported 787 badTime (3) -- Message time field was not sufficiently close 788 to the system time 789 badCertId (4) -- No certificate could be identified matching 790 the provided criteria 792 The attributes of senderNonce and recipientNonce are the 16 byte 793 random numbers generated for each transaction to prevent the replay 794 attack. 796 When an end entity sends a PKI message to the server, a senderNonce is 797 included in the message. After the server processes the request, it will 798 send back the end entity senderNonce as the recipientNonce and generates 799 another nonce as the senderNonce in the response message. Because the 800 proposed pki protocol is a two-way communication protocol, it is clear 801 that the nonce can only be used by the end entity to prevent the 802 replay. The server has to employ extra state related information to 803 prevent a replay attack. 805 Section 5. SCEP Transaction Specification 807 In this section each SCEP transaction is specified in terms of the 808 complete messages exchanged during the transaction. 810 5.1 Certificate Enrollment 812 The certificate enrollment transaction consists of one PKCSReq message 813 send to the certificate authority from an end entity, and one CertRep 814 message send back from the server. The pkiStatus returned in the 815 response message is either SUCCESS, or FAILURE, or PENDING. The 816 information portion of a PKCSReq message is a PKCS#10 certificate 817 request, which contains the subject Distinguished Name, the subject 818 public key, and two attributes, a ChallangePassword attribute to be used 819 for revocation, and an optional ExtensionReq attribute which will be a 820 sequence of extensions the end entity expects to be included in its V3 821 certificate extensions. One of the extension attribute specifies the key 822 usage. The pkiStatus is set to SUCCESS when the certificate is send 823 back in CertRep; the pkiStatus is set to FAILURE when the certificate 824 request is rejected; the pkiStatus is set to PENDING when the server has 825 decided to manually authenticate the end entity. The messages exchanged 826 in the manual authentication mode is further specified in Section 5.2. 828 Precondition: 829 Both the end entity and the certificate authority have completed their 830 initialization process. The end entity has already been configured 831 with the CA/RA certificate. 833 Postcondition: 834 Either the certificate is received by the end entity, or the end 835 entity is notified to do the manual authentication, or the request 836 is rejected. 838 5.1.1 PKCSReq Message Format 840 A PKCSReq message is created by following the steps defined below: 842 1. Create a PKCS#10 certificate request which is signed by the end 843 entity's private key, corresponding to the public key included in 844 the PKCS#10 certificate request. This constitutes the information 845 portion of PKCSReq. 847 2. Encrypt the PKCS#10 certificate request using a randomly generated 848 content-encryption key. This content-encryption key is then 849 encrypted by the CA's* public key and included in the recipientInfo. 850 This step completes the "envelope" for the PKCS#10 certificate 851 request. 853 3. Generate a unique string as the transaction id. 855 4. Generate a 16 byte random number as senderNonce. 857 5. Generate message digest on the enveloped PKCS#10 certificate request 858 using the selected digest algorithm. 860 6. Create SignedData by adding the end entity's self-signed certificate 861 as the signer's public key certificate. Include the message type, 862 transaction id, the senderNonce and the message digest as the 863 authenticated attributes and sign the attributes using the end 864 entity's private key. This completes the SignedData. 866 7. The SignedData is prepended with the ContenInfo blob which indicates 867 a SignedData object. This final step completes the create of a 868 complete PKCSReq PKI message. 870 In the following, the PKCSReq message is defined following the ASN.1 871 notation. 873 For readability, the values of a field is either represented by a quoted 874 string which specifies the intended value, or a constant when the value 875 is known. 877 -- PKCSReq information portion 878 pkcsCertReq CertificationRequest ::= { -- PKCS#10 879 version 0 880 subject "the end entity's subject name" 881 subjectPublicKeyInfo { 882 algorithm {pkcs-1 1} -- rsa encryption 883 subjectPublicKey "DER encoding of the end entity's public key" 884 } 885 attributes { 886 challengePassword {{pkcs-9 7} "password string" } 887 extensions 888 } 889 signatureAlgorithm {pkcs-1 4} -- MD5WithRSAEncryption 890 signature "bit string which is created by signing inner content 891 of the defined pkcsCertReq using end entity's private 892 key, corresponding to the public key included in 893 subjectPublicKeyInfo." 894 } 895 -- Enveloped information portion 896 pkcsCertReqEnvelope EnvelopeData ::= { -- PKCS#7 897 version 0 898 recipientInfo { 899 version 0 900 issuerAndSerialNumber { 901 issuer "the CA issuer name" 902 serialNumber "the CA certificate serial number" 903 } 904 keyEncryptionAlgorithm {pkcs-1 1} -- rsa encryption 905 encryptedKey "content-encryption key 906 encrypted by CA public key" 907 } 908 encryptedContentInfo { 909 contentType {pkcs-7 1} -- data content 910 contentEncryptionAlgorithm "object identifier 911 for DES encryption" 912 encryptedContent "encrypted pkcsCertReq using the content- 913 encryption key" 914 } 915 } 916 -- Signed PKCSReq 917 pkcsCertReqSigned SignedData ::= { -- PKCS#7 918 version 1 919 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 920 digestAlgorithm(2) 5} 921 contentInfo { 922 contentType {pkcs-7 1} -- data content identifier 923 content pkcsCertReqEnvelope 924 } 925 certificate { -- the end entity's self-signed certificate 926 version 3 927 serialNumber "the transaction id associated with enrollment" 928 signature {pkcs-1 4} -- md5WithRSAEncryption 930 issuer " the end entity's subject name" 931 validity { 932 notBefore "a UTC time" 933 notAfter "a UTC time" 934 } 935 subject "the end entity's subject name" 936 subjectPublicKeyInfo { 937 algorithm {pkcs-1 1} 938 subjectPublicKey "DER encoding of end entity's public key" 939 } 940 signatureAlgorithm {pkcs-1 4} 941 signature "the signature generated by using the end entity's 942 private key corresponding to the public key in 943 this certificate." 944 } 945 signerInfo { 946 version 1 947 issuerAndSerialNumber { 948 issuer "the end entity's subject name" 949 serialNumber "the transaction id associated 950 with the enrollment" 951 } 952 digestAlgorithm {iso(0) member-body(2) US(840) rsadsi(113549) 953 digestAlgorithm(2) 5} 954 authenticateAttributes { 955 contentType {{pkcs-9 3} {pkcs-7 1}} 956 messageDigest {{pkcs-9 4} "an octet string"} 957 transaction-id {{id-attributes transId(7)} "printable 958 string"} 959 -- this transaction id will be used 960 -- together with the subject name as 961 -- the identifier of the end entity's key 962 -- pair during enrollment 963 messageType {{id-attributes messageType(2)} "PKCSReq"} 964 senderNonce {{id-attributes senderNonce(5)} 965 "a random number encoded as a string"} 966 } 967 digestEncryptionAlgorithm {pkcs-1 1} -- rsa encryption 968 encryptedDigest "encrypted digest of the authenticated 969 attributes using end entity's private key" 970 } 971 } 972 pkcsReq PKIMessage ::= { 973 contentType {pkcs-7 2} 974 content pkcsCertRepSigned 975 } 977 5.1.2 CertRep Message Format 979 The response to an SCEP enrollment request is a CertRep message. 981 5.1.2.1 PENDING Response 983 When the CA is configured to manually authenticate the end entity, 984 the CertRep is returned with the attribute pkiStatus set to PENDING. 985 The data portion for this message is null. Only the transaction 986 required attributes are sent back. 988 CertRepSigned SignedData ::= { -- PKCS#7 989 version 1 990 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 991 digestAlgorithm(2) 5} 992 contentInfo {contentType {pkcs-7 1} -- empty content 993 } 994 signerInfo { 995 version 1 996 issuerAndSerialNumber { 997 | issuer "name of CA that issued the CA [RA] cert" 998 | serialNumber "the serial number of the CA [RA] cert" 999 } 1000 digestAlgorithm (iso(1) member-body(2) US(840) rsadsi(113549) 1001 digestAlgorithm(2) 5} 1002 authenticateAttributes { 1003 contentType {{pkcs-9 3} {pkcs-7 1}} 1004 messageDigest {{pkcs-9 4} NULL} 1005 messageType {{id-attribute messageType(0)} "CertRep"} 1006 transaction-id {{id-attributes transid(7)} "printablestring"} 1007 --- same transaction id used in PKCSReq 1008 pkiStatus {{id-attributes pkiStatus(3)} "PENDING"} 1009 recipientNonce {{id-attributes recipientNonce(6)}<16 bytes>} 1010 senderNonce {{id-attributes senderNonce(5)} <16 bytes>} 1011 } 1012 digestEncrytionAlgorithm {pkcs-1 1} 1013 encryptedDigest "encrypted message digest of the authenticated 1014 | attributes using the CA's [RA's] private key" 1015 } 1016 } 1017 CertRep PKIMessage ::= { 1018 contentType {pkcs-7 2} 1019 content CertRepSigned 1020 } 1022 5.1.2.2 Failure Response 1024 In this case, the CertRep sent back to the end entity is same as in 1025 the PENDING case, except that the pkiStatus attribute is set to FAILURE, 1026 and the failInfo attribute should be included: 1028 pkistatus {{id-attributes pkiStatus(3)} "FAILURE"} 1029 failInfo {{id-attributes failInfo(4)} "the reason to reject"} 1031 5.1.2.3 SUCCESS response 1033 In this case, the information portion of CertRep will be a degenerated 1034 PKCS#7 which contains the end entity's certificate. It is then enveloped 1035 and signed as below: 1037 pkcsCertRep SignedData ::= { -- PKCS#7 1038 version 1 1039 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1040 digestAlgorithm(2) 5} 1041 contentInfo { -- empty content since this is degenerated PKCS#7 1042 contentType {pkcs-7 1} 1043 } 1044 certificates { 1045 certificate { -- issued end entity's certificate // must be first 1046 version 3 1047 serialNumber "issued end entity's certificate serial number" 1048 signature {pkcs-1 4} -- md5WithRSAEncryption 1049 issuer "the certificate authority issuer name" 1050 validity { 1051 notBefore "UTC time" 1052 notAfter "UTC time" 1053 } 1054 subject "the end entity subject name as given in PKCS#10" 1055 subjectPublicKeyInfo { 1056 algorithm {pkcs-1 1} 1057 subjectPublicKey "a DER encoding of end entity public 1058 key as given in PKCS#10" 1059 } 1060 extensions " the extensions as given in PKCS#10" 1061 signatureAlgorithm {pkcs-1 4} 1062 signature " the certificate authority signature" 1063 } 1064 certificate "the certificate authority certificate" (optional) 1065 certificate "the registration authority certificate(s)" (optional) 1066 } 1067 } 1068 pkcsCertRepEnvelope EnvelopedData ::= { -- PKCS#7 1069 version 0 1070 recipientInfo { 1071 version 0 1072 issuerAndSerialNumber { -- use issuer name and serial number as 1073 -- conveyed in end entity's self-signed 1074 -- certificate, included in the PKCSReq 1075 issuer "the end entity's subject name" 1076 serialNumber "the serial number defined by the end entity in 1077 its self-signed certificate" 1078 } 1079 keyEncryptionAlgorithm {pkcs-1 1} 1080 encryptedKey "content-encrypt key encrypted by the end entity's 1081 public key which is same key as authenticated in 1082 the end entity's certificate" 1083 } 1084 encryptedContentInfo { 1085 contentType {pkcs-7 1} -- data content identifier 1086 contentEncryptionAlgorithm "OID for DES encryption" 1087 encryptedContent "encrypted pkcsCertRep using content encryption 1088 key" 1089 } 1090 } 1091 pkcsCertRepSigned SignedData ::= { -- PKCS#7 1092 version 1 1093 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1094 digestAlgorithm(2) 5} 1095 contentInfo { 1096 contentType {pkcs-7 1} 1097 content pkcsCertRepEnvelope 1098 } 1099 signerInfo { 1100 version 1 1101 issuerAndSerialNumber { 1102 issuer "the certificate authority issuer name" 1103 serialNumber "the CA certificate's serial number" 1104 } 1105 digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) 1106 digestAlgorithm(2) 5} 1107 authenticateAttributes { 1108 contentType {{pkcs-9 3} {pkcs-7 1}} 1109 messageDigest {{pkcs-9 4} "a octet string"} 1110 messageType {{id-attribute messageType(2)} "CertRep"} 1111 transaction-id {{id-attributes transId(7)} "printable 1112 string"} 1113 -- same transaction id as given in PKCSReq 1114 pkiStatus {{id-attributes pkiStatus(3) "SUCCESS"} 1115 recipientNonce {{id-attribute recipientNonce(6)}<16 bytes>} 1116 senderNonce {{ id-attributes senderNonce(5) <16 bytes>} 1117 } 1118 digestEncryptionAlgorithm {pkcs-1 1} 1119 encryptedDigest "encrypted digest of authenticate attributes 1120 using CA's private key " 1121 } 1122 } 1123 CertRep PKIMessage ::= { 1124 contentType {pkcs-7 2} 1125 content pkcsCertRepSigned 1126 } 1128 5.2 Poll for End Entity Initial Certificate 1130 Either triggered by the PENDING status received from the CertRep, or by 1131 the non-response timeout for the previous PKCSReq, an end entity will 1132 enter the polling state by periodically sending GetCertInitial to the 1133 server, until either the request is granted and the certificate is sent 1134 back, or the request is rejected, or the the configured time limit for 1135 polling is exceeded. 1137 Since GetCertInitial is part of the enrollment, the messages exchanged 1138 during the polling period should carries the same transaction identifier 1139 as the previous PKCSReq. 1141 PreCondition 1142 Either the end entity has received a CertRep with pkiStatus set to be 1143 PENDING, or the previous PKCSReq has timed out. 1145 PostContition 1146 The end entity has either received the certificate, or be rejected of 1147 its request, or the polling period ended as a failure. 1149 5.2.1 GetCertInitial Message Format 1151 |Since at this time the certificate has not been issued, the end entity 1152 |can only use the end entity's subject name, combined with the 1153 |transaction identifier, to identify the polled certificate request. 1155 |The certificate authority server must be able to uniquely identify the 1156 |polled certificate request. A subject name can have more than one 1157 |outstanding certificate request (with different key usage attributes). 1159 -- Information portion 1161 pkcsGetCertInitial issuerAndSubject ::= { 1162 issuer "the certificate authority issuer name" 1163 subject "the end entity subject name as given in PKCS#10" 1164 } 1165 pkcsGetCertInitialEnvelope EnvelopedData ::= { 1166 version 0 1167 recipientInfo { 1168 version 0 1169 issuerAndSerialNumber { 1170 issuer "the CA issuer name" 1171 serialNumber "the CA certificate serial number" 1172 } 1173 keyEncryptionAlgorithm {pkcs-1 1} 1174 encryptedKey "content-encrypt key encrypted by CA's public key" 1175 } 1176 encryptedContentInfo { 1177 contentType {pkcs-7 1} -- data content 1178 contentEncryptionAlgorithm "OID for DES encryption" 1179 encryptedContent "encrypted getCertInital" 1180 } 1181 } 1182 pkcsGetCertInitialSigned SignedData ::= { -- PKCS#7 1183 version 1 1184 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1185 digestAlgorithm(2) 5} 1186 contentInfo { 1187 contentType {pkcs-7 1} 1188 content pkcsGetCertIntialEnvelope 1189 } 1190 certificate { -- the end entity's self-signed certificate 1191 version 3 1192 serialNumber "the transaction id associated with enrollment" 1193 signature {pkcs-1 4} -- md5WithRSAEncryption 1194 issuer " the end entity's subject name" 1195 validity { 1196 notBefore "a UTC time" 1197 notAfter "a UTC time" 1198 } 1199 subject "the end entity's subject name" 1200 subjectPublicKeyInfo { 1201 algorithm {pkcs-1 1} 1202 subjectPublicKey "DER encoding of end entity's public key" 1203 } 1204 signatureAlgorithm {pkcs-1 4} 1205 signature "the signature generated by using the end entity's 1206 private key corresponding to the public key in 1207 this certificate." 1208 } 1209 signerInfo { 1210 version 1 1211 issuerAndSerialNumber { 1212 issuer "end entity's subject name" 1213 serialNumber "the transaction id used in previous PKCSReq" 1214 } 1215 digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) 1216 digestAlgorithm(2) 5} 1217 authenticateAttributes { 1218 contentType {{pkcs-9 3} {pkcs-7 1}} 1219 messageDigest {{pkcs-9 4} "an octet string"} 1220 -- digest of getCertInitial 1221 messageType {{id-attribute messageType(2)} "GetCertInitial"} 1222 transaction-id {{id-attributes transId(7)} "printable 1223 string"} 1224 -- same transaction idused in previous PKCSReq 1225 senderNonce {{id-attribute senderNonce(3)} 0x<16 bytes>} 1226 } 1227 digestEncryptionAlgorithm {pkcs-1 1} 1228 encryptedDigest "encrypted digest of authenticateAttributes" 1229 } 1230 } 1231 GetCertInitial PKIMessage ::= { 1232 contentType {pkcs-7 2} 1233 content pkcsGetCertInitialSigned 1234 } 1236 5.2.2 GetCertInitial Response Message Format 1238 The response messages for GetCertInitial are the same as for PKCSReq. 1240 5.3 Certificate Access 1242 The certificate query message defined in this section is an option when 1243 the LDAP server is not available to provide the certificate query. An 1244 end entity should be able to query an issued certificate from the 1245 certificate authority, as long as the issuer name and the issuer 1246 assigned certificate serial number is known to the requesting end 1247 entity. This transaction is not intended to provide the service as a 1248 certificate directory service. A more complicated query mechanism would 1249 have to be defined in order to allow an end entity to query a certificate 1250 using various different fields. 1252 This transaction consists of one GetCert message send to the server by 1253 an end entity, and one CertRep message send back from the server. 1255 PreCondition 1256 The queried certificate have been issued by the certificate authority 1257 and the issuer assigned serial number is known. 1259 PostContition 1260 Either the certificate is send back or the request is rejected. 1262 5.3.1 GetCert Message Format 1264 The queried certificate is identified by its issuer name and the issuer 1265 assigned serial number. If this is a query for an arbitrary end entity's 1266 certificate, the requesting end entity should includes its own CA issued 1267 certificate in the signed envelope. If this is a query for its own 1268 certificate (assume the end entity lost the issued certificate, or does 1269 not have enough non-volatile memory to save the certificate), then the 1270 self-signed certificate has to be included in the signed envelope. 1272 pkcsGetCert issuerAndSerialNumber ::= { 1273 issuer "the certificate issuer name" 1274 serialNumber "the certificate serial number" 1275 } 1276 pkcsGetCertEnvelope EnvelopedData ::= { 1277 version 0 1278 recipientInfo { 1279 version 0 1280 issuerAndSerialNumber { 1281 issuer "the CA [RA] issuer name" 1282 serialNumber "the CA [RA] certificate serial number" 1283 } 1284 keyEncryptionAlgorithm {pkcs-1 1} 1285 encryptedKey "content-encrypt key encrypted 1286 by CA [RA] public key" 1287 } 1288 encryptedContentInfo { 1289 contentType {pkcs-7 1} -- data content 1290 contentEncryptionAlgorithm "OID for DES encryption" 1291 encryptedContent "encrypted pkcsGetCert using the content 1292 encryption key" 1293 } 1294 } 1295 pkcsGetCertSigned SignedData ::= { 1296 version 1 1297 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1298 digestAlgorithm(2) 5} 1299 contentInfo { 1300 contentType {pkcs-7 1} 1301 content pkcsGetCertEnvelope 1302 } 1303 certificates { 1304 certificate "CA issued certificate" 1305 or "self-signed certificate" 1306 } 1307 signerInfo { 1308 version 1 1309 issuerAndSerialNumber { 1310 issuer "the end entity's subject name" 1311 serialNumber "end entity's certificate serial number" 1312 } 1313 digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) 1314 digestAlgorithm(2) 5} 1315 authenticateAttributes { 1316 contentType {{pkcs-9 3} {pkcs-7 1}} 1317 messageDigest {{pkcs-9 4} "an octet string"} 1318 -- digest of pkcsGetCertEnvelope 1319 messageType {{id-attribute messageType(2)} "GetCert"} 1320 transaction-id {{id-attributes transId(7)} "printable 1321 string"} 1322 senderNonce {{id-attribute senderNonce(3)} <16 bytes>} 1323 } 1324 digestEncryptionAlgorithm {pkcs-1 1} 1325 encryptedDigest "encrypted digest of authenticateAttributes" 1326 } 1327 } 1328 GetCert PKIMessage ::= { 1329 contentType {pkcs-7 2} 1330 content pkcsGetCertSigned 1331 } 1333 5.3.2 CertRep Message Format 1335 In this case, the CertRep from the server is same as the CertRep for the 1336 PKCSReq, except that the server will only either grant the request or 1337 reject the request. Also, the recipientInfo should use the CA issuer 1338 name and CA assigned serial number to identify the end entity's key pair 1339 since at this time, the end entity has received its own certificate. 1341 5.4 CRL Access 1343 The CRL query message defined in this section is an option when the LDAP 1344 server is not available to provide the CRL query. In the PKI protocol 1345 proposed here, only the end entity can initiate the transaction to 1346 download CRL. An end entity send GetCRL request to the server and the 1347 server send back CertRep whose information portion is a degenerated 1348 PKCS#7 which contains only the most recent CRL. The size of CRL included 1349 in the CertRep should be determined by the implementation. 1351 PreCondition 1352 The certificate authority certificate has been downloaded to the end 1353 entity. 1355 PostCondition 1356 CRL send back to the end entity. 1358 5.4.1 GetCRL Message format 1360 The CRL is identified by using both CA's issuer name and the CA 1361 certificate's serial number: 1363 pkcsGetCRL issuerAndSerialNumber { 1364 issuer "the certificate authority issuer name" 1365 serialNumber "certificate authority certificate's serial number" 1366 } 1368 When the CRLDistributionPoint is supported, the pkcsGetCRL is defined as 1369 the following: 1371 pkcsGetCRL SEQUENCE { 1372 crlIssuer issuerAndSerialNumber 1373 distributionPoint CE-CRLDistPoints 1374 } 1376 where CE-CRLDisPoints is defined in X.509, but must contain only one 1377 CRL distribution point. 1379 pkcsGetCRLEnvelope EnvelopedData ::= { 1380 version 0 1381 recipientInfo { 1382 version 0 1383 issuerAndSerialNumber { 1384 issuer "the certificate authority (or RA) issuer name" 1385 serialNumber "the CA (RA) certificate's serial number" 1386 } 1387 keyEncryptionAlgorithm {pkcs-1 1} 1388 encryptedKey "content-encrypt key encrypted by CA (RA) public key" 1389 } 1390 encryptedContentInfo { 1391 contentType {pkcs-7 1} -- data content 1392 contentEncryptionAlgorithm "OID for DES encryption" 1393 encryptedContent "encrypted pkcsGetCRL" 1394 } 1395 } 1396 pkcsGetCRLSigned SignedData ::= { 1397 version 1 1398 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1399 digestAlgorithm(2) 5} 1400 contentInfo { 1401 contentType {pkcs-7 1} 1402 content pkcsGetCRLEnvelope 1403 } 1404 certificates { 1405 certificate "CA-issued or self-signed end entity's certificate" 1406 } 1407 signerInfo { 1408 version 1 1409 issuerAndSerialNumber { 1410 issuer "the end entity's issuer name" 1411 serialNumber "the end entity's certificate serial number" 1412 } 1413 digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) 1414 digestAlgorithm(2) 5} 1415 authenticateAttributes { 1416 contentType {{pkcs-9 3} {pkcs-7 1}} 1417 messageDigest {{pkcs-9 4} 0x<16/20 bytes>} 1418 -- digest of pkcsGetCRLEnvelope 1419 messageType {{id-attribute messageType(2)} "CertCRL"} 1420 transaction-id {{id-attributes transId(7)} "printable 1421 string"} 1422 senderNonce {{id-attribute senderNonce(3)} <16 bytes>} 1423 } 1424 digestEncryptionAlgorithm {pkcs-1 1} 1425 encryptedDigest "encrypted digest of authenticateAttributes" 1426 } 1427 } 1428 GetCRL PKIMessage ::= { 1429 contentType {pkcs-7 2} 1430 content pkcsGetCRLSigned 1431 } 1433 5.4.2 CertRep Message Format 1435 The CRL is send back to the end entity through CertRep message. The 1436 information portion of this message is a degenerated PKCS#7 SignedData 1437 which contains only a CRL. 1439 pkcsCertRep SignedData ::= { 1440 version 1 1441 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1442 digestAlgorithm(2) 5} 1443 contentInfo { 1444 contentType {pkcs-7 1} 1445 } 1446 crl { 1447 signature {pkcs-1 4} 1448 issuer "the certificate authority issuer name" 1449 lastUpdate "UTC time" 1450 nextUpdate "UTC time" 1451 revokedCertificate { 1452 -- the first entry 1453 userCertificate "certificate serial number" 1454 revocationData "UTC time" 1455 .... 1456 -- last entry 1457 userCertificate "certificate serial number" 1458 revocationData "UTC time" 1459 } 1460 } 1461 pkcsCertRepEnvelope EnvelopedData ::= { 1462 version 0 1463 recipientInfo { 1464 version 0 1465 issuerAndSerialNumber { 1466 issuer "the end entity's issuer name" 1467 serialNumber "the end entity certificate serial number" 1468 } 1469 keyEncryptionAlgorithm {pkcs-1 1} 1470 encryptedKey "content-encrypt key encrypted by end entity's 1471 public key " 1472 } 1473 encryptedContentInfo { 1474 contentType {pkcs-7 1} -- data content 1475 contentEncryptionAlgorithm "OID for DES encryption" 1476 encryptedContent "encrypted pkcsCertRep using end entity's 1477 public key" 1478 } 1479 } 1480 pkcsCertRepSigned SignedData ::= { -- PKCS#7 1481 version 1 1482 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1483 digestAlgorithm(2) 5} 1484 contentInfo { 1485 contentType {pkcs-7 1} 1486 content pkcsCertRepEnvelope 1487 } 1488 signerInfo { 1489 version 1 1490 issuerAndSerialNumber { 1491 issuer "the certificate authority issuer name" 1492 serialNumber "the CA certificate's serial number" 1493 } 1494 digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) 1495 digestAlgorithm(2) 5} 1496 authenticateAttributes { 1497 contentType {{pkcs-9 3} {pkcs-7 1}} 1498 messageDigest {{pkcs-9 4} "an octet string"} 1499 -- digest of pkcsCertRepEnvelope 1500 messageType {{id-attribute messageType(2)} "CertRep"} 1501 transaction-id {{id-attributes transId(7)} "printable 1502 string"} 1503 -- same transaction id as given in PKCSReq 1504 pkiStatus {{id-attributes pkiStatus(3) "SUCCESS"} 1505 recipientNonce{{id-attribute recipientNonce(6)}<16 bytes>} 1506 senderNonce {{id-attribute senderNonce (5) 0x<16 bytes>} 1507 } 1508 digestEncryptionAlgorithm {pkcs-1 1} 1509 encryptedDigest "encrypted digest of authenticatedAttributes 1510 using CA private key" 1511 } 1512 } 1514 NOTE:The PKCS#7 EncryptedContent is specified as an octet string, but 1515 SCEP entities must also accept a sequence of octet strings as a valid 1516 alternate encoding. 1518 This alternate encoding must be accepted wherever PKCS #7 Enveloped 1519 Data is specified in this document. 1521 5.5 Get Certificate Authority Certificate 1523 Before any transaction begins, end entities have to get the CA (and 1524 possibly RA) certificate(s) first. Since no public keys have been 1525 exchanged, the message can not be encrypted and the response must be 1526 authenticated by out-of-band means. These certs are obtained by means 1527 of an HTTP GET message. To get the CA certificate, the end entity does a 1528 "HTTP GET" and receives a plain X.509 certificate in response. In the 1529 request, the URL identifies a CGI script on the server and passes the CA 1530 issuer identifier as the parameter to the CGI script. Once the CA 1531 certificate is received by the end entity, a fingerprint is generated 1532 using MD5 hash algorithm on the whole CA certificate. This fingerprint 1533 is verified by some positive out-of-band means, such as a phone call. 1535 5.5.1 GetCACert HTTP Message Format 1536 "GET" CGI-PATH CGI-PROG "?operation=GetCACert" "&message=" CA-IDENT 1537 where: 1538 CGI-PATH defines the actual CGI path to invoke the CGI program 1539 which parses the request. 1540 CGI-PROG is set to be the string "pkiclient.exe" and this is 1541 expected to be the program that the CA will use to handle the 1542 SCEP transactions. 1543 CA-IDENT is any string which is understood by the CA. 1544 For example, it could be a domain name like ietf.org. 1545 If a certificate authority has multiple root certificates 1546 this field can be used to distinguish which is required. 1547 Otherwise it may be ignored. 1549 5.5.2 Response 1551 The response for GetCACert is different between the case where the CA 1552 directly communicated with the end entity during the enrollment, and the 1553 case where a RA exists and the end entity communicates with the RA 1554 during the enrollment. 1556 5.5.2.1 CA Certificate Only Response 1558 A binary X.509 CA certificate is send back as a MIME object with a 1559 Content-Type of application/x-x509-ca-cert. 1561 5.5.2.2 CA and RA Certificates Response 1563 When an RA exists, both CA and RA certificates must be sent back in 1564 the response to the GetCACert request. The RA certificate(s) must be 1565 signed by the CA. A certificates-only PKCS#7 SignedData is used to 1566 carry the certificates to the end entity, with a Content-Type of 1567 application/x-x509-ca-ra-cert. 1569 |5.6 Get Certificate Authority Certificate Chain 1570 | 1571 |In order to support Certificate Authority hierarchies, it is necessary 1572 |to have a way to get the entire certificate chain. The following message 1573 |has been added to SCEP for this purpose. 1574 | 1575 |5.6.1 GetCACertChain HTTP Message Format 1576 | 1577 | "GET" CGI-SCRIPT "?" "operation=GetCACertChain" "&" "message" CA-IDENT 1578 | where CGI-SCRIPT and CA-IDENT are as described for GetCACert. 1579 | 1580 |5.6.2 Response 1581 | 1582 |The response for GetCACertChain is a certificates-only PKCS#7 SignedData 1583 |to carry the certificates to the end entity, with a Content-Type of 1584 |application/x-x509-ca-ra-cert-chain. 1585 | 1586 |5.6.3 Backwards Compatability 1587 | 1588 |Versions of SCEP prior to revision 3 do not support GetCACertChain. 1589 |Certificate Authorities written to these prior versions will not be 1590 |able to process the message and may return an HTML error. 1591 | 1592 |To avoid this, clients should send the GetCACert message first. If the 1593 |returned certificate is self-signed or is signed by a Certificate 1594 |Authority that is trusted by the client, then it is not necessary to 1595 |send the GetCACertChain message and it should not be sent. 1596 | 1597 |If a Certificate Authority is configured with a certificate that is 1598 |not either self-signed or has a self-signed issuer, then it should 1599 |support this message. In other words, it should be supported if the 1600 |CA hierarchy is more than two-deep. 1601 | 1602 |An old CA in a two-deep hierarchy might still get this message from 1603 |a client if the client did not trust either that CA or its issuer. 1604 |In that event, the certificate cannot be trusted anyway. In any case 1605 |the CA must not crash or hang upon the receipt of the message and the 1606 |client must be able to handle whatever error is returned by the CA, 1607 |including an HTML error or an ungraceful disconnect. 1609 The following is the ASN.1 definition of Cert-Only PKCS#7: 1611 certOnly SignedData ::= { 1612 version 1 1613 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1614 digestAlgorithm(2) 5} 1616 contentInfo { 1617 contentType {pkcs-7 1} -- data content identifier 1618 content -- NULL 1619 } 1620 certificates -- the RA and CA certificates. 1621 } 1623 CARACerts PKIMessage ::= { -- special pki message sent in the clear 1624 contentType {pkcs-7 2} 1625 content certOnly 1626 } 1628 6.0 Security Considerations 1630 This entire document is about security. Common security considerations 1631 such as keeping private keys truly private and using adequate lengths 1632 for symmetric and asymmetric keys must be followed in order to maintain 1633 the security of this protocol. 1635 7.0 Intellectual Property 1637 This protcol includes the optional use of Certificate Revocation List 1638 Distribution Point (CRLDP) technology, which is a patented technology 1639 of Entrust Technologies, Inc. (Method for Efficient Management of 1640 Certificate Revocation Lists and Update Information (U.S. Patent 1641 5,699,431)). Please contact Entrust Technologies, Inc. 1642 (www.entrust.com) for more information on licensing CRLDP technology. 1644 8.0 References 1646 [PKCS7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1647 1.5", RFC 2315, March 1998. 1649 [PKCS10] Kaliski, B., "PKCS #10: Certification Request Syntax Version 1650 1.5", RFC 2314, March 1998. 1652 [RFC2459] Housley, R., ec. al., "Internet X.509 Public Key 1653 Infrastructure Certificate and CRL Profile", RFC 2459, January 1999. 1655 Appendix A: Cisco End Entity Subject Name Definition 1657 The ip address and the FQDN of a SCEP client should be included in the 1658 V3 extension subjectAltName. When the subjectAltName extension attribute 1659 is present, both the subjectAltName fields and the subjectName field could 1660 have the IP address and the FQDN information. 1662 When the X.500 directory is used by the CA to define the name space, the 1663 subject name defined above become a RDN which is part of DN binded to 1664 the end entity's public key in the certificate. 1666 A sample of DN assigned by Entrust CA is given below (assume the same 1667 ciscoRouterAlice is used as the end entity defined subject name): 1669 OU = InteropTesting, O = Entrust Technologies, C = CA 1670 RDN = {"alice.cisco.com", "172.21.114.67", "22334455"} 1672 Appendix B: IPSEC Client Enrollment Certificate Request 1674 The following is the certificate enrollment request (PKCS#10) as created 1675 by Cisco VPN Client: 1677 -----END NEW CERTIFICATE REQUEST----- 1678 0 30 439: SEQUENCE { 1679 4 30 288: SEQUENCE { 1680 8 02 1: INTEGER 0 1681 11 30 57: SEQUENCE { 1682 13 31 55: SET { 1683 15 30 53: SEQUENCE { 1684 17 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 1685 22 13 46: PrintableString 1686 : 'For Xiaoyi, IPSEC attrs in alternate name 1687 extn' 1688 : } 1689 : } 1690 : } 1691 70 30 158: SEQUENCE { 1692 73 30 13: SEQUENCE { 1693 75 06 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1694 1 1) 1695 86 05 0: NULL 1696 : } 1697 88 03 140: BIT STRING 0 unused bits 1698 : 30 81 88 02 81 80 73 DB 1D D5 65 AA EF C7 D4 8E 1699 : AA 6E EB 46 AC 91 2A 0F 50 51 17 AD 50 A2 2A F2 1700 : CE BE F1 E4 22 8C D7 61 A1 6C 87 61 62 92 CB A6 1701 : 80 EA B4 0F 09 9D 18 5F 39 A3 02 0E DB 38 4C E4 1702 : 8A 63 2E 72 8B DC BE 9E ED 6C 1A 47 DE 13 1B 0F 1703 : 83 29 4D 3E 08 86 FF 08 2B 43 09 EF 67 A7 6B EA 1704 : 77 62 30 35 4D A9 0F 0F DF CC 44 F5 4D 2C 2E 19 1705 : E8 63 94 AC 84 A4 D0 01 E1 E3 97 16 CD 86 64 18 1706 : [ Another 11 bytes skipped ] 1707 : } 1708 231 A0 63: [0] { 1709 233 30 61: SEQUENCE { 1710 235 06 9: OBJECT IDENTIFIER extensionReq (1 2 840 113549 1 9 1711 14) 1712 246 31 48: SET { 1713 248 30 46: SEQUENCE { 1714 250 30 44: SEQUENCE { 1715 252 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 1716 257 04 37: OCTET STRING 1717 30 23 87 04 01 02 03 04 81 0D 65 6D 61 69 1718 6C 40 69 72 65 2E 63 6F 6D 82 0C 66 71 64 1719 6E 2E 69 72 65 2E 63 6F 6D 1720 : } 1721 : } 1722 : } 1723 : } 1724 : } 1725 : } 1727 296 30 13: SEQUENCE { 1728 298 06 9: OBJECT IDENTIFIER md5withRSAEncryption (1 2 840 113549 1729 1 1 4) 1730 309 05 0: NULL 1731 : } 1732 311 03 129: BIT STRING 0 unused bits 1733 : 19 60 55 45 7F 72 FD 4E E5 3F D2 66 B0 77 13 9A 1734 : 87 86 75 6A E1 36 C6 B6 21 71 68 BD 96 F0 B4 60 1735 : 95 8F 12 F1 65 33 16 FD 46 8A 63 19 90 40 B4 B7 1736 : 2C B5 AC 63 17 50 28 F0 CD A4 F0 00 4E D2 DE 6D 1737 : C3 4F F5 CB 03 4D C8 D8 31 5A 7C 01 47 D2 2B 91 1738 : B5 48 55 C8 A7 0B DD 45 D3 4A 8D 94 04 3A 6C B0 1739 : A7 1D 64 74 AB 8A F7 FF 82 C7 22 0A 2A 95 FB 24 1740 : 88 AA B6 27 83 C1 EC 5E A0 BA 0C BA 2E 6D 50 C7 1741 : } 1743 Appendix C: Private OID Definitions 1745 The OIDs used in defining pkiStatus are VeriSign self-maintained 1746 OIDs. Please note, work is in progress to replace the VeriSign owned 1747 object identifiers with the standard object identifiers. Once the 1748 standarlization is completed, this documentation will be updated. 1750 id-VeriSign OBJECT_IDENTIFIER ::= {2 16 US(840) 1 VeriSign(113733)} 1751 id-pki OBJECT_IDENTIFIER ::= {id-VeriSign pki(1)} 1752 id-attributes OBJECT_IDENTIFIER ::= {id-pki attributes(9)} 1753 id-messageType OBJECT_IDENTIFIER ::= {id-attributes messageType(2)} 1754 id-pkiStatus OBJECT_IDENTIFIER ::= {id-attributes pkiStatus(3)} 1755 id-failInfo OBJECT_IDENTIFIER ::= {id-attributes failInfo(4)} 1756 id-senderNonce OBJECT_IDENTIFIER ::= {id-attributes senderNonce(5)} 1757 id-recipientNonce OBJECT_IDENTIFIER ::= {id-attributes recipientNonce(6)} 1758 id-transId OBJECT_IDENTIFIER ::= {id-attributes transId(7)} 1759 id-extensionReq OBJECT_IDENTIFIER ::= {id-attributes extensionReq(8)} 1760 Appendix D: CRL Query by means of LDAP 1762 In order to retrieve the CRL by means of LDAP, the client needs to know 1763 where in the directory it is stored. The certificate must contain a 1764 CRL Distribution Point extension encoded as a DN or as an LDAP URI. 1766 For example, the certificate issued by Entrust VPN contains 1767 the following DN as the CRL distribution point: 1769 CN = CRL1, O = cisco, C = US. 1771 The asn.1 encoding of this distribution point is: 1773 30 2C 31 0B 30 09 06 03 55 04 06 13 02 55 53 31 0E 30 0C 06 1774 03 55 04 0A 13 05 63 69 73 63 6F 31 0D 30 0B 06 03 55 04 03 1775 13 04 43 52 4C 31 1777 The ldap form would be: 1779 ldap://servername/CN=CRL1,O=cisco,C=US 1781 Appendix E: SCEP State Transitions 1783 SCEP state transitions are based on transaction identifier. The design 1784 goal is to ensure the synchronization between the CA and the end entity 1785 under various error situations. 1787 An identity is defined by the combination of FQDN, the IP address and 1788 the client serial number. FQDN is the required name attribute. It is 1789 important to notice that, a client named as Alice.cisco.com is different 1790 from the client named as Alice.cisco.com plus IPAddress 117.96.1.219. 1792 Each enrollment transaction is uniquely associated with a transaction 1793 identifier. Because the enrollment transaction could be interrupted by 1794 various errors, including network connection errors or client reboot, 1795 the SCEP client generates a transaction identifier by calculating MD5 1796 hash on the public key value for which the enrollment is requested. This 1797 retains the same transaction identifier throughout the enrollment 1798 transaction, even if the client has rebooted or timed out, and issues a 1799 new enrollment request for the same key pair. It also provides the way 1800 for the CA to uniquely identify a transaction in its database. At the 1801 end entity side, it generates a transaction identifier which is included 1802 in PKCSReq. If the CA returns a response of PENDING, the end entity 1803 will poll by periodically sending out GetCertInitial with the same 1804 transaction identifier until either a response other than PENDING is 1805 obtained, or the configured maximum time has elapsed. 1807 If the client times out or the client reboots, the client administrator 1808 will start another enrollment transaction with the same key pair. The 1809 second enrollment will have the transaction idenifier. At the server 1810 side, instead of accepting the PKCSReq as a new enrollment request, it 1811 should respond as if another GetCertInitial message had been sent with 1812 that transaction ID. In another word, the second PKCSReq should be 1813 taken as a resynchronization message to allow the enrollment resume as 1814 the same transaction. 1816 It is important to keep the transaction id unique since CEP requires the 1817 same policy and same identity be applied to the same subject name and 1818 key pair binding. In the current implementation, an SCEP client can 1819 only assume one identity. At any time, only one key pair, with a given 1820 key usage, can be associated with the same identity. 1822 The following gives several example of client to CA transactions. 1824 Client actions are indicated in the left column, CA actions are 1825 indicated in the right column. A blank action signifies that no message 1826 was received. Note that these examples assume that the CA enforces the 1827 certificate-name uniqueness property defined in Section 2.1.1.1. 1829 The first transaction, for example, would read like this: 1830 "Client Sends PKCSReq message with transaction ID 1 to the 1831 CA. The CA signs the certificate and constructs a CertRep Message 1832 containing the signed certificate with a transaction ID 1. The client 1833 receives the message and installs the cert locally." 1835 Successful Enrollment Case: no manual authentication 1836 PKCSReq (1) ----------> CA Signs Cert 1837 Client Installs Cert <---------- CertRep (1) SIGNED CERT 1839 Successful Enrollment Case: manual authentication required 1840 PKCSReq (10) ----------> Cert Request goes into Queue 1841 Client Polls <---------- CertRep (10) PENDING 1842 GetCertInitial (10) ----------> Still pending 1843 Client Polls <---------- CertRep (10) PENDING 1844 GetCertInitial (10) ----------> Still pending 1845 Client Polls <---------- CertRep (10) PENDING 1846 GetCertInitial (10) ----------> Still pending 1847 Client Polls <---------- CertRep (10) PENDING 1848 GetCertInitial (10) ----------> Cert has been signed 1849 Client Installs Cert <---------- CertRep (10) SIGNED CERT 1851 Resync Case - CA Receive and Signs PKCSReq, Client Did not receive 1852 CertRep: 1854 PKCSReq (3) ----------> Cert Request goes into queue 1855 <---------- CertRep (3) PENDING 1856 GetCertInitial (3) ----------> 1857 <---------- CertRep (3) PENDING 1858 GetCertInitial (3) -----------> 1859 <----------- CA signed Cert and send back 1860 CertRep(3) 1861 (Time Out) 1862 PKCSReq (3) ----------> Cert already signed, send back to 1863 client 1864 Client Installs Cert <---------- CertRep (3) SIGNED CERT 1865 Case when NVRAM is lost and client has to generate a new key pair, there 1866 is no change of name information: 1868 PKCSReq (4) ----------> CA Signs Cert 1869 Client Installs Cert <---------- CertRep (4) SIGNED CERT 1870 (Client looses Cert) 1871 PKCSReq (5) ----------> There is already a valid cert with 1872 this DN. 1873 Client Admin Revokes <---------- CertRep (5) OVERLAPPING CERT ERROR 1874 PKCSReq (5) ----------> CA Signs Cert 1875 Client Installs Cert <---------- CertRep (5) SIGNED CERT 1877 Case when client admin resync the enrollment using a different PKCS#10: 1878 PKCSReq (6) ----------> CA Signs Cert 1879 <---------- CertRep (6) SIGNED CERT 1880 (Client timeout and admin starts another enrollment with a different 1881 PKCS#10, but the same transaction id) 1882 PKCSReq (6) with different PKCS#10 1883 ----------> There is already a valid cert with 1884 this entity (by checking FQDN). 1885 <---------- CertRep (6) INVALID PKCS#10 CERT 1886 ERROR 1887 Client admin either revokes the existing cert 1888 or corrects the error by enrolling with 1889 the same PKCS#10 as the first PKCSReq(6) 1890 PKCSReq (6) ----------> CA find the existing Cert 1891 Client Installs Cert <---------- CertRep (6) SIGNED CERT 1893 Resync case when server is slow in response: 1894 PKCSReq (13) ----------> Cert Request goes into Queue 1895 <---------- CertRep (13) PENDING 1896 GetCertInitial ----------> Still pending 1897 <---------- CertRep (13) PENDING 1898 GetCertInitial ----------> Still pending 1899 <---------- CertRep (13) PENDING 1900 GetCertInitial ----------> Still pending 1901 <---------- CertRep (13) PENDING 1902 GetCertInitial ----------> Still pending 1903 (TimeOut) <---------- CertRep (13) PENDING 1904 * Case 1 1905 PKCSReq (13) ----------> Still pending 1906 Client polls <---------- CertRep (13) PENDING 1907 CertCertInitial ----------> Cert has been signed 1908 Client Installs Cert <---------- CertRep (13) SIGNED CERT 1909 * Case 2 1910 PKCSReq (13) ----------> Cert has been signed 1911 Client Installs Cert <---------- CertRep (13) SIGNED CERT 1912 Appendix F. Author Contact Information 1914 Xiaoyi Liu Cheryl Madson 1915 Cisco Cisco 1916 510 McCarthy Drive 510 McCarthy Drive 1917 Milpitas, CA Milpitas, CA. 1918 xliu@cisco.com cmadson@cisco.com 1920 David McGrew Andrew Nourse 1921 Cisco Cisco 1922 170 West Tasman Drive 510 McCarthy Drive 1923 San Jose, CA 94134 Milpitas, CA. 1924 mcgrew@cisco.com nourse@cisco.com 1926 Appendix G. Copyright Section 1928 Copyright (C) The Internet Society (2000). All Rights Reserved. 1930 This document and translations of it may be copied and furnished 1931 to others, and derivative works that comment on or otherwise 1932 explain it or assist in its implmentation may be prepared, copied, 1933 published and distributed, in whole or in part, without 1934 restriction of any kind, provided that the above copyright notice 1935 and this paragraph are included on all such copies and derivative 1936 works. However, this document itself may not be modified in any 1937 way, such as by removing the copyright notice or references to the 1938 Internet Society or other Internet organizations, except as needed 1939 for the purpose of developing Internet standards in which case the 1940 procedures for copyrights defined in the Internet Standards 1941 process must be followed, or as required to translate it into 1942 languages other than English. 1944 The limited permissions granted above are perpetual and will not 1945 be revoked by the Internet Society or its successors or assigns. 1947 This document and the information contained herein is provided on 1948 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1949 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1950 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1951 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1952 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1954 This draft expires 26-Mar-2004 1956 [End of draft-nourse-scep-08.txt]