idnits 2.17.1 draft-nourse-scep-18.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (January 21, 2009) is 5573 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CERT-NONEXISTANT' is mentioned on line 672, but not defined == Missing Reference: 'CERT-REQ-PENDING' is mentioned on line 672, but not defined == Missing Reference: 'CERT-ISSUED' is mentioned on line 672, but not defined -- Looks like a reference, but probably isn't: '0' on line 1581 ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Nourse 3 Internet-Draft X. Liu 4 Intended status: Informational J. Vilhuber 5 Expires: July 25, 2009 C. Madson 6 Cisco Systems, Inc. 7 January 21, 2009 9 Cisco Systems' Simple Certificate Enrollment Protocol 10 draft-nourse-scep-18 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on July 25, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Abstract 49 This document specifies the Simple Certificate Enrollment Protocol, a 50 PKI communication protocol which leverages existing technology by 51 using PKCS#7 and PKCS#10. SCEP is the evolution of the enrollment 52 protocol developed by Verisign, Inc. for Cisco Systems, Inc. It now 53 enjoys wide support in both client and CA implementations. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 59 2. The Goal of SCEP . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.1. SCEP Entity Types . . . . . . . . . . . . . . . . . . . . 6 61 2.1.1. Requesters . . . . . . . . . . . . . . . . . . . . . . 6 62 2.1.1.1. Local Key/Certificate/CRL Storage and 63 Certificate-name uniqueness . . . . . . . . . . . 7 64 2.1.1.2. Requester authentication . . . . . . . . . . . . . 8 65 2.1.1.3. Requester Uses Existing CA-Issued or 66 Self-Signed Certificates . . . . . . . . . . . . . 9 67 2.1.1.4. Trusted CA Store . . . . . . . . . . . . . . . . . 10 68 2.1.2. Certificate Authority . . . . . . . . . . . . . . . . 10 69 2.1.3. Registration Authorities . . . . . . . . . . . . . . . 11 70 2.2. SCEP Operations Overview . . . . . . . . . . . . . . . . . 11 71 2.2.1. Requester Initialization . . . . . . . . . . . . . . . 11 72 2.2.1.1. RSA Key Pairs . . . . . . . . . . . . . . . . . . 11 73 2.2.1.2. non-RSA Keys . . . . . . . . . . . . . . . . . . . 11 74 2.2.1.3. Required Information . . . . . . . . . . . . . . . 11 75 2.2.2. CA/RA Certificate Distribution . . . . . . . . . . . . 12 76 2.2.3. Certificate Enrollment . . . . . . . . . . . . . . . . 12 77 2.2.4. Requester Certificate Revocation . . . . . . . . . . . 13 78 2.2.5. Certificate Access . . . . . . . . . . . . . . . . . 14 79 2.2.6. CRL Distribution . . . . . . . . . . . . . . . . . . . 14 80 2.3. PKI Operation Transactional Behavior . . . . . . . . . . . 15 81 2.3.1. Transaction Identifier . . . . . . . . . . . . . . . . 15 82 2.3.2. State Transitions in Certificate Enrollment . . . . . 15 83 2.3.3. Transaction Behavior of Certificate/CRL Access . . . . 16 84 2.4. Security . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 3. Transport Protocol . . . . . . . . . . . . . . . . . . . . . . 17 86 3.1. HTTP "GET" and "POST" Message Format . . . . . . . . . . . 18 87 3.2. Response Message Format . . . . . . . . . . . . . . . . . 19 88 4. Secure Transportation: PKCS#7 . . . . . . . . . . . . . . . . 20 89 4.1. SCEP Message Format . . . . . . . . . . . . . . . . . . . 20 90 4.1.1. SCEP pkcsPKIEnvelope . . . . . . . . . . . . . . . . . 20 91 4.1.2. SCEP pkiMessage type . . . . . . . . . . . . . . . . . 21 92 4.2. Signed Transaction Attributes . . . . . . . . . . . . . . 21 93 4.2.1. transactionID . . . . . . . . . . . . . . . . . . . . 22 94 4.2.2. messageType . . . . . . . . . . . . . . . . . . . . . 22 95 4.2.3. pkiStatus . . . . . . . . . . . . . . . . . . . . . . 22 96 4.2.4. failInfo . . . . . . . . . . . . . . . . . . . . . . . 23 97 4.2.5. senderNonce and responderNonce . . . . . . . . . . . . 23 98 5. SCEP Transaction Specification . . . . . . . . . . . . . . . . 23 99 5.1. Certificate Enrollment . . . . . . . . . . . . . . . . . . 23 100 5.1.1. PKCSReq Message Format . . . . . . . . . . . . . . . . 24 101 5.1.2. CertRep Message Format . . . . . . . . . . . . . . . . 24 102 5.1.2.1. PENDING Response . . . . . . . . . . . . . . . . . 25 103 5.1.2.2. FAILURE Response . . . . . . . . . . . . . . . . . 25 104 5.1.2.3. SUCCESS response . . . . . . . . . . . . . . . . . 25 105 5.2. Poll for Requester Initial Certificate . . . . . . . . . . 25 106 5.2.1. GetCertInitial Message Format . . . . . . . . . . . . 26 107 5.2.2. GetCertInitial Response Message Format . . . . . . . . 26 108 5.3. Certificate Access . . . . . . . . . . . . . . . . . . . . 26 109 5.3.1. GetCert Message Format . . . . . . . . . . . . . . . . 27 110 5.3.2. CertRep Message Format . . . . . . . . . . . . . . . . 27 111 5.4. CRL Access . . . . . . . . . . . . . . . . . . . . . . . . 28 112 5.4.1. GetCRL Message format . . . . . . . . . . . . . . . . 28 113 5.4.2. CertRep Message Format . . . . . . . . . . . . . . . . 28 114 5.5. Get Certificate Authority Certificate . . . . . . . . . . 29 115 5.5.1. GetCACert HTTP Message Format . . . . . . . . . . . . 29 116 5.5.2. Response . . . . . . . . . . . . . . . . . . . . . . . 29 117 5.5.2.1. CA Certificate Only Response . . . . . . . . . . . 29 118 5.5.2.2. CA and RA Certificates Response . . . . . . . . . 30 119 5.5.3. Get Next Certificate Authority Certificate . . . . . . 30 120 5.5.3.1. GetNextCACert HTTP Message Format . . . . . . . . 30 121 5.5.3.2. GetCACaps HTTP Message Format . . . . . . . . . . 30 122 5.6. Get Certificate Authority Certificate Chain . . . . . . . 30 123 5.6.1. GetCACertChain HTTP Message Format . . . . . . . . . . 30 124 5.6.2. Response . . . . . . . . . . . . . . . . . . . . . . . 30 125 5.6.3. Backwards Compatibility . . . . . . . . . . . . . . . 31 126 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 127 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 128 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 129 8.1. General Security . . . . . . . . . . . . . . . . . . . . . 31 130 8.2. Use of the CA keypair . . . . . . . . . . . . . . . . . . 31 131 8.3. ChallengePassword . . . . . . . . . . . . . . . . . . . . 32 132 8.4. transactionID . . . . . . . . . . . . . . . . . . . . . . 32 133 8.5. Unnecessary cryptography . . . . . . . . . . . . . . . . . 32 134 9. Intellectual Property . . . . . . . . . . . . . . . . . . . . 33 135 10. Normative References . . . . . . . . . . . . . . . . . . . . . 33 136 Appendix A. Cisco Requester Subject Name Definition . . . . . . . 34 137 Appendix B. IPSEC Client Enrollment Certificate Request . . . . . 34 138 Appendix C. Private OID Definitions . . . . . . . . . . . . . . . 36 139 Appendix D. CRL Query by means of LDAP . . . . . . . . . . . . . 36 140 Appendix E. SCEP State Transitions . . . . . . . . . . . . . . . 37 141 Appendix F. CA Capabilities . . . . . . . . . . . . . . . . . . . 40 142 Appendix G. Certificate Renewal and CA Key Rollover . . . . . . . 41 143 Appendix H. PKIOperation via HTTP POST Message . . . . . . . . . 41 144 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 146 1. Introduction 148 Public key technology is widely available and increasingly widely 149 deployed. X.509 certificates serve as the basis for several 150 standards-based security protocols in the IETF, such as IKE [RFC2409] 151 and IKEv2 [RFC4306], and TLS [RFC4346]. When an X.509 certificate is 152 issued by other than the certificate subject (a self-issued 153 certificate), there typically is a need for a certificate management 154 protocol. Such a protocol enables a PKI client to request a 155 certificate, certificate renewal, or certificate revocation from a 156 Certification Authority. Often there also is a need for protocols to 157 request a certificate or cert status info, although these functions 158 are often provided by distinct protocols, e.g., LDAP for X509 159 [RFC4523] or OCSP [RFC2560]. 161 This specification defines a protocol, SCEP, for certificate 162 management and certificate and CRL queries in a closed environment. 163 While widely deployed, this protocol omits some certificate 164 management features, e.g., in-band certificate revocation 165 transactions, that can significantly enhance the security achieved in 166 a PKI. The IETF protocol suite currently includes two certificate 167 management protocols with more comprehensive functionality: CMP 168 [RFC4210] and Certificate Management over CMS [RFC5272]. Where 169 interoperability with the installed base of SCEP implementations is 170 required, implementers are encouraged to support a comprehensive 171 standards track certificate management protocol in addition to the 172 protocol defined in this specification. This implementation strategy 173 balances near term requirements for interoperability with longer term 174 security goals. 176 1.1. Requirements Language 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in [RFC2119]. 182 2. The Goal of SCEP 184 The goal of SCEP is to support the secure issuance of certificates to 185 network devices in a scalable manner, using existing technology 186 whenever possible. The protocol supports the following operations: 188 o CA and RA public key distribution 190 o Certificate enrollment 191 o Certificate query 193 o CRL query 195 Certificate and CRL access can be achieved by using the LDAP protocol 196 (as specified in Appendix D), or by using the query messages defined 197 in SCEP. The use of HTTP certificate and CRL access, and the support 198 of CDP as specified in [RFC5280], is outside the scope of this 199 document. In Section Section 2.1, we first define PKI entity types 200 as well as the properties of each entity type. In Section 201 Section 2.2, the PKI operations are described at functional level. 202 Section Section 2.3 describes the transaction behavior of each PKI 203 operations. The complete PKI messages are covered in Section 204 Section 5. 206 2.1. SCEP Entity Types 208 The entity types defined in SCEP are the "requester" type (i.e., 209 IPSEC clients), the Certificate Authority (CA) entity type, and the 210 Registration Authority entity type (RA). A requester is sometimes 211 called a "SCEP client" in the following. 213 2.1.1. Requesters 215 A requester is an entity whose name is defined in a certificate 216 subject name field and optionally, in SubjectAltName, a X.509 217 certificate V3 extension. As a requester, a SCEP client is 218 identified by a subject name consisting of the following naming 219 attributes: 221 o Fully qualified domain name, for example, Router.cisco.com, 223 o IP Address, 225 o Serial number, and/or 227 o x.500 distinguished name. 229 The fully qualified domain name is required for a requester that 230 intends to use the certificate with, for example, IKE [RFC2409]. The 231 IP address, serial number, and x.500 distinguished name are optional 232 name attributes. 234 In the certificate enrollment request, the PKCS#10 [RFC2986] subject 235 field contains the required and optional name attributes. The 236 distinguished name, if any, should be the subject name field, while 237 any domain name, serial number, or IP address supplied should be in 238 the subjectAltName field. The subjectName field may be empty (if 239 there is no distinguished name) or the subjectAltName may be omitted, 240 but not both. 242 It is important to note that a client named as Alice.cisco.com is 243 different than a client named as "Alice.cisco.com+192.0.2.4" (read 244 Alice.cisco.com plus the IP address name attribute 192.0.2.4). From 245 a CA point of view, the Distinguished names assigned in these two 246 cases are distinct names. 248 Entity names which are specified as in the IPSEC profile (i.e., FQDN, 249 IP address and User FQDN) must be presented in the certificate's 250 SubjectAltName extension. Multiple IPSEC entity names, (if any) are 251 encoded as multiple values of a single SubjectAltName extension. The 252 CA has the authority to assign a distinguished name to a requester, 253 whether or not one was included in the request. The assigned DN 254 should contain the SCEP client names as the relative DN. 256 The attribute identifiers and an example of SCEP client subject name 257 are specified in Appendix A. Appendix B has an example from Cisco 258 VPN Client enrollment request. 260 2.1.1.1. Local Key/Certificate/CRL Storage and Certificate-name 261 uniqueness 263 A requester is required to generate, and provide storage for, 264 asymmetric keypairs. If the requester does not have enough permanent 265 memory to save its certificate, then it should be able to query its 266 own certificate from the CA or an LDAP server, once the certificate 267 has been issued. 269 A keypair can be generated with a specific key usage. The key usage 270 is conveyed to the CA through the certificate enrollment request. 271 All current SCEP client implementations expect that there will be 272 only one keypair for a given subjectName and key usage combination 273 and CA, at any time. This property is called the certificate-name 274 uniqueness property, and it implies that a CA that implements SCEP 275 will enforce the unique mapping between a SCEP client subject name 276 and its keypairs with a given key usage. At any time, if the subject 277 name is changed, or if the keypair is updated, the existing 278 certificate would have to be revoked before a new one could be 279 issued. 281 It is desirable that the CA enforce certificate-name uniqueness, but 282 it is not mandatory. However a CA that does not enforce uniqueness 283 must provide some other mechanism to prevent the re-transmission of 284 an enrollment request by a SCEP client from creating a second 285 certificate or certificate request, nor can the second request merely 286 be rejected. If a client times out from polling for a pending 287 request it can resynchronize by reissuing the original request with 288 the original subject name, key, and transaction ID. This should 289 return the status of the original transaction, including the 290 certificate if it was granted. It should not create a new 291 transaction unless the original certificate has been revoked, or the 292 transaction arrives more than halfway through the validity time of 293 the original certificate. 295 An enrollment request that occurs more than halfway through the 296 validity time of an existing certificate for the same subjectName and 297 key usage MAY be interpreted as a re-enrollment or renewal request 298 and accepted. A new certificate with new validity dates may be 299 issued, even though the old one is still valid, if the CA policy 300 permits, as described in Section 2.1.1.3. See also Appendix G. 302 2.1.1.2. Requester authentication 304 As with every protocol that uses public-key cryptography, the 305 association between the public keys used in the protocol and the 306 identities with which they are associated must be authenticated in a 307 cryptographically secure manner. This requirement is needed to 308 prevent a "man in the middle" attack, in which an adversary can 309 manipulate the data as it travels between the protocol participants 310 and subvert the security of the protocol. 312 PKCS#10 [RFC2986] specifies the use of a ChallengePassword attribute 313 to be sent as part of the enrollment request. SCEP uses this 314 ChallengePassword to satisfy the above requirements for security. 315 The PKCS#7 [RFC2315] envelope protects the privacy of the challenge 316 password. 318 2.1.1.2.1. Manual enrollment authentication 320 In the manual mode, the requester is required to wait until its 321 identity can be verified by the CA operator using any reliable out- 322 of-band method. To prevent a "man-in-the-middle" attack, a SHA-1, 323 SHA-256, SHA-512, or MD5 `fingerprint' generated on the PKCS#10 324 [RFC2986] (before PKCS#7 [RFC2315] enveloping and signing) SHOULD be 325 compared out-of-band between the CA operator and the requester. SCEP 326 clients and CAs (or RAs, if appropriate) MUST display this 327 fingerprint to the operator to enable this verification if manual 328 mode is used. Failing to provide this information leaves the 329 protocol vulnerable to attack by sophisticated adversaries. 331 In this case the challenge password is only used to authenticate a 332 request for the certificate's revocation. 334 2.1.1.2.2. Automated enrollment authentication 336 When utilizing a pre-shared secret scheme, the server should 337 distribute a shared secret to the requester which can uniquely 338 associate the enrollment request with the given end entity. The 339 distribution of the secret must be private: only the end entity 340 should know this secret. The actual binding mechanism between the 341 requester and the secret is subject to the server policy and 342 implementation. 344 When using the pre-shared secret scheme, the requester must enter the 345 pre-distributed secret as the ChallengePassword. It can then also be 346 used to authenticate a request for the certificate's revocation. 348 2.1.1.3. Requester Uses Existing CA-Issued or Self-Signed Certificates 350 In this protocol, the communication between the requester and the 351 certificate authority is secured by using PKCS#7 [RFC2315] as the 352 messaging protocol (see Section 4). PKCS#7 [RFC2315], however, is a 353 data format which assumes the communicating entities already possess 354 the peer's certificates and requires both parties use the issuer 355 names and issuer assigned certificate serial numbers to identify the 356 certificate in order to verify the signature and decrypt the message. 358 o If the requesting system already has a certificate issued by the 359 CA, that certificate SHOULD be presented as credentials for the 360 renewal of that certificate if the CA supports the "Renewal" 361 capability and the CA policy permits the certificate to be 362 renewed. 364 o If the requesting system has no certificate issued by the CA, but 365 has credentials from a different CA, that certificate MAY be 366 presented as credentials instead of a self-signed certificate. 367 Policy settings on the SCEP server will determine if the request 368 can be accepted or not. 370 o If the requester does not have an appropriate existing 371 certificate, then a self signed certificate must be used instead. 372 The self signed certificate MUST use the same subjectName as in 373 the pkcs10 request. 375 During the certificate enrollment, the requester will attach the 376 appropriate certificate to the signed certificate request. 378 When the Certificate Authority creates the PKCS#7 envelope on the 379 issued certificate, it should use the public key, issuer name, and 380 serial number conveyed in the above included certificate (from the 381 SignerInfo section of the inner pkcs#7 of the request). This will 382 inform the end entity on which private key should be used to open the 383 envelope. Note that when a client enrolls for separate encryption 384 and signature certificates, it may use the signature certificate to 385 sign both requests, and then expect its signature key to be used to 386 encrypt both responses. 388 In any case, the recipientInfo on the envelope should reflect the key 389 used to encrypt the request. 391 2.1.1.4. Trusted CA Store 393 To support interoperability between IPSEC peers whose certificates 394 are issued by different CAs, SCEP allows the users to configure 395 multiple trusted certificates. Trusted certificates are configured 396 as such in the client, based on some out-of-band means such as a 397 "fingerprint". These trusted certificates are used to verify 398 certificate chains that end in those certificates. 400 2.1.2. Certificate Authority 402 A Certificate Authority(CA) is an entity whose name is defined in the 403 certificate issuer name field. Before any PKI operations can begin, 404 the CA generates its own public key pair and creates a self-signed CA 405 certificate, or causes another CA to issue a certificate to it. 406 Associated with the CA certificate is a fingerprint which will be 407 used by the requester to authenticate the received CA certificate if 408 it is self-signed. The fingerprint is created by calculating a 409 SHA-1, SHA-256, SHA-512, or MD5 hash on the whole CA certificate. 410 Before any requester can start its enrollment, this CA certificate 411 has to be configured at the entity side securely. For IPSEC clients, 412 the client certificates must have SubjectAltName extension. To 413 utilize LDAP as a CRL query protocol, the certificates must have a 414 CRL Distribution Point. Key usage is optional. Without key usage, 415 the public key is assumed as a general purpose public key and it can 416 be used for all purposes. 418 A Certificate Authority may enforce certain name policy. When using 419 a X.500 directory name as the subject name, all the name attributes 420 specified in the PKCS#10 [RFC2986] request should be included as 421 Relative DN. All the name attributes as defined in [RFC5280] should 422 be specified in the SubjectAltName. An example is provided in 423 Appendix A. 425 If there is no LDAP or HTTP query protocol support, the Certificate 426 Authority itself should answer certificate and CRL queries, and to 427 this end it should be online all the time. 429 The updating of the CA's public key is addressed in Appendix G. 431 2.1.3. Registration Authorities 433 In an environment where an RA is present, a requester performs 434 enrollment through the RA. In order to setup a secure channel with 435 an RA using PKCS#7 [RFC2315], the RA certificate(s) have to be 436 obtained by the client in addition to the CA certificate(s). 438 In the following, the CA and RA are specified as one entity in the 439 context of PKI operation definitions. 441 2.2. SCEP Operations Overview 443 In this section, we give a high level overview of the PKI operations 444 as defined in SCEP. 446 2.2.1. Requester Initialization 448 The requester initialization includes the key pair generation and the 449 configuring of the required information to communicate with the 450 certificate authority. 452 2.2.1.1. RSA Key Pairs 454 Before a requester can start a PKI transaction, it must have at least 455 one RSA key pair. 457 Key pairs may be intended for particular purposes, such as encryption 458 only, or signing only. The usage of any associated certificate can 459 be restricted by adding key usage and extended key usage attributes 460 to the PKCS#10 [RFC2986]. 462 2.2.1.2. non-RSA Keys 464 SCEP does not support non-RSA keys. Though the protocol (being based 465 on PKCS#7) does not preclude them, RSA is the only algorithm 466 supported by current implementations. 468 2.2.1.3. Required Information 470 A requester is required to have the following information configured 471 before starting any PKI operations: 473 1. the certificate authority IP address or fully-qualified domain 474 name, 476 2. the certificate authority HTTP CGI script path, 477 3. the HTTP proxy information if there is no direct Internet 478 connection to the server, 480 4. If CRLs are being published by the CA to an LDAP directory 481 server, and there is a CRL Distribution Point containing only an 482 X.500 directory name, then the client will need to know the LDAP 483 server fully-qualified domain name or IP address. CRL 484 Distribution Points are discussed in more detail in [RFC5280]. 486 2.2.2. CA/RA Certificate Distribution 488 Before any PKI operation can be started, the requester needs to get 489 the CA/RA certificates. At this time, since no public key has been 490 exchanged between the requester and the CA/RA, the message to get the 491 CA/RA certificate cannot be secured using PKCS#7 [RFC2315]. Instead, 492 the CA/RA certificate distribution is implemented as a clear HTTP Get 493 operation. After the requester gets the CA certificate, it has to 494 authenticate the CA certificate by comparing the finger print with 495 the CA/RA operator out-of-band. Since the RA certificates are signed 496 by the CA, there is no need to authenticate the RA certificates. 498 This operation is defined as a transaction consisting of one HTTP Get 499 message and one HTTP Response message: 500 REQUESTER CA SERVER 501 Get CA/RA Certificate: HTTP Get message 502 -----------------------------> 503 CA/RA Certificate download: HTTP Response message 504 <--------------------------------------- 505 Compute finger print and 506 call CA operator. 507 Receive call and check finger print 509 Get CA/RA Certificate 511 If an RA is in use, a degenerated PKCS#7 [RFC2315] with a certificate 512 chain consisting of both RA and CA certificates is sent back to the 513 end entity. Otherwise the CA certificate is directly sent back as 514 the HTTP response payload. 516 2.2.3. Certificate Enrollment 518 A requester starts an enrollment transaction by creating a 519 certificate request using PKCS#10 [RFC2986] and sends it to the CA/RA 520 enveloped using the PKCS#7 [RFC2315]. After the CA/RA receives the 521 request, it will either automatically approve the request and send 522 the certificate back, or it will require the requester to wait until 523 the operator can manually authenticate the identity of the requester. 525 In the automatic mode, the transaction consists of one PKCSReq PKI 526 Message, and one CertRep PKI message. 528 In the manual mode, the requester enters into polling mode by 529 periodically sending a GetCertInitial PKI message to the server, 530 until the server operator completes the manual authentication, after 531 which the CA will respond to GetCertInitial by returning the issued 532 certificate. 534 It is up to local CA policy (and CA implementation) as to whether a 535 certificate is granted automatically, or whether it is manually 536 granted by the administrator. The ChallengePassword MAY be used to 537 automatically authenticate the request, but does not have to. 539 Polling mode is entered whenever the server returns a PENDING 540 response. 542 The transaction in automatic mode: 543 REQUESTER CA SERVER 545 PKCSReq: PKI cert. enrollment msg 546 --------------------------------> CertRep: pkiStatus = SUCCESS 547 certificate attached 548 <------------------------------ 549 Receive issued certificate. 551 The transaction in manual mode: 552 REQUESTER CA SERVER 553 PKCSReq: PKI cert. enrollment msg 554 --------------------------------> CertRep: pkiStatus = PENDING 555 <------------------------------ 556 GetCertInitial: polling msg 557 --------------------------------> CertRep: pkiStatus = PENDING 558 <------------------------------ 559 ................. CertRep: pkiStatus = SUCCESS 563 certificate attached 564 <------------------------------ 565 Receive issued certificate. 567 2.2.4. Requester Certificate Revocation 569 SCEP currently only allows revocation as an out-of-band process. In 570 order to revoke a certificate, the requester must contact the CA 571 server operator, who MAY wish to verify the ChallengePassword (which 572 has been sent to the server as an attribute of the PKCS#10 [RFC2986] 573 certificate request). If the ChallengePassword matches, the 574 certificate can be revoked. 576 2.2.5. Certificate Access 578 There are two methods to query certificates. The first method is to 579 use LDAP as a query protocol. Using LDAP to query assumes the client 580 understand the LDAP scheme supported by the CA. The SCEP client 581 assumes that the subject DN name in the certificate is used as the 582 URL to query the certificate. The standard attributes 583 (userCertificate and caCertificate) are used as filter. 585 For the environment where LDAP is not available, a certificate query 586 message is defined to retrieve the certificates from the CA. 588 To query a certificate from the certificate authority, a requester 589 sends a request consisting of the certificate's issuer name and the 590 serial number. This assumes that the requester has saved the issuer 591 name and the serial number of the issued certificate from the 592 previous enrollment transaction. The transaction to query a 593 certificate consists of one GetCert PKI message and one CertRep PKI 594 message: 595 REQUESTER CA SERVER 596 GetCert: PKI certificate query msg 597 -------------------------------> CertRep: pkiStatus = SUCCESS 598 certificate attached 599 <----------------------------- 600 Receive the certificate. 602 2.2.6. CRL Distribution 604 The CA/RA will not "push" the CRL to the end entities. The query of 605 the CRL can only be initialized by the requester. 607 There are two methods to query CRL: 609 1. If the CA supports CRL Distribution Points [RFC5280] (section 610 4.2.1.13), then the CRL MUST be retrieved via the mechanism 611 specified in the CDP. This is the preferred method. Please 612 refer to Appendix D for the examples of CRL Distribution Point. 614 2. If the CA does not support CDP's, a CRL query is composed by 615 creating a message consisting of the CA issuer name and the CA's 616 certificate serial number. This method is deprecated because it 617 does not scale well and requires the CA to be a high-availability 618 service. 620 The message is sent to the CA in the same way as the other SCEP 621 requests: The transaction to query CRL consists of one GetCRL PKI 622 message and one CertRep PKI message which contain only the CRL (no 623 certificates). 625 REQUESTER CA SERVER 626 GetCRL: PKI CRL query msg 627 ----------------------------------> 628 CertRep: CRL attached 629 <-------------------------------- 631 2.3. PKI Operation Transactional Behavior 633 As described before, a PKI operation is a transaction consisting of 634 the messages exchanged between a requester and the CA/RA. This 635 section will specify the transaction behavior on both the requester 636 and the certificate authority server. Because the protocol is 637 basically a two way communication protocol without a confirmation 638 message from the initiating side, state and state resynchronization 639 rules have to be defined, in case any error happens at either side. 640 Before the state transition can be defined, the notion of transaction 641 identifier has to be defined first. 643 2.3.1. Transaction Identifier 645 A transaction identifier is a string generated by the entity when 646 starting a transaction. Since all the PKI operations defined in this 647 protocol are initiated by the requester, it is the responsibility of 648 the requester to generate a unique string as the transaction 649 identifier. All the PKI messages exchanged for a given PKI 650 transaction must carry the same transaction identifier. 652 The transaction identifier is generated as a SHA-1, SHA-256, SHA-512 653 or MD5 hash on the public key value for which the enrollment request 654 is made. This allows the SCEP client to reuse the same transaction 655 identifier if it is reissuing a request for the same certificate 656 (i.e. a certificate with the same subject, issuer, and key). The 657 SCEP protocol requires that transaction identifiers be unique, so 658 that queries can be matched up with transactions. For this reason, 659 in those cases in which separate signing and encryption certificates 660 are issued to the same requester, the keys must be different. 662 2.3.2. State Transitions in Certificate Enrollment 664 The requester state transitions during enrollment operation are 665 indicated in the diagram below: 667 +-<------+ 668 | | 669 GetCertInitial triggered by timeout or 670 | | manual authentication 671 | | 672 [CERT-NONEXISTANT] ------> [CERT-REQ-PENDING] ---> [CERT-ISSUED] 673 | PKCSReq | CertRep with SUCCESS 674 | | 675 | | 676 +--------<-------------------+ 677 request rejected, timeout, or error 679 As described in the section 2.2.3, certificate enrollment starts at 680 the state CERT-NONEXISTANT. Sending PKCSReq changes the state to 681 CERT-REQ-PENDING. Receiving CertRep with SUCCESS status changes the 682 state to CERT-ISSUED. In the case the server sending back the 683 response with pending status, the requester will keep polling 684 certificate response by sending GetCertInitial to the server, until 685 either a CertRep with SUCCESS status is received, or the maximum 686 polling number has been exceeded. 688 If an error or timeout occurs in the CERT-REQ-PENDING state, the end 689 entity will transition to the CERT-NONEXISTANT state. 691 The client administrator will, eventually, start up another 692 enrollment request. It is important to note that, as long as the 693 requester does not change its subject name or keys, the same 694 transaction id will be used in the "new" transaction. This is 695 important because based on this transaction id, the certificate 696 authority server can recognize this as an existing transaction 697 instead of a new one. 699 2.3.3. Transaction Behavior of Certificate/CRL Access 701 There is no state maintained during certificate access and CRL access 702 transaction. When using the certificate query and CRL query messages 703 defined in this protocol, the transaction identifier is still 704 required so that the requester can match the response message with 705 the upstanding request message. When using LDAP to query the 706 certificate and the CRL, the behavior is specified by the LDAP 707 protocol. 709 2.4. Security 711 The security goals of SCEP are that no adversary can: 713 o subvert the public key/identity binding from that intended, 715 o discover the identity information in the enrollment requests and 716 issued certificates, 718 o cause the revocation of certificates with any non-negligible 719 probability. 721 Here an adversary is any entity other than the requester and the CA 722 (and optionally the RA) participating in the protocol that is 723 computationally limited, but that can manipulate data during 724 transmission (that is, a man-in-the-middle). The precise meaning of 725 'computationally limited' depends on the implementer's choice of 726 cryptographic hash functions and ciphers. The required algorithms 727 are RSA, DES and MD5. Depending on the CA Capabilities, Triple-DES 728 may be used instead of DES, and SHA-1, SHA-256, or SHA-512 may be 729 used instead of MD5. [See Appendix F]. 731 The first and second goals are met through the use of PKCS#7 732 [RFC2315] and PKCS#10 [RFC2986] encryption and digital signatures 733 using authenticated public keys. The CA's public key is 734 authenticated via the checking of the CA fingerprint, as specified in 735 Section 2.1.2, and the SCEP client's public key is authenticated 736 through the manual authentication or pre-shared secret 737 authentication, as specified in Section 2.1.1.2. The third goal is 738 met through the use of a Challenge Password for revocation, that is 739 chosen by the SCEP client and communicated to the CA protected by the 740 PKCS#7 [RFC2315] encryption, as specified in Section 2.2.4. 742 The motivation of the first security goal is straightforward. The 743 motivation for the second security goal is to protect the identity 744 information in the enrollment requests and certificates. For 745 example, two IPSEC hosts behind a firewall may need to exchange 746 certificates, and may need to enroll certificates with a CA that is 747 outside of a firewall. 749 Most networks with firewalls seek to prevent IP addresses and DNS 750 information from the trusted network leaving that network. The 751 second goal enables the hosts in this example to enroll with a CA 752 outside the firewall without revealing this information. The 753 motivation for the third security goal is to protect the SCEP clients 754 from denial of service attacks. 756 3. Transport Protocol 758 In the SCEP protocol, HTTP is used as the transport protocol for the 759 PKI messages. 761 3.1. HTTP "GET" and "POST" Message Format 763 The following is the syntax definition of a HTTP GET message sent 764 from a requester to a certificate authority server: 766 "GET " CGI-PATH CGI-PROG "?operation=" OPERATION "&message=" MESSAGE 768 where: 770 o CGI-PATH defines the actual CGI path to invoke the CGI program 771 which parses the request. 773 o CGI-PROG is set to be the string "pkiclient.exe". This is 774 intended to be the program that the CA will use to handle the SCEP 775 transactions, though the CA may ignore CGI-PROG and use only the 776 CGI-PATH. 778 o OPERATION is set to be the string 780 o 782 * "PKIOperation" when the GET message carries a PKI message to 783 request certificates or CRL 785 * "GetCACaps", "GetCACert", "GetNextCACert" or "GetCACertChain" 786 when the GET operation is used to get CA capabilities, CA/RA 787 certificate, the replacement CA/RA certificates for when the 788 current ones expire, or the CA Certificate chain (respectively) 790 o MESSAGE is 792 o 794 * a base64-encoded PKI message , when OPERATION is "PKIOperation" 795 and method is GET. 797 * a CRL distribution point in URI format , when OPERATION is 798 GetCRL, 800 * a string which represents the certificate authority issuer 801 identifier otherwise. 803 SCEP uses the HTTP "GET" and "POST" messages to request information 804 from the CA. Requests for CA certificates or capabilities are sent 805 in the clear, using "GET", with the OPERATION and MESSAGE fields 806 identifying the requested data. CRLs may also be requested in the 807 clear if the CA supports it. 809 Other types of requests are sent using the PKCS#7 [RFC2315] data 810 format. These may be issued by means of a GET operation with 811 OPERATION and MESSAGE parameters in the Request-URL. OPERATION 812 identifies the type of GET operation, and MESSAGE is actually the 813 PKCS#7 [RFC2315] message Base64-Encoded. 815 For example. a requester may submit a message via HTTP to the server 816 as follows: 817 GET /cgi-bin/pkiclient.exe?operation=PKIOperation&message=MIAGCSqGSIb3D 818 QEHA6CAMIACAQAxgDCBzAIBADB2MGIxETAPBgNVBAcTCE ......AAAAAA== HTTP/1.0 820 If supported by the CA, the message may also be sent via HTTP POST: 821 POST /cgi-bin/pkiclient.exe?operation=PKIOperation HTTP/1.0 822 Content-Length: 1234 824 826 This is further described in Appendix H. To determine if the CA 827 supports POST, use the GetCACaps message described in Appendix F. 829 3.2. Response Message Format 831 For each GET operation, the CA/RA server will return a MIME object 832 via HTTP. For a GET operation with PKIOperation as its type, the 833 response is tagged as having a Content Type of application/ 834 x-pki-message. The body of this message is a BER encoded binary PKI 835 message. The following is an example of the response: 836 "Content-Type:application/x-pki-message\n\n" 838 In the case of GET operation with a type of GetCACert the MIME 839 content type returned will depend on whether or not an RA is in use. 840 If there is no RA, only the CA certificate is sent back in the 841 response, and the response has the content type tagged as 842 application/x-x509-ca-cert. The body of the response is a DER 843 encoded binary X.509 certificate. For example: 844 "Content-Type:application/x-x509-ca-cert\n\n" 846 If there is an RA, the RA certificates are sent back together with 847 the CA certificates, a certificate-only PKCS#7 [RFC2315] SignedData 848 is sent back in the response where the SignerInfo is empty. Section 849 5 has the detailed definition of the message format in this case. 850 The content type is application/x-x509-ca-ra-cert. 852 The response to GetNextCACert is always a certificates-only PKCS#7 853 [RFC2315] SignedData with a content type of application/ 854 x-x509-ca-ra-cert. If there is an RA, The signer is the current RA 855 certificate. Otherwise, the signer is the current CA certificate. 857 If the CA supports it, PKIOperation may also be done via an HTTP 858 POST. This is described in Appendix H. 860 4. Secure Transportation: PKCS#7 862 PKCS#7 [RFC2315] is a general enveloping mechanism that enables both 863 signed and encrypted transmission of arbitrary data. It is widely 864 implemented and included in the RSA tool kit. In this section, the 865 general PKCS#7 [RFC2315] enveloped PKI message format is specified. 867 All messages MUST be valid PKCS#7 [RFC2315] structures, unless 868 otherwise noted. 870 4.1. SCEP Message Format 872 An SCEP message consists of an information portion (which depends on 873 the type of SCEP message being sent) and a set of transaction- 874 specific Attributes (see section Section 4.2). 876 The message-specific information is used as EnvelopeContent in an 877 SCEP pkcsPKIEnvelope message (see section Section 4.1.1). 879 Next, the pkcsPKIEnvelope is used as Content for a pkiMessage SCEP 880 type (see section Section 4.1.2). 882 The transaction-specific attributes are encoded as a set of 883 authenticatedAttributes in the SignerInfo of the SignedData. 885 By applying both enveloping and signing transformations, a SCEP 886 message is protected both for the integrity of its end-end-transition 887 information and the confidentiality of its information portion. The 888 advantage of this technique over the conventional transaction message 889 format is that, the signed transaction type information and the 890 status of the transaction can be determined prior to invoke security 891 handling procedures specific to the information portion being 892 processed. 894 4.1.1. SCEP pkcsPKIEnvelope 896 The SCEP messages are carried inside an Enveloped-data content type, 897 as defined in PKCS#7 Section 10, with the following restrictions: 899 o version shall be 0 901 o EncryptedContent shall be the SCEP message being transported (see 902 section Section 5) 904 The message is encrypted using the public key of the recipient, i.e. 905 the RA or the CA the message is for. 907 NOTE: The PKCS#7 [RFC2315] EncryptedContent is specified as an octet 908 string, but SCEP entities must also accept a sequence of octet 909 strings as a valid alternate encoding. 911 4.1.2. SCEP pkiMessage type 913 A SCEP pkiMessage consists of an Signed-data content type, as defined 914 in PKCS#7 Section 9. The following restrictions apply: 916 o version shall be 1 918 o The signed content shall be a pkcsPKIEnvelope 920 o The SignerInfo MUST contain a set of authenticatedAttributes (see 921 PKCS#7 Section 9.2 as well as section Section 4.2 in this 922 document. All messages are required to contain a SCEP 923 transactionID attribute, an SCEP messageType, and, of course, any 924 attributes required by PKCS#7 section 9.2. It may have other 925 attributes as well, depending on the messageType. 927 The message is signed in one of two ways: The requester can generate 928 a self-signed certificate, or the requester can use a previously 929 issued certificate, if the RA/CA supports the RENEWAL option. 931 4.2. Signed Transaction Attributes 933 The following transaction attributes are encoded as authenticated 934 attributes, and are carried, as specified in PKCS#7 Section 9.2, in 935 the SignerInfo for this signedData. 937 Please refer to Appendix B for the OID definitions. 939 +----------------+-----------------+---------------------------+ 940 | Attribute | Encoding | Comment | 941 +----------------+-----------------+---------------------------+ 942 | transactionID | PrintableString | Decimal value as a string | 943 | messageType | PrintableString | Decimal value as a string | 944 | pkiStatus | PrintableString | Decimal value as a string | 945 | failInfo | PrintableString | Decimal value as a string | 946 | senderNonce | OctetString | | 947 | recipientNonce | OctetString | | 948 +----------------+-----------------+---------------------------+ 950 The attributes are detailed in the following sections. 952 4.2.1. transactionID 954 The transactionID is an attribute which uniquely identifies a 955 transaction. This attribute is required in all PKI messages. 957 Because the enrollment transaction could be interrupted by various 958 errors, including network connection errors or client reboot, the 959 SCEP client generates a transaction identifier by calculating a hash 960 on the public key value for which the enrollment is requested. This 961 retains the same transaction identifier throughout the enrollment 962 transaction, even if the client has rebooted or timed out, and issues 963 a new enrollment request for the same key pair. 965 It also provides the way for the CA to uniquely identify a 966 transaction in its database. At the requester side, it generates a 967 transaction identifier which is included in PKCSReq. If the CA 968 returns a response of PENDING, the requester will poll by 969 periodically sending out GetCertInitial with the same transaction 970 identifier until either a response other than PENDING is obtained, or 971 the configured maximum time has elapsed. 973 For non-enrollment message (for example GetCert and GetCRL), the 974 transactionID should be a number unique to the client. 976 4.2.2. messageType 978 The messageType attribute specify the type of operation performed by 979 the transaction. This attribute is required in all PKI messages. 980 Currently, the following message types are defined: 982 o PKCSReq (19) -- PKCS#10 [RFC2986] certificate request 984 o CertRep (3) -- Response to certificate or CRL request 986 o GetCertInitial (20) -- Certificate polling in manual enrollment 988 o GetCert (21) -- Retrieve a certificate 990 o GetCRL (22) -- Retrieve a CRL 992 4.2.3. pkiStatus 994 All response message will include transaction status information 995 which is defined as pkiStatus attribute: 997 o SUCCESS (0) -- request granted 998 o FAILURE (2) -- request rejected. This also requires a failInfo 999 attribute to be present, as defined in section 4.2.4. 1001 o PENDING (3) -- request pending for manual approval 1003 4.2.4. failInfo 1005 The failInfo attribute will contain one of the following failure 1006 reasons: 1008 o badAlg (0) -- Unrecognized or unsupported algorithm ident 1010 o badMessageCheck (1) -- integrity check failed 1012 o badRequest (2) -- transaction not permitted or supported 1014 o badTime (3) -- Message time field was not sufficiently close to 1015 the system time 1017 o badCertId (4) -- No certificate could be identified matching the 1018 provided criteria 1020 4.2.5. senderNonce and responderNonce 1022 The attributes of senderNonce and recipientNonce are the 16 byte 1023 random numbers generated for each transaction to prevent the replay 1024 attack. 1026 When a requester sends a PKI message to the server, a senderNonce is 1027 included in the message. After the server processes the request, it 1028 will send back the requester senderNonce as the recipientNonce and 1029 generates another nonce as the senderNonce in the response message. 1030 Because the proposed PKI protocol is a two-way communication 1031 protocol, it is clear that the nonce can only be used by the 1032 requester to prevent the replay. The server has to employ extra 1033 state related information to prevent a replay attack. 1035 5. SCEP Transaction Specification 1037 In this section each SCEP transaction is specified in terms of the 1038 complete messages exchanged during the transaction. 1040 5.1. Certificate Enrollment 1042 The certificate enrollment transaction consists of one PKCSReq 1043 message sent to the certificate authority from a requester, and one 1044 CertRep message sent back from the server. 1046 Precondition: Both the requester and the certificate authority have 1047 completed their initialization process. The requester has already 1048 been configured with the CA/RA certificate. 1050 Postcondition: Either the certificate is received by the requester, 1051 or the end entity is notified to do the manual authentication, or the 1052 request is rejected. 1054 5.1.1. PKCSReq Message Format 1056 A PKCSReq message is a pkiMessage (see section Section 4.1.2), with 1057 the messageType attribute set to PKCSReq. 1059 The information portion of the pkiMessage is a PKCS#10 [RFC2986] 1060 certificate request, which MUST contain at least the following items: 1062 o the subject Distinguished Name 1064 o the subject public key 1066 o a ChallengePassword attribute. The Challenge Password may be used 1067 to (out-of-band) authenticate the enrollment request itself, or in 1068 an out-of-band revocation request for the issued certificate. 1070 Of course the certificate request may also contain any additional 1071 fields that make up a valid PKCS#10 request, including but not 1072 limited to an ExtensionReq attribute which is a sequence of 1073 extensions the requester expects to be included in its V3 certificate 1074 extensions (for example key-usage and extended key-usages). 1076 This pkiMessage of type PKCSReq MUST contain: 1078 o A transactionID attribute, calculated as per section Section 4.2.1 1080 o a messageType attribute set to PKCSReq 1082 o a senderNonce, calculated as per section Section 4.2.5 1084 The pkiMessage is then encrypted into a pkcsPKIEnvelope message (see 1085 section Section 4.1.1). 1087 5.1.2. CertRep Message Format 1089 The response to an SCEP enrollment request (PKCSReq) is a CertRep 1090 message. 1092 If the request is granted, the pkiStatus is set to SUCCESS, and the 1093 certificate is returned. 1095 If the request is rejected, the pkiStatus is set to FAILURE, and a 1096 failInfo attribute is returned. 1098 If the server requires manual approval of the request, the pkiStatus 1099 is set to PENDING. 1101 5.1.2.1. PENDING Response 1103 When the CA is configured to manually authenticate the requester, the 1104 CertRep is returned with the attribute pkiStatus set to PENDING. The 1105 data portion for this message is null. In addition to the attributes 1106 required by PKCS#7, the following SCEP attributes are required: 1108 o messageType set to CertReq 1110 o transactionID copied from the PKCSReq message 1112 o pkiStatus set to PENDING 1114 o senderNonce as defined in section Section 4.2.5 1116 o recipientNonce as defined in section Section 4.2.5 1118 5.1.2.2. FAILURE Response 1120 In this case, the CertRep sent back to the requester is same as in 1121 the PENDING case, except that the pkiStatus attribute is set to 1122 FAILURE, and the failInfo attribute should be included. 1124 5.1.2.3. SUCCESS response 1126 In this case, the information portion of CertRep will be a 1127 degenerated PKCS#7 [RFC2315] which contains the requester's newly 1128 generated certificate. The CertRep is otherwise identical to the 1129 PENDING reply, with the exception that pkiStatus is set to SUCCESS. 1131 5.2. Poll for Requester Initial Certificate 1133 Either triggered by the PENDING status received from the CertRep, or 1134 by the non-response timeout for the previous PKCSReq, a requester 1135 will enter the polling state by periodically sending GetCertInitial 1136 to the server, until either the request is granted and the 1137 certificate is sent back, or the request is rejected, or the 1138 configured time limit for polling is exceeded. 1140 Since GetCertInitial is part of the enrollment, the messages 1141 exchanged during the polling period should carry the same 1142 transactionID attribute as the previous PKCSReq. 1144 PreCondition: Either the requester has received a CertRep with 1145 pkiStatus set to PENDING, or waiting for a previous PKCSReq has timed 1146 out. 1148 PostCondition: The requester has either received a valid response, 1149 which could be either a valid certificate (pkiStatus == SUCCESS), or 1150 a FAILURE message, or the polling period times out. 1152 5.2.1. GetCertInitial Message Format 1154 Since at this time the certificate has not been issued, the requester 1155 can only use the requester's subject name (which was contained in the 1156 original PKCS#10 sent via PKCSReq), combined with the transactionID 1157 attribute, to identify the polled certificate request. 1159 The certificate authority server must be able to uniquely identify 1160 the polled certificate request. A subject name can have more than 1161 one outstanding certificate request (with different key usage 1162 attributes). 1164 The content of the pkiMessage with messageType GetCertInitial is an 1165 ASN.1 issuerAndSubject type (see figure Figure 1). 1167 In addition to the authenticatedAttributes required for a valid 1168 PKCS#7, the pkiMessage MUST include the following: 1170 o messageType set to GetCertInitial 1172 o transactionID 1174 o senderNonce 1176 issuerAndSubject 1177 issuerAndSubject ::= SEQUENCE { 1178 issuer Name, 1179 subject Name 1180 } 1182 Figure 1 1184 5.2.2. GetCertInitial Response Message Format 1186 The response messages for GetCertInitial are the same as for PKCSReq. 1188 5.3. Certificate Access 1190 The certificate query message defined in this section is an option 1191 when the LDAP server is not available to provide the certificate 1192 query. A requester should be able to query an issued certificate 1193 from the certificate authority, as long as the issuer name and the 1194 issuer assigned certificate serial number is known to the requesting 1195 end entity. This transaction is not intended to provide the service 1196 as a certificate directory service. A more complicated query 1197 mechanism would have to be defined in order to allow a requester to 1198 query a certificate using various different fields. 1200 This transaction consists of one GetCert message sent to the server 1201 by a requester, and one CertRep message sent back from the server. 1203 PreCondition: The queried certificate have been issued by the 1204 certificate authority and the issuer assigned serial number is known. 1206 PostCondition: Either the certificate is sent back or the request is 1207 rejected. 1209 5.3.1. GetCert Message Format 1211 The queried certificate is identified by its issuer name and the 1212 issuer assigned serial number. If this is a query for an arbitrary 1213 requester's certificate, the requesting requester should includes its 1214 own CA issued certificate in the signed envelope. If this is a query 1215 for its own certificate (assume the requester lost the issued 1216 certificate, or does not have enough non-volatile memory to save the 1217 certificate), then the self-signed certificate has to be included in 1218 the signed envelope. 1220 The content of the pkiMessage with messageType GetCert is an ASN.1 1221 IssuerAndSerial type, as specified in PKCS#7 Section 6.7. 1223 In addition to the authenticatedAttributes required for a valid 1224 PKCS#7, the pkiMessage MUST include the following: 1226 o messageType set to GetCert 1228 o transactionID 1230 o senderNonce 1232 5.3.2. CertRep Message Format 1234 In this case, the CertRep from the server is same as the CertRep for 1235 the PKCSReq, except that the server will only either grant the 1236 request (SUCCESS) or reject the request (FAILURE). 1238 Also, the recipientInfo should use the CA issuer name and CA assigned 1239 serial number to identify the requester's key pair since at this 1240 time, the requester has received its own certificate. 1242 5.4. CRL Access 1244 The CRL query message defined in this section is an option when the 1245 LDAP server is not available to provide the CRL query. In the PKI 1246 protocol proposed here, only the requester can initiate the 1247 transaction to download CRL. 1249 A requester sends GetCRL request to the server and the server sends 1250 back CertRep whose information portion is a degenerated PKCS#7 1251 [RFC2315] which contains only the most recent CRL. The size of CRL 1252 included in the CertRep should be determined by the implementation. 1254 When a CRLDistributionPoint is used, the GetCRL exchange should not 1255 be used. Instead, the CRLDistributionPoint, as set in the 1256 certificate, should be queried (see [RFC5280] section 4.2.1.14). 1258 PreCondition: The certificate authority certificate has been 1259 downloaded to the end entity. 1261 PostCondition: CRL sent back to the requester. 1263 5.4.1. GetCRL Message format 1265 The CRL is identified by using both CA's issuer name and the CA 1266 certificate's serial number, combined into an ASN.1 1267 issuerAndSerialNumber type, as defined in PKCS#7 Section 6.7. This 1268 constitutes the content of the pkiMessage with messageType GetCRL. 1270 In addition to the authenticatedAttributes required for a valid 1271 PKCS#7, the pkiMessage MUST include the following: 1273 o messageType set to GetCRL 1275 o transactionID 1277 o senderNonce 1279 5.4.2. CertRep Message Format 1281 The CRL is sent back to the requester through CertRep message. The 1282 information portion of this message is a degenerated PKCS#7 [RFC2315] 1283 SignedData which contains only the raw DER encoded CRL. 1285 5.5. Get Certificate Authority Certificate 1287 To get the CA certificate, the requester does a "HTTP GET" with a URL 1288 that identifies a CGI script on the server and an optional CA issuer 1289 identifier as the parameter to the CGI script. 1291 The response is either a single X.509 CA certificate ("CA mode"), or 1292 a PKCS7 message containing the CA certificate and RA certificates 1293 ("RA mode"). The client can determine which mode the CA operates in 1294 by which response it gets. 1296 Once the CA certificate is received by the requester, a fingerprint 1297 is generated using the SHA1, SHA256, SHA512 or MD5 hash algorithm on 1298 the whole CA certificate. If the requester does not have a 1299 certificate path to a trusted CA certificate, this fingerprint may be 1300 used to verify the certificate, by some positive out-of-band means, 1301 such as a phone call. 1303 5.5.1. GetCACert HTTP Message Format 1305 "GET" CGI-PATH CGI-PROG "?operation=GetCACert" "&message=" CA-IDENT 1307 where: 1309 o CGI-PATH defines the actual CGI path to invoke the CGI program 1310 which parses the request. 1312 o CGI-PROG is set to be the string "pkiclient.exe" and this is 1313 expected to be the program that the CA will use to handle the SCEP 1314 transactions. 1316 o CA-IDENT is any string which is understood by the CA. For 1317 example, it could be a domain name like ietf.org. If a 1318 certificate authority has multiple CA certificates this field can 1319 be used to distinguish which is required. Otherwise it may be 1320 ignored. 1322 5.5.2. Response 1324 The response for GetCACert is different between the case where the CA 1325 directly communicated with the requester during the enrollment, and 1326 the case where a RA exists and the requester communicates with the RA 1327 during the enrollment. 1329 5.5.2.1. CA Certificate Only Response 1331 A binary X.509 CA certificate is sent back as a MIME object with a 1332 Content-Type of application/x-x509-ca-cert. 1334 5.5.2.2. CA and RA Certificates Response 1336 When an RA exists, both CA and RA certificates must be sent back in 1337 the response to the GetCACert request. The RA certificate(s) must be 1338 signed by the CA. A certificates-only PKCS#7 [RFC2315] SignedData is 1339 used to carry the certificates to the requester, with a Content-Type 1340 of application/x-x509-ca-ra-cert. 1342 5.5.3. Get Next Certificate Authority Certificate 1344 5.5.3.1. GetNextCACert HTTP Message Format 1346 "GET" CGI-PATH CGI-PROG "?operation=GetNextCACert" "&message=" CA- 1347 IDENT 1349 The response to this message is a PKCS#7 [RFC2315] certificates-only 1350 message containing a CA certificate (and possibly RA certificates) to 1351 be used when the current CA certificate expires, signed with the 1352 current CA certificate (or RA certificate, if the CA is in RA mode. 1353 Note that a PKCS#7 [RFC2315] is returned even in CA mode. 1355 5.5.3.2. GetCACaps HTTP Message Format 1357 "GET" CGI-PATH CGI-PROG "?operation=GetCACaps" "&message=" CA-IDENT 1359 This message requests capabilities from CA. The response is a list 1360 of text capabilities, as defined in Appendix F. Support for this 1361 message is optional, but if it is not supported, the client should 1362 assume that none of the capabilities in Appendix F are supported. 1364 5.6. Get Certificate Authority Certificate Chain 1366 GetCACertChain provides a way to get the entire certificate chain. 1368 5.6.1. GetCACertChain HTTP Message Format 1370 "GET" CGI-SCRIPT "?" "operation=GetCACertChain" "&" "message" CA- 1371 IDENT 1373 where: 1375 CGI-SCRIPT and CA-IDENT are as described for GetCACert. 1377 5.6.2. Response 1379 The response for GetCACertChain is a certificates-only PKCS#7 1380 [RFC2315] SignedData to carry the certificates to the requester, with 1381 a Content-Type of application/x-x509-ca-ra-cert-chain. 1383 5.6.3. Backwards Compatibility 1385 Versions of SCEP prior to revision 3 do not support GetCACertChain or 1386 GetNextCACert. Certificate Authorities written to these prior 1387 versions will not be able to process the message and may return an 1388 HTML error. 1390 To avoid this, clients should send the GetCACert message first. If 1391 the returned certificate is self-signed or is signed by a Certificate 1392 Authority that is trusted by the client, then it is not necessary to 1393 send the GetCACertChain message and it should not be sent. 1395 An old CA in a two-deep hierarchy might still get this message from a 1396 client if the client did not trust either that CA or its issuer. 1398 6. Acknowledgements 1400 The authors would like to thank Peter William of ValiCert, Inc. 1401 (formerly of Verisign, Inc) and Alex Deacon of Verisign, Inc. and 1402 Christopher Welles of IRE, Inc. for their contributions to this 1403 protocol and to this document. 1405 7. IANA Considerations 1407 This memo includes no request to IANA. 1409 8. Security Considerations 1411 8.1. General Security 1413 Common key-management considerations such as keeping private keys 1414 truly private and using adequate lengths for symmetric and asymmetric 1415 keys must be followed in order to maintain the security of this 1416 protocol. 1418 This is especially true for CA keys, which, when compromised, 1419 compromise the security of all relying parties. 1421 8.2. Use of the CA keypair 1423 A CA keypair is generally meant for (and is usually flagged as) 1424 "certificate signing" (exclusively), rather than 'data signing' or 1425 'data encryption'. The SCEP protocol, however, uses the CA keypair 1426 indiscriminately to encrypt and sign PKCS#7 transport messages. This 1427 is generally considered undesirable, as this weakens the CA keypair 1428 over time (it is generally accepted that using any key weakens it 1429 over time, as it gives an attacker more data to work with). 1431 While the CA keypair can be generated with the 'data encryption' and 1432 'data signing' flags set, this is operationally not encouraged. It 1433 would make using the key as a PKCS#7 transport key 'legal', but the 1434 discussion from the previous paragraph still applies. 1436 A solution is to use RA keys to secure the SCEP transport (i.e. 1437 message signing and encrypting), which allows the CA keys to be used 1438 only for their intended purpose of "certificate signing". 1440 An RA can be implemented in two ways: physically separate or 1441 implicit. In the implicit case, the CA simply creates an extra 1442 keypair. A physically separate RA allows the CA to be inside the 1443 secure network, not accessible to hackers at all. 1445 8.3. ChallengePassword 1447 The ChallengePassword sent in the PKCS#10 enrollment request is 1448 signed (via inclusion in a pkiMessage) and encrypted (via inclusion 1449 in a pkcsPKIEnvelope). When saved by the CA, care should be taken to 1450 protect this password. 1452 If the ChallengePassword is used to automatically authenticate an 1453 enrollment request, it is recommend that some form of one-time 1454 password be used to minimize damage in the event the data is 1455 compromised. 1457 8.4. transactionID 1459 A well-written CA/RA will not rely on the transactionID to be correct 1460 or as specified in this document. Requesters with buggy software 1461 might add additional undetected duplicate requests to the CA's queue 1462 (or worse). A well-written CA/RA should never assume the data from a 1463 requester is well-formed. 1465 8.5. Unnecessary cryptography 1467 Some of the SCEP exchanges use signing and encryption operations that 1468 are not necessary. In particular the GetCert and GetCRL exchanges 1469 are encrypted and signed (in both directions), where simply signing 1470 the request would suffice (CRL's and Certificates, i.e. the 1471 respective responses, are already signed by the CA and can be 1472 verified by the recipient). 1474 This may affect performance and scalability of the CA which could be 1475 used as an attack vector on the CA (though not an anonymous one). 1477 The use of CDP's is recommended for CRL access, as well as other ways 1478 of retrieving certificates (LDAP, direct HTTP access, etc). 1480 9. Intellectual Property 1482 This protocol includes the optional use of Certificate Revocation 1483 List Distribution Point (CRLDP) technology, which is a patented 1484 technology of Entrust Technologies, Inc. (Method for Efficient 1485 Management of Certificate Revocation Lists and Update Information 1486 (U.S. Patent 5,699,431)). Please contact Entrust Technologies, Inc. 1487 (www.entrust.com) for more information on licensing CRLDP technology. 1489 10. Normative References 1491 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1492 Requirement Levels", BCP 14, RFC 2119, March 1997. 1494 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 1495 Version 1.5", RFC 2315, March 1998. 1497 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1498 (IKE)", RFC 2409, November 1998. 1500 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1501 Adams, "X.509 Internet Public Key Infrastructure Online 1502 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 1504 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1505 Request Syntax Specification Version 1.7", RFC 2986, 1506 November 2000. 1508 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1509 "Internet X.509 Public Key Infrastructure Certificate 1510 Management Protocol (CMP)", RFC 4210, September 2005. 1512 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1513 RFC 4306, December 2005. 1515 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1516 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1518 [RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol 1519 (LDAP) Schema Definitions for X.509 Certificates", 1520 RFC 4523, June 2006. 1522 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 1523 (CMC)", RFC 5272, June 2008. 1525 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1526 Housley, R., and W. Polk, "Internet X.509 Public Key 1527 Infrastructure Certificate and Certificate Revocation List 1528 (CRL) Profile", RFC 5280, May 2008. 1530 Appendix A. Cisco Requester Subject Name Definition 1532 The ip address and the FQDN of a SCEP client should be included in 1533 the V3 extension subjectAltName. When the subjectAltName extension 1534 attribute is present, both the subjectAltName fields and the 1535 subjectName field could have the IP address and the FQDN information. 1537 When the X.500 directory is used by the CA to define the name space, 1538 the subject name defined above become a RDN which is part of DN bound 1539 to the requester's public key in the certificate. A sample of DN 1540 assigned by Entrust CA is given below (assume the same 1541 ciscoRouterAlice is used as the requester defined subject name): 1542 OU = InteropTesting, O = Entrust Technologies, C = CA 1543 RDN = {"alice.cisco.com", "172.21.114.67", "22334455"} 1545 Appendix B. IPSEC Client Enrollment Certificate Request 1547 The following is the certificate enrollment request (PKCS#10 1548 [RFC2986]) as created by Cisco VPN Client: 1549 -----END NEW CERTIFICATE REQUEST----- 1550 0 30 439: SEQUENCE { 1551 4 30 288: SEQUENCE { 1552 8 02 1: INTEGER 0 1553 11 30 57: SEQUENCE { 1554 13 31 55: SET { 1555 15 30 53: SEQUENCE { 1556 17 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 1557 22 13 46: PrintableString 1558 : 'For Xiaoyi, IPSEC attrs in alternate name 1559 extn' 1560 : } 1561 : } 1562 : } 1563 70 30 158: SEQUENCE { 1564 73 30 13: SEQUENCE { 1565 75 06 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1566 1 1) 1567 86 05 0: NULL 1568 : } 1570 88 03 140: BIT STRING 0 unused bits 1571 : 30 81 88 02 81 80 73 DB 1D D5 65 AA EF C7 D4 8E 1572 : AA 6E EB 46 AC 91 2A 0F 50 51 17 AD 50 A2 2A F2 1573 : CE BE F1 E4 22 8C D7 61 A1 6C 87 61 62 92 CB A6 1574 : 80 EA B4 0F 09 9D 18 5F 39 A3 02 0E DB 38 4C E4 1575 : 8A 63 2E 72 8B DC BE 9E ED 6C 1A 47 DE 13 1B 0F 1576 : 83 29 4D 3E 08 86 FF 08 2B 43 09 EF 67 A7 6B EA 1577 : 77 62 30 35 4D A9 0F 0F DF CC 44 F5 4D 2C 2E 19 1578 : E8 63 94 AC 84 A4 D0 01 E1 E3 97 16 CD 86 64 18 1579 : [ Another 11 bytes skipped ] 1580 : } 1581 231 A0 63: [0] { 1582 233 30 61: SEQUENCE { 1583 235 06 9: OBJECT IDENTIFIER extensionReq (1 2 840 113549 1 9 1584 14) 1585 246 31 48: SET { 1586 248 30 46: SEQUENCE { 1587 250 30 44: SEQUENCE { 1588 252 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 1589 257 04 37: OCTET STRING 1590 30 23 87 04 01 02 03 04 81 0D 65 6D 61 69 1592 6C 40 69 72 65 2E 63 6F 6D 82 0C 66 71 64 1593 6E 2E 69 72 65 2E 63 6F 6D 1594 : } 1595 : } 1596 : } 1597 : } 1598 : } 1599 : } 1601 296 30 13: SEQUENCE { 1602 298 06 9: OBJECT IDENTIFIER md5withRSAEncryption (1 2 840 113549 1603 1 1 4) 1604 309 05 0: NULL 1605 : } 1606 311 03 129: BIT STRING 0 unused bits 1607 : 19 60 55 45 7F 72 FD 4E E5 3F D2 66 B0 77 13 9A 1608 : 87 86 75 6A E1 36 C6 B6 21 71 68 BD 96 F0 B4 60 1609 : 95 8F 12 F1 65 33 16 FD 46 8A 63 19 90 40 B4 B7 1610 : 2C B5 AC 63 17 50 28 F0 CD A4 F0 00 4E D2 DE 6D 1611 : C3 4F F5 CB 03 4D C8 D8 31 5A 7C 01 47 D2 2B 91 1612 : B5 48 55 C8 A7 0B DD 45 D3 4A 8D 94 04 3A 6C B0 1613 : A7 1D 64 74 AB 8A F7 FF 82 C7 22 0A 2A 95 FB 24 1614 : 88 AA B6 27 83 C1 EC 5E A0 BA 0C BA 2E 6D 50 C7 1615 : } 1617 Appendix C. Private OID Definitions 1619 The OIDs used in SCEP are VeriSign self-maintained OIDs. 1621 +-------------------+-----------------------------------------------+ 1622 | Name | ASN.1 Definition | 1623 +-------------------+-----------------------------------------------+ 1624 | id-VeriSign | OBJECT_IDENTIFIER ::= {2 16 US(840) 1 | 1625 | | VeriSign(113733)} | 1626 | id-pki | OBJECT_IDENTIFIER ::= {id-VeriSign pki(1)} | 1627 | id-attributes | OBJECT_IDENTIFIER ::= {id-pki attributes(9)} | 1628 | id-messageType | OBJECT_IDENTIFIER ::= {id-attributes | 1629 | | messageType(2)} | 1630 | id-pkiStatus | OBJECT_IDENTIFIER ::= {id-attributes | 1631 | | pkiStatus(3)} | 1632 | id-failInfo | OBJECT_IDENTIFIER ::= {id-attributes | 1633 | | failInfo(4)} | 1634 | id-senderNonce | OBJECT_IDENTIFIER ::= {id-attributes | 1635 | | senderNonce(5)} | 1636 | id-recipientNonce | OBJECT_IDENTIFIER ::= {id-attributes | 1637 | | recipientNonce(6)} | 1638 | id-transId | OBJECT_IDENTIFIER ::= {id-attributes | 1639 | | transId(7)} | 1640 | id-extensionReq | OBJECT_IDENTIFIER ::= {id-attributes | 1641 | | extensionReq(8)} | 1642 +-------------------+-----------------------------------------------+ 1644 Appendix D. CRL Query by means of LDAP 1646 In order to retrieve the CRL by means of LDAP, the client needs to 1647 know where in the directory it is stored. The certificate must 1648 contain a CRL Distribution Point extension encoded as a DN or as an 1649 LDAP URI. 1651 For example, the certificate issued by Entrust VPN contains the 1652 following DN as the CRL distribution point: 1653 CN = CRL1, O = cisco, C = US 1655 The ASN.1 encoding of this distribution point is: 1656 30 2C 31 0B 30 09 06 03 55 04 06 13 02 55 53 31 0E 30 0C 06 1657 03 55 04 0A 13 05 63 69 73 63 6F 31 0D 30 0B 06 03 55 04 03 1658 13 04 43 52 4C 31 1660 The ldap form would be: 1661 ldap://servername/CN=CRL1,O=cisco,C=US 1663 Appendix E. SCEP State Transitions 1665 SCEP state transitions are indexed by the transactionID attribute. 1666 The design goal is to ensure the synchronization between the CA and 1667 the requester under various error situations. An identity is defined 1668 by the combination of FQDN, the IP address and the client serial 1669 number. FQDN is the required name attribute. It is important to 1670 notice that, a client named as Alice.cisco.com is different from the 1671 client named as Alice.cisco.com plus IPAddress 192.0.2.4. 1673 Each enrollment transaction is uniquely associated with a transaction 1674 identifier (carried in the transactionID signed attribute (see 1675 section XXX). Because the enrollment transaction could be 1676 interrupted by various errors, including network connection errors or 1677 client reboot, the SCEP client generates a transaction identifier by 1678 calculating a hash on the public key value for which the enrollment 1679 is requested. This retains the same transaction identifier 1680 throughout the enrollment transaction, even if the client has 1681 rebooted or timed out, and issues a new enrollment request for the 1682 same key pair. It also provides the way for the CA to uniquely 1683 identify a transaction in its database. At the requester side, it 1684 generates a transaction identifier which is included in PKCSReq. If 1685 the CA returns a response of PENDING, the requester will poll by 1686 periodically sending out GetCertInitial with the same transaction 1687 identifier until either a response other than PENDING is obtained, or 1688 the configured maximum time has elapsed. 1690 If the client times out or the client reboots, the client 1691 administrator will start another enrollment transaction with the same 1692 key pair. The second enrollment will have the transaction 1693 identifier. At the server side, instead of accepting the PKCSReq as 1694 a new enrollment request, it should respond as if another 1695 GetCertInitial message had been sent with that transaction ID. In 1696 another word, the second PKCSReq should be taken as a 1697 resynchronization message to allow the enrollment resume as the same 1698 transaction. 1700 It is important to keep the transaction id unique since SCEP requires 1701 the same policy and same identity be applied to the same subject name 1702 and key pair binding. In the current implementation, an SCEP client 1703 can only assume one identity. At any time, only one key pair, with a 1704 given key usage, can be associated with the same identity. 1706 The following gives several examples of client to CA transactions. 1708 Client actions are indicated in the left column, CA actions are 1709 indicated in the right column. A blank action signifies that no 1710 message was received. Note that these examples assume that the CA 1711 enforces the certificate-name uniqueness property defined in 1712 Section 2.1.1.1. 1714 The first transaction, for example, would read like this: 1716 "Client Sends PKCSReq message with transaction ID 1 to the CA. The 1717 CA signs the certificate and constructs a CertRep Message containing 1718 the signed certificate with a transaction ID 1. The client receives 1719 the message and installs the certificate locally." 1721 Successful Enrollment Case: no manual authentication 1722 PKCSReq (1) ----------> CA Signs Cert 1723 Client Installs Cert <---------- CertRep (1) SIGNED CERT 1725 Successful Enrollment Case: manual authentication required 1726 PKCSReq (10) ----------> Cert Request goes into Queue 1727 Client Polls <---------- CertRep (10) PENDING 1728 GetCertInitial (10) ----------> Still pending 1729 Client Polls <---------- CertRep (10) PENDING 1730 GetCertInitial (10) ----------> Still pending 1731 Client Polls <---------- CertRep (10) PENDING 1732 GetCertInitial (10) ----------> Still pending 1733 Client Polls <---------- CertRep (10) PENDING 1734 GetCertInitial (10) ----------> Cert has been signed 1735 Client Installs Cert <---------- CertRep (10) SIGNED CERT 1737 Resync Case - CA Receive and Signs PKCSReq, Client Did not receive 1738 CertRep: 1739 PKCSReq (3) ----------> Cert Request goes into queue 1740 <---------- CertRep (3) PENDING 1741 GetCertInitial (3) ----------> 1742 <---------- CertRep (3) PENDING 1743 GetCertInitial (3) -----------> 1744 <----------- CA signed Cert and sent back 1745 CertRep(3) 1746 (Time Out) 1747 PKCSReq (3) ----------> Cert already signed, sent back to 1748 client 1749 Client Installs Cert <---------- CertRep (3) SIGNED CERT 1751 Case when NVRAM is lost and client has to generate a new key pair, 1752 there is no change of name information: 1754 PKCSReq (4) ----------> CA Signs Cert 1755 Client Installs Cert <---------- CertRep (4) SIGNED CERT 1756 (Client looses Cert) 1757 PKCSReq (5) ----------> There is already a valid cert with 1758 this DN. 1759 Client Admin Revokes <---------- CertRep (5) OVERLAPPING CERT ERROR 1760 PKCSReq (5) ----------> CA Signs Cert 1761 Client Installs Cert <---------- CertRep (5) SIGNED CERT 1762 Case when client admin resync the enrollment using a different PKCS#10: 1763 PKCSReq (6) ----------> CA Signs Cert 1764 <---------- CertRep (6) SIGNED CERT 1766 (Client timeout and admin starts another enrollment with a different 1767 PKCS#10, but the same transaction id) 1769 PKCSReq (6) with different PKCS#10 1770 ----------> There is already a valid cert with 1771 this entity (by checking FQDN). 1772 <---------- CertRep (6) INVALID PKCS#10 CERT 1773 ERROR 1775 Client admin either revokes the existing certificate or corrects the 1776 error by enrolling with the same PKCS#10 as the first PKCSReq(6) 1778 PKCSReq (6) ----------> CA find the existing Cert 1779 Client Installs Cert <---------- CertRep (6) SIGNED CERT 1780 Resync case when server is slow in response: 1781 PKCSReq (13) ----------> Cert Request goes into Queue 1782 <---------- CertRep (13) PENDING 1783 GetCertInitial ----------> Still pending 1784 <---------- CertRep (13) PENDING 1785 GetCertInitial ----------> Still pending 1786 <---------- CertRep (13) PENDING 1787 GetCertInitial ----------> Still pending 1788 <---------- CertRep (13) PENDING 1789 GetCertInitial ----------> Still pending 1790 (TimeOut) <---------- CertRep (13) PENDING 1791 * Case 1 1792 PKCSReq (13) ----------> Still pending 1793 Client polls <---------- CertRep (13) PENDING 1794 GetCertInitial ----------> Crete has been signed 1795 Client Installs Crete <---------- CertRep (13) SIGNED CERT 1796 * Case 2 1797 PKCSReq (13) ----------> Cert has been signed 1798 Client Installs Cert <---------- CertRep (13) SIGNED CERT 1800 Appendix F. CA Capabilities 1802 The response for a GetCACaps message is a list of CA capabilities, in 1803 plain text, separated by characters, as follows (quotation marks 1804 are NOT sent): 1806 +--------------------+----------------------------------------------+ 1807 | Keyword | Description | 1808 +--------------------+----------------------------------------------+ 1809 | "GetNextCACert" | CA Supports the GetNextCACert message. | 1810 | "POSTPKIOperation" | PKIOPeration messages may be sent via HTTP | 1811 | | POST. | 1812 | "Renewal" | Clients may use current certificate and key | 1813 | | to authenticate an enrollment request for a | 1814 | | new certificate. | 1815 | "SHA-512" | CA Supports the SHA-512 hashing algorithm in | 1816 | | signatures and fingerprints. | 1817 | "SHA-256" | CA Supports the SHA-256 hashing algorithm in | 1818 | | signatures and fingerprints. | 1819 | "SHA-1" | CA Supports the SHA-1 hashing algorithm in | 1820 | | signatures and fingerprints. | 1821 | "DES3" | CA Supports triple-DES for encryption. | 1822 +--------------------+----------------------------------------------+ 1824 The client should use SHA-1, SHA-256, or SHA-512 in preference to MD5 1825 hashing if it is supported by the CA. 1827 A client MUST be able to accept and ignore any unknown keywords that 1828 might be sent back by a CA. 1830 If none of the above capabilities are supported by the CA, no data is 1831 returned. 1833 The appropriate HTML headers are returned in any case. 1835 Example: 1836 GET /cgi-bin/pkiclient.exe?operation=GetCACaps&message=myca 1838 might return: 1839 GetNextCACert POSTPKIOperation 1841 This means that the CA supports the GetNextCACert message and allows 1842 PKIOperation messages (PKCSreq, GetCert, GetCertInitial...) to be 1843 sent using HTTP POST. 1845 Appendix G. Certificate Renewal and CA Key Rollover 1847 To renew a client certificate, use the PKCSreq message and sign it 1848 with the existing client certificate instead of a self-signed 1849 certificate. 1851 To obtain the new CA certificate prior to the expiration of the 1852 current one, use the GetNextCACert message if the CA supports it. 1854 To obtain a new client certificate signed by the new CA certificate, 1855 use the new CA or RA certificate in the message envelope. Example: 1856 GetNextCACert ----------> 1857 <---------- CertRep (3) New CA certificate 1859 PKCSReq* (1) ----------> CA Signs certificate with NEW key 1860 Client Stores Cert <---------- CertRep (3) Certificate issued 1861 for installation when from NEW CA certificate and keypair 1862 existing cert expires. 1864 *enveloped for new CA or RA cert and keypair. The CA will use the 1865 envelope to determine which key and certificate to use to issue the 1866 client certificate. 1868 Appendix H. PKIOperation via HTTP POST Message 1870 If the remote CA supports it, any of the PKCS#7-encoded SCEP messages 1871 may be sent via HTTP POST instead of HTTP GET. This is allowed for 1872 any SCEP message except GetCACert, GetCACertChain, GetNextCACert, or 1873 GetCACaps. In this form of the message, Base 64 encoding is not 1874 used. 1875 POST /cgi-bin/pkiclient.exe?operation=PKIOperation HTTP/1.0 1876 Content-Length: 1878 1880 The client can verify that the CA supports SCEP messages via POST by 1881 looking for the "POSTPKIOperation" capability (See Appendix F). 1883 Authors' Addresses 1885 Andrew Nourse 1886 Cisco Systems, Inc. 1887 510 McCarthy Drive 1888 Milpitas, CA 1889 USA 1891 Email: nourse@cisco.com 1893 Xiaoyi Liu 1894 Cisco Systems, Inc. 1895 510 McCarthy Drive 1896 Milpitas, CA 1897 USA 1899 Email: xliu@cisco.com 1901 Jan Vilhuber (editor) 1902 Cisco Systems, Inc. 1903 510 McCarthy Drive 1904 Milpitas, CA 1905 USA 1907 Email: vilhuber@cisco.com 1909 Cheryl Madson 1910 Cisco Systems, Inc. 1911 510 McCarthy Drive 1912 Milpitas, CA 1913 USA 1915 Email: cmadson@cisco.com