idnits 2.17.1 draft-nourse-scep-10.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 24 longer pages, the longest (page 38) being 71 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 32 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** There are 59 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 415: '...tificate. A CA MAY run in automatic ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 900 has weird spacing: '... as the signe...' == Line 964 has weird spacing: '...content pkcsC...' == Line 1427 has weird spacing: '...lIssuer issue...' == Line 1656 has weird spacing: '...rovides a way...' -- 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 (29 June 2004) is 7240 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CERT-NONEXISTANT' is mentioned on line 561, but not defined == Missing Reference: 'CERT-REQ-PENDING' is mentioned on line 561, but not defined == Missing Reference: 'CERT-ISSUED' is mentioned on line 561, but not defined == Missing Reference: 'RA' is mentioned on line 1338, but not defined -- Looks like a reference, but probably isn't: '0' on line 1796 == Unused Reference: 'PKCS7' is defined on line 1731, but no explicit reference was found in the text == Unused Reference: 'PKCS10' is defined on line 1734, but no explicit reference was found in the text == Unused Reference: 'RFC2459' is defined on line 1737, 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: 10 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-10.txt Cheryl Madson 3 expires 29 Dec 2004 David McGrew 4 (revised 29 June 2004) Andrew Nourse 5 Cisco Systems 7 Category: Informational 29 June 2004 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 Simple Certificate Enrollment Protocol, 42 a PKI communication protocol which leverages existing technology by 43 using PKCS#7 and PKCS#10. SCEP is the evolution of the enrollment 44 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 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 55 2.3 PKI Operation Transactional Behavior . . . . . . . . . . . 10 56 2.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . 12 57 3. Transport Protocol . . . . . . . . . . . . . . . . . . . . 13 58 4. Secure Transportation: PKCS #7 . . . . . . . . . . . . . . 14 59 4.1 SCEP Message Format . . . . . . . . . . . . . . . . . . . 14 60 4.2 Signed Transaction Attributes . . . . . . . . . . . . . . 15 61 5. SCEP Transaction Specification . . . . . . . . . . . . . . 16 62 6. Security Considerations . . . . . . . . . . . . . . . . . 33 63 7. Intellectual Propoerty . . . . . . . . . . . . . . . . . . 33 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . 33 65 Appendix A. Cisco Requester Subject Name Definition . . . . . . 34 66 Appendix B. IPSEC Client Enrollment Certificate Request . . . . 35 67 Appendix C. Private OID Definitions . . . . . . . . . . . . . 36 68 Appendix D. Obtaining CRL by LDAP Query . . . . . . . . . . . . 36 69 Appendix E. SCEP State Transitions . . . . . . . . . . . . . . 37 70 Appendix F. CA Capabilities . . . . . . . . . . . . . . . . . . 40 71 Appendix G. Certificate Renewal and CA Key Rollover . . . . . . 41 72 Appendix H. PKIOperation via HTTP POST Message. . . . . . . . . 42 73 Appendix Y. Author Contact Information. . . . . . . . . . . . . 43 74 Appendix Z. Copyright Section . . . . . . . . . . . . . . . . . 43 76 Section 1. Introduction 78 Public key technology is becoming more widely deployed and is becoming 79 the basis for standards based security, such as the Internet Engineering 80 Task Force's IPSEC and IKE protocols. With the use of public key 81 certificates in network security protocols comes the need for a 82 certificate management protocol that Public Key Infrastructure (PKI) 83 clients and Certificate Authority servers can use to support certificate 84 life cycle operations such as certificate enrollment and revocation, and 85 certificate and CRL access. 87 In the following, Section 2 gives an overview of the PKI operations, and 88 Section 2.4 describes the security goals of the protocol and the 89 mechanisms used to achieve them. The transport protocol and the 90 security protocol PKCS#7 are described at Section 3 and Section 4, 91 respectively. The last section, Section 5, specifies each PKI operation 92 in terms of the message formats and the data structures of each 93 operation. 95 The appendices provide detailed specifications and examples. Requester 96 subject names are specified in Appendix A, attribute OIDs are specified 97 in Appendix C , and the SCEP state transitions are described in Appendix 98 E. An example of a certificate enrollment request is provided in 99 Appendix B, and an example LDAP query URL encoding is provided in 100 Appendix D. 102 The authors would like to thank Peter William of ValiCert, Inc. 103 (formerly of Verisign, Inc) and Alex Deacon of Verisign, Inc. and 104 Christopher Welles of IRE, Inc. for their contributions to this protocol 105 and to this document. 107 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 109 2.0 The Goal of SCEP 110 The goal of SCEP is to support the secure issuance of certificates to 111 network devices in a scalable manner, using existing technology whenever 112 possible. The protocol supports the following operations: 114 CA and RA public key distribution 115 Certificate enrollment 116 Certificate revocation 117 Certificate query 118 CRL query 120 Certificate and CRL access can be achieved by using the LDAP protocol 121 (as specified in Appendix D), or by using the query messages defined in 122 SCEP. The use of HTTP certificate and CRL access, and the support of 123 CDP as specified in RFC2459, will be specified in a future version of 124 this document. In Section 2.1, we first define PKI entity types as well 125 as the properties of each entity type. In Section 2.2, the PKI 126 operations are described at functional level. Section 2.3 describes the 127 transaction behavior of each PKI operations. The complete PKI messages 128 are covered in Section 5. 130 2.1 SCEP Entity types 132 The entity types defined in SCEP are the "requester" type (i.e., IPSEC 133 clients), the Certificate Authority (CA) entity type, and the 134 Registration Authority entity type (RA). A requester is sometimes 135 called a "SCEP client" in the following. 137 2.1.1 Requesters 139 A requester is an entity whose name is defined in a certificate 140 subject name field and optionally, in SubjectAltName, a X.509 141 certificate V3 extension. As a requester, a SCEP client is identified 142 by a subject name consisting of the following naming attributes: 144 Fully qualified domain name, for example, router.cisco.com 145 IP address, Serial number, and/or x.500 distinguished name 147 The fully qualified domain name is required for a requester that intends 148 to use the certificate for ISAKMP. The IP address, serial number, and 149 x.500 distinguished name are optional name attributes. In the 150 certificate enrollment request, the PKCS#10 subject field contains the 151 required and optional name attributes. The distinguished name, if any, 152 should be the subject name field, while any domain name, serial number, 153 or IP address supplied should be in the subjectAltName field. The 154 subject name field may be empty (if there is no distinguished name) 155 or the subjectAltName may be omitted, but not both. 157 It is important to note that a client named as Alice.cisco.com is 158 different than a client named as Alice.cisco.com plus the IP address 159 name attribute 117.96.1.219. From CA point of view, the Distinguished 160 names assigned in these two cases are distinct names. 162 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 164 Entity names which are specified as in the IPSEC profile (i.e., FQDN, IP 165 address and User FQDN) must be presented in certificate's SubjectAltName 166 extension. Multiple IPSEC entity names, (if any) are encoded as multiple 167 values of a single SubjectAltName extension. The CA has the authority 168 to assign a distinguished name to a requester, whether or not one was 169 included in the request. The assigned DN should contain the SCEP client 170 names as the relative DN. 172 The attribute identifiers and an example of SCEP client subject name are 173 specified in Appendix A. Appendix B has an example from Cisco VPN Client 174 enrollment request. 176 2.1.1.1 Local Key/Certificate/CRL Storage and Certificate-name uniqueness 178 A requester is required to generate asymmetric key pairs and to provide 179 storage to store its private keys. If the requester does not have enough 180 permanent memory to save its certificate, then it should be able to query 181 its own certificate from the CA or an LDAP server, once the certificate 182 has been issued. The public key pairs can be generated with a specific 183 key usage. The key usage is conveyed to the CA through the certificate 184 enrollment request. All current SCEP client implementations expect that 185 there will be only one pair of keys for a given subject name 186 and key usage combination and CA, at any time. This property is called 187 the certificate-name uniqueness property, and it implies that a CA that 188 implements SCEP will enforce the unique mapping between a SCEP client 189 subject name and its key pairs with a given key usage. At any time, if 190 the subject name is changed, or if the key is updated, the existing 191 certificate would have to be revoked before a new one could be issued. 193 It is desirable that the CA enforce certificate-name uniqueness, but 194 it is not mandatory. However a CA that does not enforce uniqueness 195 must provide some other mechanism to prevent the re-transmission of an 196 enrollment request by a SCEP client from creating a second certificate 197 or certificate request, nor can the second request merely be rejected. 198 If a client times out from polling for a pending request it can 199 resynchronize by reissuing the original request with the original 200 subject name and transaction ID. This must return the status of the 201 original transaction, including the certificate if it was granted. 202 It must not create a new transaction unless the original cert has been 203 revoked, or the transaction arrives more than halfway through the 204 validity time of the original certificate. 206 An enrollment request that occurs more than halfway through the validity 207 time of an existing certificate for the same subject name and key usage 208 MAY be interpreted as a renewal request and accepted regardless of the 209 duplication of subject name. Certificate renewal can be done this way. 211 2.1.1.2 Requester authentication 213 As with every protocol that uses public-key cryptography, the 214 association between the public keys used in the protocol and the 215 identities with which they are associated must be authenticated in a 216 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 218 cryptographically secure manner. This requirement is needed to 219 prevent a "man in the middle" attack, in which an adversary that can 220 manipulate the data as it travels between the protocol participants 221 can subvert the security of the protocol. To satisfy this 222 requirement, SCEP provides two authentication methods: manual 223 authentication, and authentication based on pre-shared secret. In 224 the manual mode, the requester is required to wait until its identity 225 can be verified by the CA operator using any reliable out-of-band 226 method. To prevent a "man-in-the-middle" attack, an MD5 `fingerprint' 227 generated on the PKCS#10 (before PKCS #7 enveloping and signing) must 228 be compared out-of-band between the server and the requester. SCEP 229 clients and CAs (or RAs, if appropriate) must display this fingerprint 230 to the operator to enable this verification if manual mode is used. 231 Failing to provide this information leaves the protocol vulnerable to 232 attack by sophisticated adversaries. When utilizing a pre-shared secret 233 scheme, the server should distribute a shared secret to the requester 234 which can uniquely associate the enrollment request with the given end 235 entity. The distribution of the secret must be private: only the end 236 entity should know this secret. The actual binding mechanism between 237 the requester and the secret is subject to the server policy and 238 implementation. When creating the enrollment request, the requester 239 is asked to provide a challenge password. When using the pre-shared 240 secret scheme, the requester must enter the re-distributed secret 241 as the password. In the manual authentication case, the challenge 242 password only used to authenticate a request for the certificate's 243 revokation. This challenge password is included as a PKCS#10 244 attribute, and is sent to the server as encrypted data. The PKCS#7 245 envelope protects the privacy of the challenge password with DES 246 encryption. 248 2.1.1.3 Requester Uses Existing CA-Issued or Self-Signed Certificates 250 In this protocol, the communication between the requester and the 251 certificate authority is secured by using PKCS#7 as the messaging 252 protocol. PKCS#7, however, is a protocol which assumes the communicating 253 entities already possess the peer's certificates and requires both 254 parties use the issuer names and issuer assigned certificate serial 255 numbers to identify the certificate in order to verify the signature and 256 decrypt the message. If the requesting system already has a 257 certificate issued by the CA, that certificate may be presented 258 as credentials for the renewal of that certificate if the policy 259 of the CA permits this. If the requester has no certificate issued by 260 the CA, it must generate a self-signed certificate for its public key. 261 In this self-signed certificate, the issuer name is the requester 262 subject name (the same name later used in the PKCS#10). During the 263 certificate enrollment, the requester will first post itself as the 264 signing authority by attaching the self-signed certificate to the signed 265 certificate request. When the Certificate Authority makes the envelope 266 on the issued certificate using the public key included in the 267 self-signed certificate, it should use the same issuer name and serial 268 number as conveyed in the self-signed certificate to inform the end 269 entity on which private key should be used to open the envelope. 271 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 273 Note that when a client enrolls for separate encryption and signature 274 certificates, it may use the signature certificate to sign both 275 requests, and then expect its signature key to be used to encrypt 276 both responses. In any case, the recipientinfo on the envelope should 277 reflect the key used to encrypt the request. 279 2.1.1.4 Trusted CA Store 281 To support interoperability between IPSEC peers whose certificates are 282 issued by different CA, SCEP allows the users to configure multiple 283 trusted certificates. Trusted certificates are have been configured as 284 such in the client, based on some out-of-band means such as a "fingerprint". 285 These trusted certificates are used to verify certificate chains that end 286 in those certificates. 288 2.1.2 Certificate Authority 290 A Certificate Authority(CA) is an entity whose name is defined in the 291 certificate issuer name field. Before any PKI operations can begin, 292 the CA generates its own public key pair and creates a self-signed CA 293 certificate, or causes another CA to issue a certificate to it. 294 Associated with the CA certificate is a fingerprint which will be used 295 by the requester to authenticate the received CA certificate if it 296 is self-signed. The fingerprint is created by calculating a MD5 hash 297 on the whole CA certificate. Before any requester can start its 298 enrollment, this CA certificate has to be configured at the entity 299 side securely. For IPSEC clients, the client certificates must have 300 SubjectAltName extension. To utilize LDAP as a CRL query protocol, 301 the certificates must have a CRL Distribution Point. Key usage is 302 optional. Without key usage, the public key is assumed as a general 303 purpose public key and it can be used for all the purposes. 305 A Certificate Authority may enforce certain name policy. When using 306 X.500 directory name as the subject name, all the name attributes 307 specified in the PKCS#10 request should be included as Relative DN. All 308 the name attributes as defined in RFC2459 should be specified in the 309 SubjectAltName. An example is provided in Appendix A. 311 If there is no LDAP query protocol support, the Certificate Authority 312 should answer certificate and CRL queries, and to this end it should be 313 online all the time. 315 The updating of the CA's public key is addressed in Appendix G. 317 2.1.3 Registration Authorities 319 In an environment where an RA is present, a requester performs 320 enrollment through the RA. In order to setup a secure channel with an RA 321 using PKCS#7, the RA certificate(s) have to be obtained by the client 322 in addition to the CA certificate(s). 324 In the following, the CA and RA are specified as one entity in the 325 context of PKI operation definitions. 327 2.2 SCEP Operations Overview 329 In this section, we give a high level overview of the PKI operations as 330 defined in SCEP. 332 2.2.1 Requester Initialization 334 The requester initialization includes the key pair generation and the 335 configuring of the required information to communicate with the 336 certificate authority. 338 2.2.1.1 Key Pairs 340 Before a requester can start PKI transaction, it must have at least one 341 asymmetric key pair, using the selected algorithm (the RSA algorithm is 342 required in SCEP, and is the only algorithm in current implementations). 344 Key pairs may be intended for particular purposes, such as encryption only, 345 or signing only. The usage of any associated certificate can be restricted 346 by adding key usage and extended key usage attributes to the PKCS#10. 348 2.2.1.2 Required Information 350 A requester is required to have the following information configured 351 before starting any PKI operations: 353 1. the certificate authority IP address or fully-qualified domain name, 354 2. the certificate authority HTTP CGI script path, and 355 the HTTP proxy information in case there is no direct Internet 356 connection to the server, 357 3. If CRLs are being published by the CA to an LDAP directory server, 358 and there is a CRL Distribution Point containing only an X.500 directory 359 name, then the client will need to know the LDAP server fully-qualified 360 domain name or IP address. CRL Distribution Points are discussed in 361 more detail in RFC 2459. 363 2.2.2 CA/RA Certificate Distribution 365 Before any PKI operation can be started, the requester needs to get 366 the CA/RA certificates. At this time, since no public key has been 367 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 369 exchanged between the requester and the CA/RA, the message to get the 370 CA/RA certificate can not be secured using PKCS#7 protocol. Instead, the 371 CA/RA certificate distribution is implemented as a clear HTTP Get 372 operation. After the requester gets the CA certificate, it has to 373 authenticate the CA certificate by comparing the finger print with the 374 CA/RA operator. Since the RA certificates are signed by the CA, there is 375 no need to authenticate the RA certificates. 377 This operation is defined as a transaction consisting of one HTTP Get 378 message and one HTTP Response message: 380 REQUESTER CA SERVER 381 Get CA/RA Cert: HTTP Get message 382 -----------------------------> 383 CA/RA Cert download: HTTP Response message 384 <--------------------------------------- 385 Compute finger print and 386 call CA operator. 387 Receive call and check finger print 389 If an RA is in use, a degenerated PKCS#7 with a certificate chain 390 consisting of both RA and CA certificates is sent back to the end 391 entity. Otherwise the CA certificate is directly sent back as the 392 HTTP response payload. 394 2.2.3 Certificate Enrollment 396 A requester starts an enrollment transaction by creating a certificate 397 request using PKCS#10 and sends it to the CA/RA enveloped using the 398 PKCS#7. After the CA/RA receives the request, it will either 399 automatically approve the request and send the certificate back, or it 400 will require the requester to wait until the operator can manually 401 authenticate the identity of the requester. Two attributes are 402 included in the PKCS#10 certificate request - a Challenge Password 403 attribute and an optional ExtensionReq attribute which will be a 404 sequence of extensions the requester would like to be included in its 405 V3 certificate extensions. The Challenge Password may be used to 406 authenticate either the enrollment request itself, or a verbal 407 revocation request for the issued certificate in the event of key 408 compromise or other reason. 410 In the automatic mode, the transaction consists of one PKCSReq PKI 411 Message, and one CertRep PKI message. In the manual mode, the requester 412 enters into polling mode by periodically sending a GetCertInitial PKI 413 message to the server, until the server operator completes the manual 414 authentication, after which the CA will respond to GetCertInitial by 415 returning the issued certificate. A CA MAY run in automatic mode for 416 preapproved requests, and manual mode for the rest. A request with a 417 non-null password is not necessarily a pre-approved request. It is up 418 to the CA server to decide. Polling mode is entered whenever the 419 server returns a PENDING response. 421 The transaction in automatic mode: 423 REQUESTER CA SERVER 425 PKCSReq: PKI cert. enrollment msg 426 --------------------------------> CertRep: pkiStatus = SUCCESS 427 certificate attached 428 <------------------------------ 429 Receive issued certificate. 431 The transaction in manual mode: 433 REQUESTER CA SERVER 434 PKCSReq: PKI cert. enrollment msg 435 --------------------------------> CertRep: pkiStatus = PENDING 436 <------------------------------ 437 GetCertInitial: polling msg 438 --------------------------------> CertRep: pkiStatus = PENDING 439 <------------------------------ 440 ................. CertRep: pkiStatus = SUCCESS 444 certificate attached 445 <------------------------------ 446 Receive issued certificate. 448 2.2.4 Requester Certificate Revocation 450 A requester should be able to revoke its own certificate. Currently 451 the revocation is implemented as a manual process. In order to revoke a 452 certificate, the requester makes a phone call to the CA server 453 operator. The operator will come back asking the ChallengePassword 454 (which has been sent to the server as an attribute of the PKCS#10 455 certificate request). If the ChallengePassword matches, the certificate 456 is revoked. The reason of the revocation is documented by CA/RA. 458 2.2.5 Certificate Access 460 There are two methods to query certificates. The first method is to use 461 LDAP as a query protocol. Using LDAP to query assumes the client 462 understand the LDAP scheme supported by the CA. The SCEP client assumes 463 that the subject DN name in the certificate is used as the URL to query the 464 certificate. The standard attributes (userCertificate and caCertificate) 465 are used as filter. 467 For the environment where LDAP is not available, a certificate query 468 message is defined to retrieve the certificates from the CA. 470 To query a certificate from the certificate authority, a requester 471 sends a request consisting of the certificate's issuer name and the 472 serial number. This assumes that the requester has saved the issuer 473 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 475 name and the serial number of the issued certificate from the previous 476 enrollment transaction. The transaction to query a certificate consists 477 of one GetCert PKI message and one CertRep PKI message: 479 REQUESTER CA SERVER 480 GetCert: PKI cert query msg 481 -------------------------------> CertRep: pkiStatus = SUCCESS 482 certificate 483 attached 484 <----------------------------- 485 Receive the certificate. 487 2.2.6 CRL Distribution 489 The CA/RA will not "push" the CRL to the end entities. The query of the 490 CRL can only be initialized by the requester. 492 There are three methods to query CRL. 494 The CRL may be retrieved by a simple HTTP GET. If the CA supports this 495 method, it should encode the URL into a CRL Distribution Point extension 496 in the certificates it issues. Support for this method should be 497 incorporated in new and updated clients, but may not be in older 498 versions. 500 The second method is to query CRL using LDAP. This assumes the CA server 501 supports CRL LDAP publishing and issues the CRL Distribution Point in 502 the certificate. The CRL Distribution Point is encoded as a DN. Please 503 refer to Appendix D for the examples of CRL Distribution Point. 505 The third method is implemented for the CA which does not support LDAP 506 CRL publishing or does not implement the CRL Distribution Point. In this 507 case, a CRL query is composed by creating a message consists of the CA 508 issuer name and the CA's certificate serial number. This method is 509 deprecated because it does not scale well and requires the CA to be a 510 high-availability service. 512 The message is sent to the CA in the same way as the other SCEP 513 requests: The transaction to query CRL consists of one GetCRL PKI 514 message and one CertRep PKI message which have no certificates but CRL. 516 REQUESTER CA SERVER 517 GetCRL: PKI CRL query msg 518 ----------------------------------> CertRep: CRL attached 519 <-------------------------------- 521 2.3 PKI Operation Transactional Behavior 523 As described before, a PKI operation is a transaction consisting of the 524 messages exchanged between a requester and the CA/RA. This section 525 will specify the transaction behavior on both the requester and the 526 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 528 certificate authority server. Because the protocol is basically a two 529 way communication protocol without a confirmation message from the 530 initiating side, state and state resynchronization rules have to be 531 defined, in case any error happens at either side. Before the state 532 transition can be defined, the notion of transaction identifier has to 533 be defined first. 535 2.3.1 Transaction Identifier 537 A transaction identifier is a string generated by the entity when 538 starting a transaction. Since all the PKI operations defined in this 539 protocol are initiated by the requester, it is the responsibility of 540 the requester to generate a unique string as the transaction 541 identifier. All the PKI messages exchanged for a given PKI transaction 542 must carry the same transaction identifier. The transaction identifier 543 is generated as a MD5 hash on the public key value for which the 544 enrollment request is made. This allows the SCEP client to reuse the 545 same transaction identifier if it is reissuing a request for the same 546 certificate (i.e. a certificate with the same subject, issuer, and key). 547 The SCEP protocol requires that transaction identifiers be unique, so 548 that queries can be matched up with transactions. For this reason, in 549 those cases in which separate signing and encryption certificates are 550 issued to the same requester, the keys must be different. 552 2.3.2 State Transitions in Certificate Enrollment 554 The requester state transitions during enrollment operation are 555 indicated in the diagram below: 556 +-<------+ 557 | | 558 GetCertInitial triggered by timeout or 559 | | manual authentication 560 | | 561 [CERT-NONEXISTANT] ------> [CERT-REQ-PENDING] ---> [CERT-ISSUED] 562 | PKCSReq | CertRep with SUCCESS 563 | | 564 | | 565 +--------<-------------------+ 566 request rejected, timeout, or error 568 As described in the section 2.2.3, certificate enrollment starts at the 569 state CERT-NONEXISTANT. Sending PKCSReq changes the state to 570 CERT-REQ-PENDING. Receiving CertRep with SUCCESS status changes the 571 state to CERT-ISSUED. In the case the server sending back the response 572 with pending status, the requester will keep polling certificate 573 response by sending GetCertInitial to the server, until either a CertRep 574 with SUCCESS status is received, or the maximum polling number has been 575 exceeded. 577 If an error or timeout occurs in the CERT-REQ-PENDING state, the end 578 entity will transition to the CERT-NONEXISTANT state. 580 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 582 The client administrator will, eventually, start up another enrollment 583 request. It is important to note that, as long as the requester does 584 not change its subject name or keys, the same transaction id will be 585 used in the "new" transaction. This is important because based on this 586 transaction id, the certificate authority server can recognize this as 587 an existing transaction instead of a new one. 589 2.3.3 Transaction Behavior of Certificate/CRL Access 591 There is no state maintained during certificate access and CRL access 592 transaction. When using the certificate query and CRL query messages 593 defined in this protocol, the transaction identifier is still required 594 so that the requester can match the response message with the 595 upstanding request message. When using LDAP to query the certificate and 596 the CRL, the behavior is specified by the LDAP protocol. 598 2.4 Security 600 The security goals of SCEP are that no adversary can: 602 o subvert the public key/identity binding from that intended, 603 o discover the identity information in the enrollment requests and 604 issued certificates, 605 o cause the revocation of certificates with any non-negligible 606 probability. 608 Here an adversary is any entity other than the requester and the CA 609 (and optionally the RA) participating in the protocol that is 610 computationally limited, but that can manipulate data during 611 transmission (that is, a man-in-the-middle). The precise meaning of 612 'computationally limited' depends on the implementer's choice of 613 cryptographic hash functions and ciphers. The required algorithms are 614 RSA, DES, and MD5. 616 The first and second goals are met through the use of PKCS#7 and PKCS#10 617 encryption and digital signatures using authenticated public keys. The 618 CA's public key is authenticated via the checking of the CA fingerprint, 619 as specified in Section 2.1.2, and the SCEP client's public key is 620 authenticated through the manual authentication or pre-shared secret 621 authentication, as specified in Section 2.1.1.2. The third goal is met 622 through the use of a Challenge Password for revocation, that is chosen 623 by the SCEP client and communicated to the CA protected by the PKCS#7 624 encryption, as specified in Section 2.2.4. 626 The motivation of the first security goal is straightforward. The 627 motivation for the second security goal is to protect the identity 628 information in the enrollment requests and certificates. For example, 629 two IPSEC hosts behind a firewall may need to exchange certificates, and 630 may need to enroll certificates with a CA that is outside of a firewall. 631 Most networks with firewalls seek to prevent IP addresses and DNS 632 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 634 information from the trusted network leaving that network. The second 635 goal enables the hosts in this example to enroll with a CA outside the 636 firewall without revealing this information. The motivation for the 637 third security goal is to protect the SCEP clients from denial of 638 service attacks. 640 Section 3 Transport Protocol 642 In the SCEP protocol, HTTP is used as the transport protocol for the PKI 643 messages. 645 3.1 HTTP "GET" and "POST" Message Format 647 The following is the syntax definition of a HTTP GET message sent from 648 a requester to a certificate authority server: 650 Request = "GET " CGI-PATH CGI-PROG "?operation=" OPERATION "&message=" MESSAGE 651 where: 652 CGI-PATH defines the actual CGI path to invoke the CGI program which 653 parses the request. 654 CGI-PROG is set to be the string "pkiclient.exe". This is intended 655 to be the program that the CA will use to handle the SCEP transactions, 656 though the CA may ignore CGI-PROG and use only the CGI-PATH. 657 OPERATION is set to be the string "PKIOperation" when the GET message 658 carries a PKI message to request certificates or CRL; OPERATION is set 659 to be the string "GetCACaps", "GetCACert", "GetNextCACert" or 660 "GetCACertChain" when the GET operation is used to get CA capabilities, 661 CA/RA certificate, the next CA/RA certificates, or the CA Cert chain 662 (respectively). When OPERATION is "PKIOperation", MESSAGE is a base64- 663 encoded PKI message, When OPERATION is GetCACert, MESSAGE is a CRL distribution 664 point in URI format, otherwise, MESSAGE is a string which represents 665 the certificate authority issuer identifier. 667 SCEP uses the HTTP "GET" and "POST" messages to request information from the CA. 668 Requests for CA certificates or capabilities are sent in the clear, using "GET", 669 with the OPERATION and MESSAGE fields identifying the requested data. 670 CRLs may also be requested in the clear if the CA supports it. 672 Other types of requests are sent using the PKCS#7 secure protocol. 673 These may be issued by means of a GET operation with 674 OPERATION and MESSAGE parameters in the Request-URL. OPERATION 675 identifies the type of GET operation, and MESSAGE is actually the PKCS#7 676 message Base64-Encoded. 678 For example. a requester may submit a message via HTTP to the server 679 as follows: 681 GET /cgi-bin/pkiclient.exe?operation=PKIOperation&message=MIAGCSqGSIb3D 682 QEHA6CAMIACAQAxgDCBzAIBADB2MGIxETAPBgNVBAcTCE ......AAAAAA== 683 If supported by the CA, the message may also be sent via HTTP POST: 685 POST /cgi-bin/pkiclient.exe?operation=PKIOperation 687 This is further described in Appendix H. 688 To determine if the CA supports POST, use the GetCACaps message described 689 in Appendix F. 691 3.2 Response Message Format 693 For each GET operation, the CA/RA server will return a MIME object via 694 HTTP. For a GET operation with PKIOperation as its type, the response is 695 tagged as having a Content Type of application/x-pki-message. The body 696 of this message is a BER encoded binary PKI message. The following is an 697 example of the response: 699 "Content-Type:application/x-pki-message\n\n" 701 In the case of GET operation with a type of GetCACert or GetNextCACert, 702 the MIME content type returned will depend on whether or not an RA is in 703 use. If there is no RA, only the CA certificate is sent back in the 704 response, and the response has the content type tagged as 705 application/x-x509-ca-cert. the body of the response is a DER encoded 706 binary X.509 certificate. For example: 708 "Content-Type:application/x-x509-ca-cert\n\n" 710 If there is an RA, the RA certificates are sent back together with the 711 CA certificates, a certificate-only PKCS#7 SignedData is sent back in 712 the response where the SignerInfo is empty. Section 5 has the detailed 713 definition of the message format in this case. The content type is 714 application/x-x509-ca-ra-cert. 716 If the CA supports it, PKIOperation may also be done via an HTTP POST. 717 This is described in appendix I. 719 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 721 Section 4 Secure Transportation: PKCS#7 723 PKCS#7 is a general enveloping mechanism that enables both signed and 724 encrypted transmission of arbitrary data. It is widely implemented and 725 included in the RSA tool kit. In this section, the general PKCS#7 726 enveloped PKI message format is specified. The complete PKCS#7 message 727 format for each PKI transaction will be covered in Section 5. 729 4.1 SCEP Message Format 731 As a transaction message, a SCEP message has a set of transaction 732 specific attributes and an information portion. Employing PKCS#7 733 protocol, the transaction specific attributes are encoded as a set of 734 authenticated attributes of the SignedData. The information portion will 735 first be encrypted to become Enveloped Data, and then the digest of the 736 enveloped information portion is included as one of the message digest 737 attributes and being signed together with the other transaction specific 738 attributes. 740 By applying both enveloping and signing transformations, a SCEP message 741 is protected both for the integrity of its end-end-transition 742 information and the confidentiality of its information portion. The 743 advantage of this technique over the conventional transaction message 744 format is that, the signed transaction type information and the status 745 of the transaction can be determined prior to invoke security handling 746 procedures specific to the information portion being processed. 748 The following is an example of a SCEP message with its enveloped and 749 signed data portion represented by pkcsPKISigned and 750 pkcsPKIEnveloped. The out-most of any PKI message is a blob of 751 ContentInfo, with its content type set to SignedData and the actual 752 signed data as the content. 754 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 756 pkiMessage ContentInfo ::= { 757 contentType {pkcs-7 signedData(2)} 758 content pkcsPKISigned 759 } 760 pkcsPKISigned SignedData ::= { 761 version 1 762 digestAlgorithm { iso(1) member-body(2) US(840) rsadsi(113549) 763 digestAlgorithm(2) 5} 764 contentInfo { 765 contentType {pkcs-7 1} -- data content identifier 766 content pkcsPKIEnvelope -- enveloped information portion 767 } 768 certificates -- signer certificate chain 769 signerInfo -- including signed transaction info and the digest 770 -- of the enveloped information portion as the 771 -- authenticated attributes 772 } 773 pkcsPKIEnveloped EnvelopedData ::= { 774 version 0 775 recipientInfos -- information required to open the envelop 776 encryptedContentInfo { 777 contentType {pkcs-7 1} -- data content identifier 778 contentEncryptionAlgorithm 779 encryptedContent -- encrypted information portion 780 } 781 } 783 4.2 Signed Transaction Attributes 785 The following transaction attributes are encoded as authenticated 786 attributes. Please refer to Appendix B for the OID definitions. 788 transactionID PrintableString -- Decimal value as a string 789 messageType PrintableString -- Decimal value as a string 790 pkiStatus PrintableString -- Decimal value as a string 791 failinfo PrintableString -- Decimal value as a string 792 senderNonce Octet String 793 recipientNonce Octet String 795 where: 797 The transactionID is an attribute which uniquely identify a 798 transaction. This attribute is required in all PKI messages. 800 The messageType attribute specify the type of operation performed by the 801 transaction. This attribute is required in all PKI 802 messages. Currently, the following message types are defined: 804 PKCSReq (19) -- Permits use of PKCS#10 certificate request 805 CertRep (3) -- Response to certificate or CRL request 806 GetCertInitial (20) -- Certificate polling in manual enrollment 807 GetCert (21) -- Retrieve a certificate 808 GetCRL (22) -- Retrieve a CRL 809 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 811 All response message will include transaction status information which 812 is defined as pkiStatus attribute: 814 SUCCESS (0) -- request granted 815 FAILURE (2) -- request rejected 816 PENDING (3) -- request pending for manual approval. 818 If the status in the response is FAILURE, the failinfo attribute will 819 contain one of the following failure reasons: 821 badAlg (0) -- Unrecognized or unsupported algorithm ident 822 badMessageCheck (1) -- integrity check failed 823 badRequest (2) -- transaction not permitted or supported 824 badTime (3) -- Message time field was not sufficiently close 825 to the system time 826 badCertId (4) -- No certificate could be identified matching 827 the provided criteria 829 The attributes of senderNonce and recipientNonce are the 16 byte 830 random numbers generated for each transaction to prevent the replay 831 attack. 833 When a requester sends a PKI message to the server, a senderNonce is 834 included in the message. After the server processes the request, it will 835 send back the requester senderNonce as the recipientNonce and generates 836 another nonce as the senderNonce in the response message. Because the 837 proposed pki protocol is a two-way communication protocol, it is clear 838 that the nonce can only be used by the requester to prevent the 839 replay. The server has to employ extra state related information to 840 prevent a replay attack. 842 Section 5. SCEP Transaction Specification 844 In this section each SCEP transaction is specified in terms of the 845 complete messages exchanged during the transaction. 847 5.1 Certificate Enrollment 849 The certificate enrollment transaction consists of one PKCSReq message 850 sent to the certificate authority from a requester, and one CertRep 851 message sent back from the server. The pkiStatus returned in the 852 response message is either SUCCESS, or FAILURE, or PENDING. The 853 information portion of a PKCSReq message is a PKCS#10 certificate 854 request, which contains the subject Distinguished Name, the subject 855 public key, and two attributes, a ChallengePassword attribute to be used 856 for revocation, and an optional ExtensionReq attribute which will be a 857 sequence of extensions the requester expects to be included in its V3 858 certificate extensions. One of the extension attribute specifies the key 859 usage. If the request is granted, the pkiStatus is set to SUCCESS, and 860 the certificate is returned in CertRep; if the request is rejected, the 861 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 863 pkiStatus is set to FAILURE; if the server requires manual approval of 864 the request, the pkiStatus is set to PENDING. The messages exchanged 865 in the manual authentication mode is further specified in Section 5.2. 867 Precondition: 868 Both the requester and the certificate authority have completed their 869 initialization process. The requester has already been configured 870 with the CA/RA certificate. 872 Postcondition: 873 Either the certificate is received by the requester, or the end 874 entity is notified to do the manual authentication, or the request 875 is rejected. 877 5.1.1 PKCSReq Message Format 879 A PKCSReq message is created by following the steps defined below: 881 1. Create a PKCS#10 certificate request which is signed by the end 882 entity's private key, corresponding to the public key included in 883 the PKCS#10 certificate request. This constitutes the information 884 portion of PKCSReq. 886 2. Encrypt the PKCS#10 certificate request using a randomly generated 887 content-encryption key. This content-encryption key is then 888 encrypted by the CA's* public key and included in the recipientInfo. 889 This step completes the "envelope" for the PKCS#10 certificate 890 request. 892 3. Generate a unique string as the transaction id. 894 4. Generate a 16 byte random number as senderNonce. 896 5. Generate message digest on the enveloped PKCS#10 certificate request 897 using the selected digest algorithm. 899 6. Create SignedData by adding the requester's self- or CA-certificate 900 as the signer's public key certificate. Include the message type, 901 transaction id, the senderNonce and the message digest as the 902 authenticated attributes and sign the attributes using the end 903 entity's private key. This completes the SignedData. 905 7. The SignedData is prepended with the ContenInfo blob which indicates 906 a SignedData object. This final step completes the create of a 907 complete PKCSReq PKI message. 909 In the following, the PKCSReq message is defined following the ASN.1 910 notation. 912 For readability, the values of a field is either represented by a quoted 913 string which specifies the intended value, or a constant when the value 914 is known. 916 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 918 -- PKCSReq information portion 919 pkcsCertReq CertificationRequest ::= { -- PKCS#10 920 version 0 921 subject "the requester's subject name" 922 subjectPublicKeyInfo { 923 algorithm {pkcs-1 1} -- rsa encryption 924 subjectPublicKey "DER encoding of the requester's public key" 925 } 926 attributes { 927 challengePassword {{pkcs-9 7} "password string" } 928 extensions 929 } 930 signatureAlgorithm {pkcs-1 4} -- MD5WithRSAEncryption 931 signature "bit string which is created by signing inner content 932 of the defined pkcsCertReq using requester's private 933 key, corresponding to the public key included in 934 subjectPublicKeyInfo." 935 } 936 -- Enveloped information portion 937 pkcsCertReqEnvelope EnvelopeData ::= { -- PKCS#7 938 version 0 939 recipientInfo { 940 version 0 941 issuerAndSerialNumber { 942 issuer "the CA issuer name" 943 serialNumber "the CA certificate serial number" 944 } 945 keyEncryptionAlgorithm {pkcs-1 1} -- rsa encryption 946 encryptedKey "content-encryption key 947 encrypted by CA public key" 948 } 949 encryptedContentInfo { 950 contentType {pkcs-7 1} -- data content 951 contentEncryptionAlgorithm "object identifier 952 for DES encryption" 953 encryptedContent "encrypted pkcsCertReq using the content- 954 encryption key" 955 } 956 } 957 -- Signed PKCSReq 958 pkcsCertReqSigned SignedData ::= { -- PKCS#7 959 version 1 960 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 961 digestAlgorithm(2) 5} 962 contentInfo { 963 contentType {pkcs-7 1} -- data content identifier 964 content pkcsCertReqEnvelope 965 } 966 certificate { -- requester self-signed or CA-issued certificate 967 version 3 968 serialNumber "the transaction id associated with enrollment" 969 signature {pkcs-1 4} -- md5WithRSAEncryption 970 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 972 issuer " the requester's subject name" 973 validity { 974 notBefore "a UTC time" 975 notAfter "a UTC time" 976 } 977 subject "the requester's subject name" 978 subjectPublicKeyInfo { 979 algorithm {pkcs-1 1} 980 subjectPublicKey "DER encoding of requester's public key" 981 } 982 signatureAlgorithm {pkcs-1 4} 983 signature "the signature generated by using the requester's 984 private key corresponding to the public key in 985 this certificate." 986 } 987 signerInfo { 988 version 1 989 issuerAndSerialNumber { 990 issuer "the requester's subject name" 991 serialNumber "the transaction id associated 992 with the enrollment" 993 } 994 digestAlgorithm {iso(0) 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} "an octet string"} 999 transaction-id {{id-attributes transId(7)} "printable 1000 string"} 1001 -- this transaction id will be used 1002 -- together with the subject name as 1003 -- the identifier of the requester's key 1004 -- pair during enrollment 1005 messageType {{id-attributes messageType(2)} "PKCSReq"} 1006 senderNonce {{id-attributes senderNonce(5)} 1007 "a random number encoded as a string"} 1008 } 1009 digestEncryptionAlgorithm {pkcs-1 1} -- rsa encryption 1010 encryptedDigest "encrypted digest of the authenticated 1011 attributes using requester's private key" 1012 } 1013 } 1014 pkcsReq PKIMessage ::= { 1015 contentType {pkcs-7 2} 1016 content pkcsCertRepSigned 1017 } 1018 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 1020 5.1.2 CertRep Message Format 1022 The response to an SCEP enrollment request is a CertRep message. 1024 5.1.2.1 PENDING Response 1026 When the CA is configured to manually authenticate the requester, 1027 the CertRep is returned with the attribute pkiStatus set to PENDING. 1028 The data portion for this message is null. Only the transaction 1029 required attributes are sent back. 1031 CertRepSigned SignedData ::= { -- PKCS#7 1032 version 1 1033 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1034 digestAlgorithm(2) 5} 1035 contentInfo {contentType {pkcs-7 1} -- empty content 1036 } 1037 signerInfo { 1038 version 1 1039 issuerAndSerialNumber { 1040 issuer "name of CA that issued the CA [RA] cert" 1041 serialNumber "the serial number of the CA [RA] cert" 1042 } 1043 digestAlgorithm (iso(1) member-body(2) US(840) rsadsi(113549) 1044 digestAlgorithm(2) 5} 1045 authenticateAttributes { 1046 contentType {{pkcs-9 3} {pkcs-7 1}} 1047 messageDigest {{pkcs-9 4} NULL} 1048 messageType {{id-attribute messageType(0)} "CertRep"} 1049 transaction-id {{id-attributes transid(7)} "printablestring"} 1050 --- same transaction id used in PKCSReq 1051 pkiStatus {{id-attributes pkiStatus(3)} "PENDING"} 1052 recipientNonce {{id-attributes recipientNonce(6)}<16 bytes>} 1053 senderNonce {{id-attributes senderNonce(5)} <16 bytes>} 1054 } 1055 digestEncrytionAlgorithm {pkcs-1 1} 1056 encryptedDigest "encrypted message digest of the authenticated 1057 attributes using the CA's [RA's] private key" 1058 } 1059 } 1060 CertRep PKIMessage ::= { 1061 contentType {pkcs-7 2} 1062 content CertRepSigned 1063 } 1065 5.1.2.2 Failure Response 1067 In this case, the CertRep sent back to the requester is same as in 1068 the PENDING case, except that the pkiStatus attribute is set to FAILURE, 1069 and the failInfo attribute should be included: 1071 pkistatus {{id-attributes pkiStatus(3)} "FAILURE"} 1072 failInfo {{id-attributes failInfo(4)} "the reason to reject"} 1073 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 1075 5.1.2.3 SUCCESS response 1077 In this case, the information portion of CertRep will be a degenerated 1078 PKCS#7 which contains the requester's certificate. It is then enveloped 1079 and signed as below: 1081 pkcsCertRep SignedData ::= { -- PKCS#7 1082 version 1 1083 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1084 digestAlgorithm(2) 5} 1085 contentInfo { -- empty content since this is degenerated PKCS#7 1086 contentType {pkcs-7 1} 1087 } 1088 certificates { 1089 certificate { -- issued requester's certificate // must be first 1090 version 3 1091 serialNumber "issued requester's certificate serial number" 1092 signature {pkcs-1 4} -- md5WithRSAEncryption 1093 issuer "the certificate authority issuer name" 1094 validity { 1095 notBefore "UTC time" 1096 notAfter "UTC time" 1097 } 1098 subject "the requester subject name as given in PKCS#10" 1099 subjectPublicKeyInfo { 1100 algorithm {pkcs-1 1} 1101 subjectPublicKey "a DER encoding of requester public 1102 key as given in PKCS#10" 1103 } 1104 extensions " the extensions as given in PKCS#10" 1105 signatureAlgorithm {pkcs-1 4} 1106 signature " the certificate authority signature" 1107 } 1108 certificate "the certificate authority certificate" (optional) 1109 certificate "the registration authority certificate(s)" (optional) 1110 } 1111 } 1112 pkcsCertRepEnvelope EnvelopedData ::= { -- PKCS#7 1113 version 0 1114 recipientInfo { 1115 version 0 1116 issuerAndSerialNumber { -- use issuer name and serial number as 1117 -- conveyed in requester's self-signed 1118 -- certificate, included in the PKCSReq 1119 issuer "the requester's subject name" 1120 serialNumber "the serial number defined by the requester in 1121 its self-signed certificate" 1122 } 1123 keyEncryptionAlgorithm {pkcs-1 1} 1124 encryptedKey "content-encrypt key encrypted by the requester's 1125 public key which is same key as authenticated in 1126 the requester's certificate" 1127 } 1128 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 1130 encryptedContentInfo { 1131 contentType {pkcs-7 1} -- data content identifier 1132 contentEncryptionAlgorithm "OID for DES encryption" 1133 encryptedContent "encrypted pkcsCertRep using content encryption 1134 key" 1135 } 1136 } 1137 pkcsCertRepSigned SignedData ::= { -- PKCS#7 1138 version 1 1139 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1140 digestAlgorithm(2) 5} 1141 contentInfo { 1142 contentType {pkcs-7 1} 1143 content pkcsCertRepEnvelope 1144 } 1145 signerInfo { 1146 version 1 1147 issuerAndSerialNumber { 1148 issuer "the certificate authority issuer name" 1149 serialNumber "the CA certificate's serial number" 1150 } 1151 digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) 1152 digestAlgorithm(2) 5} 1153 authenticateAttributes { 1154 contentType {{pkcs-9 3} {pkcs-7 1}} 1155 messageDigest {{pkcs-9 4} "a octet string"} 1156 messageType {{id-attribute messageType(2)} "CertRep"} 1157 transaction-id {{id-attributes transId(7)} "printable 1158 string"} 1159 -- same transaction id as given in PKCSReq 1160 pkiStatus {{id-attributes pkiStatus(3) "SUCCESS"} 1161 recipientNonce {{id-attribute recipientNonce(6)}<16 bytes>} 1162 senderNonce {{ id-attributes senderNonce(5) <16 bytes>} 1163 } 1164 digestEncryptionAlgorithm {pkcs-1 1} 1165 encryptedDigest "encrypted digest of authenticate attributes 1166 using CA's private key " 1167 } 1168 } 1169 CertRep PKIMessage ::= { 1170 contentType {pkcs-7 2} 1171 content pkcsCertRepSigned 1172 } 1174 5.2 Poll for Requester Initial Certificate 1176 Either triggered by the PENDING status received from the CertRep, or by 1177 the non-response timeout for the previous PKCSReq, a requester will 1178 enter the polling state by periodically sending GetCertInitial to the 1179 server, until either the request is granted and the certificate is sent 1180 back, or the request is rejected, or the configured time limit for 1181 polling is exceeded. 1183 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 1185 Since GetCertInitial is part of the enrollment, the messages exchanged 1186 during the polling period should carry the same transaction identifier 1187 as the previous PKCSReq. 1189 PreCondition 1190 Either the requester has received a CertRep with pkiStatus set to be 1191 PENDING, or the previous PKCSReq has timed out. 1193 PostContition 1194 The requester has either received the certificate, or be rejected of 1195 its request, or the polling period ended as a failure. 1197 5.2.1 GetCertInitial Message Format 1199 Since at this time the certificate has not been issued, the requester 1200 can only use the requester's subject name, combined with the 1201 transaction identifier, to identify the polled certificate request. 1203 The certificate authority server must be able to uniquely identify the 1204 polled certificate request. A subject name can have more than one 1205 outstanding certificate request (with different key usage attributes). 1207 -- Information portion 1209 pkcsGetCertInitial issuerAndSubject ::= { 1210 issuer "the certificate authority issuer name" 1211 subject "the requester subject name as given in PKCS#10" 1212 } 1213 pkcsGetCertInitialEnvelope EnvelopedData ::= { 1214 version 0 1215 recipientInfo { 1216 version 0 1217 issuerAndSerialNumber { 1218 issuer "the CA issuer name" 1219 serialNumber "the CA certificate serial number" 1220 } 1221 keyEncryptionAlgorithm {pkcs-1 1} 1222 encryptedKey "content-encrypt key encrypted by CA's public key" 1223 } 1224 encryptedContentInfo { 1225 contentType {pkcs-7 1} -- data content 1226 contentEncryptionAlgorithm "OID for DES encryption" 1227 encryptedContent "encrypted getCertInital" 1228 } 1229 } 1230 pkcsGetCertInitialSigned SignedData ::= { -- PKCS#7 1231 version 1 1232 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1233 digestAlgorithm(2) 5} 1234 contentInfo { 1235 contentType {pkcs-7 1} 1236 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 1238 content pkcsGetCertIntialEnvelope 1239 } 1240 certificate { -- the requester's self-signed certificate 1241 version 3 1242 serialNumber "the transaction id associated with enrollment" 1243 signature {pkcs-1 4} -- md5WithRSAEncryption 1244 issuer " the requester's subject name" 1245 validity { 1246 notBefore "a UTC time" 1247 notAfter "a UTC time" 1248 } 1249 subject "the requester's subject name" 1250 subjectPublicKeyInfo { 1251 algorithm {pkcs-1 1} 1252 subjectPublicKey "DER encoding of requester's public key" 1253 } 1254 signatureAlgorithm {pkcs-1 4} 1255 signature "the signature generated by using the requester's 1256 private key corresponding to the public key in 1257 this certificate." 1258 } 1259 signerInfo { 1260 version 1 1261 issuerAndSerialNumber { 1262 issuer "requester's subject name" 1263 serialNumber "the transaction id used in previous PKCSReq" 1264 } 1265 digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) 1266 digestAlgorithm(2) 5} 1267 authenticateAttributes { 1268 contentType {{pkcs-9 3} {pkcs-7 1}} 1269 messageDigest {{pkcs-9 4} "an octet string"} 1270 -- digest of getCertInitial 1271 messageType {{id-attribute messageType(2)} "GetCertInitial"} 1272 transaction-id {{id-attributes transId(7)} "printable 1273 string"} 1274 -- same transaction idused in previous PKCSReq 1275 senderNonce {{id-attribute senderNonce(3)} 0x<16 bytes>} 1276 } 1277 digestEncryptionAlgorithm {pkcs-1 1} 1278 encryptedDigest "encrypted digest of authenticateAttributes" 1279 } 1280 } 1281 GetCertInitial PKIMessage ::= { 1282 contentType {pkcs-7 2} 1283 content pkcsGetCertInitialSigned 1284 } 1286 5.2.2 GetCertInitial Response Message Format 1288 The response messages for GetCertInitial are the same as for PKCSReq. 1290 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 1292 5.3 Certificate Access 1294 The certificate query message defined in this section is an option when 1295 the LDAP server is not available to provide the certificate query. A 1296 requester should be able to query an issued certificate from the 1297 certificate authority, as long as the issuer name and the issuer 1298 assigned certificate serial number is known to the requesting end 1299 entity. This transaction is not intended to provide the service as a 1300 certificate directory service. A more complicated query mechanism would 1301 have to be defined in order to allow a requester to query a certificate 1302 using various different fields. 1304 This transaction consists of one GetCert message sent to the server by 1305 a requester, and one CertRep message sent back from the server. 1307 PreCondition 1308 The queried certificate have been issued by the certificate authority 1309 and the issuer assigned serial number is known. 1311 PostCondition 1312 Either the certificate is sent back or the request is rejected. 1314 5.3.1 GetCert Message Format 1316 The queried certificate is identified by its issuer name and the issuer 1317 assigned serial number. If this is a query for an arbitrary requester's 1318 certificate, the requesting requester should includes its own CA issued 1319 certificate in the signed envelope. If this is a query for its own 1320 certificate (assume the requester lost the issued certificate, or does 1321 not have enough non-volatile memory to save the certificate), then the 1322 self-signed certificate has to be included in the signed envelope. 1324 pkcsGetCert issuerAndSerialNumber ::= { 1325 issuer "the certificate issuer name" 1326 serialNumber "the certificate serial number" 1327 } 1328 pkcsGetCertEnvelope EnvelopedData ::= { 1329 version 0 1330 recipientInfo { 1331 version 0 1332 issuerAndSerialNumber { 1333 issuer "the CA [RA] issuer name" 1334 serialNumber "the CA [RA] certificate serial number" 1335 } 1336 keyEncryptionAlgorithm {pkcs-1 1} 1337 encryptedKey "content-encrypt key encrypted 1338 by CA [RA] public key" 1339 } 1340 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 1342 encryptedContentInfo { 1343 contentType {pkcs-7 1} -- data content 1344 contentEncryptionAlgorithm "OID for DES encryption" 1345 encryptedContent "encrypted pkcsGetCert using the content 1346 encryption key" 1347 } 1348 } 1349 pkcsGetCertSigned SignedData ::= { 1350 version 1 1351 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1352 digestAlgorithm(2) 5} 1353 contentInfo { 1354 contentType {pkcs-7 1} 1355 content pkcsGetCertEnvelope 1356 } 1357 certificates { 1358 certificate "CA issued certificate" 1359 or "self-signed certificate" 1360 } 1361 signerInfo { 1362 version 1 1363 issuerAndSerialNumber { 1364 issuer "the requester's subject name" 1365 serialNumber "requester's certificate serial number" 1366 } 1367 digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) 1368 digestAlgorithm(2) 5} 1369 authenticateAttributes { 1370 contentType {{pkcs-9 3} {pkcs-7 1}} 1371 messageDigest {{pkcs-9 4} "an octet string"} 1372 -- digest of pkcsGetCertEnvelope 1373 messageType {{id-attribute messageType(2)} "GetCert"} 1374 transaction-id {{id-attributes transId(7)} "printable 1375 string"} 1376 senderNonce {{id-attribute senderNonce(3)} <16 bytes>} 1377 } 1378 digestEncryptionAlgorithm {pkcs-1 1} 1379 encryptedDigest "encrypted digest of authenticateAttributes" 1380 } 1381 } 1382 GetCert PKIMessage ::= { 1383 contentType {pkcs-7 2} 1384 content pkcsGetCertSigned 1385 } 1386 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 1388 5.3.2 CertRep Message Format 1390 In this case, the CertRep from the server is same as the CertRep for the 1391 PKCSReq, except that the server will only either grant the request or 1392 reject the request. Also, the recipientInfo should use the CA issuer 1393 name and CA assigned serial number to identify the requester's key pair 1394 since at this time, the requester has received its own certificate. 1396 5.4 CRL Access 1398 The CRL query message defined in this section is an option when the LDAP 1399 server is not available to provide the CRL query. In the PKI protocol 1400 proposed here, only the requester can initiate the transaction to 1401 download CRL. A requester sends GetCRL request to the server and the 1402 server sends back CertRep whose information portion is a degenerated 1403 PKCS#7 which contains only the most recent CRL. The size of CRL included 1404 in the CertRep should be determined by the implementation. 1406 PreCondition 1407 The certificate authority certificate has been downloaded to the end 1408 entity. 1410 PostCondition 1411 CRL sent back to the requester. 1413 5.4.1 GetCRL Message format 1415 The CRL is identified by using both CA's issuer name and the CA 1416 certificate's serial number: 1418 pkcsGetCRL issuerAndSerialNumber { 1419 issuer "the certificate authority issuer name" 1420 serialNumber "certificate authority certificate's serial number" 1421 } 1423 When the CRLDistributionPoint is supported, the pkcsGetCRL is defined as 1424 the following: 1426 pkcsGetCRL SEQUENCE { 1427 crlIssuer issuerAndSerialNumber 1428 distributionPoint CE-CRLDistPoints 1429 } 1431 where CE-CRLDisPoints is defined in X.509, but must contain only one 1432 CRL distribution point. 1434 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 1436 pkcsGetCRLEnvelope EnvelopedData ::= { 1437 version 0 1438 recipientInfo { 1439 version 0 1440 issuerAndSerialNumber { 1441 issuer "the certificate authority (or RA) issuer name" 1442 serialNumber "the CA (RA) certificate's serial number" 1443 } 1444 keyEncryptionAlgorithm {pkcs-1 1} 1445 encryptedKey "content-encrypt key encrypted by CA (RA) public key" 1446 } 1447 encryptedContentInfo { 1448 contentType {pkcs-7 1} -- data content 1449 contentEncryptionAlgorithm "OID for DES encryption" 1450 encryptedContent "encrypted pkcsGetCRL" 1451 } 1452 } 1453 pkcsGetCRLSigned SignedData ::= { 1454 version 1 1455 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1456 digestAlgorithm(2) 5} 1457 contentInfo { 1458 contentType {pkcs-7 1} 1459 content pkcsGetCRLEnvelope 1460 } 1461 certificates { 1462 certificate "CA-issued or self-signed requester's certificate" 1463 } 1464 signerInfo { 1465 version 1 1466 issuerAndSerialNumber { 1467 issuer "the requester's issuer name" 1468 serialNumber "the requester's certificate serial number" 1469 } 1470 digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) 1471 digestAlgorithm(2) 5} 1472 authenticateAttributes { 1473 contentType {{pkcs-9 3} {pkcs-7 1}} 1474 messageDigest {{pkcs-9 4} 0x<16/20 bytes>} 1475 -- digest of pkcsGetCRLEnvelope 1476 messageType {{id-attribute messageType(2)} "CertCRL"} 1477 transaction-id {{id-attributes transId(7)} "printable 1478 string"} 1479 senderNonce {{id-attribute senderNonce(3)} <16 bytes>} 1480 } 1481 digestEncryptionAlgorithm {pkcs-1 1} 1482 encryptedDigest "encrypted digest of authenticateAttributes" 1483 } 1484 } 1485 GetCRL PKIMessage ::= { 1486 contentType {pkcs-7 2} 1487 content pkcsGetCRLSigned 1488 } 1489 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 1491 5.4.2 CertRep Message Format 1493 The CRL is sent back to the requester through CertRep message. The 1494 information portion of this message is a degenerated PKCS#7 SignedData 1495 which contains only a CRL. 1497 pkcsCertRep SignedData ::= { 1498 version 1 1499 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1500 digestAlgorithm(2) 5} 1501 contentInfo { 1502 contentType {pkcs-7 1} 1503 } 1504 crl { 1505 signature {pkcs-1 4} 1506 issuer "the certificate authority issuer name" 1507 lastUpdate "UTC time" 1508 nextUpdate "UTC time" 1509 revokedCertificate { 1510 -- the first entry 1511 userCertificate "certificate serial number" 1512 revocationData "UTC time" 1513 .... 1514 -- last entry 1515 userCertificate "certificate serial number" 1516 revocationData "UTC time" 1517 } 1518 } 1519 pkcsCertRepEnvelope EnvelopedData ::= { 1520 version 0 1521 recipientInfo { 1522 version 0 1523 issuerAndSerialNumber { 1524 issuer "the requester's issuer name" 1525 serialNumber "the requester certificate serial number" 1526 } 1527 keyEncryptionAlgorithm {pkcs-1 1} 1528 encryptedKey "content-encrypt key encrypted by requester's 1529 public key " 1530 } 1531 encryptedContentInfo { 1532 contentType {pkcs-7 1} -- data content 1533 contentEncryptionAlgorithm "OID for DES encryption" 1534 encryptedContent "encrypted pkcsCertRep using requester's 1535 public key" 1536 } 1537 } 1538 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 1540 pkcsCertRepSigned SignedData ::= { -- PKCS#7 1541 version 1 1542 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1543 digestAlgorithm(2) 5} 1544 contentInfo { 1545 contentType {pkcs-7 1} 1546 content pkcsCertRepEnvelope 1547 } 1548 signerInfo { 1549 version 1 1550 issuerAndSerialNumber { 1551 issuer "the certificate authority issuer name" 1552 serialNumber "the CA certificate's serial number" 1553 } 1554 digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) 1555 digestAlgorithm(2) 5} 1556 authenticateAttributes { 1557 contentType {{pkcs-9 3} {pkcs-7 1}} 1558 messageDigest {{pkcs-9 4} "an octet string"} 1559 -- digest of pkcsCertRepEnvelope 1560 messageType {{id-attribute messageType(2)} "CertRep"} 1561 transaction-id {{id-attributes transId(7)} "printable 1562 string"} 1563 -- same transaction id as given in PKCSReq 1564 pkiStatus {{id-attributes pkiStatus(3) "SUCCESS"} 1565 recipientNonce{{id-attribute recipientNonce(6)}<16 bytes>} 1566 senderNonce {{id-attribute senderNonce (5) 0x<16 bytes>} 1567 } 1568 digestEncryptionAlgorithm {pkcs-1 1} 1569 encryptedDigest "encrypted digest of authenticatedAttributes 1570 using CA private key" 1571 } 1572 } 1574 NOTE:The PKCS#7 EncryptedContent is specified as an octet string, but 1575 SCEP entities must also accept a sequence of octet strings as a valid 1576 alternate encoding. 1578 This alternate encoding must be accepted wherever PKCS #7 Enveloped 1579 Data is specified in this document. 1581 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 1583 5.5 Get Certificate Authority Certificate 1585 Before any transaction begins, end entities have to get the CA (and 1586 possibly RA) certificate(s) first. Since the requester may have no 1587 CA certificates or CA public keys at all, this message can not be 1588 encrypted and the response must be authenticated by out-of-band means. 1589 These certs are obtained by means of an HTTP GET message. To get the 1590 CA certificate, the requester does a "HTTP GET" with a URL that 1591 identifies a CGI script on the server and an optional CA issuer 1592 identifier as the parameter to the CGI script. The response is either 1593 a single X.509 CA certificate ("CA mode"), or a PKCS7 message containing 1594 the CA certificate and RA certificates ("RA mode"). The client can 1595 determine which mode the CA operates in by which response it gets. 1596 Once the CA certificate is received by the requester, a fingerprint 1597 is generated using MD5 hash algorithm on the whole CA certificate. 1598 If the requester does not have a certificate path to a trusted CA 1599 certificate, this fingerprint may be used to verify the certificate, 1600 by some positive out-of-band means, such as a phone call. 1602 5.5.1 GetCACert HTTP Message Format 1603 "GET" CGI-PATH CGI-PROG "?operation=GetCACert" "&message=" CA-IDENT 1604 where: 1605 CGI-PATH defines the actual CGI path to invoke the CGI program 1606 which parses the request. 1607 CGI-PROG is set to be the string "pkiclient.exe" and this is 1608 expected to be the program that the CA will use to handle the 1609 SCEP transactions. 1610 CA-IDENT is any string which is understood by the CA. 1611 For example, it could be a domain name like ietf.org. 1612 If a certificate authority has multiple CA certificates 1613 this field can be used to distinguish which is required. 1614 Otherwise it may be ignored. 1616 5.5.2 Response 1618 The response for GetCACert is different between the case where the CA 1619 directly communicated with the requester during the enrollment, and the 1620 case where a RA exists and the requester communicates with the RA 1621 during the enrollment. 1623 5.5.2.1 CA Certificate Only Response 1625 A binary X.509 CA certificate is sent back as a MIME object with a 1626 Content-Type of application/x-x509-ca-cert. 1628 5.5.2.2 CA and RA Certificates Response 1630 When an RA exists, both CA and RA certificates must be sent back in 1631 the response to the GetCACert request. The RA certificate(s) must be 1632 signed by the CA. A certificates-only PKCS#7 SignedData is used to 1633 carry the certificates to the requester, with a Content-Type of 1634 application/x-x509-ca-ra-cert. 1636 5.5.3 Get Next Certificate Authority Certificate 1638 5.5.3.1 GetNextCACert HTTP Message Format 1639 "GET" CGI-PATH CGI-PROG "?operation=GetNextCACert" "&message=" CA-IDENT 1641 The response to this message is a PKCS#7 certificates-only message containing 1642 a CA certificate (and possibly RA certificates) to be used when the current CA 1643 certificate expires. This PKCS#7 is signed by the old CA certificate. 1644 For GetNextCACert, a PKCS#7 is returned even in CA mode. 1646 5.5.3.2 GetCACaps HTTP Message Format 1647 "GET" CGI-PATH CGI-PROG "?operation=GetCACaps" "&message=" CA-IDENT 1649 This message requests capabilities from CA. The response is a list of 1650 text capabilities, as defined in Appendix F. Support for this message 1651 is optional, but if it is not supported, the client should assume that 1652 none of the capabilities in Appendix F are supported. 1654 5.6 Get Certificate Authority Certificate Chain 1656 GetCACertChain provides a way to get the entire certificate chain. 1658 5.6.1 GetCACertChain HTTP Message Format 1660 "GET" CGI-SCRIPT "?" "operation=GetCACertChain" "&" "message" CA-IDENT 1661 where CGI-SCRIPT and CA-IDENT are as described for GetCACert. 1663 5.6.2 Response 1665 The response for GetCACertChain is a certificates-only PKCS#7 SignedData 1666 to carry the certificates to the requester, with a Content-Type of 1667 application/x-x509-ca-ra-cert-chain. 1669 5.6.3 Backwards Compatability 1671 Versions of SCEP prior to revision 3 do not support GetCACertChain. 1672 Certificate Authorities written to these prior versions will not be 1673 able to process the message and may return an HTML error. 1675 To avoid this, clients should send the GetCACert message first. If the 1676 returned certificate is self-signed or is signed by a Certificate 1677 Authority that is trusted by the client, then it is not necessary to 1678 send the GetCACertChain message and it should not be sent. 1680 If a Certificate Authority is configured with a certificate that is 1681 not either self-signed or has a self-signed issuer, then it should 1682 support this message. In other words, it should be supported if the 1683 CA hierarchy is more than two-deep. 1685 An old CA in a two-deep hierarchy might still get this message from 1686 a client if the client did not trust either that CA or its issuer. 1687 In that event, the certificate cannot be trusted anyway. In any case 1688 the CA must not crash or hang upon the receipt of the message and the 1689 client must be able to handle whatever error is returned by the CA, 1690 including an HTML error or an ungraceful disconnect. 1692 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 1694 The following is the ASN.1 definition of Cert-Only PKCS#7: 1696 certOnly SignedData ::= { 1697 version 1 1698 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1699 digestAlgorithm(2) 5} 1701 contentInfo { 1702 contentType {pkcs-7 1} -- data content identifier 1703 content -- NULL 1704 } 1705 certificates -- the RA and CA certificates. 1706 } 1708 CARACerts PKIMessage ::= { -- special pki message sent in the clear 1709 contentType {pkcs-7 2} 1710 content certOnly 1711 } 1713 6.0 Security Considerations 1715 This entire document is about security. Common security considerations 1716 such as keeping private keys truly private and using adequate lengths 1717 for symmetric and asymmetric keys must be followed in order to maintain 1718 the security of this protocol. 1720 7.0 Intellectual Property 1722 This protcol includes the optional use of Certificate Revocation List 1723 Distribution Point (CRLDP) technology, which is a patented technology 1724 of Entrust Technologies, Inc. (Method for Efficient Management of 1725 Certificate Revocation Lists and Update Information (U.S. Patent 1726 5,699,431)). Please contact Entrust Technologies, Inc. 1727 (www.entrust.com) for more information on licensing CRLDP technology. 1729 8.0 References 1731 [PKCS7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1732 1.5", RFC 2315, March 1998. 1734 [PKCS10] Kaliski, B., "PKCS #10: Certification Request Syntax Version 1735 1.5", RFC 2314, March 1998. 1737 [RFC2459] Housley, R., ec. al., "Internet X.509 Public Key 1738 Infrastructure Certificate and CRL Profile", RFC 2459, January 1999. 1740 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 1742 Appendix A: Cisco Requester Subject Name Definition 1744 The ip address and the FQDN of a SCEP client should be included in the 1745 V3 extension subjectAltName. When the subjectAltName extension attribute 1746 is present, both the subjectAltName fields and the subjectName field could 1747 have the IP address and the FQDN information. 1749 When the X.500 directory is used by the CA to define the name space, the 1750 subject name defined above become a RDN which is part of DN binded to 1751 the requester's public key in the certificate. 1753 A sample of DN assigned by Entrust CA is given below (assume the same 1754 ciscoRouterAlice is used as the requester defined subject name): 1756 OU = InteropTesting, O = Entrust Technologies, C = CA 1757 RDN = {"alice.cisco.com", "172.21.114.67", "22334455"} 1758 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 1760 Appendix B: IPSEC Client Enrollment Certificate Request 1762 The following is the certificate enrollment request (PKCS#10) as created 1763 by Cisco VPN Client: 1765 -----END NEW CERTIFICATE REQUEST----- 1766 0 30 439: SEQUENCE { 1767 4 30 288: SEQUENCE { 1768 8 02 1: INTEGER 0 1769 11 30 57: SEQUENCE { 1770 13 31 55: SET { 1771 15 30 53: SEQUENCE { 1772 17 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 1773 22 13 46: PrintableString 1774 : 'For Xiaoyi, IPSEC attrs in alternate name 1775 extn' 1776 : } 1777 : } 1778 : } 1779 70 30 158: SEQUENCE { 1780 73 30 13: SEQUENCE { 1781 75 06 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1782 1 1) 1783 86 05 0: NULL 1784 : } 1785 88 03 140: BIT STRING 0 unused bits 1786 : 30 81 88 02 81 80 73 DB 1D D5 65 AA EF C7 D4 8E 1787 : AA 6E EB 46 AC 91 2A 0F 50 51 17 AD 50 A2 2A F2 1788 : CE BE F1 E4 22 8C D7 61 A1 6C 87 61 62 92 CB A6 1789 : 80 EA B4 0F 09 9D 18 5F 39 A3 02 0E DB 38 4C E4 1790 : 8A 63 2E 72 8B DC BE 9E ED 6C 1A 47 DE 13 1B 0F 1791 : 83 29 4D 3E 08 86 FF 08 2B 43 09 EF 67 A7 6B EA 1792 : 77 62 30 35 4D A9 0F 0F DF CC 44 F5 4D 2C 2E 19 1793 : E8 63 94 AC 84 A4 D0 01 E1 E3 97 16 CD 86 64 18 1794 : [ Another 11 bytes skipped ] 1795 : } 1796 231 A0 63: [0] { 1797 233 30 61: SEQUENCE { 1798 235 06 9: OBJECT IDENTIFIER extensionReq (1 2 840 113549 1 9 1799 14) 1800 246 31 48: SET { 1801 248 30 46: SEQUENCE { 1802 250 30 44: SEQUENCE { 1803 252 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 1804 257 04 37: OCTET STRING 1805 30 23 87 04 01 02 03 04 81 0D 65 6D 61 69 1806 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 1808 6C 40 69 72 65 2E 63 6F 6D 82 0C 66 71 64 1809 6E 2E 69 72 65 2E 63 6F 6D 1810 : } 1811 : } 1812 : } 1813 : } 1814 : } 1815 : } 1817 296 30 13: SEQUENCE { 1818 298 06 9: OBJECT IDENTIFIER md5withRSAEncryption (1 2 840 113549 1819 1 1 4) 1820 309 05 0: NULL 1821 : } 1822 311 03 129: BIT STRING 0 unused bits 1823 : 19 60 55 45 7F 72 FD 4E E5 3F D2 66 B0 77 13 9A 1824 : 87 86 75 6A E1 36 C6 B6 21 71 68 BD 96 F0 B4 60 1825 : 95 8F 12 F1 65 33 16 FD 46 8A 63 19 90 40 B4 B7 1826 : 2C B5 AC 63 17 50 28 F0 CD A4 F0 00 4E D2 DE 6D 1827 : C3 4F F5 CB 03 4D C8 D8 31 5A 7C 01 47 D2 2B 91 1828 : B5 48 55 C8 A7 0B DD 45 D3 4A 8D 94 04 3A 6C B0 1829 : A7 1D 64 74 AB 8A F7 FF 82 C7 22 0A 2A 95 FB 24 1830 : 88 AA B6 27 83 C1 EC 5E A0 BA 0C BA 2E 6D 50 C7 1831 : } 1833 Appendix C: Private OID Definitions 1835 The OIDs used in defining pkiStatus are VeriSign self-maintained 1836 OIDs. Please note, work is in progress to replace the VeriSign owned 1837 object identifiers with the standard object identifiers. Once the 1838 standarlization is completed, this documentation will be updated. 1840 id-VeriSign OBJECT_IDENTIFIER ::= {2 16 US(840) 1 VeriSign(113733)} 1841 id-pki OBJECT_IDENTIFIER ::= {id-VeriSign pki(1)} 1842 id-attributes OBJECT_IDENTIFIER ::= {id-pki attributes(9)} 1843 id-messageType OBJECT_IDENTIFIER ::= {id-attributes messageType(2)} 1844 id-pkiStatus OBJECT_IDENTIFIER ::= {id-attributes pkiStatus(3)} 1845 id-failInfo OBJECT_IDENTIFIER ::= {id-attributes failInfo(4)} 1846 id-senderNonce OBJECT_IDENTIFIER ::= {id-attributes senderNonce(5)} 1847 id-recipientNonce OBJECT_IDENTIFIER ::= {id-attributes recipientNonce(6)} 1848 id-transId OBJECT_IDENTIFIER ::= {id-attributes transId(7)} 1849 id-extensionReq OBJECT_IDENTIFIER ::= {id-attributes extensionReq(8)} 1850 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 1852 Appendix D: CRL Query by means of LDAP 1854 In order to retrieve the CRL by means of LDAP, the client needs to know 1855 where in the directory it is stored. The certificate must contain a 1856 CRL Distribution Point extension encoded as a DN or as an LDAP URI. 1858 For example, the certificate issued by Entrust VPN contains 1859 the following DN as the CRL distribution point: 1861 CN = CRL1, O = cisco, C = US. 1863 The asn.1 encoding of this distribution point is: 1865 30 2C 31 0B 30 09 06 03 55 04 06 13 02 55 53 31 0E 30 0C 06 1866 03 55 04 0A 13 05 63 69 73 63 6F 31 0D 30 0B 06 03 55 04 03 1867 13 04 43 52 4C 31 1869 The ldap form would be: 1871 ldap://servername/CN=CRL1,O=cisco,C=US 1873 Appendix E: SCEP State Transitions 1875 SCEP state transitions are based on transaction identifier. The design 1876 goal is to ensure the synchronization between the CA and the requester 1877 under various error situations. 1879 An identity is defined by the combination of FQDN, the IP address and 1880 the client serial number. FQDN is the required name attribute. It is 1881 important to notice that, a client named as Alice.cisco.com is different 1882 from the client named as Alice.cisco.com plus IPAddress 117.96.1.219. 1884 Each enrollment transaction is uniquely associated with a transaction 1885 identifier. Because the enrollment transaction could be interrupted by 1886 various errors, including network connection errors or client reboot, 1887 the SCEP client generates a transaction identifier by calculating MD5 1888 hash on the public key value for which the enrollment is requested. This 1889 retains the same transaction identifier throughout the enrollment 1890 transaction, even if the client has rebooted or timed out, and issues a 1891 new enrollment request for the same key pair. It also provides the way 1892 for the CA to uniquely identify a transaction in its database. At the 1893 requester side, it generates a transaction identifier which is included 1894 in PKCSReq. If the CA returns a response of PENDING, the requester 1895 will poll by periodically sending out GetCertInitial with the same 1896 transaction identifier until either a response other than PENDING is 1897 obtained, or the configured maximum time has elapsed. 1899 If the client times out or the client reboots, the client administrator 1900 will start another enrollment transaction with the same key pair. The 1901 second enrollment will have the transaction idenifier. At the server 1902 side, instead of accepting the PKCSReq as a new enrollment request, it 1903 should respond as if another GetCertInitial message had been sent with 1904 that transaction ID. In another word, the second PKCSReq should be 1905 taken as a resynchronization message to allow the enrollment resume as 1906 the same transaction. 1908 It is important to keep the transaction id unique since SCEP requires the 1909 same policy and same identity be applied to the same subject name and 1910 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 1912 key pair binding. In the current implementation, an SCEP client can 1913 only assume one identity. At any time, only one key pair, with a given 1914 key usage, can be associated with the same identity. 1916 The following gives several examples of client to CA transactions. 1918 Client actions are indicated in the left column, CA actions are 1919 indicated in the right column. A blank action signifies that no message 1920 was received. Note that these examples assume that the CA enforces the 1921 certificate-name uniqueness property defined in Section 2.1.1.1. 1923 The first transaction, for example, would read like this: 1924 "Client Sends PKCSReq message with transaction ID 1 to the 1925 CA. The CA signs the certificate and constructs a CertRep Message 1926 containing the signed certificate with a transaction ID 1. The client 1927 receives the message and installs the cert locally." 1929 Successful Enrollment Case: no manual authentication 1930 PKCSReq (1) ----------> CA Signs Cert 1931 Client Installs Cert <---------- CertRep (1) SIGNED CERT 1933 Successful Enrollment Case: manual authentication required 1934 PKCSReq (10) ----------> Cert Request goes into Queue 1935 Client Polls <---------- CertRep (10) PENDING 1936 GetCertInitial (10) ----------> Still pending 1937 Client Polls <---------- CertRep (10) PENDING 1938 GetCertInitial (10) ----------> Still pending 1939 Client Polls <---------- CertRep (10) PENDING 1940 GetCertInitial (10) ----------> Still pending 1941 Client Polls <---------- CertRep (10) PENDING 1942 GetCertInitial (10) ----------> Cert has been signed 1943 Client Installs Cert <---------- CertRep (10) SIGNED CERT 1945 Resync Case - CA Receive and Signs PKCSReq, Client Did not receive 1946 CertRep: 1948 PKCSReq (3) ----------> Cert Request goes into queue 1949 <---------- CertRep (3) PENDING 1950 GetCertInitial (3) ----------> 1951 <---------- CertRep (3) PENDING 1952 GetCertInitial (3) -----------> 1953 <----------- CA signed Cert and sent back 1954 CertRep(3) 1955 (Time Out) 1956 PKCSReq (3) ----------> Cert already signed, sent back to 1957 client 1958 Client Installs Cert <---------- CertRep (3) SIGNED CERT 1959 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 1961 Case when NVRAM is lost and client has to generate a new key pair, there 1962 is no change of name information: 1964 PKCSReq (4) ----------> CA Signs Cert 1965 Client Installs Cert <---------- CertRep (4) SIGNED CERT 1966 (Client looses Cert) 1967 PKCSReq (5) ----------> There is already a valid cert with 1968 this DN. 1969 Client Admin Revokes <---------- CertRep (5) OVERLAPPING CERT ERROR 1970 PKCSReq (5) ----------> CA Signs Cert 1971 Client Installs Cert <---------- CertRep (5) SIGNED CERT 1973 Case when client admin resync the enrollment using a different PKCS#10: 1974 PKCSReq (6) ----------> CA Signs Cert 1975 <---------- CertRep (6) SIGNED CERT 1976 (Client timeout and admin starts another enrollment with a different 1977 PKCS#10, but the same transaction id) 1978 PKCSReq (6) with different PKCS#10 1979 ----------> There is already a valid cert with 1980 this entity (by checking FQDN). 1981 <---------- CertRep (6) INVALID PKCS#10 CERT 1982 ERROR 1983 Client admin either revokes the existing cert 1984 or corrects the error by enrolling with 1985 the same PKCS#10 as the first PKCSReq(6) 1986 PKCSReq (6) ----------> CA find the existing Cert 1987 Client Installs Cert <---------- CertRep (6) SIGNED CERT 1989 Resync case when server is slow in response: 1990 PKCSReq (13) ----------> Cert Request goes into Queue 1991 <---------- CertRep (13) PENDING 1992 GetCertInitial ----------> Still pending 1993 <---------- CertRep (13) PENDING 1994 GetCertInitial ----------> Still pending 1995 <---------- CertRep (13) PENDING 1996 GetCertInitial ----------> Still pending 1997 <---------- CertRep (13) PENDING 1998 GetCertInitial ----------> Still pending 1999 (TimeOut) <---------- CertRep (13) PENDING 2000 * Case 1 2001 PKCSReq (13) ----------> Still pending 2002 Client polls <---------- CertRep (13) PENDING 2003 CertCertInitial ----------> Cert has been signed 2004 Client Installs Cert <---------- CertRep (13) SIGNED CERT 2005 * Case 2 2006 PKCSReq (13) ----------> Cert has been signed 2007 Client Installs Cert <---------- CertRep (13) SIGNED CERT 2008 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 2010 Appendix F. CA Capabilities 2012 The response for a GetCACaps message is a list of CA capabilities, in 2013 plain text, separated by characters, as follows (quotation marks 2014 are NOT sent): 2016 Keyword Description 2018 "GetNextCACert" CA Supports the GetNextCACert message. 2019 "POSTPKIOperation" PKIOPeration messages may be sent via HTTP POST. 2021 A client must be able to accept and ignore any unknown keywords that 2022 might be sent back by a CA that implements a future version of SCEP. 2024 Example: 2026 GET /cgi-bin/pkiclient.exe?operation=GetCACaps&message=myca 2028 returns: 2030 GetNextCACert 2031 POSTPKIOperation 2033 This means that the CA supports the GetNextCACert message and allows 2034 PKIOperation messages (PKCSreq, GetCert, GetCertInitial...) to be sent 2035 using HTTP POST. 2037 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 2039 Appendix G. Certificate Renewal and CA Key Rollover 2041 To renew a client certificate, use the PKCSreq message and sign it with 2042 the existing client certificate instead of a self-signed certificate. 2044 To obtain the new CA certificate prior to the expiration of the current 2045 one, use the GetNextCACert message if the CA supports it. 2047 To obtain a new client certificate signed by the new CA certificate, 2048 use the new CA or RA certificate in the message envelope. 2050 Example: 2052 GetNextCACert ----------> 2053 <---------- CertRep (3) New CA certificate 2055 PKCSReq* (1) ----------> CA Signs certificate with NEW key 2056 Client Stores Cert <---------- CertRep (3) Certificate issued 2057 for installation when from NEW CA certificate and keypair. 2058 existing cert expires. 2060 *enveloped for new CA or RA cert and keypair. The CA will use the 2061 envelope to determine which key and certificate to use to issue the 2062 client certificate. 2064 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 2066 Appendix H. PKIOperation via HTTP POST Message 2068 If the remote CA supports it, any of the PKCS#7-encoded SCEP messages 2069 may be sent via HTTP POST instead of HTTP GET. This is allowed for 2070 any SCEP message except GetCACert, GetCACertChain, GetNextCACert, 2071 or GetCACaps. In this form of the message, Base 64 encoding is not 2072 used. 2074 POST /cgi-bin/pkiclient.exe?operation=PKIOperation 2075 2077 The client can verify that the CA supports SCEP messages via POST by 2078 looking for the "POSTPKIOperation" capability (See Appendix F). 2080 Cisco Systems' Simple Certificate Enrollment Protocol June 2004 2082 Appendix Y. Author Contact Information 2084 Xiaoyi Liu Cheryl Madson 2085 Cisco Cisco 2086 510 McCarthy Drive 510 McCarthy Drive 2087 Milpitas, CA Milpitas, CA. 2088 xliu@cisco.com cmadson@cisco.com 2090 David McGrew Andrew Nourse 2091 Cisco Cisco 2092 170 West Tasman Drive 510 McCarthy Drive 2093 San Jose, CA 94134 Milpitas, CA. 2094 mcgrew@cisco.com nourse@cisco.com 2096 Appendix Z. Copyright Section 2098 Copyright (C) The Internet Society (2000). All Rights Reserved. 2100 This document and translations of it may be copied and furnished 2101 to others, and derivative works that comment on or otherwise 2102 explain it or assist in its implmentation may be prepared, copied, 2103 published and distributed, in whole or in part, without 2104 restriction of any kind, provided that the above copyright notice 2105 and this paragraph are included on all such copies and derivative 2106 works. However, this document itself may not be modified in any 2107 way, such as by removing the copyright notice or references to the 2108 Internet Society or other Internet organizations, except as needed 2109 for the purpose of developing Internet standards in which case the 2110 procedures for copyrights defined in the Internet Standards 2111 process must be followed, or as required to translate it into 2112 languages other than English. 2114 The limited permissions granted above are perpetual and will not 2115 be revoked by the Internet Society or its successors or assigns. 2117 This document and the information contained herein is provided on 2118 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 2119 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 2120 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2121 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2122 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2124 This draft expires 29 Dec 2004 2126 [End of draft-nourse-scep-10.txt]