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