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