idnits 2.17.1 draft-nourse-scep-23.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 7, 2011) is 4613 days in the past. Is this intentional? Checking references for intended status: Historic ---------------------------------------------------------------------------- == Missing Reference: 'RFC4523' is mentioned on line 172, but not defined == Missing Reference: 'RFC2560' is mentioned on line 173, but not defined ** Obsolete undefined reference: RFC 2560 (Obsoleted by RFC 6960) == Missing Reference: 'CERT-NONEXISTANT' is mentioned on line 518, but not defined == Missing Reference: 'CERT-REQ-PENDING' is mentioned on line 518, but not defined == Missing Reference: 'CERT-ISSUED' is mentioned on line 518, but not defined ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 5 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: Historic J. Vilhuber 5 Expires: March 10, 2012 Cisco Systems, Inc 6 September 7, 2011 8 Simple Certificate Enrollment Protocol 9 draft-nourse-scep-23 11 Abstract 13 This document specifies the Simple Certificate Enrollment Protocol 14 (SCEP), a Public Key Infrastructure (PKI) communication protocol 15 which leverages existing technology by using PKCS#7 and PKCS#10 over 16 HTTP. SCEP is the evolution of the enrollment protocol developed by 17 VeriSign, Inc. for Cisco Systems, Inc. It now enjoys wide support in 18 both client and a Certification Authority implementations. 20 Status of this Memo 22 This Internet-Draft is submitted 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). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on March 10, 2012. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 68 2. SCEP Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 69 2.1. SCEP Entities . . . . . . . . . . . . . . . . . . . . . . 6 70 2.1.1. Requester . . . . . . . . . . . . . . . . . . . . . . 6 71 2.1.2. Certification Authority . . . . . . . . . . . . . . . 7 72 2.1.3. Registration Authority . . . . . . . . . . . . . . . . 8 73 2.2. Requester authentication . . . . . . . . . . . . . . . . . 8 74 2.3. Enrollment authorization . . . . . . . . . . . . . . . . . 9 75 2.4. CA/RA Certificate Distribution . . . . . . . . . . . . . . 11 76 2.5. Certificate Enrollment . . . . . . . . . . . . . . . . . . 11 77 2.5.1. Client State Transitions . . . . . . . . . . . . . . . 12 78 2.6. Certificate Access . . . . . . . . . . . . . . . . . . . . 14 79 2.7. CRL Access . . . . . . . . . . . . . . . . . . . . . . . . 14 80 2.8. Certificate Revocation . . . . . . . . . . . . . . . . . . 15 81 3. SCEP Secure Message Objects . . . . . . . . . . . . . . . . . 16 82 3.1. SCEP pkiMessage . . . . . . . . . . . . . . . . . . . . . 17 83 3.1.1. Signed Transaction Attributes . . . . . . . . . . . . 18 84 3.1.1.1. transactionID . . . . . . . . . . . . . . . . . . 18 85 3.1.1.2. messageType . . . . . . . . . . . . . . . . . . . 19 86 3.1.1.3. pkiStatus . . . . . . . . . . . . . . . . . . . . 19 87 3.1.1.4. failInfo . . . . . . . . . . . . . . . . . . . . . 19 88 3.1.1.5. senderNonce and recipientNonce . . . . . . . . . . 20 89 3.1.1.6. signingTime Attribute . . . . . . . . . . . . . . 20 90 3.1.2. SCEP pkcsPKIEnvelope . . . . . . . . . . . . . . . . . 20 91 3.2. SCEP pkiMessage types . . . . . . . . . . . . . . . . . . 21 92 3.2.1. PKCSReq . . . . . . . . . . . . . . . . . . . . . . . 21 93 3.2.2. CertRep . . . . . . . . . . . . . . . . . . . . . . . 21 94 3.2.2.1. CertRep SUCCESS . . . . . . . . . . . . . . . . . 22 95 3.2.2.2. CertRep FAILURE . . . . . . . . . . . . . . . . . 23 96 3.2.2.3. CertRep PENDING . . . . . . . . . . . . . . . . . 23 97 3.2.3. GetCertInitial . . . . . . . . . . . . . . . . . . . . 23 98 3.2.3.1. IssuerAndSubject . . . . . . . . . . . . . . . . . 23 99 3.2.4. GetCert . . . . . . . . . . . . . . . . . . . . . . . 24 100 3.2.5. GetCRL . . . . . . . . . . . . . . . . . . . . . . . . 24 101 3.3. Degenerate certificates-only PKCS#7 Signed-data . . . . . 25 102 4. SCEP Transactions . . . . . . . . . . . . . . . . . . . . . . 25 103 4.1. Get CA Certificate . . . . . . . . . . . . . . . . . . . . 25 104 4.1.1. Get CA Certificate Response Message Format . . . . . . 25 105 4.1.1.1. CA Certificate Response Message Format . . . . . . 26 106 4.1.1.2. CA/RA Certificate Response Message Format . . . . 26 107 4.2. Certificate Enrollment . . . . . . . . . . . . . . . . . . 26 108 4.2.1. Certificate Enrollment Response Message . . . . . . . 26 109 4.3. Poll for Requester Initial Certificate . . . . . . . . . . 26 110 4.3.1. Polling Response Message Format . . . . . . . . . . . 27 111 4.4. Certificate Access . . . . . . . . . . . . . . . . . . . . 27 112 4.4.1. Certificate Access Response Message Format . . . . . . 28 113 4.5. CRL Access . . . . . . . . . . . . . . . . . . . . . . . . 28 114 4.5.1. CRL Access Response Message Format . . . . . . . . . . 28 115 4.6. Get Next Certification Authority Certificate . . . . . . . 28 116 4.6.1. Get Next CA Response Message Format . . . . . . . . . 28 117 5. SCEP Transport . . . . . . . . . . . . . . . . . . . . . . . . 29 118 5.1. HTTP "GET" Message Format . . . . . . . . . . . . . . . . 29 119 5.1.1. Response Message Format . . . . . . . . . . . . . . . 29 120 5.2. SCEP HTTP Messages . . . . . . . . . . . . . . . . . . . . 29 121 5.2.1. GetCACert . . . . . . . . . . . . . . . . . . . . . . 30 122 5.2.1.1. GetCACert Response . . . . . . . . . . . . . . . . 30 123 5.2.2. PKCSReq . . . . . . . . . . . . . . . . . . . . . . . 30 124 5.2.2.1. PKCSReq Response . . . . . . . . . . . . . . . . . 31 125 5.2.3. GetCertInitial . . . . . . . . . . . . . . . . . . . . 31 126 5.2.3.1. GetCertInitial Response . . . . . . . . . . . . . 31 127 5.2.4. GetCert . . . . . . . . . . . . . . . . . . . . . . . 31 128 5.2.4.1. GetCert Response . . . . . . . . . . . . . . . . . 31 129 5.2.5. GetCRL . . . . . . . . . . . . . . . . . . . . . . . . 31 130 5.2.5.1. GetCRL Response . . . . . . . . . . . . . . . . . 32 131 5.2.6. GetNextCACert . . . . . . . . . . . . . . . . . . . . 32 132 5.2.6.1. GetNextCACert Response . . . . . . . . . . . . . . 32 133 6. Contributors/Acknowledgements . . . . . . . . . . . . . . . . 32 134 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 135 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 136 8.1. General Security . . . . . . . . . . . . . . . . . . . . . 33 137 8.2. Use of the CA keypair . . . . . . . . . . . . . . . . . . 34 138 8.3. ChallengePassword . . . . . . . . . . . . . . . . . . . . 34 139 8.4. transactionID . . . . . . . . . . . . . . . . . . . . . . 35 140 8.5. Nonces and Replay . . . . . . . . . . . . . . . . . . . . 35 141 8.6. Key Usage Issues . . . . . . . . . . . . . . . . . . . . . 35 142 8.7. GetCACaps Issues . . . . . . . . . . . . . . . . . . . . . 35 143 8.8. Unnecessary cryptography . . . . . . . . . . . . . . . . . 35 144 8.9. GetNextCACert . . . . . . . . . . . . . . . . . . . . . . 36 145 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 146 9.1. Normative References . . . . . . . . . . . . . . . . . . . 36 147 9.2. Informative References . . . . . . . . . . . . . . . . . . 37 148 Appendix A. Private OID Definitions . . . . . . . . . . . . . . . 37 149 Appendix B. SCEP State Transitions . . . . . . . . . . . . . . . 38 150 Appendix C. CA Capabilities . . . . . . . . . . . . . . . . . . . 40 151 C.1. GetCACaps HTTP Message Format . . . . . . . . . . . . . . 40 152 C.2. CA Capabilities Response Format . . . . . . . . . . . . . 40 153 Appendix D. Client Certificate Renewal . . . . . . . . . . . . . 41 154 Appendix E. CA Key Rollover . . . . . . . . . . . . . . . . . . . 42 155 Appendix F. PKIOperation via HTTP POST Message . . . . . . . . . 43 156 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 158 1. Introduction 160 Public key technology is widely available and increasingly widely 161 deployed. X.509 certificates serve as the basis for several 162 standards-based security protocols in the IETF, such as The Internet 163 Key Exchange (IKE) [RFC2409] and IKEv2 [RFC4306], and The Transport 164 Layer Security Protocol (TLS) [RFC4346]. When an X.509 certificate 165 is issued by other than the certificate subject (a self-issued 166 certificate), there typically is a need for a certificate management 167 protocol. Such a protocol enables a PKI client to request a 168 certificate, certificate renewal, or certificate revocation from a 169 Certification Authority (CA). Often there also is a need for 170 protocols to request certificate revocation status information, 171 although these functions are often provided by distinct mechanisms, 172 e.g. Certificaet Revocation Lists (CRLs) [RFC4523] or Online 173 Certificate Status Protocol (OCSP) [RFC2560]. 175 This specification defines a protocol, Simple Certificate Enrollment 176 Protocol (SCEP), for certificate management and certificate and CRL 177 queries in a closed environment. While widely deployed, this 178 protocol omits some certificate management features, e.g. in-band 179 certificate revocation transactions, which can significantly enhance 180 the security achieved in a PKI. The IETF protocol suite currently 181 includes two certificate management protocols with more comprehensive 182 functionality: Certificate Management Protocol (CMP) [RFC4210] and 183 Certificate Management over CMS (CMC) [RFC5272]. Environments that 184 do not require interoperability with SCEP implementations SHOULD use 185 the above-mentioned, PKIX-standard certificate management protocols. 186 In light of the functionality gap between this specification and the 187 two IETF standards track protocols, this specification is being 188 published as Historic. Even when interoperability with the installed 189 base of SCEP implementations is needed, implementers are encouraged 190 to support one of these comprehensive standards track certificate 191 management protocols in addition to the protocol defined in this 192 specification. This implementation strategy balances near-term 193 requirements for interoperability with longer term security goals. 195 As a reflection of the history of SCEP implementations some of the 196 operations described in this document are indicated as 'SHOULD' or 197 'MAY' where a stricter protocol specification might have indicated a 198 'MUST'. 200 The protocol supports the following general operations: 202 o CA and Registration Authority (RA) public key distribution 204 o Certificate enrollment 205 o Certificate query 207 o CRLquery 209 SCEP makes extensive use of PKCS#7 [RFC2315] and PKCS#10 [RFC2986]. 211 1.1. Requirements Language 213 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 214 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 215 document are to be interpreted as described in [RFC2119]. 217 2. SCEP Overview 219 This section provides a high level overview of the functionality of 220 SCEP. 222 2.1. SCEP Entities 224 The entity types defined in SCEP are 226 o the Requester (Section 2.1.1) (e.g., IPSEC clients) 228 o the Server, which may be either a Certification Authority (CA) 229 (Section 2.1.2) or a Registration Authority (RA) (Section 2.1.3) 231 2.1.1. Requester 233 The requester is sometimes called a "client" in this document. It is 234 the client of the SCEP exchange. 236 The requester MAY submit SCEP messages for itself or it MAY submit 237 SCEP messages on behalf of peers as described in Registration 238 Authority (Section 2.1.3). This section focuses on the requester 239 that is obtaining certificates for its own use. 241 Before a requester can start a PKI transaction, it MUST have at least 242 one appropriate key pair (e.g. RSA) for use when signing the SCEP 243 pkiMessage (Section 3.1). 245 The message types, being based on PKCS#7 [RFC2315] and PKCS#10 246 [RFC2986], fully support algorithm agility but the requester has to 247 use a key type that is supported by the server. RSA is the only 248 algorithm supported by current implementations. 250 A requester MUST have the following information locally configured: 252 1. The Certification Authority IP address or fully qualified domain 253 name 255 2. The Certification Authority HTTP CGI script path 257 3. The identifying information that is used for authentication of 258 the Certification Authority in Section 4.1.1. This information 259 MAY be obtained from the user, or presented to the end user for 260 manual authorization during the protocol exchange (e.g. the user 261 indicates acceptance of a fingerprint via a user-interface 262 element). 264 The requester MUST have MESSAGE information configured if the 265 Certification Authority requires it (see Section 5.1). 267 The requester MAY maintain multiple independent configurations 268 appropriate for multiple Certification Authorities. Doing so does 269 not effect the protocol operation and is not in scope of this 270 document. 272 Certificate requests for certificates whose purpose is a specific 273 solution are encouraged to conform to the solution's profile, e.g. 274 [RFC4945] Section 5 for IKE/IPsec certificates. 276 2.1.2. Certification Authority 278 An SCEP Certification Authority (CA) is the entity that signs client 279 certificates. The CAs name appears in the issuer field of resulting 280 certificates. 282 Before any PKI operations can occur, the SCEP CA server obtains a 283 'CA' certificate that is compliant with the profile in [RFC5280]. 284 This MAY be a CA certificate that was issued by a higher level CA. 286 The SCEP server CA certificate MUST be provided out-of-band to the 287 SCEP requester. The CA certificate fingerprint MAY be used to 288 authenticate a CA Certificate distributed by the GetCACert response 289 (Section 4.1.1). The fingerprint is created by calculating a SHA-1, 290 SHA-256, SHA-512, or MD5 hash on the whole CA certificate. 292 The certification authority MUST either include a 293 cRLDistributionPoint extension in every certificate it issues or 294 answer CRL queries itself, in which case it SHOULD be online at all 295 times. The certification authority SHOULD either answer certificate 296 queries or make certificates available via LDAP. 298 A certification authority may enforce any arbitrary policies, 299 including name uniqueness policies, and apply them to certification 300 requests. The certification authority MAY reject any request. If 301 the client has already been issued a certificate for this keypair the 302 server MAY return the previously created certificate. The requester 303 MUST NOT assume any of the fields in the certification request, 304 except for the public key, will be the same in the certificate 305 issued. 307 If a client times out from polling for a pending request it can 308 resynchronize by reissuing the original request with the original 309 subject name, key, and transaction ID. The CA SHOULD return the 310 status of the original transaction, including the certificate if it 311 was granted. The CA SHOULD NOT create a new transaction unless the 312 original certificate has been revoked, or the transaction arrives 313 more than halfway through the validity period of the original 314 certificate. 316 2.1.3. Registration Authority 318 An SCEP Registration Authority (RA) is an SCEP server that performs 319 validation and authorization checks of the SCEP requester but 320 forwards the certification requests to the CA. The RAs name does not 321 appear in the issuer field of resulting certificates. 323 The RA MUST return the RA certificate, in addition to the CA 324 certificate, in the GetCACert Response (see Section 5.2.1.1.2). The 325 existence of an RA certificate in this response indicates to the 326 client that an RA is in use. In order to securely communicate with 327 an RA using SCEP Secure Message Objects (Section 3) the client 328 specifies the RA as the recipient of subsequent SCEP pkiMessages (see 329 Section 3.1.2). 331 In order to service certification requests the RA must pass the 332 requests to the CA server for signing. The RA MAY use SCEP to 333 communicate with the CA, in which case the RA acts as both an SCEP 334 server (between the client and the RA) and an SCEP requester (between 335 the RA and the CA). The RA MAY respond to client certificate 336 requests with a PENDING response while communicating with the CA; for 337 example if the CA must manually authorize a certification request and 338 thus returns PENDING to the RA the RA may respond with PENDING to the 339 client while polling the CA. 341 Communication between the RA and the CA MAY be over other protocols 342 such as Certificate Management over CMS [RFC5272]. 344 2.2. Requester authentication 346 As with every protocol that uses public-key cryptography, the 347 association between the public keys used in the protocol and the 348 identities with which they are associated must be authenticated in a 349 cryptographically secure manner. This requirement is needed to 350 prevent a "man-in-the-middle" attack, in which an adversary can 351 manipulate the data as it travels between the protocol participants 352 and subvert the security of the protocol. 354 The communication between the requester and the certification 355 authority are secured using SCEP Secure Message Objects (Section 3) 356 which specifies how PKCS#7 [RFC2315] is used to encrypt and sign the 357 data. In order to perform the signing operation the client uses an 358 appropriate local certificate: 360 1. If the requesting system already has a certificate issued by the 361 SCEP server, and the server supports renewal (see Appendix C), 362 that certificate SHOULD be used. 364 2. If the requesting system has no certificate issued by the new CA, 365 but has credentials from an alternate CA the certificate issued 366 by the alternate CA MAY be used. Policy settings on the new CA 367 will determine if the request can be accepted or not. This is 368 useful when enrolling with a new administrative domain; by using 369 a certificate from the old domain as credentials. 371 3. If the requester does not have an appropriate existing 372 certificate, then a locally generated self-signed certificate 373 MUST be used instead. The self-signed certificate MUST use the 374 same subject name as in the PKCS#10 request. 376 During the certificate enrollment, the requester MUST use the 377 selected certificate's keypair when signing the PKCS#7 [RFC2315] (see 378 Section 3). The server CertResp uses this signing certificate's 379 public key when encrypting the response (see Section 3.2.2). 381 When the certification authority creates the PKCS#7 [RFC2315] 382 envelope on the issued certificate, it SHOULD use the public key, 383 issuer name, and serial number conveyed in the above included 384 certificate. This will inform the end entity of which private key is 385 needed to open the envelope. Note that when a client enrolls for 386 separate encryption and signature certificates, it MAY use the 387 signature certificate to sign both requests, and then expect its 388 signature key to be used to encrypt both responses. In any case, the 389 RecipientInfo on the envelope MUST reflect the key used to encrypt 390 the request. 392 2.3. Enrollment authorization 394 There are two mechanisms for automated enrollment authorization. 396 When the client uses a keypair that is associated with a certificate 397 which is not self-signed to sign SCEP messages the server MAY use 398 this certificate to authenticate the client and determine the 399 appropriate authorization. The SCEP server SHOULD implement 400 appropriate logic to support client authentication and automated 401 enrollment using existing client credentials that were issued by an 402 alternate PKI hierarchy, in addition to the policy requirements 403 implied by optional support of renewal (see Appendix D). The SCEP 404 server MUST NOT attempt to authenticate a client based on a self- 405 signed certificate. 407 PKCS#10 [RFC2986] specifies a PKCS#9 [RFC2985] challengePassword 408 attribute to be sent as part of the enrollment request. Inclusion of 409 the challengePassword by the SCEP client is OPTIONAL and allows for 410 unauthenticated authorization of enrollment requests. The PKCS#7 411 [RFC2315] envelope protects the privacy of the challenge password. 413 When utilizing the challengePassword, the server distributes a shared 414 secret to the requester which will uniquely associate the enrollment 415 request with the requester. The distribution of the secret must be 416 private: only the end entity should know this secret. The actual 417 binding mechanism between the requester and the secret is subject to 418 the server policy and implementation. 420 A client that is performing certificate renewal as per Appendix D 421 SHOULD send an empty challenge password (i.e. use the empty string as 422 the challenge password) but MAY send the originally distributed 423 challenge password in the challengePassword attribute. In the former 424 case the SCEP CA MUST authenticate the request based on the 425 certificate used to sign the renewal request. In the latter case the 426 SCEP CA MAY use either the challengePassword or the previously issued 427 certificate (or both) to authenticate the request. 429 In the manual mode the requester's messages are placed in the PENDING 430 state until the CA operator authorizes or rejects them. Manual 431 authorization is used when the client has only a self-signed 432 certificate and/or a challengePassword is not available. The SCEP 433 server MAY either reject unauthorized certification requests or mark 434 them for manual authorization according to server configuration. 436 The requester generates a SHA-1, SHA-256, SHA-512, or MD5 437 'fingerprint' of the PKCS#10 [RFC2986] (before PKCS#7 [RFC2315] 438 enveloping and signing). This fingerprint is sent to the CA operator 439 using an out-of-band method. The CA operator MUST compared this 440 fingerprint to a locally generated fingerprint based on the message 441 received during the SCEP exchange. 443 SCEP clients and CAs (or RAs, if appropriate) MUST support display of 444 this fingerprint to the operator to enable this authorization method. 445 The out-of-band distribution and comparison of fingerprints is not 446 covered by this document. 448 2.4. CA/RA Certificate Distribution 450 If the CA and/or RA certificates have not previously been acquired by 451 the requester in some other means, the requester MUST retrieve the 452 CA/RA certificates before any PKI operation (Section 3) can be 453 started. 455 Since no public key has yet been exchanged between the requester and 456 the CA/RA, the messages cannot be secured using PKCS#7 [RFC2315], and 457 the data is instead transferred in the clear. 459 If an RA is in use, a certificates-only PKCS#7 [RFC2315] SignedData 460 with a certificate chain consisting of both RA and CA certificates is 461 returned. Otherwise the CA certificate itself is returned. The 462 transport protocol (Section 5) MUST indicate which one is returned. 464 After the requester gets the CA certificate, it MUST authenticate the 465 CA certificate by comparing the CA certificate fingerprint (see 466 Section 2.1.2) with the locally configured, out-of-band distributed, 467 identifying information. RA certificates, if any, are signed by the 468 CA so there is no need to authenticate them against the out-of-band 469 data. Clients MUST verify the RA certificate signatures before use 470 during protocol exchanges. 472 Clients MUST verify the authorization of the RA certificates. The 473 authorization mechanism is specified by the CA administrator and is 474 out of scope for this document. 476 Because a long time can pass between queries from a requester to a 477 CA/RA and because RA certificates can change at any time, it is 478 recommended that a requester not store RA certificates. Instead, the 479 requester SHOULD retrieve the CA/RA certificates before each 480 operation. 482 2.5. Certificate Enrollment 484 A requester starts an enrollment (Section 3.2.1) transaction by 485 creating a certificate request using PKCS#10 [RFC2986] and sends it 486 to the CA/RA enveloped using the PKCS#7 (Section 3). 488 It is up to local CA policy (and CA implementation) as to whether a 489 certificate is granted automatically, or whether it is manually 490 granted by the administrator. The challengePassword MAY be used to 491 automatically authorize the request. 493 If the CA/RA returns a CertRep (Section 3.2.2) message with status 494 set to PENDING, the requester enters into polling mode by 495 periodically sending a GetCertInitial (Section 3.2.3) PKI message to 496 the CA/RA, until the CA/RA operator completes the manual 497 authentication (approving or denying the request). 499 In general, the requester will send a single PKCSReq (Section 3.2.1) 500 message, followed by 0 or more GetCertInitial (Section 3.2.3) 501 messages, if polling mode is entered. 503 In general, the CA/RA will send 0 or more CertRep (Section 3.2.2) 504 messages with status set to PENDING, followed by a single CertRep 505 (Section 3.2.2) with status set to either SUCCESS or FAILURE. 507 2.5.1. Client State Transitions 509 The requester state transitions during enrollment operation are 510 indicated in Figure 1. 512 GetCertInitial 513 +----<---+ 514 | | CertRep(PENDING), 515 | | GetCertInitial send-timeout, 516 | | new-poll timer 517 | | 518 [CERT-NONEXISTANT] -----+---> [CERT-REQ-PENDING] [CERT-ISSUED] 519 ^ PKCSReq | | ^ 520 | | | | 521 | | +---------------+ 522 | | CertRep(SUCCESS) 523 +--------------------------+ 524 CertRep(FAILURE), 525 PKCSReq send-timeout, 526 max-time/max-polls exceeded 528 Figure 1: State Transition Diagram 530 Certificate enrollment starts at the state CERT-NONEXISTANT. 532 Sending a PKCSReq message changes the state to CERT-REQ-PENDING. If 533 there is no response, or sending is not possible, the state reverts 534 back to CERT-NONEXISTANT. 536 Receiving a CertRep message with pkiStatus set to SUCCESS changes the 537 state to CERT-ISSUED. 539 Receiving a CertRep message with pkiStatus set to FAILURE changes the 540 state to CERT-NONEXISTANT. 542 If the server sends back a CertRep message with pkiStatus set to 543 PENDING, the requester will keep polling by sending a GetCertInitial 544 message to the server, until either a CertRep message with status set 545 to SUCCESS or FAILURE is received, or the maximum number of polls has 546 been exceeded. 548 If the maximum number of polls has been exceeded or a CertRep message 549 with pkiStatus set to FAILURE is received while in the CERT-REQ- 550 PENDING state, the end entity will transition to the CERT-NONEXISTANT 551 state, and the SCEP client can eventually initiate another enrollment 552 request. It is important to note that, as long as the requester does 553 not change its subject name or keys, the same transaction ID will be 554 used in the "new" transaction. This is important because based on 555 this transaction ID, the certification authority can recognize this 556 as an existing transaction instead of a new one. 558 A successful transaction in automatic mode: 559 REQUESTER CA SERVER 561 PKCSReq: PKI cert. enrollment msg 562 --------------------------------> CertRep: pkiStatus = SUCCESS 563 certificate attached 564 <------------------------------ 565 Receive issued certificate. 567 Figure 2: Automatic mode transaction 569 A successful transaction in manual mode: 570 REQUESTER CA SERVER 571 PKCSReq: PKI cert. enrollment msg 572 --------------------------------> CertRep: pkiStatus = PENDING 573 <------------------------------ 574 GetCertInitial: polling msg 575 --------------------------------> CertRep: pkiStatus = PENDING 576 <------------------------------ 577 ................ ............... 579 GetCertInitial: polling msg 580 --------------------------------> CertRep: pkiStatus = SUCCESS 581 certificate attached 582 <------------------------------ 583 Receive issued certificate. 585 Figure 3: Manual mode transaction 587 2.6. Certificate Access 589 A certificate query message is defined for clients to retrieve a copy 590 of their own certificates from the CA. It allows clients that do not 591 store their certificate locally to obtain a copy when needed. This 592 functionality is not intended to provide a general purpose 593 certificate directory service. 595 To query a certificate from the certification authority, a requester 596 sends a request consisting of the certificate's issuer name and 597 serial number. This assumes that the requester has saved the issuer 598 name and the serial number of the issued certificate from the 599 previous enrollment transaction. The transaction to query a 600 certificate consists of one GetCert (Section 3.2.4) message and one 601 CertRep (Section 3.2.2) message, as shown in Figure 4. 603 REQUESTER CA SERVER 604 GetCert: PKI certificate query msg 605 -------------------------------> CertRep: pkiStatus = SUCCESS 606 certificate attached 607 <----------------------------- 608 Receive the certificate. 610 Figure 4: GetCert Transaction 612 2.7. CRL Access 614 SCEP clients request a CRL via one of two methods: 616 1. If the CA supports CRL Distribution Points (CDPs) [RFC5280] 617 (Section 4.2.1.13), then the CRL MUST be retrieved via the 618 mechanism specified in the CDP. 620 2. If the CA does not support CDP's, a CRL query is composed by 621 creating a GetCRL message consisting of the issuer name and 622 serial number from a certificate within the scope of the CRL to 623 be retrieved (e.g. from a certificate to be validated). 625 The server SHOULD NOT support the GetCRL method because: 627 o it does not scale well due to the unnecessary cryptography (see, 628 Section 8.8) 630 o it requires the CA to be a high-availability service 632 o only limited information to determine the CRL scope is provided 633 (see [RFC5280] Section 5). 635 The message is sent to the SCEP server in the same way as the other 636 SCEP requests: The transaction to retrieve a CRL consists of one 637 GetCRL PKI message and one CertRep PKI message, which contains only 638 the CRL (no certificates), as shown in Figure 5. 640 On receipt of this message, the SCEP server MAY use the 641 IssuerAndSerial information to return an appropriate CRL. 643 REQUESTER CA SERVER 644 GetCRL: PKI CRL query msg 645 ----------------------------------> 646 CertRep: CRL attached 647 <-------------------------------- 649 Figure 5: GetCRL Transaction 651 2.8. Certificate Revocation 653 SCEP does not specify a method to request certificate revocation. 655 In order to revoke a certificate, the requester must contact the CA 656 server operator using a non-SCEP defined mechanism. Although the 657 PKCS#10 [RFC2986] challengePassword is used by SCEP for enrollment 658 authorization (see Enrollment authorization (Section 2.3)) this does 659 not inhibit the CA server from maintaining a record of the 660 challengePassword to use during subsequent revocation operations as 661 implied by [RFC2985]. 663 3. SCEP Secure Message Objects 665 PKCS#7 [RFC2315] is a general enveloping mechanism that enables both 666 signed and encrypted transmission of arbitrary data. 668 All messages MUST be valid PKCS#7 [RFC2315] structures, unless 669 otherwise noted. 671 SCEP messages that require confidentiality use two layers of PKCS#7, 672 as shown in Figure 6. By applying both enveloping and signing 673 transformations, the SCEP message is protected both for the integrity 674 of its end-to-end transaction information and the confidentiality of 675 its information portion. The advantage of this technique over the 676 conventional transaction message format is that the signed 677 transaction type information and the status of the transaction can be 678 determined prior to invoking security handling procedures specific to 679 the information portion being processed. 681 Some messages do not require enveloping, in which case the 682 EnvelopedData in Figure 6 is omitted. 684 ContentType = SignedData (called pkiMessage) 685 SignerInfo 686 Signature 687 authenticatedAttributes 688 transactionID 689 messageType 690 pkiStatus 691 failInfo 692 senderNonce 693 recipientNonce 694 etc 695 ContentInfo type = EnvelopedData (called pkcsPKIEnvelope; optional) 696 RecipientInfo 697 ContentInfo type = Data 698 messageData 700 Figure 6: PKCS#7 Layering 702 Description: 704 o The outer PKCS#7 is a pkiMessage (Section 3.1). 706 o The SignedData ContentInfo, if present (e.g. FAILURE and PENDING 707 CertRep messages will lack any signed content), MUST be a 708 pkcsPKIEnvelope (Section 3.1.2). 710 When a particular SCEP message carries data, this data is carried in 711 the messageData. 713 Note: The remainder of this document will refer only to 714 'messageData', but it is understood to always be encapsulated in the 715 pkcsPKIEnvelope (Section 3.1.2). The format of the data in the 716 messageData is defined by the messageType attribute (see 717 Section 3.1.1) of the SignedData. If there is no messageData to be 718 transmitted, the entire pkcsPKIEnvelope MUST be omitted. 720 3.1. SCEP pkiMessage 722 The basic building block of all secured SCEP messages is the SCEP 723 pkiMessage. It consists of an PKCS#7 signed-data content type, as 724 defined in PKCS#7 [RFC2315] Section 9. The following restrictions 725 apply: 727 o version MUST be 1 729 o the contentType in contentInfo MUST be data ({pkcs-7 1}) as 730 defined in PKCS#7 [RFC2315] Section 8. 732 o The signed content, if present (e.g. FAILURE and PENDING CertRep 733 messages will lack any signed content), MUST be a pkcsPKIEnvelope 734 (Section 3.1.2), and MUST match the messageType attribute. 736 o The SignerInfo MUST contain a set of authenticatedAttributes (see 737 PKCS#7 [RFC2315] Section 9.2 as well as Section 3.1.1 in this 738 document). All messages MUST contain 740 * an SCEP transactionID attribute 742 * an SCEP messageType attribute 744 * an SCEP senderNonce attribute 746 * any attributes required by PKCS#7 [RFC2315] Section 9.2 748 If the message is a response, it MUST also include 750 * an SCEP pkiStatus attribute 752 * an SCEP recipientNonce attribute 754 3.1.1. Signed Transaction Attributes 756 The following transaction attributes are encoded as authenticated 757 attributes, and are carried, as specified in PKCS#7 [RFC2315] Section 758 9.2, in the SignerInfo for this signedData. 760 Please refer to Appendix A for the OID definitions. 762 +----------------+-----------------+---------------------------+ 763 | Attribute | Encoding | Comment | 764 +----------------+-----------------+---------------------------+ 765 | transactionID | PrintableString | Hash value as a string | 766 | messageType | PrintableString | Decimal value as a string | 767 | pkiStatus | PrintableString | Decimal value as a string | 768 | failInfo | PrintableString | Decimal value as a string | 769 | senderNonce | OCTET STRING | | 770 | recipientNonce | OCTET STRING | | 771 +----------------+-----------------+---------------------------+ 773 Transaction Attributes 775 The attributes are detailed in the following sections. 777 3.1.1.1. transactionID 779 A PKI operation is a transaction consisting of the messages exchanged 780 between a requester and the server. The transaction identifier is a 781 string generated by the client when starting a transaction. The 782 client MUST generate a unique string as the transaction identifier, 783 which MUST be used for all PKI messages exchanged for a given 784 enrollment, encoded as a PrintableString. 786 The transactionID SHOULD be generated as a SHA-1, SHA-256, SHA-512 or 787 MD5 hash on the public key value for which the enrollment request is 788 made. This allows the SCEP client to automatically generate the same 789 transactionID for any given keypair. The SCEP protocol requires that 790 transactionIDs be unique, so that subsequent polling queries can be 791 matched with previous transactions. When separate signing and 792 encryption certificates are requested by the client, using distinct 793 keypairs ensures that distinct transactionIDs are also used. 795 When using the certificate query and CRL query messages defined in 796 this protocol, the transactionID is required so that the requester 797 can match the response message with the outstanding request message. 798 When using LDAP to query the certificate and the CRL, the behavior is 799 specified by the LDAP protocol. For a non-enrollment message (for 800 example GetCert and GetCRL), the transactionID SHOULD be a number 801 unique to the client. 803 3.1.1.2. messageType 805 The messageType attribute specifies the type of operation performed 806 by the transaction. This attribute MUST be included in all PKI 807 messages. The following message types are defined: 809 o PKCSReq (19) -- PKCS#10 [RFC2986] certificate request 811 o CertRep (3) -- Response to certificate or CRL request 813 o GetCertInitial (20) -- Certificate polling in manual enrollment 815 o GetCert (21) -- Retrieve a certificate 817 o GetCRL (22) -- Retrieve a CRL 819 Undefined message types are treated as an error. 821 3.1.1.3. pkiStatus 823 All response messages MUST include transaction status information, 824 which is defined as pkiStatus attribute: 826 o SUCCESS (0) -- request granted 828 o FAILURE (2) -- request rejected. When pkiStatus is FAILURE, the 829 failInfo attribute, as defined in Section 3.1.1.4, MUST also be 830 present. 832 o PENDING (3) -- request pending for manual approval 834 Undefined pkiStatus attributes are treated as an error. 836 3.1.1.4. failInfo 838 The failInfo attribute MUST contain one of the following failure 839 reasons: 841 o badAlg (0) -- Unrecognized or unsupported algorithm identifier 843 o badMessageCheck (1) -- integrity check failed 845 o badRequest (2) -- transaction not permitted or supported 847 o badTime (3) -- The signingTime attribute from the PKCS#7 848 authenticatedAttributes was not sufficiently close to the system 849 time (see Section 3.1.1.6). 851 o badCertId (4) -- No certificate could be identified matching the 852 provided criteria 854 Undefined failInfo attributes are treated as an error. 856 3.1.1.5. senderNonce and recipientNonce 858 The attributes of senderNonce and recipientNonce are a 16 byte random 859 number generated for each transaction. These are intended to prevent 860 replay attacks. 862 When a requester sends a PKI message to the server, a senderNonce 863 MUST be included in the message. 865 The recipient SHOULD copy the senderNonce into the recipientNonce of 866 the reply as a proof of liveliness. 868 The requester SHOULD verify that the recipientNonce of the reply 869 matches the senderNonce it sent in the request. 871 3.1.1.6. signingTime Attribute 873 The signingTime attribute is defined in [RFC2985] Section 5.3.3, and 874 is carried as specified in [RFC2315] Section 9.2. This attribute is 875 OPTIONAL. 877 3.1.2. SCEP pkcsPKIEnvelope 879 The information portion of a SCEP message is carried inside an 880 enveloped-data content type, as defined in PKCS#7 [RFC2315] Section 881 10, with the following restrictions: 883 o version MUST be 0 885 o contentType in encryptedContentInfo MUST be data ({pkcs-7 1}) as 886 defined in PKCS#7 [RFC2315] Section 8. 888 o encryptedContent MUST be the SCEP message being transported (see 889 Section 4), and must match the messageType authenticated Attribute 890 in the pkiMessage. 892 The PKCS#7 [RFC2315] content-encryption key (see Section 10, step 2) 893 is encrypted using the public key of the recipient of the message, 894 i.e. the RA or the CA public key (if sent from the requester), or the 895 requester public key (if sent as a reply to the requester). 897 3.2. SCEP pkiMessage types 899 All of the messages in this section are pkiMessages (Section 3.1), 900 where the type of the message MUST be specified in the 'messageType' 901 authenticated Attribute. Each section defines a valid message type, 902 the corresponding messageData formats, and mandatory authenticated 903 attributes for that type. 905 3.2.1. PKCSReq 907 The messageData for this type consists of a PKCS#10 Certification 908 Request [RFC2986]. The certification request MAY contain any fields 909 defined in PKCS#10 [RFC2986], and MUST contain at least the following 910 items: 912 o the subject Distinguished Name 914 o the subject public key 916 o a challengePassword attribute. The Challenge Password may be used 917 to (out-of-band) authenticate the enrollment request itself, or in 918 an out-of-band revocation request for the issued certificate. 920 In addition to the authenticatedAttributes required for a valid 921 PKCS#7 [RFC2315], this pkiMessage MUST include the following 922 attributes: 924 o a transactionID (Section 3.1.1.1) attribute 926 o a messageType (Section 3.1.1.2) attribute set to PKCSReq 928 o a senderNonce (Section 3.1.1.5) attribute 930 The pkcsPKIEnvelope for this message type is protected using the 931 public key of the recipient as detailed in Section 3.1.2, e.g. either 932 the CA or RA public key. 934 3.2.2. CertRep 936 The messageData for this type consists of a degenerate certificates- 937 only PKCS#7 Signed-data (Section 3.3). The exact content required 938 for the reply depends on the type of request this message is a reply 939 to. They are detailed in Table 1 and in Section 4. 941 In addition to the authenticatedAttributes required for a valid 942 PKCS#7 [RFC2315], this pkiMessage MUST include the following 943 attributes: 945 o the transactionID (Section 3.1.1.1) attribute copied from the 946 request we are responding to 948 o a messageType (Section 3.1.1.2) attribute set to CertRep 950 o a senderNonce (Section 3.1.1.5) attribute 952 o a recipientNonce attribute (Section 3.1.1.5) copied from the 953 senderNonce from the request we are responding to. 955 o a pkiStatus (Section 3.1.1.3) set to the status of the reply. 957 The pkcsPKIEnvelope for this message type is protected using the 958 public key of the recipient as detailed in Section 3.1.2. For 959 example if a self-signed certificate was used to send the original 960 request then this self-signed certificate's public key is used to 961 encrypt the content-encryption key of the SUCCESS response's 962 pkcsPKIEnvelope. 964 3.2.2.1. CertRep SUCCESS 966 When the pkiStatus attribute is set to SUCCESS, the messageData for 967 this message consists of a degenerate certificates-only PKCS#7 968 Signed-data (Section 3.3). The content of this degenerate 969 certificates-only Signed-Data depends on what the original request 970 was, as outlined in Table 1. 972 +----------------+--------------------------------------------------+ 973 | Request-type | Reply-contents | 974 +----------------+--------------------------------------------------+ 975 | PKCSReq | the reply MUST contain at least the issued | 976 | | certificate in the certificates field of the | 977 | | Signed-Data. The reply MAY contain additional | 978 | | certificates, but the issued certificate MUST be | 979 | | the first in the list. The reply MUST NOT | 980 | | contain a CRL. All returned certificates MUST | 981 | | conform to [RFC5280]. | 982 | GetCertInitial | same as PKCSReq | 983 | GetCert | the reply MUST contain at least the requested | 984 | | certificate in the certificates field of the | 985 | | Signed-Data. The reply MAY contain additional | 986 | | certificates, but the requested certificate MUST | 987 | | be the first in the list. The reply MUST NOT | 988 | | contain a CRL. All returned certificates MUST | 989 | | conform to [RFC5280]. | 990 | GetCRL | the reply MUST contain the CRL in the crls field | 991 | | of the Signed-Data. The reply MUST NOT contain | 992 | | a certificate. The CRL MUST be a valid CRL | 993 | | according to [RFC5280]. | 994 +----------------+--------------------------------------------------+ 996 Table 1: CertRep Types 998 3.2.2.2. CertRep FAILURE 1000 When the pkiStatus attribute is set to FAILURE, the reply MUST also 1001 contain a failInfo (Section 3.1.1.4) attribute set to the appropriate 1002 error condition describing the failure. The pkcsPKIEnvelope 1003 (Section 3.1.2) MUST be omitted. 1005 3.2.2.3. CertRep PENDING 1007 When the pkiStatus attribute is set to PENDING, the pkcsPKIEnvelope 1008 (Section 3.1.2) MUST be omitted. 1010 3.2.3. GetCertInitial 1012 The messageData for this type consists of a IssuerAndSubject 1013 (Section 3.2.3.1). The issuer is set to the issuerName from the 1014 certification authority from which we are issued certificates. The 1015 Subject is set to the SubjectName we used when requesting the 1016 certificate. 1018 In addition to the authenticatedAttributes required for a valid 1019 PKCS#7 [RFC2315], this pkiMessage MUST include the following 1020 attributes: 1022 o the same transactionID (Section 3.1.1.1) attribute from original 1023 PKCSReq message 1025 o a messageType (Section 3.1.1.2) attribute set to GetCertInitial 1027 o a senderNonce (Section 3.1.1.5) attribute 1029 3.2.3.1. IssuerAndSubject 1031 Similar to the IssuerAndSerial defined in PKCS#7 [RFC2315] Section 1032 6.7, we need to define an IssuerAndSubject ASN.1 type (Figure 7). 1034 The ASN.1 definition of the issuerAndSubject type is as follows: 1035 issuerAndSubject ::= SEQUENCE { 1036 issuer Name, 1037 subject Name 1038 } 1040 Figure 7: IssuerAndSubject ASN.1 1042 3.2.4. GetCert 1044 The messageData for this type consists of a IssuerAndSerial as 1045 defined in PKCS#7 [RFC2315] Section 6.7 containing the "distinguished 1046 name of the certificate issuer and an issuer-specific certificate 1047 serial number" which uniquely identifies the certificate being 1048 requested. 1050 In addition to the authenticatedAttributes required for a valid 1051 PKCS#7 [RFC2315], this pkiMessage MUST include the following 1052 attributes: 1054 o a transactionID (Section 3.1.1.1) attribute 1056 o a messageType (Section 3.1.1.2) attribute set to GetCert 1058 o a senderNonce (Section 3.1.1.5) attribute 1060 A self-signed certificate MAY be used in the signed envelope. This 1061 enables the requester to request their own certificate if they were 1062 unable to store it previously. 1064 3.2.5. GetCRL 1066 The messageData for this type consists of a IssuerAndSerial as 1067 defined in PKCS#7 [RFC2315] Section 6.7 along with the issuer name 1068 and serial number from the certificate to be validated. 1070 In addition to the authenticatedAttributes required for a valid 1071 PKCS#7 [RFC2315], this pkiMessage MUST include the following 1072 attributes: 1074 o a transactionID (Section 3.1.1.1) attribute 1076 o a messageType (Section 3.1.1.2) attribute set to GetCRL 1078 o a senderNonce (Section 3.1.1.5) attribute 1080 3.3. Degenerate certificates-only PKCS#7 Signed-data 1082 [RFC2315] Section 9 includes a degenerate case of the PKCS#7 Signed- 1083 data content type, in which there are no signers. The use of such a 1084 degenerate case is to disseminate certificates and certificate- 1085 revocation lists. For SCEP the content field of the ContentInfo 1086 value of a degenerate certificates-only Signed-Data MUST be omitted. 1088 When carrying certificates, the certificates are included in the 1089 'certificates' field of the Signed-Data. When carrying a CRL, the 1090 CRL will be included in the 'crls' field of the Signed-Data. 1092 4. SCEP Transactions 1094 This section describes the SCEP Transactions, without explaining the 1095 transport. The transport of each message is discussed in Section 5. 1096 Some of the transaction-requests have no data to send, i.e. the only 1097 data is the message-type itself (e.g. a GetCACert message has no 1098 additional data). The use of such messages will become clearer in 1099 Section 5. 1101 In this section, each SCEP transaction is specified in terms of the 1102 complete messages exchanged during the transaction. 1104 The order of the transactions in this section is mirrored in 1105 Section 5.2 for better organization and readability. 1107 4.1. Get CA Certificate 1109 To get the CA certificate(s), the requester sends a GetCACert message 1110 to the server. There is no request data associated with this message 1111 (see Section 5.2.1). 1113 4.1.1. Get CA Certificate Response Message Format 1115 The response depends on whether the responding server has RA 1116 certificates or only a single CA certificate. The server MUST 1117 indicate which response it is sending via the transport protocol used 1118 (see Section 5.2.1). 1120 All returned certificates MUST conform to [RFC5280]. 1122 A fingerprint is generated using the SHA-1, SHA-256, SHA-512 or MD5 1123 hash algorithm on the whole CA certificate received by the requester 1124 (regardless of the presence of RA certificates). If the requester 1125 does not have a certificate path to a trust anchor certificate, this 1126 fingerprint may be used to verify the certificate, by some positive 1127 out-of-band means, such as a phone call or prior configuration. 1129 4.1.1.1. CA Certificate Response Message Format 1131 If the server is a certification authority and does not have any RA 1132 Certificates, the response consists of a single X.509 CA certificate. 1134 4.1.1.2. CA/RA Certificate Response Message Format 1136 If the server has RA Certificates, the response consists of a 1137 degenerate certificates-only PKCS#7 Signed-data (Section 3.3) 1138 containing the CA certificate and RA certificates. 1140 4.2. Certificate Enrollment 1142 A PKCSReq (Section 3.2.1) message is used to perform a certificate 1143 enrollment transaction. 1145 The reply MUST be a CertRep (Section 3.2.2) message sent back from 1146 the server, indicating SUCCESS, FAILURE, or PENDING. 1148 Precondition: Both the requester and the certification authority have 1149 completed their initialization process. The requester has already 1150 been configured with the CA/RA certificate. 1152 Postcondition: The requester receives the certificate, the request is 1153 rejected, or the request is pending. A pending response might 1154 indicate that manual authentication is necessary. 1156 4.2.1. Certificate Enrollment Response Message 1158 If the request is granted, a CertRep (Section 3.2.2) message with 1159 pkiStatus set to SUCCESS is returned. The reply MUST also contain 1160 the certificate (and MAY contain any other certificates needed by the 1161 requester). The issued certificate MUST be the first in the list. 1163 If the request is rejected, a CertRep (Section 3.2.2) message with 1164 pkiStatus set to FAILURE is returned. The reply MUST also contain a 1165 failInfo attribute. 1167 If the the CA is configured to manually authenticate the requester, a 1168 CertRep (Section 3.2.2) message with pkiStatus set to PENDING MAY be 1169 returned. The CA MAY return a PENDING for other reasons. 1171 4.3. Poll for Requester Initial Certificate 1173 Triggered by a CertRep (Section 3.2.2) with pkiStatus set to PENDING, 1174 a requester will enter the polling state by periodically sending 1175 GetCertInitial (Section 3.2.3) to the server, until either the 1176 request is granted and the certificate is sent back, or the request 1177 is rejected, or the configured time limit for polling (or maximum 1178 number of polls) is exceeded. 1180 Since GetCertInitial is part of the enrollment, the messages 1181 exchanged during the polling period MUST carry the same transactionID 1182 attribute as the previous PKCSReq. A server receiving a 1183 GetCertInitial for which it does not have a matching PKCSReq MUST 1184 ignore this request. 1186 Since at this time the certificate has not been issued, the requester 1187 can only use its own subject name (which was contained in the 1188 original PKCS#10 sent via PKCSReq) to identify the polled certificate 1189 request. Since there can be multiple outstanding requests from one 1190 requester (for example, if different keys and different key-usages 1191 were used to request multiple certificates), the transaction ID must 1192 also be included, to disambiguate between multiple requests. 1194 PreCondition: The requester has received a CertRep with pkiStatus set 1195 to PENDING. 1197 PostCondition: The requester has either received a valid response, 1198 which could be either a valid certificate (pkiStatus = SUCCESS), or a 1199 FAILURE message, or the polling period times out. 1201 4.3.1. Polling Response Message Format 1203 The response messages for GetCertInitial are the same as in 1204 Section 4.2.1. 1206 4.4. Certificate Access 1208 A requester can query an issued certificate from the SCEP server, as 1209 long as the requester knows the issuer name and the issuer assigned 1210 certificate serial number. This transaction is not intended to 1211 provide a generic certificate directory service. 1213 This transaction consists of one GetCert (Section 3.2.4) message sent 1214 to the server by a requester, and one CertRep (Section 3.2.2) message 1215 sent back from the server. 1217 PreCondition: The certification authority has issued the queried 1218 certificate and the issuer assigned serial number is known. 1220 PostCondition: Either the certificate is sent back or the request is 1221 rejected. 1223 4.4.1. Certificate Access Response Message Format 1225 In this case, the CertRep from the server is same as in 1226 Section 4.2.1, except that the server will only either grant the 1227 request (SUCCESS) or reject the request (FAILURE). 1229 4.5. CRL Access 1231 Clients MAY request a CRL from the SCEP server as described in 1232 Section 2.7. 1234 PreCondition: The certification authority certificate has been 1235 downloaded to the end entity. 1237 PostCondition: CRL sent back to the requester. 1239 4.5.1. CRL Access Response Message Format 1241 The CRL is sent back to the requester in a CertRep (Section 3.2.2) 1242 message. The information portion of this message is a degenerate 1243 certificates-only Signed-data (Section 3.3) that contains only the 1244 most recent CRL in the crls field of the Signed-Data. 1246 The server MAY return any appropriate CRL. 1248 4.6. Get Next Certification Authority Certificate 1250 When a CA certificate is about to expire, clients need to retrieve 1251 the CA's next CA certificate (i.e. the Rollover Certificate). This 1252 is done via the GetNextCACert message. There is no request data 1253 associated with this message (see Section 5.2.6). 1255 4.6.1. Get Next CA Response Message Format 1257 The response consists of a SignedData PKCS#7 [RFC2315], signed by the 1258 current CA (or RA) signing key. 1260 Clients MUST validate the signature on the the SignedData PKCS#7 1261 [RFC2315] before accepting any of its contents. 1263 The content of the SignedData PKCS#7 [RFC2315] is a degenerate 1264 certificates-only Signed-data (Section 3.3) message containing the 1265 new CA certificate and any new RA certificates, as defined in 1266 Section 5.2.1.1.2, to be used when the current CA certificate 1267 expires. 1269 If the CA (or RA) does not have the Rollover certificate(s) it MUST 1270 reject the request. It SHOULD also remove the GetNextCACert setting 1271 from the capabilities until it does have rollover certificates. 1273 If there are any RA certificates in this response, clients MUST check 1274 that these RA certificates are signed by the CA, and MUST check 1275 authorization of these RA certificates (see Section 2.1.3). 1277 5. SCEP Transport 1279 HTTP [RFC2616] is used as the transport protocol for SCEP Message 1280 Objects. 1282 5.1. HTTP "GET" Message Format 1284 SCEP uses the HTTP "GET" messages to request information from the CA. 1285 The following defines the syntax of a HTTP GET message sent from a 1286 requester to a certification authority server: 1287 "GET" CGI-PATH CGI-PROG "?operation=" OPERATION "&message=" MESSAGE 1289 where: 1291 o CGI-PATH defines the actual CGI path to invoke the CGI program 1292 that parses the request. 1294 o CGI-PROG is set to be the string "pkiclient.exe". This is 1295 intended to be the program that the CA will use to handle the SCEP 1296 transactions, though the CA may ignore CGI-PROG and use only the 1297 CGI-PATH. 1299 o OPERATION depends on the SCEP transaction and is defined in the 1300 following sections. 1302 o MESSAGE depends on the SCEP transaction and is defined in the 1303 following sections. 1305 If the CA supports it, requests SHOULD be done via an HTTP POST. 1306 This is described in Appendix F. 1308 5.1.1. Response Message Format 1310 For each GET operation, the CA/RA server MUST return a Content-Type 1311 and appropriate response data, if any. 1313 5.2. SCEP HTTP Messages 1315 This section describes the OPERATION and MESSAGE values for SCEP 1316 exchanges. 1318 5.2.1. GetCACert 1320 The OPERATION MUST be set to "GetCACert". 1322 The MESSAGE MAY be omitted, or it MAY be a string that represents the 1323 certification authority issuer identifier. A CA Administrator 1324 defined string allows for multiple CAs supported by one SCEP server. 1326 5.2.1.1. GetCACert Response 1328 The response for GetCACert is different between the case where the CA 1329 directly communicates with the requester during the enrollment, and 1330 the case where a RA exists and the requester communicates with the RA 1331 during the enrollment. 1333 5.2.1.1.1. CA Certificate Only Response 1335 The response will have a Content-Type of "application/ 1336 x-x509-ca-cert". 1338 The body of this response consists of an X.509 CA certificate, as 1339 defined in Section 4.1.1.1. 1340 "Content-Type:application/x-x509-ca-cert\n\n" 1342 5.2.1.1.2. CA and RA Certificates Response 1344 The response will have a Content-Type of "application/ 1345 x-x509-ca-ra-cert". 1347 The body of this response consists of a degenerate certificates-only 1348 PKCS#7 Signed-data (Section 3.3) containing both CA and RA 1349 certificates, as defined in Section 4.1.1.2. 1350 "Content-Type:application/x-x509-ca-ra-cert\n\n" 1352 5.2.2. PKCSReq 1354 The OPERATION MUST be set to "PKIOperation". 1356 The MESSAGE consists of a PKCSReq SCEP message. The message is 1357 "base64" encoded as specified in [RFC4648] Section 4. The "base64" 1358 encoded data is distinct from "base64url" and may contain URI 1359 reserved characters, thus it MUST be escaped as specified in 1360 [RFC2396]. 1362 An example PKIOperation request might look as follows: 1363 GET /cgi-bin/pkiclient.exe?operation=PKIOperation&message=MIAGCSqGSIb3D 1364 QEHA6CAMIACAQAxgDCBzAIBADB2MGIxETAPBgNVBAcTCE ......AAAAAA== HTTP/1.0 1366 5.2.2.1. PKCSReq Response 1368 The response will have a Content-Type of "application/x-pki-message". 1370 The body of this response consists of a CertRep SCEP message defined 1371 in Section 4.2.1. The following is an example of the response: 1372 "Content-Type:application/x-pki-message\n\n" 1374 5.2.3. GetCertInitial 1376 The OPERATION MUST be set to "PKIOperation". 1378 The MESSAGE consists of a GetCertInitial SCEP message. The message 1379 is "base64" encoded as specified in [RFC4648] Section 4. The 1380 "base64" encoded data is distinct from "base64url" and may contain 1381 URI reserved characters, thus it MUST be escaped as specified in 1382 [RFC2396]. 1384 5.2.3.1. GetCertInitial Response 1386 The body of this response consists of a CertRep SCEP message defined 1387 in Section 4.3.1. 1389 5.2.4. GetCert 1391 The OPERATION MUST be set to "PKIOperation". 1393 The MESSAGE consists of a GetCert SCEP message. The message is 1394 "base64" encoded as specified in [RFC4648] Section 4. The "base64" 1395 encoded data is distinct from "base64url" and may contain URI 1396 reserved characters, thus it MUST be escaped as specified in 1397 [RFC2396]. 1399 5.2.4.1. GetCert Response 1401 The body of this response consists of a CertRep SCEP message defined 1402 in Section 4.4.1. 1404 5.2.5. GetCRL 1406 The OPERATION MUST be set to "PKIOperation". 1408 The MESSAGE consists of a GetCRL SCEP message. The message is 1409 "base64" encoded as specified in [RFC4648] Section 4. The "base64" 1410 encoded data is distinct from "base64url" and may contain URI 1411 reserved characters, thus it MUST be escaped as specified in 1412 [RFC2396]. 1414 5.2.5.1. GetCRL Response 1416 The body of this response consists of a CertRep SCEP message defined 1417 in Section 4.5.1. 1419 5.2.6. GetNextCACert 1421 The OPERATION MUST be set to "GetNextCACert". 1423 The MESSAGE MAY be ommitted, or it MAY be a string that represents 1424 the certification authority issuer identifier, if such has been set 1425 by the CA Administrator. 1427 5.2.6.1. GetNextCACert Response 1429 The response will have a Content-Type of "application/ 1430 x-x509-next-ca-cert". 1432 The body of this response consists of a SignedData PKCS#7 [RFC2315], 1433 as defined in Section 4.6.1. (This is similar to the GetCert 1434 response but does not include any of the attributes defined in 1435 Section 3.1.1.) 1436 "Content-Type:application/x-x509-next-ca-cert\n\n" 1437 1439 6. Contributors/Acknowledgements 1441 The editor would like to thank all the previous editors, authors and 1442 contributors: Cheryl Madson, Xiaoyi Liu, David McGrew, David Cooper, 1443 Andy Nourse etc for their work maintaining the draft over the years. 1444 Numerous other people have contributed during the long life cycle of 1445 the draft and all deserve thanks. 1447 The authors would like to thank Peter William of ValiCert, Inc. 1448 (formerly of VeriSign, Inc.) and Alex Deacon of VeriSign, Inc. and 1449 Christopher Welles of IRE, Inc. for their contributions to early 1450 versions of this protocol and this document. 1452 7. IANA Considerations 1454 This memo includes no request to IANA. 1456 8. Security Considerations 1458 The security goals of SCEP are that no adversary can: 1460 o subvert the public key/identity binding from that intended, 1462 o discover the identity information in the enrollment requests and 1463 issued certificates, 1465 o cause the revocation of certificates with any non-negligible 1466 probability. 1468 Here an adversary is any entity other than the requester and the CA 1469 (and optionally the RA) participating in the protocol. The adversary 1470 is computationally limited, but that can manipulate data during 1471 transmission (that is, can act as a man-in-the-middle). The precise 1472 meaning of 'computationally limited' depends on the implementer's 1473 choice of one-way hash functions and cryptographic algorithms. 1474 Reflecting the historical nature of this document the mandatory to 1475 implement algorithms are RSA, DES and MD5. Depending on the CA 1476 capabilities, Triple-DES [TripleDES] SHOULD be used instead of DES, 1477 and SHA-1, SHA-256, or SHA-512 SHOULD be used instead of MD5 (see 1478 Appendix C). 1480 The first and second goals are met through the use of PKCS#7 1481 [RFC2315] and PKCS#10 [RFC2986] encryption and digital signatures 1482 using authenticated public keys. The CA's public key is 1483 authenticated via the checking of the CA fingerprint, as specified in 1484 Section 2.1.2, and the SCEP client's public key is authenticated 1485 through the manual authentication or pre-shared secret 1486 authentication, as specified in Section 2.2. The third goal is met 1487 through the use of a challenge password for revocation, which is 1488 chosen by the SCEP client and communicated to the CA protected by the 1489 PKCS#7 [RFC2315] encryptedData, as specified in Section 2.8. 1491 The motivation of the first security goal is straightforward. The 1492 motivation for the second security goal is to protect the identity 1493 information in the enrollment requests and issued certificates. 1494 Subsequent protocols can use the certificate in ways that either 1495 expose the identity information, or protect it, depending on the 1496 security requirements of those protocols. The motivation for the 1497 third security goal is to protect the SCEP clients from denial of 1498 service attacks. 1500 8.1. General Security 1502 Common key-management considerations such as keeping private keys 1503 truly private and using adequate lengths for symmetric and asymmetric 1504 keys must be followed in order to maintain the security of this 1505 protocol. 1507 This is especially true for CA keys, which, when compromised, 1508 compromise the security of all relying parties. 1510 8.2. Use of the CA keypair 1512 A CA key pair is generally meant for (and is usually flagged as) 1513 certificate signing ("keyCertSign") exclusively, rather than data 1514 signing ("digitalSignature") or data encryption 1515 ("dataEnchipherment"). The SCEP protocol, however, uses the CA 1516 private key to both encrypt and sign PKCS#7 [RFC2315] transport 1517 messages. This is generally considered undesirable, as it widens the 1518 possibility of an implementation weakness, and provides 1520 o another place that the private key must be used (and hence is 1521 slightly more vulnerable to exposure), 1523 o another place where a side channel attack (say, timing or power 1524 analysis) might be used, 1526 o another place that the attacker might somehow insert his own text, 1527 and get it signed by the private key. 1529 While the CA key pair can be generated with the data encryption and 1530 data signing flags set, this is operationally not encouraged. It 1531 would make using the key as a PKCS#7 [RFC2315] transport key 'legal', 1532 but the discussion from the previous paragraph still applies. 1534 A solution is to use RA keys to secure the SCEP transport (i.e. 1535 message signing and encrypting), which allows the CA keys to be used 1536 only for their intended purpose of certificate signing. 1538 An RA can be implemented in two ways: physically separate or 1539 implicit. In the implicit case, the CA simply creates an extra key 1540 pair. A physically separate RA allows the CA to be inside the secure 1541 network, not accessible to hackers at all. 1543 8.3. ChallengePassword 1545 The challengePassword sent in the PKCS#10 enrollment request is 1546 signed and encrypted by way of being encapsulated in a pkiMessage. 1547 When saved by the CA, care should be taken to protect this password. 1549 If the challengePassword is used to automatically authenticate an 1550 enrollment request, it is recommended that some form of one-time 1551 password be used to minimize damage in the event the data is 1552 compromised. 1554 8.4. transactionID 1556 A well-written CA/RA SHOULD NOT rely on the transactionID to be 1557 correct or as specified in this document. Requesters with buggy 1558 software might add additional undetected duplicate requests to the 1559 CA's queue (or worse). A well-written CA/RA should never assume the 1560 data from a requester is well-formed. 1562 8.5. Nonces and Replay 1564 In order to detect replay attacks, both sides need to maintain state 1565 information sufficient to detect an unexpected nonce value. 1567 Since existing implementations do not copy the senderNonce from a 1568 CertRep into subsequent GetCertinitial requests, the server will 1569 never see its own nonce reflected back to it. The transactionID can 1570 be used to link together the GetCertInitial and PKCSReq messages. 1572 8.6. Key Usage Issues 1574 Key pairs may be intended for particular purposes, such as encryption 1575 only or signing only. The usage of any associated certificate can be 1576 restricted by adding key usage and extended key usage attributes to 1577 the PKCS#10 [RFC2986]. If key usage is not present, the public key 1578 is assumed to be a general purpose key that may be used for all 1579 purposes. 1581 When building a pkiMessage, clients MUST have a certificate to sign 1582 the PKCS#7 [RFC2315] signed-data (because PKCS#7 [RFC2315] requires 1583 it). Clients MUST either use an existing certificate, or create a 1584 self-signed certificate (see Section 2.3). If the certificate has a 1585 key usage extension in it, then both the SCEP client and SCEP server 1586 MUST ignore the key usage for the duration of the transaction (the 1587 key will be used for signing during the creation of the PKCSReq 1588 message, and for encryption during the creation of the CertRep 1589 message). 1591 8.7. GetCACaps Issues 1593 The GetCACaps response is not signed. This allows an attacker to use 1594 downgrade attacks (as well as "upgrade attacks") on the cryptographic 1595 capabilities of the CA. 1597 8.8. Unnecessary cryptography 1599 Some of the SCEP exchanges use signing and encryption operations that 1600 are not necessary. In particular the GetCert and GetCRL exchanges 1601 are encrypted and signed in both directions. The information 1602 requested is public and thus signing the requests is of questionable 1603 value but also CRLs and Certificates, i.e. the respective responses, 1604 are already signed by the CA and can be verified by the recipient 1605 without requiring additional signing and encryption. 1607 This may affect performance and scalability of the CA and could be 1608 used as an attack vector on the CA (though not an anonymous one). 1609 The use of CDPs is recommended for CRL access, as well as other ways 1610 of retrieving certificates (LDAP, direct HTTP access, etc.). 1612 8.9. GetNextCACert 1614 Servers implementing early versions of the SCEP draft might return an 1615 unsigned GetNextCACert response by erroneously mirroring the 1616 (unsigned) functionality of GetCACert. Client receiving such 1617 responses MUST ignored them. 1619 GetNextCACert depends on a 'flag moment' at which every client in the 1620 PKI infrastructure switches from the current CA certificate (and 1621 client certificate) to the new CA certificate and client 1622 certificates. Proper monitoring of the network infrastructure can 1623 ensure that this will proceed as expected but any errors in 1624 processing or implementation can result in a failure of the PKI 1625 infrastructure. 1627 9. References 1629 9.1. Normative References 1631 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1632 Requirement Levels", BCP 14, RFC 2119, March 1997. 1634 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 1635 Version 1.5", RFC 2315, March 1998. 1637 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1638 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1639 August 1998. 1641 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1642 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1643 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1645 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 1646 Classes and Attribute Types Version 2.0", RFC 2985, 1647 November 2000. 1649 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1650 Request Syntax Specification Version 1.7", RFC 2986, 1651 November 2000. 1653 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1654 "Internet X.509 Public Key Infrastructure Certificate 1655 Management Protocol (CMP)", RFC 4210, September 2005. 1657 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1658 Encodings", RFC 4648, October 2006. 1660 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 1661 (CMC)", RFC 5272, June 2008. 1663 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1664 Housley, R., and W. Polk, "Internet X.509 Public Key 1665 Infrastructure Certificate and Certificate Revocation List 1666 (CRL) Profile", RFC 5280, May 2008. 1668 [TripleDES] 1669 "ANSI X9.52-1998, Triple Data Encryption Algorithm Modes 1670 of Operation", 1998. 1672 9.2. Informative References 1674 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1675 (IKE)", RFC 2409, November 1998. 1677 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1678 RFC 4306, December 2005. 1680 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1681 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1683 [RFC4945] Korver, B., "The Internet IP Security PKI Profile of 1684 IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007. 1686 Appendix A. Private OID Definitions 1688 The OIDs used in SCEP are VeriSign self-maintained OIDs. 1690 +-------------------+-----------------------------------------------+ 1691 | Name | ASN.1 Definition | 1692 +-------------------+-----------------------------------------------+ 1693 | id-VeriSign | OBJECT_IDENTIFIER ::= {2 16 US(840) 1 | 1694 | | VeriSign(113733)} | 1695 | id-pki | OBJECT_IDENTIFIER ::= {id-VeriSign pki(1)} | 1696 | id-attributes | OBJECT_IDENTIFIER ::= {id-pki attributes(9)} | 1697 | id-messageType | OBJECT_IDENTIFIER ::= {id-attributes | 1698 | | messageType(2)} | 1699 | id-pkiStatus | OBJECT_IDENTIFIER ::= {id-attributes | 1700 | | pkiStatus(3)} | 1701 | id-failInfo | OBJECT_IDENTIFIER ::= {id-attributes | 1702 | | failInfo(4)} | 1703 | id-senderNonce | OBJECT_IDENTIFIER ::= {id-attributes | 1704 | | senderNonce(5)} | 1705 | id-recipientNonce | OBJECT_IDENTIFIER ::= {id-attributes | 1706 | | recipientNonce(6)} | 1707 | id-transId | OBJECT_IDENTIFIER ::= {id-attributes | 1708 | | transId(7)} | 1709 | id-extensionReq | OBJECT_IDENTIFIER ::= {id-attributes | 1710 | | extensionReq(8)} | 1711 +-------------------+-----------------------------------------------+ 1713 Appendix B. SCEP State Transitions 1715 SCEP state transitions are indexed by the transactionID attribute. 1716 The design goal is to ensure the synchronization between the CA and 1717 the requester under various error situations. 1719 Each enrollment transaction is uniquely associated with a transaction 1720 identifier (carried in the transactionID signed attribute (see 1721 Section 3.1.1.1). Because the enrollment transaction could be 1722 interrupted by various errors, including network connection errors or 1723 client reboot, the SCEP client generates a transaction identifier by 1724 calculating a hash on the public key value for which the enrollment 1725 is requested. The requester generates the transaction identifier 1726 which is included in PKCSReq. If the CA returns a response of 1727 PENDING, the requester will poll by periodically sending out 1728 GetCertInitial with the same transaction identifier until either a 1729 response other than PENDING is obtained, or the configured maximum 1730 time has elapsed. This mechanism retains the same transaction 1731 identifier throughout the enrollment transaction. 1733 If the client times out or the client reboots, the client 1734 administrator will start another enrollment transaction with the same 1735 key pair. The second enrollment will have the same transaction 1736 identifier. At the server side, instead of accepting the PKCSReq as 1737 a new enrollment request, it can respond as if another GetCertInitial 1738 message had been sent with that transaction ID. The second PKCSReq 1739 should be taken as a resynchronization message to allow the 1740 enrollment to resume as the same transaction. 1742 The following gives several examples of client to CA transactions. 1744 Client actions are indicated in the left column, CA actions are 1745 indicated in the right column. A blank action signifies that no 1746 message was received. 1748 The first transaction, for example, would read like this: 1750 "Client Sends PKCSReq message with transaction ID 1 to the CA. The 1751 CA signs the certificate and constructs a CertRep Message containing 1752 the signed certificate with a transaction ID 1. The client receives 1753 the message and installs the certificate locally." 1755 Successful Enrollment Case: no manual authentication 1756 PKCSReq (1) ----------> CA Signs Cert 1757 Client Installs Cert <---------- CertRep (1) SIGNED CERT 1759 Successful Enrollment Case: manual authentication required 1760 PKCSReq (10) ----------> Cert Request goes into Queue 1761 Client Polls <---------- CertRep (10) PENDING 1762 GetCertInitial (10) ----------> Still pending 1763 Client Polls <---------- CertRep (10) PENDING 1764 GetCertInitial (10) ----------> Still pending 1765 Client Polls <---------- CertRep (10) PENDING 1766 GetCertInitial (10) ----------> Still pending 1767 Client Polls <---------- CertRep (10) PENDING 1768 GetCertInitial (10) ----------> Cert has been signed 1769 <---------- CertRep (10) SIGNED CERT 1770 Client Installs Cert 1772 Resync Case 1 - CA Receives PKCSReq, sends PENDING, eventually grants 1773 the certificate and returns SUCCESS, with the certificate. The 1774 SUCCESS gets lost: 1775 PKCSReq (3) ----------> Cert Request goes into queue 1776 <---------- CertRep (3) PENDING 1777 GetCertInitial (3) ----------> Still pending 1778 <---------- CertRep (3) PENDING 1779 GetCertInitial (3) -----------> Cert has been signed 1780 X-------- CertRep(3) SIGNED CERT 1781 (Time Out) 1782 PKCSReq (3) ----------> Cert already granted 1783 <---------- CertRep (3) SIGNED CERT 1784 Client Installs Cert 1785 Resync Case 2 - CA Receives PKCSReq, sends PENDING, PENDING reply 1786 gets lost: 1787 PKCSReq (3) ----------> Cert Request goes into queue 1788 X-------- CertRep (3) PENDING 1789 (Time Out) 1790 PKCSReq (3) ----------> 1791 <---------- CertRep (3) PENDING 1792 etc... 1794 Case when the Certificate is lost, the CA arbitrarily refuses to sign 1795 a replacement (enforcing name-uniqueness) until the original 1796 certificate has been revoked (there is no change of name 1797 information): 1798 PKCSReq (4) ----------> CA Signs Cert 1799 <---------- CertRep (4) SIGNED CERT 1800 Client Installs Cert 1801 (Client looses Cert) 1802 PKCSReq (5) ----------> There is already a valid cert with 1803 this DN. 1804 <---------- CertRep (5) BAD REQUEST 1805 Admin Revokes 1806 PKCSReq (5) ----------> CA Signs Cert 1807 <---------- CertRep (5) SIGNED CERT 1808 Client Installs Cert 1810 Appendix C. CA Capabilities 1812 C.1. GetCACaps HTTP Message Format 1814 "GET" CGI-PATH CGI-PROG "?operation=GetCACaps" "&message=" CA-IDENT 1816 This message requests capabilities from CA. The response is a list 1817 of text capabilities, as defined in Appendix C.2. CA servers SHOULD 1818 support the GetCACaps message and MUST support it when they support 1819 certificate renewal using the method described in Appendix D. 1821 C.2. CA Capabilities Response Format 1823 The response for a GetCACaps message is a list of CA capabilities, in 1824 plain text, separated by characters, as follows (quotation marks 1825 are NOT sent): 1827 +--------------------+----------------------------------------------+ 1828 | Keyword | Description | 1829 +--------------------+----------------------------------------------+ 1830 | "GetNextCACert" | CA Supports the GetNextCACert message. | 1831 | "POSTPKIOperation" | PKIOPeration messages may be sent via HTTP | 1832 | | POST. | 1833 | "Renewal" | Clients may use current certificate and key | 1834 | | to authenticate an enrollment request for a | 1835 | | new certificate. | 1836 | "SHA-512" | CA Supports the SHA-512 hashing algorithm. | 1837 | "SHA-256" | CA Supports the SHA-256 hashing algorithm. | 1838 | "SHA-1" | CA Supports the SHA-1 hashing algorithm. | 1839 | "DES3" | CA Supports the Triple-DES encryption | 1840 | | algorithm. | 1841 +--------------------+----------------------------------------------+ 1843 The client SHOULD use SHA-1, SHA-256, or SHA-512 in preference to MD5 1844 hashing if it is supported by the CA. 1846 The server MUST use the texual case specified here, but clients 1847 SHOULD ignore the textual case when processing this message. A 1848 client MUST be able to accept and ignore any unknown keywords that 1849 might be sent back by a CA. 1851 If the CA supports none of the above capabilities the SCEP server 1852 SHOULD return an empty message. A server MAY simply return an HTTP 1853 Error. A client that receives an empty message or an HTTP error 1854 SHOULD interpret the response as if none of the requested 1855 capabilities are supported by the CA. 1857 The Content-type of the reply SHOULD be "text/plain". Clients SHOULD 1858 ignore the Content-type, as older server implementations of SCEP may 1859 send various Content-types. 1861 Example: 1862 GET /cgi-bin/pkiclient.exe?operation=GetCACaps&message=myca 1864 might return: 1865 GetNextCACertPOSTPKIOperation 1867 This means that the CA supports the GetNextCACert message and allows 1868 PKIOperation messages (PKCSreq, GetCert, GetCertInitial, ...) to be 1869 sent using HTTP POST. 1871 Appendix D. Client Certificate Renewal 1873 An enrollment request that occurs more than halfway through the 1874 validity period of an existing certificate for the same subject name 1875 and key usage MAY be interpreted as a re-enrollment or renewal 1876 request and be accepted. A new certificate with new validity dates 1877 can be issued, even though the old one is still valid, if the CA 1878 policy permits. The server MAY automatically revoke the old client 1879 certificate. Clients MUST use GetCACaps (see Appendix C) to 1880 determine if the CA supports renewal. Clients MUST support servers 1881 that do not implement renewal, or that reject renewal requests. 1883 To renew a client certificate, the client uses the PKCSreq message 1884 and signs it with the existing client certificate. The client SHOULD 1885 use a new keypair when requesting a new certificate. The client MAY 1886 request a new certicate using the old keypair. 1888 Appendix E. CA Key Rollover 1890 When the CA certificate expires all certificates that have been 1891 signed by it are no longer valid. CA key rollover provides a 1892 mechanism by which the server MAY distribute a new CA certificate 1893 which is valid in the future; when the current certificate has 1894 expired. Clients MUST use GetCACaps (see Appendix C) to determine if 1895 the CA supports GetNextCACert. 1897 To obtain the new CA certificate prior to the expiration of the 1898 current one, the client uses the GetNextCACert message. 1900 To obtain a new client certificate signed by the new CA certificate, 1901 use the new CA or RA certificate in the PKCSreq message envelope. 1903 Clients MUST store the not-yet-valid CA certificate, and any not-yet- 1904 valid client certificates obitained, until such time that they are 1905 valid. At which point clients switch over to using the newly valid 1906 certificates. 1908 Example: 1910 GetNextCACert ----------> 1911 <---------- New CA certificate 1913 PKCSReq* ----------> CA Signs certificate with NEW key 1914 Client Stores Cert <---------- CertRep - Certificate issued 1915 for installation when from NEW CA certificate and key pair 1916 existing cert expires. 1918 *enveloped for new CA or RA cert and key pair. The CA will use the 1919 envelope to determine which key and certificate to use to issue the 1920 client certificate. 1922 Appendix F. PKIOperation via HTTP POST Message 1924 If the remote CA supports it, any of the PKCS#7 [RFC2315]-encoded 1925 SCEP messages may be sent via HTTP POST instead of HTTP GET. This is 1926 allowed for any SCEP message except GetCACert, GetNextCACert, or 1927 GetCACaps. In this form of the message, base64 encoding is not used. 1928 POST /cgi-bin/pkiclient.exe?operation=PKIOperation HTTP/1.0 1929 Content-Length: 1931 1933 General POST Syntax 1935 The client can verify that the CA supports SCEP messages via POST by 1936 looking for the "POSTPKIOperation" capability (See Appendix C). 1938 Authors' Addresses 1940 Max Pritikin (editor) 1941 Cisco Systems, Inc 1943 Email: pritikin@cisco.com 1945 Andrew Nourse 1946 Cisco Systems, Inc 1948 Email: nourse@cisco.com 1950 Jan Vilhuber 1951 Cisco Systems, Inc 1953 Email: vilhuber@cisco.com