idnits 2.17.1 draft-nourse-scep-21.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 (September 22, 2010) is 4959 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: March 26, 2011 Cisco Systems, Inc 6 September 22, 2010 8 Cisco Systems' Simple Certificate Enrollment Protocol 9 draft-nourse-scep-21 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 March 26, 2011. 43 Copyright Notice 45 Copyright (c) 2010 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 PKCS#7 [RFC2315] content-encryption key (see Section 10, step 2) 875 is encrypted using the public key of the recipient of the message, 876 i.e. the RA or the CA public key (if sent from the requester), or the 877 requester public key (if sent as a reply to the 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 protected using the 913 public key of the recipient as detailed in Section 3.1.2. For 914 example the CA or RA public key. 916 3.2.2. CertRep 918 The messageData for this type consists of a DER-encoded degenerate 919 certificates-only Signed-data (Section 3.3). The exact contents 920 required for certain CertRep replies depends on the type of request 921 this message is a reply to and is detailed in Table 1 and in 922 Section 4. 924 In addition to the authenticatedAttributes required for a valid 925 PKCS#7 [RFC2315], this pkiMessage MUST include the following 926 attributes: 928 o the transactionID (Section 3.1.1.1) attribute copied from the 929 request we are responding to 931 o a messageType (Section 3.1.1.2) attribute set to CertRep 933 o a senderNonce (Section 3.1.1.5) attribute 935 o a recipientNonce attribute (Section 3.1.1.5) copied from the 936 senderNonce from the request we are responding to. 938 o a pkiStatus (Section 3.1.1.3) set to the status of the reply. 940 The pkcsPKIEnvelope for this message type is protected using the 941 public key of the recipient as detailed in Section 3.1.2. For 942 example if a self-signed certificate was used to send the original 943 request then this self-signed certificate's public key is used to 944 encrypt the content-encryption key of the SUCCESS response's 945 pkcsPKIEnvelope. 947 3.2.2.1. CertRep SUCCESS 949 When the pkiStatus attribute is set to SUCCESS, the messageData for 950 this message consists of a DER-encoded degenerate certificates-only 951 Signed-data (Section 3.3). The contents of this degenerate 952 certificates-only Signed-Data depends on what the original request 953 was, as outlined in Table 1. 955 +----------------+--------------------------------------------------+ 956 | Request-type | Reply-contents | 957 +----------------+--------------------------------------------------+ 958 | PKCSReq | the reply MUST contain at least the issued | 959 | | certificate in the certificates field of the | 960 | | Signed-Data. The reply MAY contain additional | 961 | | certificates, but the issued certificate MUST be | 962 | | the first in the list. The reply MUST NOT | 963 | | contain any CRL's. All returned certificates | 964 | | MUST conform to [RFC5280]. | 965 | GetCertInitial | same as PKCSReq | 966 | GetCert | the reply MUST contain at least the requested | 967 | | certificate in the certificates field of the | 968 | | Signed-Data. The reply MAY contain additional | 969 | | certificates, but the requested certificate MUST | 970 | | be the first in the list. The reply MUST NOT | 971 | | contain any CRL's. All returned certificates | 972 | | MUST conform to [RFC5280]. | 973 | GetCRL | the reply MUST contain the CRL in the crls field | 974 | | of the Signed-Data. The reply MUST NOT contain | 975 | | any certificates. The CRL MUST be a valid CRL | 976 | | according to [RFC5280]. | 977 +----------------+--------------------------------------------------+ 979 Table 1: CertRep Types 981 3.2.2.2. CertRep FAILURE 983 When the pkiStatus attribute is set to FAILURE, the reply MUST also 984 contain a failInfo (Section 3.1.1.4) attribute set to the appropriate 985 error condition describing the failure. The pkcsPKIEnvelope 986 (Section 3.1.2) MUST be omitted. 988 3.2.2.3. CertRep PENDING 990 When the pkiStatus attribute is set to PENDING, the pkcsPKIEnvelope 991 (Section 3.1.2) MUST be omitted. 993 3.2.3. GetCertInitial 995 The messageData for this type consists of a DER-encoded 996 IssuerAndSubject (Section 3.2.3.1). The issuer is set to the 997 issuerName from the certification authority from which we are issued 998 certificates. The Subject is set to the SubjectName we used when 999 requesting the certificate. 1001 In addition to the authenticatedAttributes required for a valid 1002 PKCS#7 [RFC2315], this pkiMessage MUST include the following 1003 attributes: 1005 o the same transactionID (Section 3.1.1.1) attribute from original 1006 PKCSReq message 1008 o a messageType (Section 3.1.1.2) attribute set to GetCertInitial 1010 o a senderNonce (Section 3.1.1.5) attribute 1012 3.2.3.1. IssuerAndSubject 1014 Similar to the IssuerAndSerial defined in PKCS#7 [RFC2315] Section 1015 6.7, we need to define an IssuerAndSubject ASN.1 type (Figure 7). 1017 The ASN.1 definition of the issuerAndSubject type is as follows: 1018 issuerAndSubject ::= SEQUENCE { 1019 issuer Name, 1020 subject Name 1021 } 1023 Figure 7: IssuerAndSubject ASN.1 1025 3.2.4. GetCert 1027 The messageData for this type consists of a DER-encoded 1028 IssuerAndSerial as defined in PKCS#7 [RFC2315] Section 6.7 containing 1029 the "distinguished name of the certificate issuer and an issuer- 1030 specific certificate serial number" which uniquely identifies the 1031 certificate being requested. 1033 In addition to the authenticatedAttributes required for a valid 1034 PKCS#7 [RFC2315], this pkiMessage MUST include the following 1035 attributes: 1037 o a transactionID (Section 3.1.1.1) attribute 1039 o a messageType (Section 3.1.1.2) attribute set to GetCert 1041 o a senderNonce (Section 3.1.1.5) attribute 1043 A self-signed certificate MAY be used in the signed envelope. This 1044 enables the requester to request their own certificate if they were 1045 unable to store it previously. 1047 3.2.5. GetCRL 1049 The messageData for this type consists of a DER-encoded 1050 IssuerAndSerial as defined in PKCS#7 [RFC2315] Section 6.7 the issuer 1051 name and serial number from the certificate to be validated. 1053 In addition to the authenticatedAttributes required for a valid 1054 PKCS#7 [RFC2315], this pkiMessage MUST include the following 1055 attributes: 1057 o a transactionID (Section 3.1.1.1) attribute 1059 o a messageType (Section 3.1.1.2) attribute set to GetCRL 1061 o a senderNonce (Section 3.1.1.5) attribute 1063 3.3. Degenerate certificates-only PKCS#7 Signed-data 1065 [RFC2315] section 9 includes a degenerate case of the PKCS#7 Signed- 1066 data content type, in which there are no signers. The use of such a 1067 degenerate case is to disseminate certificates and certificate- 1068 revocation lists. For SCEP the content field of the ContentInfo 1069 value of a degenerate certificates-only Signed-Data MUST be omitted. 1071 When carrying certificates, the certificates are included in the 1072 'certificates' field of the Signed-Data. When carrying a CRL, the 1073 CRL will be included in the 'crls' field of the Signed-Data. 1075 4. SCEP Transactions 1077 This section describes the SCEP Transactions, without explaining the 1078 transport. The transport of each message is discussed in Section 5. 1079 Some of the transaction-requests have no data to send, i.e. the only 1080 data is the message-type itself (e.g. a GetCACert message has no 1081 additional data). The use of such messages will become clearer in 1082 Section 5. 1084 In this section, each SCEP transaction is specified in terms of the 1085 complete messages exchanged during the transaction. 1087 The order of the transactions in this section is mirrored in 1088 Section 5.2 for better organization and readability. 1090 4.1. Get CA Certificate 1092 To get the CA certificate(s), the requester sends a GetCACert message 1093 to the server. There is no request data associated with this message 1094 (see Section 5.2.1). 1096 4.1.1. Get CA Certificate Response Message Format 1098 The response depends on whether the responding server has RA 1099 certificates or only a single CA certificate. The server MUST 1100 indicate which response it is sending via the transport protocol used 1101 (see Section 5.2.1). 1103 All returned certificates MUST conform to [RFC5280]. 1105 Once the CA certificate is received by the requester (regardless of 1106 the presence of RA certificates), a fingerprint is generated using 1107 the SHA1, SHA256, SHA512 or MD5 hash algorithm on the whole CA 1108 certificate. If the requester does not have a certificate path to a 1109 trusted CA certificate, this fingerprint may be used to verify the 1110 certificate, by some positive out-of-band means, such as a phone call 1111 or pre-provisioning. 1113 4.1.1.1. CA Certificate Response Message Format 1115 If the server is a certification authority and does not have any RA 1116 Certificates, the response consists of a single DER-encoded X.509 CA 1117 certificate. 1119 4.1.1.2. CA/RA Certificate Response Message Format 1121 If the server has RA Certificates, the response consists of a DER- 1122 encoded degenerate certificates-only Signed-data (Section 3.3) 1123 containing the CA certificate and RA certificates. 1125 4.2. Certificate Enrollment 1127 A PKCSReq (Section 3.2.1) message is used to perform a certificate 1128 enrollment transaction. 1130 The reply MUST be a CertRep (Section 3.2.2) message sent back from 1131 the server, indicating SUCCESS, FAILURE, or PENDING. 1133 Precondition: Both the requester and the certification authority have 1134 completed their initialization process. The requester has already 1135 been configured with the CA/RA certificate. 1137 Postcondition: Either the certificate is received by the requester, 1138 or the end entity is notified to do the manual authentication, or the 1139 request is rejected. 1141 4.2.1. Certificate Enrollment Response Message 1143 If the request is granted, a CertRep (Section 3.2.2) message with 1144 pkiStatus set to SUCCESS is returned. The reply MUST also contain 1145 the certificate (and MAY contain any other certificates needed by the 1146 requester). The issued certificate MUST be the first in the list. 1148 If the request is rejected, a CertRep (Section 3.2.2) message with 1149 pkiStatus set to FAILURE is returned. The reply MUST also contain a 1150 failInfo attribute. 1152 If the the CA is configured to manually authenticate the requester, a 1153 CertRep (Section 3.2.2) message with pkiStatus set to 'PENDING' MAY 1154 be returned. 1156 4.3. Poll for Requester Initial Certificate 1158 Triggered by a CertRep (Section 3.2.2) with pkiStatus set to PENDING, 1159 a requester will enter the polling state by periodically sending 1160 GetCertInitial (Section 3.2.3) to the server, until either the 1161 request is granted and the certificate is sent back, or the request 1162 is rejected, or the configured time limit for polling (or maximum 1163 number of polls) is exceeded. 1165 Since GetCertInitial is part of the enrollment, the messages 1166 exchanged during the polling period MUST carry the same transactionID 1167 attribute as the previous PKCSReq. A server receiving a 1168 GetCertInitial for which it does not have a matching PKCSReq MUST 1169 ignore this request. 1171 Since at this time the certificate has not been issued, the requester 1172 can only use its own subject name (which was contained in the 1173 original PKCS#10 sent via PKCSReq) to identify the polled certificate 1174 request. Since there can be multiple outstanding requests from one 1175 requester (for example, if different keys and different key-usages 1176 were used to request multiple certificates), the transaction ID must 1177 also be included, to disambiguate between multiple requests. 1179 PreCondition: The requester has received a CertRep with pkiStatus set 1180 to PENDING. 1182 PostCondition: The requester has either received a valid response, 1183 which could be either a valid certificate (pkiStatus = SUCCESS), or a 1184 FAILURE message, or the polling period times out. 1186 4.3.1. Polling Response Message Format 1188 The response messages for GetCertInitial are the same as in 1189 Section 4.2.1. 1191 4.4. Certificate Access 1193 The certificate query message is an option when the LDAP server is 1194 not available to provide the certificate query. A requester should 1195 be able to query an issued certificate from the certification 1196 authority, as long as the issuer name and the issuer assigned 1197 certificate serial number is known to the requesting end entity. 1198 This transaction is not intended to provide the service as a 1199 certificate directory service. A more complicated query mechanism 1200 would have to be defined in order to allow a requester to query a 1201 certificate using various different fields. 1203 This transaction consists of one GetCert (Section 3.2.4) message sent 1204 to the server by a requester, and one CertRep (Section 3.2.2) message 1205 sent back from the server. 1207 PreCondition: The queried certificate have been issued by the 1208 certification authority and the issuer assigned serial number is 1209 known. 1211 PostCondition: Either the certificate is sent back or the request is 1212 rejected. 1214 4.4.1. Certificate Access Response Message Format 1216 In this case, the CertRep from the server is same as in 1217 Section 4.2.1, except that the server will only either grant the 1218 request (SUCCESS) or reject the request (FAILURE). 1220 4.5. CRL Access 1222 Clients MAY request a CRL from the SCEP server as described in 1223 Section 2.7. 1225 PreCondition: The certification authority certificate has been 1226 downloaded to the end entity. 1228 PostCondition: CRL sent back to the requester. 1230 4.5.1. CRL Access Response Message Format 1232 The CRL is sent back to the requester in a CertRep (Section 3.2.2) 1233 message. The information portion of this message is a degenerate 1234 certificates-only Signed-data (Section 3.3) which contains only the 1235 most recent CRL in the crls field of the Signed-Data. 1237 The server MAY return any appropriate CRL. 1239 4.6. Get Next Certification Authority Certificate 1241 When a CA certificate is about to expire, clients need to retrieve 1242 the CA's next CA certificate (i.e. the Rollover Certificate). This 1243 is done via the GetNextCACert message. There is no request data 1244 associated with this message (see Section 5.2.6). 1246 4.6.1. Get Next CA Response Message Format 1248 The response consists of a SignedData PKCS#7 [RFC2315], signed by the 1249 current CA (or RA) signing key. 1251 Clients MUST validate the signature on the the SignedData PKCS#7 1252 [RFC2315] before accepting any of its contents. 1254 The content of the SignedData PKCS#7 [RFC2315] is a degenerate 1255 certificates-only Signed-data (Section 3.3) message containing the 1256 new CA certificate and any new RA certificates, as defined in 1257 Section 5.2.1.1.2, to be used when the current CA certificate 1258 expires. 1260 If the CA (or RA) does not have the Rollover certificate(s) it MUST 1261 reject the request. It SHOULD also remove the GetNextCACert setting 1262 from the capabilities until it does have rollover certificates. 1264 If there are any RA certificates in this response, clients MUST check 1265 that these RA certificates are signed by the CA, and MUST check 1266 authorization of these RA certificates (see Section 2.1.3). 1268 5. SCEP Transport 1270 HTTP is used as the transport protocol for SCEP Message Objects. 1272 5.1. HTTP "GET" Message Format 1274 SCEP uses the HTTP "GET" messages to request information from the CA. 1275 The following is the syntax definition of a HTTP GET message sent 1276 from a requester to a certification authority server: 1277 "GET" CGI-PATH CGI-PROG "?operation=" OPERATION "&message=" MESSAGE 1279 where: 1281 o CGI-PATH defines the actual CGI path to invoke the CGI program 1282 that parses the request. 1284 o CGI-PROG is set to be the string "pkiclient.exe". This is 1285 intended to be the program that the CA will use to handle the SCEP 1286 transactions, though the CA may ignore CGI-PROG and use only the 1287 CGI-PATH. 1289 o OPERATION depends on the SCEP transaction and is defined in the 1290 following sections. 1292 o MESSAGE depends on the SCEP transaction and is defined in the 1293 following sections. 1295 If the CA supports it, requests may also be done via an HTTP POST. 1296 This is described in Appendix F. 1298 5.1.1. Response Message Format 1300 For each GET operation, the CA/RA server MUST return a Content-Type 1301 and appropriate response data, if any. 1303 5.2. SCEP HTTP Messages 1305 5.2.1. GetCACert 1307 OPERATION MUST be set to "GetCACert". 1309 MESSAGE MAY be omitted, or it MAY be a string that represents the 1310 certification authority issuer identifier, if such has been set by 1311 the CA Administrator. 1313 5.2.1.1. GetCACert Response 1315 The response for GetCACert is different between the case where the CA 1316 directly communicates with the requester during the enrollment, and 1317 the case where a RA exists and the requester communicates with the RA 1318 during the enrollment. 1320 5.2.1.1.1. CA Certificate Only Response 1322 The response will have a Content-Type of "application/ 1323 x-x509-ca-cert". 1325 The body of this response consists of a DER-encoded X.509 CA 1326 certificate, as defined in Section 4.1.1.1. 1327 "Content-Type:application/x-x509-ca-cert\n\n" 1329 5.2.1.1.2. CA and RA Certificates Response 1331 The response will have a Content-Type of "application/ 1332 x-x509-ca-ra-cert". 1334 The body of this response consists of a DER-encoded degenerate 1335 certificates-only Signed-data (Section 3.3) containing both CA and RA 1336 certificates, as defined in Section 4.1.1.2. 1337 "Content-Type:application/x-x509-ca-ra-cert\n\n" 1339 5.2.2. PKCSReq 1341 OPERATION MUST be set to "PKIOperation". 1343 MESSAGE consists of a base64-encoded DER-encoded PKCSReq SCEP 1344 message. 1346 An example PKIOperation request might look as follows: 1347 GET /cgi-bin/pkiclient.exe?operation=PKIOperation&message=MIAGCSqGSIb3D 1348 QEHA6CAMIACAQAxgDCBzAIBADB2MGIxETAPBgNVBAcTCE ......AAAAAA== HTTP/1.0 1350 5.2.2.1. PKCSReq Response 1352 The response will have a Content-Type of "application/x-pki-message". 1354 The body of this response consists of a DER-encoded CertRep SCEP 1355 message defined in Section 4.2.1. The following is an example of the 1356 response: 1357 "Content-Type:application/x-pki-message\n\n" 1359 5.2.3. GetCertInitial 1361 OPERATION MUST be set to "PKIOperation". 1363 MESSAGE consists of a base64-encoded DER-encoded GetCertInitial SCEP 1364 message. 1366 5.2.3.1. GetCertInitial Response 1368 The body of this response consists of a DER-encoded CertRep SCEP 1369 message defined in Section 4.3.1. 1371 5.2.4. GetCert 1373 OPERATION MUST be set to "PKIOperation". 1375 MESSAGE consists of a base64-encoded DER-encoded GetCert SCEP 1376 message. 1378 5.2.4.1. GetCert Response 1380 The body of this response consists of a DER-encoded CertRep SCEP 1381 message defined in Section 4.4.1. 1383 5.2.5. GetCRL 1385 OPERATION MUST be set to "PKIOperation". 1387 MESSAGE consists of a base64-encoded DER-encoded GetCRL SCEP message. 1389 5.2.5.1. GetCRL Response 1391 The body of this response consists of a DER-encoded CertRep SCEP 1392 message defined in Section 4.5.1. 1394 5.2.6. GetNextCACert 1396 OPERATION MUST be set to "GetNextCACert". 1398 MESSAGE MAY be ommitted, or it MAY be a string that represents the 1399 certification authority issuer identifier, if such has been set by 1400 the CA Administrator. 1402 5.2.6.1. GetNextCACert Response 1404 The response will have a Content-Type of "application/ 1405 x-x509-next-ca-cert". 1407 The body of this response consists of a SignedData PKCS#7 [RFC2315], 1408 as defined in Section 4.6.1. (This is similar to the GetCert 1409 response but does not include any of the attributes defined in 1410 Section 3.1.1.) 1411 "Content-Type:application/x-x509-next-ca-cert\n\n" 1412 > 1414 6. Contributors/Acknowledgements 1416 The editor would like to thank all the previous authors and 1417 contributors: Cheryl Madson, Xiaoyi Liu, David McGrew, David Cooper, 1418 etc for their work on the draft over the years. 1420 The authors would like to thank Peter William of ValiCert, Inc. 1421 (formerly of VeriSign, Inc.) and Alex Deacon of VeriSign, Inc. and 1422 Christopher Welles of IRE, Inc. for their contributions to early 1423 versions of this protocol and this document. 1425 7. IANA Considerations 1427 This memo includes no request to IANA. 1429 8. Security Considerations 1431 The security goals of SCEP are that no adversary can: 1433 o subvert the public key/identity binding from that intended, 1435 o discover the identity information in the enrollment requests and 1436 issued certificates, 1438 o cause the revocation of certificates with any non-negligible 1439 probability. 1441 Here an adversary is any entity other than the requester and the CA 1442 (and optionally the RA) participating in the protocol that is 1443 computationally limited, but that can manipulate data during 1444 transmission (that is, a man-in-the-middle). The precise meaning of 1445 'computationally limited' depends on the implementer's choice of 1446 cryptographic hash functions and ciphers. The required algorithms 1447 are RSA, DES and MD5. Depending on the CA capabilities (see 1448 Appendix C), Triple-DES MAY be used instead of DES, and SHA-1, SHA- 1449 256, or SHA-512 MAY be used instead of MD5. 1451 The first and second goals are met through the use of PKCS#7 1452 [RFC2315] and PKCS#10 [RFC2986] encryption and digital signatures 1453 using authenticated public keys. The CA's public key is 1454 authenticated via the checking of the CA fingerprint, as specified in 1455 Section 2.1.2, and the SCEP client's public key is authenticated 1456 through the manual authentication or pre-shared secret 1457 authentication, as specified in Section 2.2. The third goal is met 1458 through the use of a challenge password for revocation, which is 1459 chosen by the SCEP client and communicated to the CA protected by the 1460 PKCS#7 [RFC2315] encryptedData, as specified in Section 2.8. 1462 The motivation of the first security goal is straightforward. The 1463 motivation for the second security goal is to protect the identity 1464 information in the enrollment requests and certificates. For 1465 example, two IPSEC hosts behind a firewall may need to exchange 1466 certificates, and may need to enroll certificates with a CA that is 1467 outside of a firewall. 1469 Most networks with firewalls seek to prevent IP addresses and DNS 1470 information from the trusted network leaving that network. The 1471 second goal enables the hosts in this example to enroll with a CA 1472 outside the firewall without revealing this information. The 1473 motivation for the third security goal is to protect the SCEP clients 1474 from denial of service attacks. 1476 8.1. General Security 1478 Common key-management considerations such as keeping private keys 1479 truly private and using adequate lengths for symmetric and asymmetric 1480 keys must be followed in order to maintain the security of this 1481 protocol. 1483 This is especially true for CA keys, which, when compromised, 1484 compromise the security of all relying parties. 1486 8.2. Use of the CA keypair 1488 A CA key pair is generally meant for (and is usually flagged as) 1489 "certificate signing" (exclusively), rather than 'data signing' or 1490 'data encryption'. The SCEP protocol, however, uses the CA key pair 1491 to encrypt and sign PKCS#7 [RFC2315] transport messages, regardless 1492 of the key usage of the CA certificate. This is generally considered 1493 undesirable, as it widens the possibility of an implementation 1494 weakness, and provides 1496 o another place that the private key must be used (and hence is 1497 slightly more vulnerable to exposure), 1499 o another place where a side channel attack (say, timing or power 1500 analysis) might be used, 1502 o another place that the attacker might somehow insert his own text, 1503 and get it signed by the private key. 1505 While the CA key pair can be generated with the 'data encryption' and 1506 'data signing' flags set, this is operationally not encouraged. It 1507 would make using the key as a PKCS#7 [RFC2315] transport key 'legal', 1508 but the discussion from the previous paragraph still applies. 1510 A solution is to use RA keys to secure the SCEP transport (i.e. 1511 message signing and encrypting), which allows the CA keys to be used 1512 only for their intended purpose of "certificate signing". 1514 An RA can be implemented in two ways: physically separate or 1515 implicit. In the implicit case, the CA simply creates an extra key 1516 pair. A physically separate RA allows the CA to be inside the secure 1517 network, not accessible to hackers at all. 1519 8.3. ChallengePassword 1521 The challengePassword sent in the PKCS#10 enrollment request is 1522 signed and encrypted by way of being encapsulated in a pkiMessage. 1523 When saved by the CA, care should be taken to protect this password. 1525 If the challengePassword is used to automatically authenticate an 1526 enrollment request, it is recommended that some form of one-time 1527 password be used to minimize damage in the event the data is 1528 compromised. 1530 8.4. transactionID 1532 A well-written CA/RA SHOULD NOT rely on the transactionID to be 1533 correct or as specified in this document. Requesters with buggy 1534 software might add additional undetected duplicate requests to the 1535 CA's queue (or worse). A well-written CA/RA should never assume the 1536 data from a requester is well-formed. 1538 8.5. Nonces and Replay 1540 In order to detect replay attacks, both sides need to maintain state 1541 information sufficient to detect a repeated, duplicate senderNonce. 1543 Since existing implementations do not copy the senderNonce from a 1544 CertRep into subsequent GetCertinitial requests, the server will 1545 never see its own nonce reflected back to it. The transactionID 1546 links together the GetCertInitial and PKCSReq, in any case. 1548 8.6. Key Usage Issues 1550 Key pairs may be intended for particular purposes, such as encryption 1551 only or signing only. The usage of any associated certificate can be 1552 restricted by adding key usage and extended key usage attributes to 1553 the PKCS#10 [RFC2986]. If key usage is not present, the public key 1554 is assumed to be a general purpose key that may be used for all 1555 purposes. 1557 When building a pkiMessage, clients MUST have a certificate to sign 1558 the PKCS#7 [RFC2315] signed-data (because PKCS#7 [RFC2315] requires 1559 it). Clients MUST either use an existing certificate, or create a 1560 self-signed certificate (see Section 2.3). If this certificate has a 1561 key usage extension in it, then this key usage MUST be ignored by 1562 both the SCEP client and SCEP server for the duration of the 1563 transaction (the key will be used for signing during the creation of 1564 the PKCSReq message, and for encryption during the creation of the 1565 CertRep message). 1567 8.7. GetCACaps Issues 1569 The GetCACaps response is not signed. This allows an attacker to use 1570 downgrade attacks (as well as "upgrade attacks") on the cryptographic 1571 capabilities of the CA. 1573 8.8. Unnecessary cryptography 1575 Some of the SCEP exchanges use signing and encryption operations that 1576 are not necessary. In particular the GetCert and GetCRL exchanges 1577 are encrypted and signed in both directions. The information 1578 requested is public and thus signing the requests is of questionable 1579 value but also CRLs and Certificates, i.e. the respective responses, 1580 are already signed by the CA and can be verified by the recipient 1581 without requiring additional signing and encryption. 1583 This may affect performance and scalability of the CA which could be 1584 used as an attack vector on the CA (though not an anonymous one). 1585 The use of CDPs is recommended for CRL access, as well as other ways 1586 of retrieving certificates (LDAP, direct HTTP access, etc.). 1588 8.9. GetNextCACert 1590 Servers implementing early versions of the SCEP draft might return an 1591 unsigned GetNextCACert response by erroneously mirroring the 1592 (unsigned) functionality of GetCACert. Client receiving such 1593 responses MUST ignored them. 1595 GetNextCACert depends on a 'flag moment' at which every client in the 1596 PKI infrastructure switches from the current CA certificate (and 1597 client certificate) to the new CA certificate and client 1598 certificates. Proper monitoring of the network infrastructure can 1599 ensure that this will proceed as expected but any errors in 1600 processing or implementation can result in a failure of the PKI 1601 infrastructure. 1603 9. Normative References 1605 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1606 Requirement Levels", BCP 14, RFC 2119, March 1997. 1608 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 1609 Version 1.5", RFC 2315, March 1998. 1611 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1612 (IKE)", RFC 2409, November 1998. 1614 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 1615 Classes and Attribute Types Version 2.0", RFC 2985, 1616 November 2000. 1618 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1619 Request Syntax Specification Version 1.7", RFC 2986, 1620 November 2000. 1622 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1623 "Internet X.509 Public Key Infrastructure Certificate 1624 Management Protocol (CMP)", RFC 4210, September 2005. 1626 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1627 RFC 4306, December 2005. 1629 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1630 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1632 [RFC4945] Korver, B., "The Internet IP Security PKI Profile of 1633 IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007. 1635 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 1636 (CMC)", RFC 5272, June 2008. 1638 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1639 Housley, R., and W. Polk, "Internet X.509 Public Key 1640 Infrastructure Certificate and Certificate Revocation List 1641 (CRL) Profile", RFC 5280, May 2008. 1643 Appendix A. Private OID Definitions 1645 The OIDs used in SCEP are VeriSign self-maintained OIDs. 1647 +-------------------+-----------------------------------------------+ 1648 | Name | ASN.1 Definition | 1649 +-------------------+-----------------------------------------------+ 1650 | id-VeriSign | OBJECT_IDENTIFIER ::= {2 16 US(840) 1 | 1651 | | VeriSign(113733)} | 1652 | id-pki | OBJECT_IDENTIFIER ::= {id-VeriSign pki(1)} | 1653 | id-attributes | OBJECT_IDENTIFIER ::= {id-pki attributes(9)} | 1654 | id-messageType | OBJECT_IDENTIFIER ::= {id-attributes | 1655 | | messageType(2)} | 1656 | id-pkiStatus | OBJECT_IDENTIFIER ::= {id-attributes | 1657 | | pkiStatus(3)} | 1658 | id-failInfo | OBJECT_IDENTIFIER ::= {id-attributes | 1659 | | failInfo(4)} | 1660 | id-senderNonce | OBJECT_IDENTIFIER ::= {id-attributes | 1661 | | senderNonce(5)} | 1662 | id-recipientNonce | OBJECT_IDENTIFIER ::= {id-attributes | 1663 | | recipientNonce(6)} | 1664 | id-transId | OBJECT_IDENTIFIER ::= {id-attributes | 1665 | | transId(7)} | 1666 | id-extensionReq | OBJECT_IDENTIFIER ::= {id-attributes | 1667 | | extensionReq(8)} | 1668 +-------------------+-----------------------------------------------+ 1670 Appendix B. SCEP State Transitions 1672 SCEP state transitions are indexed by the transactionID attribute. 1673 The design goal is to ensure the synchronization between the CA and 1674 the requester under various error situations. 1676 Each enrollment transaction is uniquely associated with a transaction 1677 identifier (carried in the transactionID signed attribute (see 1678 Section 3.1.1.1). Because the enrollment transaction could be 1679 interrupted by various errors, including network connection errors or 1680 client reboot, the SCEP client generates a transaction identifier by 1681 calculating a hash on the public key value for which the enrollment 1682 is requested. This retains the same transaction identifier 1683 throughout the enrollment transaction, even if the client has 1684 rebooted or timed out, and issues a new enrollment request for the 1685 same key pair. It also provides the way for a CA to uniquely 1686 identify a transaction in its database. At the requester side, it 1687 generates a transaction identifier which is included in PKCSReq. If 1688 the CA returns a response of PENDING, the requester will poll by 1689 periodically sending out GetCertInitial with the same transaction 1690 identifier until either a response other than PENDING is obtained, or 1691 the configured maximum time has elapsed. 1693 If the client times out or the client reboots, the client 1694 administrator will start another enrollment transaction with the same 1695 key pair. The second enrollment will have the same transaction 1696 identifier. At the server side, instead of accepting the PKCSReq as 1697 a new enrollment request, it should respond as if another 1698 GetCertInitial message had been sent with that transaction ID. The 1699 second PKCSReq should be taken as a resynchronization message to 1700 allow the enrollment to resume as the same transaction. 1702 It is important to keep the transaction ID unique since SCEP requires 1703 the same policy and same identity be applied to the same subject name 1704 and key pair binding. In the current implementation, an SCEP client 1705 can only assume one identity. At any time, only one key pair, with a 1706 given key usage, can be associated with the same identity. 1708 The following gives several examples of client to CA transactions. 1710 Client actions are indicated in the left column, CA actions are 1711 indicated in the right column. A blank action signifies that no 1712 message was received. 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 <---------- CertRep (10) SIGNED CERT 1736 Client Installs Cert 1738 Resync Case 1 - CA Receives PKCSReq, sends PENDING, eventually grants 1739 the certificate and returns SUCCESS, with the certificate. The 1740 SUCCESS gets lost: 1741 PKCSReq (3) ----------> Cert Request goes into queue 1742 <---------- CertRep (3) PENDING 1743 GetCertInitial (3) ----------> Still pending 1744 <---------- CertRep (3) PENDING 1745 GetCertInitial (3) -----------> Cert has been signed 1746 X-------- CertRep(3) SIGNED CERT 1747 (Time Out) 1748 PKCSReq (3) ----------> Cert already granted 1749 <---------- CertRep (3) SIGNED CERT 1750 Client Installs Cert 1751 Resync Case 2 - CA Receives PKCSReq, sends PENDING, PENDING reply 1752 gets lost: 1753 PKCSReq (3) ----------> Cert Request goes into queue 1754 X-------- CertRep (3) PENDING 1755 (Time Out) 1756 PKCSReq (3) ----------> 1757 <---------- CertRep (3) PENDING 1758 etc... 1760 Case when the Certificate is lost, the CA arbitrarily refuses to sign 1761 a replacement (enforcing name-uniqueness) until the original 1762 certificate has been revoked (there is no change of name 1763 information): 1764 PKCSReq (4) ----------> CA Signs Cert 1765 <---------- CertRep (4) SIGNED CERT 1766 Client Installs Cert 1767 (Client looses Cert) 1768 PKCSReq (5) ----------> There is already a valid cert with 1769 this DN. 1770 <---------- CertRep (5) BAD REQUEST 1771 Admin Revokes 1772 PKCSReq (5) ----------> CA Signs Cert 1773 <---------- CertRep (5) SIGNED CERT 1774 Client Installs Cert 1776 Appendix C. CA Capabilities 1778 C.1. GetCACaps HTTP Message Format 1780 "GET" CGI-PATH CGI-PROG "?operation=GetCACaps" "&message=" CA-IDENT 1782 This message requests capabilities from CA. The response is a list 1783 of text capabilities, as defined in Appendix C.2. CA servers SHOULD 1784 support the GetCACaps message. 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. | 1802 | "SHA-256" | CA Supports the SHA-256 hashing algorithm. | 1803 | "SHA-1" | CA Supports the SHA-1 hashing algorithm. | 1804 | "DES3" | CA Supports the triple-DES encryption | 1805 | | algorithm. | 1806 +--------------------+----------------------------------------------+ 1808 The client SHOULD use SHA-1, SHA-256, or SHA-512 in preference to MD5 1809 hashing if it is supported by the CA. 1811 The server MUST use the texual case specified here, but clients 1812 SHOULD ignore the textual case when processing this message. A 1813 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. A client that receives an empty message or an HTTP error 1819 SHOULD interpret the response as if none of the requested 1820 capabilities are supported by the CA. 1822 The Content-type of the reply SHOULD be "text/plain". Clients SHOULD 1823 ignore the Content-type, as older server implementations of SCEP may 1824 send various Content-types. 1826 Example: 1827 GET /cgi-bin/pkiclient.exe?operation=GetCACaps&message=myca 1829 might return: 1830 GetNextCACertPOSTPKIOperation 1832 This means that the CA supports the GetNextCACert message and allows 1833 PKIOperation messages (PKCSreq, GetCert, GetCertInitial, ...) to be 1834 sent using HTTP POST. 1836 Appendix D. Client Certificate Renewal 1838 An enrollment request that occurs more than halfway through the 1839 validity period of an existing certificate for the same subject name 1840 and key usage MAY be interpreted as a re-enrollment or renewal 1841 request and be accepted. A new certificate with new validity dates 1842 may be issued, even though the old one is still valid, if the CA 1843 policy permits. The server MAY automatically revoke the old client 1844 certificate. Clients MUST use GetCACaps (see Appendix C) to 1845 determine if the CA supports renewal. Clients MUST support servers 1846 that do not implement renewal, or that reject renewal requests. 1848 To renew a client certificate, the client uses the PKCSreq message 1849 and signs it with the existing client certificate. The client SHOULD 1850 use a new keypair when requesting a new certificate. The client MAY 1851 request a new certicate using the old keypair. 1853 Appendix E. CA Key Rollover 1855 When the CA certificate expires all certificates that have been 1856 signed by it are no longer valid. CA key rollover provides a 1857 mechanism by which the server MAY distribute a new CA certificate 1858 which is valid in the future; when the current certificate has 1859 expired. Clients MUST use GetCACaps (see Appendix C) to determine if 1860 the CA supports GetNextCACert. 1862 To obtain the new CA certificate prior to the expiration of the 1863 current one, the client uses the GetNextCACert message. 1865 To obtain a new client certificate signed by the new CA certificate, 1866 use the new CA or RA certificate in the PKCSreq message envelope. 1868 Clients MUST store the not-yet-valid CA certificate, and any not-yet- 1869 valid client certificates obitained, until such time that they are 1870 valid. At which point clients switch over to using the newly valid 1871 certificates. 1873 Example: 1875 GetNextCACert ----------> 1876 <---------- New CA certificate 1878 PKCSReq* ----------> CA Signs certificate with NEW key 1879 Client Stores Cert <---------- CertRep - Certificate issued 1880 for installation when from NEW CA certificate and key pair 1881 existing cert expires. 1883 *enveloped for new CA or RA cert and key pair. The CA will use the 1884 envelope to determine which key and certificate to use to issue the 1885 client certificate. 1887 Appendix F. PKIOperation via HTTP POST Message 1889 If the remote CA supports it, any of the PKCS#7 [RFC2315]-encoded 1890 SCEP messages may be sent via HTTP POST instead of HTTP GET. This is 1891 allowed for any SCEP message except GetCACert, GetNextCACert, or 1892 GetCACaps. In this form of the message, Base 64 encoding is not 1893 used. 1894 POST /cgi-bin/pkiclient.exe?operation=PKIOperation HTTP/1.0 1895 Content-Length: 1897 1899 General POST Syntax 1901 The client can verify that the CA supports SCEP messages via POST by 1902 looking for the "POSTPKIOperation" capability (See Appendix C). 1904 Authors' Addresses 1906 Max Pritikin (editor) 1907 Cisco Systems, Inc 1909 Email: pritikin@cisco.com 1911 Andrew Nourse 1912 Cisco Systems, Inc 1914 Email: nourse@cisco.com 1916 Jan Vilhuber 1917 Cisco Systems, Inc 1919 Email: vilhuber@cisco.com