idnits 2.17.1 draft-nourse-scep-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 30, 2009) is 5262 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CERT-NONEXISTANT' is mentioned on line 504, but not defined == Missing Reference: 'CERT-REQ-PENDING' is mentioned on line 504, but not defined == Missing Reference: 'CERT-ISSUED' is mentioned on line 504, but not defined ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** 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 (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Pritikin, Ed. 3 Internet-Draft A. Nourse 4 Intended status: Informational J. Vilhuber 5 Expires: June 3, 2010 Cisco Systems, Inc 6 November 30, 2009 8 Cisco Systems' Simple Certificate Enrollment Protocol 9 draft-nourse-scep-20 11 Abstract 13 This document specifies the Simple Certificate Enrollment Protocol, a 14 PKI communication protocol which leverages existing technology by 15 using PKCS#7 and PKCS#10 over HTTP. SCEP is the evolution of the 16 enrollment protocol developed by VeriSign, Inc. for Cisco Systems, 17 Inc. It now enjoys wide support in both client and CA 18 implementations. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on June 3, 2010. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 74 2. SCEP Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 75 2.1. SCEP Entities . . . . . . . . . . . . . . . . . . . . . . 6 76 2.1.1. Requester . . . . . . . . . . . . . . . . . . . . . . 6 77 2.1.2. Certification Authority . . . . . . . . . . . . . . . 7 78 2.1.3. Registration Authority . . . . . . . . . . . . . . . . 8 79 2.2. Requester authentication . . . . . . . . . . . . . . . . . 8 80 2.3. Enrollment authorization . . . . . . . . . . . . . . . . . 9 81 2.4. CA/RA Certificate Distribution . . . . . . . . . . . . . . 10 82 2.5. Certificate Enrollment . . . . . . . . . . . . . . . . . . 11 83 2.5.1. Client State Transitions . . . . . . . . . . . . . . . 12 84 2.6. Certificate Access . . . . . . . . . . . . . . . . . . . . 13 85 2.7. CRL Access . . . . . . . . . . . . . . . . . . . . . . . . 14 86 2.8. Certificate Revocation . . . . . . . . . . . . . . . . . . 15 87 3. SCEP Secure Message Objects . . . . . . . . . . . . . . . . . 15 88 3.1. SCEP pkiMessage . . . . . . . . . . . . . . . . . . . . . 16 89 3.1.1. Signed Transaction Attributes . . . . . . . . . . . . 17 90 3.1.1.1. transactionID . . . . . . . . . . . . . . . . . . 18 91 3.1.1.2. messageType . . . . . . . . . . . . . . . . . . . 18 92 3.1.1.3. pkiStatus . . . . . . . . . . . . . . . . . . . . 18 93 3.1.1.4. failInfo . . . . . . . . . . . . . . . . . . . . . 19 94 3.1.1.5. senderNonce and recipientNonce . . . . . . . . . . 19 95 3.1.1.6. signingTime Attribute . . . . . . . . . . . . . . 19 96 3.1.2. SCEP pkcsPKIEnvelope . . . . . . . . . . . . . . . . . 20 97 3.2. SCEP pkiMessage types . . . . . . . . . . . . . . . . . . 20 98 3.2.1. PKCSReq . . . . . . . . . . . . . . . . . . . . . . . 20 99 3.2.2. CertRep . . . . . . . . . . . . . . . . . . . . . . . 21 100 3.2.2.1. CertRep SUCCESS . . . . . . . . . . . . . . . . . 21 101 3.2.2.2. CertRep FAILURE . . . . . . . . . . . . . . . . . 22 102 3.2.2.3. CertRep PENDING . . . . . . . . . . . . . . . . . 22 103 3.2.3. GetCertInitial . . . . . . . . . . . . . . . . . . . . 22 104 3.2.3.1. IssuerAndSubject . . . . . . . . . . . . . . . . . 23 105 3.2.4. GetCert . . . . . . . . . . . . . . . . . . . . . . . 23 106 3.2.5. GetCRL . . . . . . . . . . . . . . . . . . . . . . . . 23 107 3.3. Degenerate certificates-only PKCS#7 Signed-data . . . . . 24 108 4. SCEP Transactions . . . . . . . . . . . . . . . . . . . . . . 24 109 4.1. Get CA Certificate . . . . . . . . . . . . . . . . . . . . 24 110 4.1.1. Get CA Certificate Response Message Format . . . . . . 25 111 4.1.1.1. CA Certificate Response Message Format . . . . . . 25 112 4.1.1.2. CA/RA Certificate Response Message Format . . . . 25 113 4.2. Certificate Enrollment . . . . . . . . . . . . . . . . . . 25 114 4.2.1. Certificate Enrollment Response Message . . . . . . . 26 115 4.3. Poll for Requester Initial Certificate . . . . . . . . . . 26 116 4.3.1. Polling Response Message Format . . . . . . . . . . . 27 117 4.4. Certificate Access . . . . . . . . . . . . . . . . . . . . 27 118 4.4.1. Certificate Access Response Message Format . . . . . . 27 119 4.5. CRL Access . . . . . . . . . . . . . . . . . . . . . . . . 27 120 4.5.1. CRL Access Response Message Format . . . . . . . . . . 27 121 4.6. Get Next Certification Authority Certificate . . . . . . . 28 122 4.6.1. Get Next CA Response Message Format . . . . . . . . . 28 123 5. SCEP Transport . . . . . . . . . . . . . . . . . . . . . . . . 28 124 5.1. HTTP "GET" Message Format . . . . . . . . . . . . . . . . 28 125 5.1.1. Response Message Format . . . . . . . . . . . . . . . 29 126 5.2. SCEP HTTP Messages . . . . . . . . . . . . . . . . . . . . 29 127 5.2.1. GetCACert . . . . . . . . . . . . . . . . . . . . . . 29 128 5.2.1.1. GetCACert Response . . . . . . . . . . . . . . . . 29 129 5.2.2. PKCSReq . . . . . . . . . . . . . . . . . . . . . . . 30 130 5.2.2.1. PKCSReq Response . . . . . . . . . . . . . . . . . 30 131 5.2.3. GetCertInitial . . . . . . . . . . . . . . . . . . . . 30 132 5.2.3.1. GetCertInitial Response . . . . . . . . . . . . . 30 133 5.2.4. GetCert . . . . . . . . . . . . . . . . . . . . . . . 30 134 5.2.4.1. GetCert Response . . . . . . . . . . . . . . . . . 31 135 5.2.5. GetCRL . . . . . . . . . . . . . . . . . . . . . . . . 31 136 5.2.5.1. GetCRL Response . . . . . . . . . . . . . . . . . 31 137 5.2.6. GetNextCACert . . . . . . . . . . . . . . . . . . . . 31 138 5.2.6.1. GetNextCACert Response . . . . . . . . . . . . . . 31 139 6. Contributors/Acknowledgements . . . . . . . . . . . . . . . . 31 140 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 141 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 142 8.1. General Security . . . . . . . . . . . . . . . . . . . . . 33 143 8.2. Use of the CA keypair . . . . . . . . . . . . . . . . . . 33 144 8.3. ChallengePassword . . . . . . . . . . . . . . . . . . . . 34 145 8.4. transactionID . . . . . . . . . . . . . . . . . . . . . . 34 146 8.5. Nonces and Replay . . . . . . . . . . . . . . . . . . . . 34 147 8.6. Key Usage Issues . . . . . . . . . . . . . . . . . . . . . 34 148 8.7. GetCACaps Issues . . . . . . . . . . . . . . . . . . . . . 35 149 8.8. Unnecessary cryptography . . . . . . . . . . . . . . . . . 35 150 8.9. GetNextCACert . . . . . . . . . . . . . . . . . . . . . . 35 151 9. Normative References . . . . . . . . . . . . . . . . . . . . . 35 152 Appendix A. Private OID Definitions . . . . . . . . . . . . . . . 36 153 Appendix B. SCEP State Transitions . . . . . . . . . . . . . . . 37 154 Appendix C. CA Capabilities . . . . . . . . . . . . . . . . . . . 39 155 C.1. GetCACaps HTTP Message Format . . . . . . . . . . . . . . 39 156 C.2. CA Capabilities Response Format . . . . . . . . . . . . . 39 157 Appendix D. Client Certificate Renewal . . . . . . . . . . . . . 40 158 Appendix E. CA Key Rollover . . . . . . . . . . . . . . . . . . . 41 159 Appendix F. PKIOperation via HTTP POST Message . . . . . . . . . 42 160 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 162 1. Introduction 164 Public key technology is widely available and increasingly widely 165 deployed. X.509 certificates serve as the basis for several 166 standards-based security protocols in the IETF, such as IKE [RFC2409] 167 and IKEv2 [RFC4306], and TLS [RFC4346]. When an X.509 certificate is 168 issued by other than the certificate subject (a self-issued 169 certificate), there typically is a need for a certificate management 170 protocol. Such a protocol enables a PKI client to request a 171 certificate, certificate renewal, or certificate revocation from a 172 certification authority. Often there also is a need for protocols to 173 request a certificate or certificate status information, although 174 these functions are often provided by distinct protocols. 176 This specification defines a protocol, SCEP, for certificate 177 management and certificate and CRL queries in a closed environment. 178 While widely deployed, this protocol omits some certificate 179 management features, e.g., in-band certificate revocation 180 transactions, that can significantly enhance the security achieved in 181 a PKI. The IETF protocol suite currently includes two certificate 182 management protocols with more comprehensive functionality: CMP 183 [RFC4210] and Certificate Management over CMS [RFC5272]. Where 184 interoperability with the installed base of SCEP implementations is 185 required, implementers are encouraged to support a comprehensive 186 standards track certificate management protocol in addition to the 187 protocol defined in this specification. This implementation strategy 188 balances near term requirements for interoperability with longer term 189 security goals. 191 As a reflection of the history of SCEP implementations some of the 192 operations described in this document are indicated as 'SHOULD' or 193 'MAY' where a stricter protocol specification might have indicated a 194 'MUST'. 196 The protocol supports the following general operations: 198 o CA and RA public key distribution 200 o Certificate enrollment 202 o Certificate query 204 o CRL query 206 SCEP makes extensive use of PKCS#7 [RFC2315] and PKCS#10 [RFC2986]. 208 1.1. Requirements Language 210 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 211 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 212 document are to be interpreted as described in [RFC2119]. 214 2. SCEP Overview 216 In this section, we give a high level overview of the functionality 217 of SCEP. 219 2.1. SCEP Entities 221 The entity types defined in SCEP are 223 o the Requester (Section 2.1.1) (e.g., IPSEC clients) 225 o the Server, which may be either a Certification Authority (CA) 226 (Section 2.1.2) or a Registration Authority (RA) (Section 2.1.3) 228 2.1.1. Requester 230 The requester is sometimes called a "client" in this document. It is 231 the client of the SCEP exchange. 233 The requester MAY submit SCEP messages for itself or it MAY submit 234 SCEP messages on behalf of peers as described in Registration 235 Authority (Section 2.1.3). This section focuses on the requester 236 that is obtaining certificates for its own use. 238 Before a requester can start a PKI transaction, it MUST have at least 239 one RSA key pair use for signing the SCEP pkiMessage (Section 3.1). 241 The requester MUST use RSA keys for all symmetric key operations. 242 (The message types, being based on PKCS#7 [RFC2315], fully support 243 algorithm agility). 245 A requester MUST have the following information locally configured: 247 1. The Certification Authority IP address or fully qualified domain 248 name 250 2. The Certification Authority HTTP CGI script path 252 3. The identifying information that is used for authentication of 253 the Certification Authority in Section 4.1.1. This information 254 MAY be obtained from the user, or presented to the end user for 255 manual authorization during the protocol exchange (e.g. the user 256 indicates acceptance of a fingerprint via a user-interface 257 element). 259 The requester MUST have MESSAGE information configured if the 260 Certification Authority requires it (see Section 5.1). 262 The requester MAY maintain multiple independent configurations 263 appropriate for multiple Certification Authorities. Doing so does 264 not effect the protocol operation and is not in scope of this 265 document. 267 Certificate requests for certificates whose purpose is a specific 268 solution are encouraged to conform to the solution's profile, e.g. 269 [RFC4945] section 5 for IKE/IPsec certificates. 271 2.1.2. Certification Authority 273 An SCEP Certification Authority (CA) is the entity that signs client 274 certificates. The CAs name appears in the issuer field of resulting 275 certificates. 277 Before any PKI operations can occur, the SCEP CA server obtains a 278 'CA' certificate that matches the profile in [RFC5280]. This MAY be 279 a CA certificate that was issued by a higher level CA. 281 The SCEP server CA certificate MUST be provided out-of-band to the 282 SCEP requester. The CA certificate fingerprint MAY be used to 283 authenticate a CA Certificate distributed by the GetCACert response 284 (Section 4.1.1). The fingerprint is created by calculating a SHA-1, 285 SHA-256, SHA-512, or MD5 hash on the whole CA certificate. 287 The certification authority MUST either include a 288 cRLDistributionPoint extension in every certificate it issues or 289 answer CRL queries itself, in which case it SHOULD be online at all 290 times. The certification authority SHOULD either answer certificate 291 queries or make certificates available via LDAP. 293 A certification authority may enforce any arbitrary policies, 294 including name uniqueness policies, and apply them to certification 295 requests. The certification authority MAY reject any request. If 296 the client has already been issued a certificate for this keypair the 297 server MAY return the previously created certificate. The requester 298 MUST NOT assume any of the fields in the certification request, 299 except for the public key, will be the same in the certificate 300 issued. 302 If a client times out from polling for a pending request it can 303 resynchronize by reissuing the original request with the original 304 subject name, key, and transaction ID. The CA SHOULD return the 305 status of the original transaction, including the certificate if it 306 was granted. The CA SHOULD NOT create a new transaction unless the 307 original certificate has been revoked, or the transaction arrives 308 more than halfway through the validity period of the original 309 certificate. 311 2.1.3. Registration Authority 313 An SCEP Registration Authority (RA) is an SCEP server that performs 314 validation and authorization checks of the SCEP requester but 315 forwards the certification requests to the CA. The RAs name does not 316 appear in the issuer field of resulting certificates. 318 The RA MUST return the RA certificate, in addition to the CA 319 certificate, in the GetCACert Response (see Section 5.2.1.1.2). The 320 existence of an RA certificate in this response indicates to the 321 client that an RA is in use. In order to securely communicate with 322 an RA using SCEP Secure Message Objects (Section 3) the client MUST 323 use the RA's keys instead of the CA's keys to sign the messages. 325 In order to service certification requests the RA must pass the 326 requests to the CA server for signing. The RA MAY use SCEP to 327 communicate with the CA, in which case the RA acts as both an SCEP 328 server (between the client and the RA) and an SCEP requester (between 329 the RA and the CA). The RA MAY respond to client certificate 330 requests with a PENDING response while communicating with the CA; for 331 example if the CA must manually authorize a certification request and 332 thus returns PENDING to the RA the RA may respond with PENDING to the 333 client while polling the CA. 335 Communication between the RA and the CA MAY be over other protocols 336 such as Certificate Management over CMS [RFC5272]. 338 2.2. Requester authentication 340 As with every protocol that uses public-key cryptography, the 341 association between the public keys used in the protocol and the 342 identities with which they are associated must be authenticated in a 343 cryptographically secure manner. This requirement is needed to 344 prevent a "man-in-the-middle" attack, in which an adversary can 345 manipulate the data as it travels between the protocol participants 346 and subvert the security of the protocol. 348 The communication between the requester and the certification 349 authority are secured using SCEP Secure Message Objects (Section 3) 350 which specifies how PKCS#7 [RFC2315] is used to encrypt and sign the 351 data. In order to perform the signing operation the client uses an 352 appropriate local certificate: 354 1. If the requesting system already has a certificate issued by the 355 SCEP server, and the server supports RENEWAL (see Appendix C), 356 that certificate SHOULD be used. 358 2. If the requesting system has no certificate issued by the new CA, 359 but has credentials from an alternate CA the certificate issued 360 by the alternate CA MAY be used. Policy settings on the new CA 361 will determine if the request can be accepted or not. This is 362 useful when enrolling with a new administrative domain; by using 363 a certificate from the old domain as credentials. 365 3. If the requester does not have an appropriate existing 366 certificate, then a locally generated self-signed certificate 367 MUST be used instead. The self-signed certificate MUST use the 368 same subject name as in the PKCS#10 request. 370 During the certificate enrollment, the requester MUST use the 371 selected certificate to sign the PKCS#7 [RFC2315] (see Section 3). 372 The server CertResp uses this signing certificate when encrypting the 373 response (see Section 3.2.2). 375 When the certification authority creates the PKCS#7 [RFC2315] 376 envelope on the issued certificate, it SHOULD use the public key, 377 issuer name, and serial number conveyed in the above included 378 certificate. This will inform the end entity of which private key 379 should be used to open the envelope. Note that when a client enrolls 380 for separate encryption and signature certificates, it MAY use the 381 signature certificate to sign both requests, and then expect its 382 signature key to be used to encrypt both responses. In any case, the 383 RecipientInfo on the envelope MUST reflect the key used to encrypt 384 the request. 386 2.3. Enrollment authorization 388 There are two mechanisms for automated enrollment authorization. 390 Since the client uses an existing certificate to sign SCEP messages 391 the server MAY use this certificate to authenticate the client and 392 determine the appropriate authorization. In addition to the policy 393 requirements implied by optional support of RENEWAL, see Appendix D, 394 the SCEP server SHOULD implement appropriate logic to support client 395 authentication and automated enrollment using existing client 396 credentials that were issued by an alternate PKI hierarchy. 398 Additionally PKCS#10 [RFC2986] specifies the use of a PKCS#9 400 [RFC2985] challengePassword attribute to be sent as part of the 401 enrollment request. SCEP optionally uses this challengePassword to 402 allow for unauthenticated authorization of enrollment requests. The 403 PKCS#7 [RFC2315] envelope protects the privacy of the challenge 404 password. 406 When utilizing the challengePassword, the server distributes a shared 407 secret to the requester which will uniquely associate the enrollment 408 request with the requester. The distribution of the secret must be 409 private: only the end entity should know this secret. If a 410 challengePassword is provided by the CA operator the client SHOULD 411 use this in the certification request. The actual binding mechanism 412 between the requester and the secret is subject to the server policy 413 and implementation. . The requester MAY use any of the requester 414 authentication mechanisms to provide additional authentication 415 material, although the server MAY ignore everything but the 416 challengePassword. 418 In the manual mode the requester's messages wait, or are placed in 419 the PENDING state, until the CA operator authorizes or rejects them. 420 Manual authorization is used when the client has only a self-signed 421 certificate and/or a challengePassword is not available.. 423 The requester generates a SHA-1, SHA-256, SHA-512, or MD5 424 'fingerprint' of the PKCS#10 [RFC2986] (before PKCS#7 [RFC2315] 425 enveloping and signing). This fingerprint is sent to the CA operator 426 using an out-of-band method. The CA operator MUST compared this 427 fingerprint to a locally generated fingerprint based on the message 428 received during the SCEP exchange. 430 SCEP clients and CAs (or RAs, if appropriate) MUST support display of 431 this fingerprint to the operator to enable this authorization method. 432 The out-of-band distribution and comparison of fingerprints is not 433 covered by this document. 435 2.4. CA/RA Certificate Distribution 437 If the CA and/or RA certificates have not previously been acquired by 438 the requester in some other means, the requester MUST retrieve the 439 CA/RA certificates before any PKI operation (Section 3) can be 440 started. 442 Since no public key has yet been exchanged between the requester and 443 the CA/RA, the messages cannot be secured using PKCS#7 [RFC2315], and 444 the data is instead transferred in the clear. 446 If an RA is in use, a certificates-only PKCS#7 [RFC2315] SignedData 447 with a certificate chain consisting of both RA and CA certificates is 448 returned. Otherwise the CA certificate itself is returned. The 449 transport protocol (Section 5) MUST indicate which one is returned. 451 After the requester gets the CA certificate, it MUST authenticate the 452 CA certificate by comparing the CA certificate fingerprint (see 453 Section 2.1.2) with the locally configured, out-of-band distributed, 454 identifying information. 456 Since the optional RA certificates are signed by the CA there is no 457 need to authenticate them against the out-of-band data. Clients MUST 458 verify the RA certificate signature before use during protocol 459 exchanges. Clients MUST verify the authorization of the RA 460 certificates. The authorization mechanism is specified by the CA 461 administrator and is out of scope for this document. 463 Because a long time can pass between queries from a requester to a 464 CA/RA and because RA certificates can change at any time, it is 465 recommended that a requester not store RA certificates. Instead, the 466 requester SHOULD retrieve the CA/RA certificates before each 467 operation. 469 2.5. Certificate Enrollment 471 A requester starts an enrollment (Section 3.2.1) transaction by 472 creating a certificate request using PKCS#10 [RFC2986] and sends it 473 to the CA/RA enveloped using the PKCS#7 (Section 3). 475 It is up to local CA policy (and CA implementation) as to whether a 476 certificate is granted automatically, or whether it is manually 477 granted by the administrator. The challengePassword MAY be used to 478 automatically authenticate the request. 480 If the CA/RA returns a CertRep (Section 3.2.2) message with status 481 set to PENDING, the requester enters into polling mode by 482 periodically sending a GetCertInitial (Section 3.2.3) PKI message to 483 the CA/RA, until the CA/RA operator completes the manual 484 authentication (approving or denying the request). 486 In general, the requester will send a single PKCSReq (Section 3.2.1) 487 message, followed by 0 or more GetCertInitial (Section 3.2.3) 488 messages, if polling mode is entered. 490 In general, the CA/RA will send 0 or more CertRep (Section 3.2.2) 491 messages with status set to PENDING, followed by a single CertRep 492 (Section 3.2.2) with status set to either SUCCESS or FAILURE. 494 2.5.1. Client State Transitions 496 The requester state transitions during enrollment operation are 497 indicated in Figure 1. 498 GetCertInitial 499 +----<---+ 500 | | CertRep(PENDING), 501 | | GetCertInitial send-timeout, 502 | | new-poll timer 503 | | 504 [CERT-NONEXISTANT] -----+---> [CERT-REQ-PENDING] [CERT-ISSUED] 505 ^ PKCSReq | | ^ 506 | | | | 507 | | +---------------+ 508 | | CertRep(SUCCESS) 509 +--------------------------+ 510 CertRep(FAILURE), 511 PKCSReq send-timeout, 512 max-time/max-polls exceeded 514 Figure 1: State Transition Diagram 516 Certificate enrollment starts at the state CERT-NONEXISTANT. 518 Sending a PKCSReq message changes the state to CERT-REQ-PENDING. If 519 there is no response, or sending is not possible, the state reverts 520 back to CERT-NONEXISTANT. 522 Receiving a CertRep message with pkiStatus set to SUCCESS changes the 523 state to CERT-ISSUED. 525 Receiving a CertRep message with pkiStatus set to FAILURE changes the 526 state to CERT-NONEXISTANT. 528 If the server sends back a CertRep message with pkiStatus set to 529 PENDING, the requester will keep polling by sending a GetCertInitial 530 message to the server, until either a CertRep message with status set 531 to SUCCESS or FAILURE is received, or the maximum number of polls has 532 been exceeded. 534 If the maximum number of polls has been exceeded or a CertRep message 535 with pkiStatus set to FAILURE is received while in the CERT-REQ- 536 PENDING state, the end entity will transition to the CERT-NONEXISTANT 537 state, and the SCEP client can eventually initiate another enrollment 538 request. It is important to note that, as long as the requester does 539 not change its subject name or keys, the same transaction ID will be 540 used in the "new" transaction. This is important because based on 541 this transaction ID, the certification authority can recognize this 542 as an existing transaction instead of a new one. 544 A successful transaction in automatic mode: 545 REQUESTER CA SERVER 547 PKCSReq: PKI cert. enrollment msg 548 --------------------------------> CertRep: pkiStatus = SUCCESS 549 certificate attached 550 <------------------------------ 551 Receive issued certificate. 553 Figure 2: Automatic mode transaction 555 A successful transaction in manual mode: 556 REQUESTER CA SERVER 557 PKCSReq: PKI cert. enrollment msg 558 --------------------------------> CertRep: pkiStatus = PENDING 559 <------------------------------ 560 GetCertInitial: polling msg 561 --------------------------------> CertRep: pkiStatus = PENDING 562 <------------------------------ 563 ................ ............... 565 GetCertInitial: polling msg 566 --------------------------------> CertRep: pkiStatus = SUCCESS 567 certificate attached 568 <------------------------------ 569 Receive issued certificate. 571 Figure 3: Manual mode transaction 573 2.6. Certificate Access 575 There are two methods to query certificates. The first method is to 576 use LDAP as a query protocol. Using LDAP to query assumes the client 577 understands the LDAP scheme supported by the CA. The SCEP client 578 assumes that the subject DN in the certificate is used as the URL to 579 query the certificate. The standard attributes (userCertificate and 580 caCertificate) are used as filter. 582 For the environment where LDAP is not available, a certificate query 583 message is defined to retrieve the certificates from the CA. 585 To query a certificate from the certification authority, a requester 586 sends a request consisting of the certificate's issuer name and 587 serial number. This assumes that the requester has saved the issuer 588 name and the serial number of the issued certificate from the 589 previous enrollment transaction. The transaction to query a 590 certificate consists of one GetCert (Section 3.2.4) message and one 591 CertRep (Section 3.2.2) message, as shown in Figure 4. 592 REQUESTER CA SERVER 593 GetCert: PKI certificate query msg 594 -------------------------------> CertRep: pkiStatus = SUCCESS 595 certificate attached 596 <----------------------------- 597 Receive the certificate. 599 Figure 4: GetCert Transaction 601 2.7. CRL Access 603 SCEP clients request a CRL via one of two methods: 605 1. If the CA supports CRL Distribution Points [RFC5280] (section 606 4.2.1.13), then the CRL MUST be retrieved via the mechanism 607 specified in the CDP. 609 2. If the CA does not support CDP's, a CRL query is composed by 610 creating a GetCRL message consisting of the issuer name and 611 serial number from a certificate within the scope of the CRL to 612 be retrieved (e.g. from a certificate to be validated). 614 The server SHOULD NOT support the GetCRL method because: 616 o it does not scale well due to the unnecessary cryptography (see, 617 Section 8.8) 619 o it requires the CA to be a high-availability service 621 o only limited information to determine the CRL scope is provided 622 (see [RFC5280] Section 5). 624 The message is sent to the SCEP server in the same way as the other 625 SCEP requests: The transaction to retrieve a CRL consists of one 626 GetCRL PKI message and one CertRep PKI message, which contains only 627 the CRL (no certificates), as shown in Figure 5. 629 On receipt of this message, the SCEP server MAY use the 630 IssuerAndSerial information to return an appropriate CRL. 632 REQUESTER CA SERVER 633 GetCRL: PKI CRL query msg 634 ----------------------------------> 635 CertRep: CRL attached 636 <-------------------------------- 638 Figure 5: GetCRL Transaction 640 2.8. Certificate Revocation 642 SCEP does not specify a method to request certificate revocation. 644 In order to revoke a certificate, the requester must contact the CA 645 server operator using a non-SCEP defined mechanism. Although the 646 PKCS#10 [RFC2986] challengePassword is used by SCEP for enrollment 647 authorization (see Enrollment authorization (Section 2.3)) this does 648 not inhibit the CA server from maintaining a record of the 649 challengePassword to use during subsequent revocation operations as 650 implied by [RFC2985]. 652 3. SCEP Secure Message Objects 654 PKCS#7 [RFC2315] is a general enveloping mechanism that enables both 655 signed and encrypted transmission of arbitrary data. 657 All messages MUST be valid PKCS#7 [RFC2315] structures, unless 658 otherwise noted. 660 SCEP messages that require confidentiality use two layers of PKCS#7, 661 as shown in Figure 6. By applying both enveloping and signing 662 transformations, the SCEP message is protected both for the integrity 663 of its end-to-end transaction information and the confidentiality of 664 its information portion. The advantage of this technique over the 665 conventional transaction message format is that the signed 666 transaction type information and the status of the transaction can be 667 determined prior to invoking security handling procedures specific to 668 the information portion being processed. 670 Some messages do not require enveloping, in which case the 671 EnvelopedData in Figure 6 is omitted. 673 ContentType = SignedData (called pkiMessage) 674 SignerInfo 675 Signature 676 authenticatedAttributes 677 transactionID 678 messageType 679 pkiStatus 680 failInfo 681 senderNonce 682 recipientNonce 683 etc 684 ContentInfo type = EnvelopedData (called pkcsPKIEnvelope; optional) 685 RecipientInfo 686 ContentInfo type = Data 687 messageData 689 Figure 6: PKCS#7 Layering 691 Description: 693 o The outer PKCS#7 is a pkiMessage (Section 3.1). 695 o The SignedData ContentInfo, if present (e.g. FAILURE and PENDING 696 CertRep messages will lack any signed content), MUST be a 697 pkcsPKIEnvelope (Section 3.1.2). 699 When a particular SCEP message carries data, this data is carried in 700 the messageData. 702 Note: The remainder of this document will refer only to 703 'messageData', but it is understood to always be encapsulated in the 704 pkcsPKIEnvelope (Section 3.1.2). The format of the data in the 705 messageData is defined by the messageType attribute (see 706 Section 3.1.1) of the SignedData. If there is no messageData to be 707 transmitted, the entire pkcsPKIEnvelope MUST be omitted. 709 3.1. SCEP pkiMessage 711 The basic building block of all secured SCEP messages is the SCEP 712 pkiMessage. It consists of an PKCS#7 signed-data content type, as 713 defined in PKCS#7 [RFC2315] Section 9. The following restrictions 714 apply: 716 o version MUST be 1 718 o the contentType in contentInfo MUST be data ({pkcs-7 1}) as 719 defined in PKCS#7 [RFC2315] Section 8. 721 o The signed content, if present (e.g. FAILURE and PENDING CertRep 722 messages will lack any signed content), MUST be a pkcsPKIEnvelope 723 (Section 3.1.2), and must match the messageType attribute. 725 o The SignerInfo MUST contain a set of authenticatedAttributes (see 726 PKCS#7 [RFC2315] Section 9.2 as well as Section 3.1.1 in this 727 document). All messages MUST contain 729 * an SCEP transactionID attribute 731 * an SCEP messageType attribute 733 * an SCEP senderNonce attribute 735 * any attributes required by PKCS#7 [RFC2315] section 9.2 737 If the message is a response, it MUST also include 739 * an SCEP pkiStatus attribute 741 * an SCEP recipientNonce attribute 743 3.1.1. Signed Transaction Attributes 745 The following transaction attributes are encoded as authenticated 746 attributes, and are carried, as specified in PKCS#7 [RFC2315] Section 747 9.2, in the SignerInfo for this signedData. 749 Please refer to Appendix A for the OID definitions. 751 +----------------+-----------------+---------------------------+ 752 | Attribute | Encoding | Comment | 753 +----------------+-----------------+---------------------------+ 754 | transactionID | PrintableString | Hash value as a string | 755 | messageType | PrintableString | Decimal value as a string | 756 | pkiStatus | PrintableString | Decimal value as a string | 757 | failInfo | PrintableString | Decimal value as a string | 758 | senderNonce | OCTET STRING | | 759 | recipientNonce | OCTET STRING | | 760 +----------------+-----------------+---------------------------+ 762 Transaction Attributes 764 The attributes are detailed in the following sections. 766 3.1.1.1. transactionID 768 A PKI operation is a transaction consisting of the messages exchanged 769 between a requester and the server. The transaction identifier is a 770 string generated by the client when starting a transaction. The 771 client MUST generate a unique string as the transaction identifier, 772 which MUST be used for all PKI messages exchanged for a given 773 enrollment, encoded as a PrintableString. 775 The transaction identifier SHOULD be generated as a SHA-1, SHA-256, 776 SHA-512 or MD5 hash on the public key value for which the enrollment 777 request is made. This allows the SCEP client to automatically 778 generate the same transaction id for any given keypair. The SCEP 779 protocol requires that transaction identifiers be unique, so that 780 subsequent polling queries can be matched with previous transactions. 781 Thus, if separate signing and encryption certificates are requested 782 by the client the keys must be different. 784 When using the certificate query and CRL query messages defined in 785 this protocol, the transaction identifier is still required so that 786 the requester can match the response message with the outstanding 787 request message. When using LDAP to query the certificate and the 788 CRL, the behavior is specified by the LDAP protocol. For a non- 789 enrollment message (for example GetCert and GetCRL), the 790 transactionID SHOULD be a number unique to the client. 792 3.1.1.2. messageType 794 The messageType attribute specifies the type of operation performed 795 by the transaction. This attribute MUST be included in all PKI 796 messages. Currently, the following message types are defined: 798 o PKCSReq (19) -- PKCS#10 [RFC2986] certificate request 800 o CertRep (3) -- Response to certificate or CRL request 802 o GetCertInitial (20) -- Certificate polling in manual enrollment 804 o GetCert (21) -- Retrieve a certificate 806 o GetCRL (22) -- Retrieve a CRL 808 3.1.1.3. pkiStatus 810 All response messages MUST include transaction status information, 811 which is defined as pkiStatus attribute: 813 o SUCCESS (0) -- request granted 815 o FAILURE (2) -- request rejected. When pkiStatus is FAILURE, the 816 failInfo attribute, as defined in Section 3.1.1.4, MUST also be 817 present. 819 o PENDING (3) -- request pending for manual approval 821 3.1.1.4. failInfo 823 The failInfo attribute MUST contain one of the following failure 824 reasons: 826 o badAlg (0) -- Unrecognized or unsupported algorithm identifier 828 o badMessageCheck (1) -- integrity check failed 830 o badRequest (2) -- transaction not permitted or supported 832 o badTime (3) -- The signingTime attribute from the PKCS#7 833 authenticatedAttributes was not sufficiently close to the system 834 time (see Section 3.1.1.6). 836 o badCertId (4) -- No certificate could be identified matching the 837 provided criteria 839 3.1.1.5. senderNonce and recipientNonce 841 The attributes of senderNonce and recipientNonce are 16 byte random 842 numbers generated for each transaction to prevent replay attacks. 844 When a requester sends a PKI message to the server, a senderNonce 845 MUST be included in the message. 847 The recipient SHOULD copy the senderNonce into the recipientNonce of 848 the reply as a proof of liveliness. 850 The requester SHOULD verify that the recipientNonce of the reply 851 matches the senderNonce it sent in the request. 853 3.1.1.6. signingTime Attribute 855 The signingTime Attribute is defined in [RFC2985] Section 5.3.3, and 856 is carried as defined in a [RFC2315] authenticated attribute (Section 857 9.2). This attribute is optional. 859 3.1.2. SCEP pkcsPKIEnvelope 861 The information portion of a SCEP message is carried inside an 862 enveloped-data content type, as defined in PKCS#7 [RFC2315] Section 863 10, with the following restrictions: 865 o version MUST be 0 867 o contentType in encryptedContentInfo MUST be data ({pkcs-7 1}) as 868 defined in PKCS#7 [RFC2315] Section 8. 870 o encryptedContent MUST be the SCEP message being transported (see 871 Section 4), and must match the messageType authenticated Attribute 872 in the pkiMessage. 874 The message is encrypted using the public key of the recipient of the 875 message, i.e. the RA or the CA public key (if sent from the 876 requester), or the requester public key (if sent as a reply to the 877 requester). 879 3.2. SCEP pkiMessage types 881 All of the messages in this section are pkiMessages (Section 3.1), 882 where the type of the message MUST be specified in the 'messageType' 883 authenticated Attribute. Each section defines a valid message type, 884 the corresponding messageData formats, and mandatory authenticated 885 attributes for that type. 887 3.2.1. PKCSReq 889 The messageData for this type consists of a DER-encoded PKCS#10 890 Certification Request [RFC2986]. The certification request MAY 891 contain any fields defined in PKCS#10 [RFC2986], and MUST contain at 892 least the following items: 894 o the subject Distinguished Name 896 o the subject public key 898 o a challengePassword attribute. The Challenge Password may be used 899 to (out-of-band) authenticate the enrollment request itself, or in 900 an out-of-band revocation request for the issued certificate. 902 In addition to the authenticatedAttributes required for a valid 903 PKCS#7 [RFC2315], this pkiMessage MUST include the following 904 attributes: 906 o a transactionID (Section 3.1.1.1) attribute 908 o a messageType (Section 3.1.1.2) attribute set to PKCSReq 910 o a senderNonce (Section 3.1.1.5) attribute 912 The pkcsPKIEnvelope for this message type is encrypted using the 913 public key of the recipient, i.e. the CA or RA public key. 915 3.2.2. CertRep 917 The messageData for this type consists of a DER-encoded degenerate 918 certificates-only Signed-data (Section 3.3). The exact contents 919 required for certain CertRep replies depends on the type of request 920 this message is a reply to and is detailed in Table 1 and in 921 Section 4. 923 In addition to the authenticatedAttributes required for a valid 924 PKCS#7 [RFC2315], this pkiMessage MUST include the following 925 attributes: 927 o the transactionID (Section 3.1.1.1) attribute copied from the 928 request we are responding to 930 o a messageType (Section 3.1.1.2) attribute set to CertRep 932 o a senderNonce (Section 3.1.1.5) attribute 934 o a recipientNonce attribute (Section 3.1.1.5) copied from the 935 senderNonce from the request we are responding to. 937 o a pkiStatus (Section 3.1.1.3) set to the status of the reply. 939 The pkcsPKIEnvelope of a CertRep (if present), MUST be encrypted with 940 the same certificate used to sign the PKCSReq this message is a reply 941 to, according to section 10 in PKCS#7 [RFC2315]. This means that if 942 a self-signed certificate was used to send the request, this self- 943 signed certificate will be reflected in the recipientInfo field of 944 the envelopedData, in accordance with PKCS#7 [RFC2315] section 10. 946 3.2.2.1. CertRep SUCCESS 948 When the pkiStatus attribute is set to SUCCESS, the messageData for 949 this message consists of a DER-encoded degenerate certificates-only 950 Signed-data (Section 3.3). The contents of this degenerate 951 certificates-only Signed-Data depends on what the original request 952 was, as outlined in Table 1. 954 +----------------+--------------------------------------------------+ 955 | Request-type | Reply-contents | 956 +----------------+--------------------------------------------------+ 957 | PKCSReq | the reply MUST contain at least the issued | 958 | | certificate in the certificates field of the | 959 | | Signed-Data. The reply MAY contain additional | 960 | | certificates, but the issued certificate MUST be | 961 | | the first in the list. The reply MUST NOT | 962 | | contain any CRL's. All returned certificates | 963 | | MUST conform to [RFC5280]. | 964 | GetCertInitial | same as PKCSReq | 965 | GetCert | the reply MUST contain at least the requested | 966 | | certificate in the certificates field of the | 967 | | Signed-Data. The reply MAY contain additional | 968 | | certificates, but the requested certificate MUST | 969 | | be the first in the list. The reply MUST NOT | 970 | | contain any CRL's. All returned certificates | 971 | | MUST conform to [RFC5280]. | 972 | GetCRL | the reply MUST contain the CRL in the crls field | 973 | | of the Signed-Data. The reply MUST NOT contain | 974 | | any certificates. The CRL MUST be a valid CRL | 975 | | according to [RFC5280]. | 976 +----------------+--------------------------------------------------+ 978 Table 1: CertRep Types 980 3.2.2.2. CertRep FAILURE 982 When the pkiStatus attribute is set to FAILURE, the reply MUST also 983 contain a failInfo (Section 3.1.1.4) attribute set to the appropriate 984 error condition describing the failure. The pkcsPKIEnvelope 985 (Section 3.1.2) MUST be omitted. 987 3.2.2.3. CertRep PENDING 989 When the pkiStatus attribute is set to PENDING, the pkcsPKIEnvelope 990 (Section 3.1.2) MUST be omitted. 992 3.2.3. GetCertInitial 994 The messageData for this type consists of a DER-encoded 995 IssuerAndSubject (Section 3.2.3.1). The issuer is set to the 996 issuerName from the certification authority from which we are issued 997 certificates. The Subject is set to the SubjectName we used when 998 requesting the certificate. 1000 In addition to the authenticatedAttributes required for a valid 1001 PKCS#7 [RFC2315], this pkiMessage MUST include the following 1002 attributes: 1004 o the same transactionID (Section 3.1.1.1) attribute from original 1005 PKCSReq message 1007 o a messageType (Section 3.1.1.2) attribute set to GetCertInitial 1009 o a senderNonce (Section 3.1.1.5) attribute 1011 3.2.3.1. IssuerAndSubject 1013 Similar to the IssuerAndSerial defined in PKCS#7 [RFC2315] Section 1014 6.7, we need to define an IssuerAndSubject ASN.1 type (Figure 7). 1016 The ASN.1 definition of the issuerAndSubject type is as follows: 1017 issuerAndSubject ::= SEQUENCE { 1018 issuer Name, 1019 subject Name 1020 } 1022 Figure 7: IssuerAndSubject ASN.1 1024 3.2.4. GetCert 1026 The messageData for this type consists of a DER-encoded 1027 IssuerAndSerial as defined in PKCS#7 [RFC2315] Section 6.7 containing 1028 the "distinguished name of the certificate issuer and an issuer- 1029 specific certificate serial number" which uniquely identifies the 1030 certificate being requested. 1032 In addition to the authenticatedAttributes required for a valid 1033 PKCS#7 [RFC2315], this pkiMessage MUST include the following 1034 attributes: 1036 o a transactionID (Section 3.1.1.1) attribute 1038 o a messageType (Section 3.1.1.2) attribute set to PKCSReq 1040 o a senderNonce (Section 3.1.1.5) attribute 1042 A self-signed certificate MAY be used in the signed envelope. This 1043 enables the requester to request their own certificate if they were 1044 unable to store it previously. 1046 3.2.5. GetCRL 1048 The messageData for this type consists of a DER-encoded 1049 IssuerAndSerial as defined in PKCS#7 [RFC2315] Section 6.7 the issuer 1050 name and serial number from the certificate to be validated. 1052 In addition to the authenticatedAttributes required for a valid 1053 PKCS#7 [RFC2315], this pkiMessage MUST include the following 1054 attributes: 1056 o a transactionID (Section 3.1.1.1) attribute 1058 o a messageType (Section 3.1.1.2) attribute set to PKCSReq 1060 o a senderNonce (Section 3.1.1.5) attribute 1062 3.3. Degenerate certificates-only PKCS#7 Signed-data 1064 [RFC2315] section 9 includes a degenerate case of the PKCS#7 Signed- 1065 data content type, in which there are no signers. The use of such a 1066 degenerate case is to disseminate certificates and certificate- 1067 revocation lists. For SCEP the content field of the ContentInfo 1068 value of a degenerate certificates-only Signed-Data MUST be omitted. 1070 When carrying certificates, the certificates are included in the 1071 'certificates' field of the Signed-Data. When carrying a CRL, the 1072 CRL will be included in the 'crls' field of the Signed-Data. 1074 4. SCEP Transactions 1076 This section describes the SCEP Transactions, without explaining the 1077 transport. The transport of each message is discussed in Section 5. 1078 Some of the transaction-requests have no data to send, i.e. the only 1079 data is the message-type itself (e.g. a GetCACert message has no 1080 additional data). The use of such messages will become clearer in 1081 Section 5. 1083 In this section, each SCEP transaction is specified in terms of the 1084 complete messages exchanged during the transaction. 1086 The order of the transactions in this section is mirrored in 1087 Section 5.2 for better organization and readability. 1089 4.1. Get CA Certificate 1091 To get the CA certificate(s), the requester sends a GetCACert message 1092 to the server. There is no request data associated with this message 1093 (see Section 5.2.1). 1095 4.1.1. Get CA Certificate Response Message Format 1097 The response depends on whether the responding server has RA 1098 certificates or only a single CA certificate. The server MUST 1099 indicate which response it is sending via the transport protocol used 1100 (see Section 5.2.1). 1102 All returned certificates MUST conform to [RFC5280]. 1104 Once the CA certificate is received by the requester (regardless of 1105 the presence of RA certificates), a fingerprint is generated using 1106 the SHA1, SHA256, SHA512 or MD5 hash algorithm on the whole CA 1107 certificate. If the requester does not have a certificate path to a 1108 trusted CA certificate, this fingerprint may be used to verify the 1109 certificate, by some positive out-of-band means, such as a phone call 1110 or pre-provisioning. 1112 4.1.1.1. CA Certificate Response Message Format 1114 If the server is a certification authority and does not have any RA 1115 Certificates, the response consists of a single DER-encoded X.509 CA 1116 certificate. 1118 4.1.1.2. CA/RA Certificate Response Message Format 1120 If the server has RA Certificates, the response consists of a DER- 1121 encoded degenerate certificates-only Signed-data (Section 3.3) 1122 containing the CA certificate and RA certificates. 1124 4.2. Certificate Enrollment 1126 A PKCSReq (Section 3.2.1) message is used to perform a certificate 1127 enrollment transaction. 1129 The reply MUST be a CertRep (Section 3.2.2) message sent back from 1130 the server, indicating SUCCESS, FAILURE, or PENDING. 1132 Precondition: Both the requester and the certification authority have 1133 completed their initialization process. The requester has already 1134 been configured with the CA/RA certificate. 1136 Postcondition: Either the certificate is received by the requester, 1137 or the end entity is notified to do the manual authentication, or the 1138 request is rejected. 1140 4.2.1. Certificate Enrollment Response Message 1142 If the request is granted, a CertRep (Section 3.2.2) message with 1143 pkiStatus set to SUCCESS is returned. The reply MUST also contain 1144 the certificate (and MAY contain any other certificates needed by the 1145 requester). The issued certificate MUST be the first in the list. 1147 If the request is rejected, a CertRep (Section 3.2.2) message with 1148 pkiStatus set to FAILURE is returned. The reply MUST also contain a 1149 failInfo attribute. 1151 If the the CA is configured to manually authenticate the requester, a 1152 CertRep (Section 3.2.2) message with pkiStatus set to 'PENDING' MAY 1153 be returned. 1155 4.3. Poll for Requester Initial Certificate 1157 Triggered by a CertRep (Section 3.2.2) with pkiStatus set to PENDING, 1158 a requester will enter the polling state by periodically sending 1159 GetCertInitial (Section 3.2.3) to the server, until either the 1160 request is granted and the certificate is sent back, or the request 1161 is rejected, or the configured time limit for polling (or maximum 1162 number of polls) is exceeded. 1164 Since GetCertInitial is part of the enrollment, the messages 1165 exchanged during the polling period MUST carry the same transactionID 1166 attribute as the previous PKCSReq. A server receiving a 1167 GetCertInitial for which it does not have a matching PKCSReq MUST 1168 ignore this request. 1170 Since at this time the certificate has not been issued, the requester 1171 can only use its own subject name (which was contained in the 1172 original PKCS#10 sent via PKCSReq) to identify the polled certificate 1173 request. Since there can be multiple outstanding requests from one 1174 requester (for example, if different keys and different key-usages 1175 were used to request multiple certificates), the transaction ID must 1176 also be included, to disambiguate between multiple requests. 1178 PreCondition: The requester has received a CertRep with pkiStatus set 1179 to PENDING. 1181 PostCondition: The requester has either received a valid response, 1182 which could be either a valid certificate (pkiStatus = SUCCESS), or a 1183 FAILURE message, or the polling period times out. 1185 4.3.1. Polling Response Message Format 1187 The response messages for GetCertInitial are the same as in 1188 Section 4.2.1. 1190 4.4. Certificate Access 1192 The certificate query message is an option when the LDAP server is 1193 not available to provide the certificate query. A requester should 1194 be able to query an issued certificate from the certification 1195 authority, as long as the issuer name and the issuer assigned 1196 certificate serial number is known to the requesting end entity. 1197 This transaction is not intended to provide the service as a 1198 certificate directory service. A more complicated query mechanism 1199 would have to be defined in order to allow a requester to query a 1200 certificate using various different fields. 1202 This transaction consists of one GetCert (Section 3.2.4) message sent 1203 to the server by a requester, and one CertRep (Section 3.2.2) message 1204 sent back from the server. 1206 PreCondition: The queried certificate have been issued by the 1207 certification authority and the issuer assigned serial number is 1208 known. 1210 PostCondition: Either the certificate is sent back or the request is 1211 rejected. 1213 4.4.1. Certificate Access Response Message Format 1215 In this case, the CertRep from the server is same as in 1216 Section 4.2.1, except that the server will only either grant the 1217 request (SUCCESS) or reject the request (FAILURE). 1219 4.5. CRL Access 1221 Clients MAY request a CRL from the SCEP server as described in 1222 Section 2.7. 1224 PreCondition: The certification authority certificate has been 1225 downloaded to the end entity. 1227 PostCondition: CRL sent back to the requester. 1229 4.5.1. CRL Access Response Message Format 1231 The CRL is sent back to the requester in a CertRep (Section 3.2.2) 1232 message. The information portion of this message is a degenerate 1233 certificates-only Signed-data (Section 3.3) which contains only the 1234 most recent CRL in the crls field of the Signed-Data. 1236 The server MAY return any appropriate CRL. 1238 4.6. Get Next Certification Authority Certificate 1240 When a CA certificate is about to expire, clients need to retrieve 1241 the CA's next CA certificate (i.e. the Rollover Certificate). This 1242 is done via the GetNextCACert message. There is no request data 1243 associated with this message (see Section 5.2.6). 1245 4.6.1. Get Next CA Response Message Format 1247 The response consists of a SignedData PKCS#7 [RFC2315], signed by the 1248 current CA (or RA) signing key. 1250 Clients MUST validate the signature on the the SignedData PKCS#7 1251 [RFC2315] before accepting any of its contents. 1253 The content of the SignedData PKCS#7 [RFC2315] is a degenerate 1254 certificates-only Signed-data (Section 3.3) message containing the 1255 new CA certificate and any new RA certificates, as defined in 1256 Section 5.2.1.1.2, to be used when the current CA certificate 1257 expires. 1259 If the CA (or RA) does not have the Rollover certificate(s) it MUST 1260 reject the request. It SHOULD also remove the GetNextCACert setting 1261 from the capabilities until it does have rollover certificates. 1263 If there are any RA certificates in this response, clients MUST check 1264 that these RA certificates are signed by the CA, and MUST check 1265 authorization of these RA certificates (see Section 2.1.3). 1267 5. SCEP Transport 1269 HTTP is used as the transport protocol for SCEP Message Objects. 1271 5.1. HTTP "GET" Message Format 1273 SCEP uses the HTTP "GET" messages to request information from the CA. 1274 The following is the syntax definition of a HTTP GET message sent 1275 from a requester to a certification authority server: 1276 "GET" CGI-PATH CGI-PROG "?operation=" OPERATION "&message=" MESSAGE 1278 where: 1280 o CGI-PATH defines the actual CGI path to invoke the CGI program 1281 that parses the request. 1283 o CGI-PROG is set to be the string "pkiclient.exe". This is 1284 intended to be the program that the CA will use to handle the SCEP 1285 transactions, though the CA may ignore CGI-PROG and use only the 1286 CGI-PATH. 1288 o OPERATION depends on the SCEP transaction and is defined in the 1289 following sections. 1291 o MESSAGE depends on the SCEP transaction and is defined in the 1292 following sections. 1294 If the CA supports it, requests may also be done via an HTTP POST. 1295 This is described in Appendix F. 1297 5.1.1. Response Message Format 1299 For each GET operation, the CA/RA server MUST return a Content-Type 1300 and appropriate response data, if any. 1302 5.2. SCEP HTTP Messages 1304 5.2.1. GetCACert 1306 OPERATION MUST be set to "GetCACert". 1308 MESSAGE MAY be omitted, or it MAY be a string that represents the 1309 certification authority issuer identifier, if such has been set by 1310 the CA Administrator. 1312 5.2.1.1. GetCACert Response 1314 The response for GetCACert is different between the case where the CA 1315 directly communicates with the requester during the enrollment, and 1316 the case where a RA exists and the requester communicates with the RA 1317 during the enrollment. 1319 5.2.1.1.1. CA Certificate Only Response 1321 The response will have a Content-Type of "application/ 1322 x-x509-ca-cert". 1324 The body of this response consists of a DER-encoded X.509 CA 1325 certificate, as defined in Section 4.1.1.1. 1326 "Content-Type:application/x-x509-ca-cert\n\n" 1328 5.2.1.1.2. CA and RA Certificates Response 1330 The response will have a Content-Type of "application/ 1331 x-x509-ca-ra-cert". 1333 The body of this response consists of a DER-encoded degenerate 1334 certificates-only Signed-data (Section 3.3) containing both CA and RA 1335 certificates, as defined in Section 4.1.1.2. 1336 "Content-Type:application/x-x509-ca-ra-cert\n\n" 1338 5.2.2. PKCSReq 1340 OPERATION MUST be set to "PKIOperation". 1342 MESSAGE consists of a base64-encoded DER-encoded PKCSReq SCEP 1343 message. 1345 An example PKIOperation request might look as follows: 1346 GET /cgi-bin/pkiclient.exe?operation=PKIOperation&message=MIAGCSqGSIb3D 1347 QEHA6CAMIACAQAxgDCBzAIBADB2MGIxETAPBgNVBAcTCE ......AAAAAA== HTTP/1.0 1349 5.2.2.1. PKCSReq Response 1351 The response will have a Content-Type of "application/x-pki-message". 1353 The body of this response consists of a DER-encoded CertRep SCEP 1354 message defined in Section 4.2.1. The following is an example of the 1355 response: 1356 "Content-Type:application/x-pki-message\n\n" 1358 5.2.3. GetCertInitial 1360 OPERATION MUST be set to "PKIOperation". 1362 MESSAGE consists of a base64-encoded DER-encoded GetCertInitial SCEP 1363 message. 1365 5.2.3.1. GetCertInitial Response 1367 The body of this response consists of a DER-encoded CertRep SCEP 1368 message defined in Section 4.3.1. 1370 5.2.4. GetCert 1372 OPERATION MUST be set to "PKIOperation". 1374 MESSAGE consists of a base64-encoded DER-encoded GetCert SCEP 1375 message. 1377 5.2.4.1. GetCert Response 1379 The body of this response consists of a DER-encoded CertRep SCEP 1380 message defined in Section 4.4.1. 1382 5.2.5. GetCRL 1384 OPERATION MUST be set to "PKIOperation". 1386 MESSAGE consists of a base64-encoded DER-encoded GetCRL SCEP message. 1388 5.2.5.1. GetCRL Response 1390 The body of this response consists of a DER-encoded CertRep SCEP 1391 message defined in Section 4.5.1. 1393 5.2.6. GetNextCACert 1395 OPERATION MUST be set to "GetNextCACert". 1397 MESSAGE MAY be ommitted, or it MAY be a string that represents the 1398 certification authority issuer identifier, if such has been set by 1399 the CA Administrator. 1401 5.2.6.1. GetNextCACert Response 1403 The response will have a Content-Type of "application/ 1404 x-x509-next-ca-cert". 1406 The body of this response consists of a SignedData PKCS#7 [RFC2315], 1407 as defined in Section 4.6.1. (This is similar to the GetCert 1408 response but does not include any of the attributes defined in 1409 Section 3.1.1.) 1410 "Content-Type:application/x-x509-next-ca-cert\n\n" 1411 > 1413 6. Contributors/Acknowledgements 1415 The editor would like to thank all the previous authors and 1416 contributors: Cheryl Madson, Xiaoyi Liu, David McGrew, David Cooper, 1417 etc for their work on the draft over the years. 1419 The authors would like to thank Peter William of ValiCert, Inc. 1420 (formerly of VeriSign, Inc.) and Alex Deacon of VeriSign, Inc. and 1421 Christopher Welles of IRE, Inc. for their contributions to early 1422 versions of this protocol and this document. 1424 7. IANA Considerations 1426 This memo includes no request to IANA. 1428 8. Security Considerations 1430 The security goals of SCEP are that no adversary can: 1432 o subvert the public key/identity binding from that intended, 1434 o discover the identity information in the enrollment requests and 1435 issued certificates, 1437 o cause the revocation of certificates with any non-negligible 1438 probability. 1440 Here an adversary is any entity other than the requester and the CA 1441 (and optionally the RA) participating in the protocol that is 1442 computationally limited, but that can manipulate data during 1443 transmission (that is, a man-in-the-middle). The precise meaning of 1444 'computationally limited' depends on the implementer's choice of 1445 cryptographic hash functions and ciphers. The required algorithms 1446 are RSA, DES and MD5. Depending on the CA capabilities (see 1447 Appendix C), Triple-DES MAY be used instead of DES, and SHA-1, SHA- 1448 256, or SHA-512 MAY be used instead of MD5. 1450 The first and second goals are met through the use of PKCS#7 1451 [RFC2315] and PKCS#10 [RFC2986] encryption and digital signatures 1452 using authenticated public keys. The CA's public key is 1453 authenticated via the checking of the CA fingerprint, as specified in 1454 Section 2.1.2, and the SCEP client's public key is authenticated 1455 through the manual authentication or pre-shared secret 1456 authentication, as specified in Section 2.2. The third goal is met 1457 through the use of a challenge password for revocation, which is 1458 chosen by the SCEP client and communicated to the CA protected by the 1459 PKCS#7 [RFC2315] encryptedData, as specified in Section 2.8. 1461 The motivation of the first security goal is straightforward. The 1462 motivation for the second security goal is to protect the identity 1463 information in the enrollment requests and certificates. For 1464 example, two IPSEC hosts behind a firewall may need to exchange 1465 certificates, and may need to enroll certificates with a CA that is 1466 outside of a firewall. 1468 Most networks with firewalls seek to prevent IP addresses and DNS 1469 information from the trusted network leaving that network. The 1470 second goal enables the hosts in this example to enroll with a CA 1471 outside the firewall without revealing this information. The 1472 motivation for the third security goal is to protect the SCEP clients 1473 from denial of service attacks. 1475 8.1. General Security 1477 Common key-management considerations such as keeping private keys 1478 truly private and using adequate lengths for symmetric and asymmetric 1479 keys must be followed in order to maintain the security of this 1480 protocol. 1482 This is especially true for CA keys, which, when compromised, 1483 compromise the security of all relying parties. 1485 8.2. Use of the CA keypair 1487 A CA key pair is generally meant for (and is usually flagged as) 1488 "certificate signing" (exclusively), rather than 'data signing' or 1489 'data encryption'. The SCEP protocol, however, uses the CA key pair 1490 to encrypt and sign PKCS#7 [RFC2315] transport messages, regardless 1491 of the key usage of the CA certificate. This is generally considered 1492 undesirable, as it widens the possibility of an implementation 1493 weakness, and provides 1495 o another place that the private key must be used (and hence is 1496 slightly more vulnerable to exposure), 1498 o another place where a side channel attack (say, timing or power 1499 analysis) might be used, 1501 o another place that the attacker might somehow insert his own text, 1502 and get it signed by the private key. 1504 While the CA key pair can be generated with the 'data encryption' and 1505 'data signing' flags set, this is operationally not encouraged. It 1506 would make using the key as a PKCS#7 [RFC2315] transport key 'legal', 1507 but the discussion from the previous paragraph still applies. 1509 A solution is to use RA keys to secure the SCEP transport (i.e. 1510 message signing and encrypting), which allows the CA keys to be used 1511 only for their intended purpose of "certificate signing". 1513 An RA can be implemented in two ways: physically separate or 1514 implicit. In the implicit case, the CA simply creates an extra key 1515 pair. A physically separate RA allows the CA to be inside the secure 1516 network, not accessible to hackers at all. 1518 8.3. ChallengePassword 1520 The challengePassword sent in the PKCS#10 enrollment request is 1521 signed and encrypted by way of being encapsulated in a pkiMessage. 1522 When saved by the CA, care should be taken to protect this password. 1524 If the challengePassword is used to automatically authenticate an 1525 enrollment request, it is recommended that some form of one-time 1526 password be used to minimize damage in the event the data is 1527 compromised. 1529 8.4. transactionID 1531 A well-written CA/RA SHOULD NOT rely on the transactionID to be 1532 correct or as specified in this document. Requesters with buggy 1533 software might add additional undetected duplicate requests to the 1534 CA's queue (or worse). A well-written CA/RA should never assume the 1535 data from a requester is well-formed. 1537 8.5. Nonces and Replay 1539 In order to detect replay attacks, both sides need to maintain state 1540 information sufficient to detect a repeated, duplicate senderNonce. 1542 Since existing implementations do not copy the senderNonce from a 1543 CertRep into subsequent GetCertinitial requests, the server will 1544 never see its own nonce reflected back to it. The transactionID 1545 links together the GetCertInitial and PKCSReq, in any case. 1547 8.6. Key Usage Issues 1549 Key pairs may be intended for particular purposes, such as encryption 1550 only or signing only. The usage of any associated certificate can be 1551 restricted by adding key usage and extended key usage attributes to 1552 the PKCS#10 [RFC2986]. If key usage is not present, the public key 1553 is assumed to be a general purpose key that may be used for all 1554 purposes. 1556 When building a pkiMessage, clients MUST have a certificate to sign 1557 the PKCS#7 [RFC2315] signed-data (because PKCS#7 [RFC2315] requires 1558 it). Clients MUST either use an existing certificate, or create a 1559 self-signed certificate (see Section 2.3). If this certificate has a 1560 key usage extension in it, then this key usage MUST be ignored by 1561 both the SCEP client and SCEP server for the duration of the 1562 transaction (the key will be used for signing during the creation of 1563 the PKCSReq message, and for encryption during the creation of the 1564 CertRep message). 1566 8.7. GetCACaps Issues 1568 The GetCACaps response is not signed. This allows an attacker to use 1569 downgrade attacks (as well as "upgrade attacks") on the cryptographic 1570 capabilities of the CA. 1572 8.8. Unnecessary cryptography 1574 Some of the SCEP exchanges use signing and encryption operations that 1575 are not necessary. In particular the GetCert and GetCRL exchanges 1576 are encrypted and signed in both directions. The information 1577 requested is public and thus signing the requests is of questionable 1578 value but also CRLs and Certificates, i.e. the respective responses, 1579 are already signed by the CA and can be verified by the recipient 1580 without requiring additional signing and encryption. 1582 This may affect performance and scalability of the CA which could be 1583 used as an attack vector on the CA (though not an anonymous one). 1584 The use of CDPs is recommended for CRL access, as well as other ways 1585 of retrieving certificates (LDAP, direct HTTP access, etc.). 1587 8.9. GetNextCACert 1589 Servers implementing early versions of the SCEP draft might return an 1590 unsigned GetNextCACert response by erroneously mirroring the 1591 (unsigned) functionality of GetCACert. Client receiving such 1592 responses MUST ignored them. 1594 GetNextCACert depends on a 'flag moment' at which every client in the 1595 PKI infrastructure switches from the current CA certificate (and 1596 client certificate) to the new CA certificate and client 1597 certificates. Proper monitoring of the network infrastructure can 1598 ensure that this will proceed as expected but any errors in 1599 processing or implementation can result in a failure of the PKI 1600 infrastructure. 1602 9. Normative References 1604 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1605 Requirement Levels", BCP 14, RFC 2119, March 1997. 1607 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 1608 Version 1.5", RFC 2315, March 1998. 1610 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1611 (IKE)", RFC 2409, November 1998. 1613 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 1614 Classes and Attribute Types Version 2.0", RFC 2985, 1615 November 2000. 1617 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1618 Request Syntax Specification Version 1.7", RFC 2986, 1619 November 2000. 1621 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1622 "Internet X.509 Public Key Infrastructure Certificate 1623 Management Protocol (CMP)", RFC 4210, September 2005. 1625 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1626 RFC 4306, December 2005. 1628 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1629 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1631 [RFC4945] Korver, B., "The Internet IP Security PKI Profile of 1632 IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007. 1634 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 1635 (CMC)", RFC 5272, June 2008. 1637 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1638 Housley, R., and W. Polk, "Internet X.509 Public Key 1639 Infrastructure Certificate and Certificate Revocation List 1640 (CRL) Profile", RFC 5280, May 2008. 1642 Appendix A. Private OID Definitions 1644 The OIDs used in SCEP are VeriSign self-maintained OIDs. 1646 +-------------------+-----------------------------------------------+ 1647 | Name | ASN.1 Definition | 1648 +-------------------+-----------------------------------------------+ 1649 | id-VeriSign | OBJECT_IDENTIFIER ::= {2 16 US(840) 1 | 1650 | | VeriSign(113733)} | 1651 | id-pki | OBJECT_IDENTIFIER ::= {id-VeriSign pki(1)} | 1652 | id-attributes | OBJECT_IDENTIFIER ::= {id-pki attributes(9)} | 1653 | id-messageType | OBJECT_IDENTIFIER ::= {id-attributes | 1654 | | messageType(2)} | 1655 | id-pkiStatus | OBJECT_IDENTIFIER ::= {id-attributes | 1656 | | pkiStatus(3)} | 1657 | id-failInfo | OBJECT_IDENTIFIER ::= {id-attributes | 1658 | | failInfo(4)} | 1659 | id-senderNonce | OBJECT_IDENTIFIER ::= {id-attributes | 1660 | | senderNonce(5)} | 1661 | id-recipientNonce | OBJECT_IDENTIFIER ::= {id-attributes | 1662 | | recipientNonce(6)} | 1663 | id-transId | OBJECT_IDENTIFIER ::= {id-attributes | 1664 | | transId(7)} | 1665 | id-extensionReq | OBJECT_IDENTIFIER ::= {id-attributes | 1666 | | extensionReq(8)} | 1667 +-------------------+-----------------------------------------------+ 1669 Appendix B. SCEP State Transitions 1671 SCEP state transitions are indexed by the transactionID attribute. 1672 The design goal is to ensure the synchronization between the CA and 1673 the requester under various error situations. 1675 Each enrollment transaction is uniquely associated with a transaction 1676 identifier (carried in the transactionID signed attribute (see 1677 Section 3.1.1.1). Because the enrollment transaction could be 1678 interrupted by various errors, including network connection errors or 1679 client reboot, the SCEP client generates a transaction identifier by 1680 calculating a hash on the public key value for which the enrollment 1681 is requested. This retains the same transaction identifier 1682 throughout the enrollment transaction, even if the client has 1683 rebooted or timed out, and issues a new enrollment request for the 1684 same key pair. It also provides the way for a CA to uniquely 1685 identify a transaction in its database. At the requester side, it 1686 generates a transaction identifier which is included in PKCSReq. If 1687 the CA returns a response of PENDING, the requester will poll by 1688 periodically sending out GetCertInitial with the same transaction 1689 identifier until either a response other than PENDING is obtained, or 1690 the configured maximum time has elapsed. 1692 If the client times out or the client reboots, the client 1693 administrator will start another enrollment transaction with the same 1694 key pair. The second enrollment will have the same transaction 1695 identifier. At the server side, instead of accepting the PKCSReq as 1696 a new enrollment request, it should respond as if another 1697 GetCertInitial message had been sent with that transaction ID. The 1698 second PKCSReq should be taken as a resynchronization message to 1699 allow the enrollment to resume as the same transaction. 1701 It is important to keep the transaction ID unique since SCEP requires 1702 the same policy and same identity be applied to the same subject name 1703 and key pair binding. In the current implementation, an SCEP client 1704 can only assume one identity. At any time, only one key pair, with a 1705 given key usage, can be associated with the same identity. 1707 The following gives several examples of client to CA transactions. 1709 Client actions are indicated in the left column, CA actions are 1710 indicated in the right column. A blank action signifies that no 1711 message was received. 1713 The first transaction, for example, would read like this: 1715 "Client Sends PKCSReq message with transaction ID 1 to the CA. The 1716 CA signs the certificate and constructs a CertRep Message containing 1717 the signed certificate with a transaction ID 1. The client receives 1718 the message and installs the certificate locally." 1720 Successful Enrollment Case: no manual authentication 1721 PKCSReq (1) ----------> CA Signs Cert 1722 Client Installs Cert <---------- CertRep (1) SIGNED CERT 1724 Successful Enrollment Case: manual authentication required 1725 PKCSReq (10) ----------> Cert Request goes into Queue 1726 Client Polls <---------- CertRep (10) PENDING 1727 GetCertInitial (10) ----------> Still pending 1728 Client Polls <---------- CertRep (10) PENDING 1729 GetCertInitial (10) ----------> Still pending 1730 Client Polls <---------- CertRep (10) PENDING 1731 GetCertInitial (10) ----------> Still pending 1732 Client Polls <---------- CertRep (10) PENDING 1733 GetCertInitial (10) ----------> Cert has been signed 1734 <---------- CertRep (10) SIGNED CERT 1735 Client Installs Cert 1737 Resync Case 1 - CA Receives PKCSReq, sends PENDING, eventually grants 1738 the certificate and returns SUCCESS, with the certificate. The 1739 SUCCESS gets lost: 1740 PKCSReq (3) ----------> Cert Request goes into queue 1741 <---------- CertRep (3) PENDING 1742 GetCertInitial (3) ----------> Still pending 1743 <---------- CertRep (3) PENDING 1744 GetCertInitial (3) -----------> Cert has been signed 1745 X-------- CertRep(3) SIGNED CERT 1746 (Time Out) 1747 PKCSReq (3) ----------> Cert already granted 1748 <---------- CertRep (3) SIGNED CERT 1749 Client Installs Cert 1750 Resync Case 2 - CA Receives PKCSReq, sends PENDING, PENDING reply 1751 gets lost: 1752 PKCSReq (3) ----------> Cert Request goes into queue 1753 X-------- CertRep (3) PENDING 1754 (Time Out) 1755 PKCSReq (3) ----------> 1756 <---------- CertRep (3) PENDING 1757 etc... 1759 Case when the Certificate is lost, the CA arbitrarily refuses to sign 1760 a replacement (enforcing name-uniqueness) until the original 1761 certificate has been revoked (there is no change of name 1762 information): 1763 PKCSReq (4) ----------> CA Signs Cert 1764 <---------- CertRep (4) SIGNED CERT 1765 Client Installs Cert 1766 (Client looses Cert) 1767 PKCSReq (5) ----------> There is already a valid cert with 1768 this DN. 1769 <---------- CertRep (5) BAD REQUEST 1770 Admin Revokes 1771 PKCSReq (5) ----------> CA Signs Cert 1772 <---------- CertRep (5) SIGNED CERT 1773 Client Installs Cert 1775 Appendix C. CA Capabilities 1777 C.1. GetCACaps HTTP Message Format 1779 "GET" CGI-PATH CGI-PROG "?operation=GetCACaps" "&message=" CA-IDENT 1781 This message requests capabilities from CA. The response is a list 1782 of text capabilities, as defined in Appendix C.2. Support for this 1783 message is OPTIONAL, but if it is not supported, the client SHOULD 1784 assume that none of the capabilities in Appendix C.2 are supported. 1786 C.2. CA Capabilities Response Format 1788 The response for a GetCACaps message is a list of CA capabilities, in 1789 plain text, separated by characters, as follows (quotation marks 1790 are NOT sent): 1792 +--------------------+----------------------------------------------+ 1793 | Keyword | Description | 1794 +--------------------+----------------------------------------------+ 1795 | "GetNextCACert" | CA Supports the GetNextCACert message. | 1796 | "POSTPKIOperation" | PKIOPeration messages may be sent via HTTP | 1797 | | POST. | 1798 | "Renewal" | Clients may use current certificate and key | 1799 | | to authenticate an enrollment request for a | 1800 | | new certificate. | 1801 | "SHA-512" | CA Supports the SHA-512 hashing algorithm in | 1802 | | signatures and fingerprints. | 1803 | "SHA-256" | CA Supports the SHA-256 hashing algorithm in | 1804 | | signatures and fingerprints. | 1805 | "SHA-1" | CA Supports the SHA-1 hashing algorithm in | 1806 | | signatures and fingerprints. | 1807 | "DES3" | CA Supports triple-DES for encryption. | 1808 +--------------------+----------------------------------------------+ 1810 The client SHOULD use SHA-1, SHA-256, or SHA-512 in preference to MD5 1811 hashing if it is supported by the CA. 1813 A client MUST be able to accept and ignore any unknown keywords that 1814 might be sent back by a CA. 1816 If none of the above capabilities are supported by the CA, a server 1817 SHOULD return an empty message. A server MAY simply return an HTTP 1818 error. 1820 The Content-type of the reply SHOULD be "text/plain". Clients SHOULD 1821 ignore the Content-type, as older server implementations of SCEP may 1822 send various Content-types. 1824 Example: 1825 GET /cgi-bin/pkiclient.exe?operation=GetCACaps&message=myca 1827 might return: 1828 GetNextCACertPOSTPKIOperation 1830 This means that the CA supports the GetNextCACert message and allows 1831 PKIOperation messages (PKCSreq, GetCert, GetCertInitial, ...) to be 1832 sent using HTTP POST. 1834 Appendix D. Client Certificate Renewal 1836 An enrollment request that occurs more than halfway through the 1837 validity period of an existing certificate for the same subject name 1838 and key usage MAY be interpreted as a re-enrollment or renewal 1839 request and be accepted. A new certificate with new validity dates 1840 may be issued, even though the old one is still valid, if the CA 1841 policy permits. The server MAY automatically revoke the old client 1842 certificate. Clients MUST use GetCACaps (see Appendix C) to 1843 determine if the CA supports renewal. Clients MUST support servers 1844 that do not implement renewal, or that reject renewal requests. 1846 To renew a client certificate, the client uses the PKCSreq message 1847 and signs it with the existing client certificate. The client SHOULD 1848 use a new keypair when requesting a new certificate. The client MAY 1849 request a new certicate using the old keypair. 1851 Appendix E. CA Key Rollover 1853 When the CA certificate expires all certificates that have been 1854 signed by it are no longer valid. CA key rollover provides a 1855 mechanism by which the server MAY distribute a new CA certificate 1856 which is valid in the future; when the current certificate has 1857 expired. Clients MUST use GetCACaps (see Appendix C) to determine if 1858 the CA supports GetNextCACert. 1860 To obtain the new CA certificate prior to the expiration of the 1861 current one, the client uses the GetNextCACert message. 1863 To obtain a new client certificate signed by the new CA certificate, 1864 use the new CA or RA certificate in the PKCSreq message envelope. 1866 Clients MUST store the not-yet-valid CA certificate, and any not-yet- 1867 valid client certificates obitained, until such time that they are 1868 valid. At which point clients switch over to using the newly valid 1869 certificates. 1871 Example: 1873 GetNextCACert ----------> 1874 <---------- New CA certificate 1876 PKCSReq* ----------> CA Signs certificate with NEW key 1877 Client Stores Cert <---------- CertRep - Certificate issued 1878 for installation when from NEW CA certificate and key pair 1879 existing cert expires. 1881 *enveloped for new CA or RA cert and key pair. The CA will use the 1882 envelope to determine which key and certificate to use to issue the 1883 client certificate. 1885 Appendix F. PKIOperation via HTTP POST Message 1887 If the remote CA supports it, any of the PKCS#7 [RFC2315]-encoded 1888 SCEP messages may be sent via HTTP POST instead of HTTP GET. This is 1889 allowed for any SCEP message except GetCACert, GetNextCACert, or 1890 GetCACaps. In this form of the message, Base 64 encoding is not 1891 used. 1892 POST /cgi-bin/pkiclient.exe?operation=PKIOperation HTTP/1.0 1893 Content-Length: 1895 1897 General POST Syntax 1899 The client can verify that the CA supports SCEP messages via POST by 1900 looking for the "POSTPKIOperation" capability (See Appendix C). 1902 Authors' Addresses 1904 Max Pritikin (editor) 1905 Cisco Systems, Inc 1907 Email: pritikin@cisco.com 1909 Andrew Nourse 1910 Cisco Systems, Inc 1912 Email: nourse@cisco.com 1914 Jan Vilhuber 1915 Cisco Systems, Inc 1917 Email: vilhuber@cisco.com