idnits 2.17.1 draft-gutmann-scep-08.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, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, 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 (January 8, 2018) is 2299 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'CERT-NONEXISTENT' on line 374 -- Looks like a reference, but probably isn't: 'CERT-REQ-PENDING' on line 374 -- Looks like a reference, but probably isn't: 'CERT-ISSUED' on line 374 ** Obsolete normative reference: RFC 2616 (ref. '4') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2396 (ref. '8') (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. '12') (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 5751 (ref. '13') (Obsoleted by RFC 8551) -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. '16') (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Gutmann 3 Internet-Draft University of Auckland 4 Intended status: Informational January 8, 2018 5 Expires: July 12, 2018 7 Simple Certificate Enrolment Protocol 8 draft-gutmann-scep-08 10 Abstract 12 This document specifies the Simple Certificate Enrolment Protocol 13 (SCEP), a PKI protocol that leverages existing technology by using 14 CMS (formerly known as PKCS #7) and PKCS #10 over HTTP. SCEP is the 15 evolution of the enrolment protocol sponsored by Cisco Systems, which 16 enjoys wide support in both client and server implementations, as 17 well as being relied upon by numerous other industry standards that 18 work with certificates. 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 https://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 July 12, 2018. 37 Copyright Notice 39 Copyright (c) 2018 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 68 2. SCEP Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.1. SCEP Entities . . . . . . . . . . . . . . . . . . . . . . 5 70 2.1.1. Client . . . . . . . . . . . . . . . . . . . . . . . 5 71 2.1.2. Certificate Authority . . . . . . . . . . . . . . . . 5 72 2.1.3. CA Certificate Distribution . . . . . . . . . . . . . 5 73 2.2. Client authentication . . . . . . . . . . . . . . . . . . 6 74 2.3. Enrolment authorization . . . . . . . . . . . . . . . . . 7 75 2.4. Certificate Enrolment/Renewal . . . . . . . . . . . . . . 8 76 2.4.1. Client State Transitions . . . . . . . . . . . . . . 8 77 2.5. Certificate Access . . . . . . . . . . . . . . . . . . . 10 78 2.6. CRL Access . . . . . . . . . . . . . . . . . . . . . . . 11 79 2.7. Certificate Revocation . . . . . . . . . . . . . . . . . 11 80 2.8. Mandatory-to-Implement Functionality . . . . . . . . . . 11 81 3. SCEP Secure Message Objects . . . . . . . . . . . . . . . . . 12 82 3.1. SCEP Message Object Processing . . . . . . . . . . . . . 14 83 3.2. SCEP pkiMessage . . . . . . . . . . . . . . . . . . . . . 14 84 3.2.1. Signed Transaction Attributes . . . . . . . . . . . . 14 85 3.2.1.1. transactionID . . . . . . . . . . . . . . . . . . 16 86 3.2.1.2. messageType . . . . . . . . . . . . . . . . . . . 17 87 3.2.1.3. pkiStatus . . . . . . . . . . . . . . . . . . . . 17 88 3.2.1.4. failInfo and failInfoText . . . . . . . . . . . . 17 89 3.2.1.5. senderNonce and recipientNonce . . . . . . . . . 18 90 3.2.2. SCEP pkcsPKIEnvelope . . . . . . . . . . . . . . . . 18 91 3.3. SCEP pkiMessage types . . . . . . . . . . . . . . . . . . 19 92 3.3.1. PKCSReq/RenewalReq . . . . . . . . . . . . . . . . . 19 93 3.3.2. CertRep . . . . . . . . . . . . . . . . . . . . . . . 19 94 3.3.2.1. CertRep SUCCESS . . . . . . . . . . . . . . . . . 20 95 3.3.2.2. CertRep FAILURE . . . . . . . . . . . . . . . . . 20 96 3.3.2.3. CertRep PENDING . . . . . . . . . . . . . . . . . 21 98 3.3.3. CertPoll (GetCertInitial) . . . . . . . . . . . . . . 21 99 3.3.4. GetCert and GetCRL . . . . . . . . . . . . . . . . . 22 100 3.4. Degenerate certificates-only CMS Signed-Data . . . . . . 22 101 3.5. CA Capabilities . . . . . . . . . . . . . . . . . . . . . 22 102 3.5.1. GetCACaps HTTP Message Format . . . . . . . . . . . . 22 103 3.5.2. CA Capabilities Response Format . . . . . . . . . . . 23 104 4. SCEP Transactions . . . . . . . . . . . . . . . . . . . . . . 25 105 4.1. HTTP POST and GET Message Formats . . . . . . . . . . . . 25 106 4.2. Get CA Certificate . . . . . . . . . . . . . . . . . . . 26 107 4.2.1. Get CA Certificate Response Message Format . . . . . 26 108 4.2.1.1. CA Certificate Response Message Format . . . . . 27 109 4.2.1.2. CA Certificate Chain Response Message Format . . 27 110 4.3. Certificate Enrolment/Renewal . . . . . . . . . . . . . . 27 111 4.3.1. Certificate Enrolment/Renewal Response Message . . . 28 112 4.4. Poll for Client Initial Certificate . . . . . . . . . . . 28 113 4.4.1. Polling Response Message Format . . . . . . . . . . . 29 114 4.5. Certificate Access . . . . . . . . . . . . . . . . . . . 29 115 4.5.1. Certificate Access Response Message Format . . . . . 29 116 4.6. CRL Access . . . . . . . . . . . . . . . . . . . . . . . 29 117 4.6.1. CRL Access Response Message Format . . . . . . . . . 29 118 4.7. Get Next Certificate Authority Certificate . . . . . . . 29 119 4.7.1. Get Next CA Response Message Format . . . . . . . . . 30 120 5. SCEP State Transitions . . . . . . . . . . . . . . . . . . . 30 121 5.1. Successful Transactions . . . . . . . . . . . . . . . . . 30 122 5.2. Transactions with Errors . . . . . . . . . . . . . . . . 31 123 6. Contributors/Acknowledgements . . . . . . . . . . . . . . . . 34 124 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 125 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 126 8.1. General Security . . . . . . . . . . . . . . . . . . . . 35 127 8.2. Use of the CA keypair . . . . . . . . . . . . . . . . . . 35 128 8.3. Challenge Password . . . . . . . . . . . . . . . . . . . 35 129 8.4. Lack of Certificate Issue Confirmation . . . . . . . . . 35 130 8.5. GetCACaps Issues . . . . . . . . . . . . . . . . . . . . 36 131 8.6. Lack of PoP in Renewal Requests . . . . . . . . . . . . . 36 132 8.7. Unnecessary cryptography . . . . . . . . . . . . . . . . 36 133 8.8. Use of SHA-1 . . . . . . . . . . . . . . . . . . . . . . 37 134 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 135 9.1. Normative References . . . . . . . . . . . . . . . . . . 37 136 9.2. Informative References . . . . . . . . . . . . . . . . . 38 137 Appendix A. Background Notes . . . . . . . . . . . . . . . . . . 39 138 Appendix B. Sample SCEP Messages . . . . . . . . . . . . . . . . 42 139 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42 141 1. Introduction 143 X.509 certificates serve as the basis for several standards-based 144 security protocols such as TLS [16], S/MIME [13], and IKE/IPsec [12]. 145 When an X.509 certificate is issued there typically is a need for a 146 certificate management protocol to enable a PKI client to request or 147 renew a certificate from a Certificate Authority (CA). 149 This specification defines a protocol, Simple Certificate Enrolment 150 Protocol (SCEP), for certificate management and certificate and CRL 151 queries. While widely deployed, this protocol omits some certificate 152 management features, e.g. certificate revocation transactions, which 153 may enhance the security achieved in a PKI. The IETF protocol suite 154 currently includes two further certificate management protocols with 155 more comprehensive functionality, Certificate Management Protocol 156 (CMP) [10] and Certificate Management over CMS (CMC) [9]. 157 Environments that do not require interoperability with SCEP 158 implementations MAY consider using the above-mentioned certificate 159 management protocols, however anyone considering this step should be 160 aware that the high level of complexity of these two protocols has 161 resulted in serious interoperability problems and corresponding lack 162 of industry support. SCEP's simplicity, while being a drawback in 163 terms of its slightly restricted functionality, also makes deployment 164 relatively straightforward, so that it enjoys widespread support and 165 ready interoperability across a range of platforms. While 166 implementers are encouraged to investigate one of the more 167 comprehensive alternative certificate management protocols in 168 addition to the protocol defined in this specification, anyone 169 wishing to deploy them should proceed with caution, and consider 170 support and interoperability issues before committing to their use. 172 The SCEP protocol supports the following general operations: 174 o CA public key distribution. 175 o Certificate enrolment and issue. 176 o Certificate renewal. 177 o Certificate query. 178 o CRL query. 180 SCEP makes extensive use of CMS [3] and PKCS #10 [6]. 182 1.1. Conventions Used in This Document 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in [1]. 188 2. SCEP Overview 190 This section provides a high level overview of the functionality of 191 SCEP. 193 2.1. SCEP Entities 195 The entity types defined in SCEP are a client requesting a 196 certificate and a Certificate Authority (CA) that issues the 197 certificate. These are described in the following sections. 199 2.1.1. Client 201 A client MUST have the following information locally configured: 203 1. The CA fully qualified domain name or IP address. 204 2. The CA HTTP CGI script path (this usually has a default value, 205 see Section 4.1). 206 3. The identifying information that is used for authentication of 207 the CA in Section 4.2.1, typically a certificate fingerprint. 209 2.1.2. Certificate Authority 211 A SCEP CA is the entity that signs client certificates. A CA MAY 212 enforce any arbitrary policies and apply them to certificate 213 requests, and MAY reject any request. 215 Since the client is expected to perform signature verification and 216 optionally encryption using the CA certificate, the keyUsage 217 extension in the CA certificate MUST indicate that it is valid for 218 digitalSignature and keyEncipherment (if available) alongside the 219 usual CA usages of keyCertSign and/or cRLSign. 221 2.1.3. CA Certificate Distribution 223 If the CA certificate(s) have not previously been acquired by the 224 client through some other means, the client MUST retrieve them before 225 any PKI operation (Section 3) can be started. Since no public key 226 has yet been exchanged between the client and the CA, the messages 227 cannot be secured using CMS, and the data is instead transferred in 228 the clear. 230 If an intermediate CA is in use, a certificates-only CMS Signed-Data 231 message with a certificate chain consisting of all CA certificates is 232 returned. Otherwise the CA certificate itself is returned. 234 The CA certificate MAY be provided out-of-band to the client. 235 Alternatively, the CA certificate fingerprint MAY be used to 236 authenticate a CA Certificate distributed by the GetCACert response 237 (Section 4.2) or via HTTP certificate-store access [11]. The 238 fingerprint is created by calculating a SHA-256 hash over the whole 239 CA certificate (for legacy reasons, a SHA-1 hash may be used by some 240 implementations). 242 After the client gets the CA certificate, it SHOULD authenticate the 243 certificate by comparing its fingerprint with the locally configured, 244 out-of-band distributed, identifying information. Intermediate CA 245 certificates, if any, are signed by a higher-level CA so there is no 246 need to authenticate them against the out-of-band data. Clients 247 SHOULD verify intermediate-level CA certificate signatures using the 248 issuing CA's certificate before use during protocol exchanges. 250 When a CA certificate expires, certificates that have been signed by 251 it may no longer be regarded as valid. CA key rollover provides a 252 mechanism by which the CA MAY distribute a new CA certificate which 253 is valid in the future once the current certificate has expired. 254 This is done in the GetNextCACert message (section Section 4.7). 256 2.2. Client authentication 258 As with every protocol that uses public-key cryptography, the 259 association between the public keys used in the protocol and the 260 identities with which they are associated must be authenticated in a 261 cryptographically secure manner. The communications between the 262 client and the CA are secured using SCEP Secure Message Objects as 263 explained in Section 3, which specifies how CMS is used to encrypt 264 and sign the data. In order to perform the signing operation the 265 client uses an appropriate local certificate: 267 1. If the client does not have an appropriate existing certificate 268 then a locally generated self-signed certificate MUST be used. 269 The keyUsage extension in the certificate MUST indicate that it 270 is valid for digitalSignature and keyEncipherment (if available). 271 The self-signed certificate SHOULD use the same subject name as 272 in the PKCS #10 request. In this case the messageType is PKCSReq 273 (see Section 3.2.1.2). 274 2. If the requesting system already has a certificate issued by the 275 SCEP CA and the CA supports renewal (see Section 2.4), that 276 certificate SHOULD be used. In this case the messageType is 277 RenewalReq (see Section 3.2.1.2). 278 3. Alternatively, if the requesting system has no certificate issued 279 by the SCEP CA but has credentials from an alternate CA then the 280 certificate issued by the alternate CA MAY be used in a renewal 281 request as described above. Policy settings on the SCEP CA will 282 determine if the request can be accepted or not. 284 Note that although the above text describes several different types 285 of operations, in practice most implementations always apply the 286 first one even if an existing certificate already exists. For this 287 reason support for the first case is mandatory while support for the 288 latter ones are optional (see Section 2.8). 290 During the certificate enrolment process, the client MUST use the 291 selected certificate's key when signing the CMS envelope (see 292 Section 3). This certificate will be either the self-signed one 293 matching the PKCS #10 request or the CA-issued one used to authorise 294 a renewal, and MUST be included in the signedData certificates field 295 (possibly as part of a full certificate chain). If the key being 296 certified allows encryption then the CA's CertResp will use the same 297 certificate's public key when encrypting the response. 299 Note that this means that, in the case of renewal operations, the 300 request is signed with, and the returned response may be encrypted 301 with, the key in the previously-issued certificate used to 302 authenticate the request, not the key in the PKCS #10 request. This 303 has security implications, see Section 8.6. 305 2.3. Enrolment authorization 307 PKCS #10 [6] specifies a PKCS #9 [5] challengePassword attribute to 308 be sent as part of the enrolment request. When utilizing the 309 challengePassword, the CA distributes a shared secret to the client 310 which will uniquely associate the enrolment request with the client. 312 Inclusion of the challengePassword by the SCEP client is OPTIONAL and 313 allows for unauthenticated authorization of enrolment requests 314 (which, however, requires manual approval of each certificate issue, 315 see below), or for renewal requests that are authenticated by being 316 signed with an existing certificate. The CMS envelope protects the 317 privacy of the challengePassword. 319 A client that is performing certificate renewal as per Section 2.4 320 SHOULD omit the challengePassword but MAY send the originally 321 distributed password in the challengePassword attribute. The SCEP CA 322 MAY use the challengePassword in addition to the previously issued 323 certificate that signs the request to authenticate the request. The 324 SCEP CA MUST NOT attempt to authenticate a client based on a self- 325 signed certificate unless it has been verified through out-of-band 326 means such as a certificate fingerprint. 328 To perform the authorization in manual mode the client's request is 329 placed in the PENDING state until the CA operator authorizes or 330 rejects it. Manual authorization is used when the client has only a 331 self-signed certificate that hasn't been previously authenticated by 332 the CA and/or a challengePassword is not available. The SCEP CA MAY 333 either reject unauthorized requests or mark them for manual 334 authorization according to CA policy. 336 2.4. Certificate Enrolment/Renewal 338 A client starts an enrolment transaction (Section 3.3.1) by creating 339 a certificate request using PKCS #10 and sends it to the CA enveloped 340 using CMS (Section 3). 342 If the CA supports certificate renewal and if the CA policy permits 343 then a new certificate with new validity dates can be issued even 344 though the old one is still valid. The CA MAY automatically revoke 345 the old client certificate. To renew an existing certificate, the 346 client uses the RenewalReq message (see Section 3.3) and signs it 347 with the existing client certificate. The client SHOULD use a new 348 keypair when requesting a new certificate, but MAY request a new 349 certificate using the old keypair. 351 If the CA returns a CertRep message (Section 3.3.2) with status set 352 to PENDING, the client enters into polling mode by periodically 353 sending a CertPoll message (Section 3.3.3) to the CA until the CA 354 operator completes the manual authentication (approving or denying 355 the request). 357 If polling mode is being used then the client will send a single 358 PKCSReq/RenewalReq message (Section 3.3.1), followed by 0 or more 359 CertPoll messages (Section 3.3.3). The CA will in return send 0 or 360 more CertRep messages (Section 3.3.2) with status set to PENDING in 361 response to CertPolls, followed by a single CertRep message 362 (Section 3.3.2) with status set to either SUCCESS or FAILURE. 364 2.4.1. Client State Transitions 366 The client state transitions during the SCEP process are indicated in 367 Figure 1. 369 CertPoll 370 +-----<----+ 371 | | 372 | | CertRep(PENDING) 373 | | 374 [CERT-NONEXISTENT] ------> [CERT-REQ-PENDING] ---------> [CERT-ISSUED] 375 ^ PKCSReq | CertRep(SUCCESS) 376 | RenewalReq | 377 | | 378 +-----------------------+ 379 CertRep(FAILURE) or 380 Max-time/max-polls exceeded 382 Figure 1: State Transition Diagram 384 The certificate issue process starts at state CERT-NONEXISTENT. 385 Sending a PKCSReq/RenewalReq message changes the state to CERT-REQ- 386 PENDING. 388 If the CA returns a CertRep message with pkiStatus set to SUCCESS 389 then the state changes to CERT-ISSUED. 391 If the CA returns a CertRep message with pkiStatus set to FAILURE or 392 there is no response then the state reverts back to CERT-NONEXISTENT. 394 If the CA returns a CertRep message with pkiStatus set to PENDING 395 then the client will keep polling by sending a CertPoll message until 396 either a CertRep message with status set to SUCCESS or FAILURE is 397 received or a timeout occurs or the maximum number of polls has been 398 exceeded. 400 A successful transaction in automatic mode: 402 CLIENT CA SERVER 404 PKCSReq: PKI cert. enrolment message 405 --------------------------------> CertRep: pkiStatus = SUCCESS 406 Certificate attached 407 <------------------------------ 408 Receive issued certificate. 410 A successful transaction in manual mode: 412 CLIENT CA SERVER 414 PKCSReq: PKI cert. enrolment message 415 --------------------------------> CertRep: pkiStatus = PENDING 416 <------------------------------ 417 CertPoll: Polling message 418 --------------------------------> CertRep: pkiStatus = PENDING 419 <------------------------------ 420 ................ ............... 422 CertPoll: Polling message 423 --------------------------------> CertRep: pkiStatus = SUCCESS 424 Certificate attached 425 <------------------------------ 426 Receive issued certificate. 428 2.5. Certificate Access 430 A certificate query message is defined for clients to retrieve a copy 431 of their own certificate from the CA. It allows clients that do not 432 store their certificates locally to obtain a copy when needed. This 433 functionality is not intended to provide a general purpose 434 certificate access service, which may be achieved via HTTP 435 certificate-store access [11] or LDAP. 437 To query a certificate from the CA, a client sends a request 438 consisting of the certificate's issuer name and serial number. This 439 assumes that the client has saved the issuer name and the serial 440 number of the issued certificate from the previous enrolment 441 transaction. The transaction to query a certificate consists of one 442 GetCert (Section 3.3.4) message and one CertRep (Section 3.3.2) 443 message, as shown below. 445 CLIENT CA SERVER 447 GetCert: PKI certificate query message 448 -------------------------------> CertRep: pkiStatus = SUCCESS 449 Certificate attached 450 <----------------------------- 451 Receive the certificate. 453 2.6. CRL Access 455 SCEP clients MAY request a CRL via one of three methods: 457 1. If the CA supports CRL Distribution Points (CRLDPs) [7], then the 458 CRL MAY be retrieved via the mechanism specified in the CRDLP. 459 2. If the CA supports HTTP certificate-store access [11], then the 460 CRL MAY be retrieved via the AuthorityInfoAcces [7] location 461 specified in the certificate. 462 3. Only if the CA does not support CRDLPs or HTTP access should a 463 CRL query be composed by creating a GetCRL message consisting of 464 the issuer name and serial number from the certificate whose 465 revocation status is being queried. 467 The CA SHOULD NOT support the GetCRL method because it does not scale 468 well due to the unnecessary cryptography (see Section 8.7) and it 469 requires the CA to be a high-availability service. 471 The message is sent to the SCEP CA in the same way as the other SCEP 472 requests. The transaction to retrieve a CRL consists of one GetCRL 473 PKI message and one CertRep PKI message, which contains only the CRL 474 (no certificates) in a degenerate certificates-only CMS Signed-Data 475 message (Section 3.4), as shown below. 477 CLIENT CA SERVER 479 GetCRL: PKI CRL query message 480 ----------------------------------> 481 CertRep: CRL attached 482 <----------------------------- 483 Receive the CRL 485 2.7. Certificate Revocation 487 SCEP does not specify a method to request certificate revocation. In 488 order to revoke a certificate, the client must contact the CA using a 489 non-SCEP defined mechanism. 491 2.8. Mandatory-to-Implement Functionality 493 At a minimum, all SCEP implementations compliant with this 494 specification MUST support GetCACaps (Section 3.5.1), GetCACert 495 (Section 4.2), PKCSReq (Section 3.3.1) (and its associated response 496 messages), communication of binary data via HTTP POST (Section 4.1), 497 and the AES and SHA-256 algorithms to secure pkiMessages 498 (Section 3.2). 500 For historical reasons implementations MAY support communications of 501 binary data via HTTP GET (Section 4.1), and the triple DES and SHA-1 502 algorithms to secure pkiMessages (Section 3.2). Implementations MUST 503 NOT support the obsolete and/or insecure single DES and MD5 504 algorithms used in earlier versions of this specification, since the 505 unsecured nature of GetCACaps means that an in-path attacker can 506 trivially roll back the encryption used to these insecure algorithms, 507 see Section 8.5. 509 3. SCEP Secure Message Objects 511 CMS is a general enveloping mechanism that enables both signed and 512 encrypted transmission of arbitrary data. SCEP messages that require 513 confidentiality use two layers of CMS, as shown in Figure 2. By 514 applying both enveloping and signing transformations, the SCEP 515 message is protected both for the integrity of its end-to-end 516 transaction information and the confidentiality of its information 517 portion. Some messages do not require enveloping, in which case the 518 EnvelopedData in Figure 2 is omitted. 520 pkiMessage { 521 contentType = signedData { pkcs-7 2 }, 522 content { 523 digestAlgorithms, 524 encapsulatedContentInfo { 525 eContentType = data { pkcs-7 1 }, 526 eContent { -- pkcsPKIEnvelope, optional 527 contentType = envelopedData { pkcs-7 3 }, 528 content { 529 recipientInfo, 530 encryptedContentInfo { 531 contentType = data { pkcs-7 1 }, 532 contentEncrAlgorithm, 533 encryptedContent { 534 messageData -- Typically PKCS #10 request 535 } 536 } 537 } 538 } 539 }, 540 certificates, -- Optional 541 crls, -- Optional 542 signerInfo { 543 signedAttrs { 544 transactionID, 545 messageType, 546 pkiStatus, 547 failInfo, -- Optional 548 senderNonce / recipientNonce, 549 }, 550 signature 551 } 552 } 553 } 555 Figure 2: CMS Layering 557 When a particular SCEP message carries data, this data is carried in 558 the messageData. CertRep messages will lack any signed content and 559 consist only of a pkcsPKIEnvelope (Section 3.2.2). 561 The remainder of this document will refer only to 'messageData', but 562 it is understood to always be encapsulated in the pkcsPKIEnvelope 563 (Section 3.2.2). The format of the data in the messageData is 564 defined by the messageType attribute (see Section 3.2) of the Signed- 565 Data. If there is no messageData to be transmitted, the entire 566 pkcsPKIEnvelope MUST be omitted. 568 3.1. SCEP Message Object Processing 570 Creating a SCEP message consists of several stages. The content to 571 be conveyed (in other words the messageData) is first encrypted, and 572 the encrypted content is then signed. 574 The form of encryption to be applied depends on the capabilities of 575 the recipient's public key. If the key is encryption-capable (for 576 example RSA) then the messageData is encrypted using the recipient's 577 public key with the CMS KeyTransRecipientInfo mechanism. If the key 578 is not encryption-capable (for example DSA or ECDSA) then the 579 messageData is encrypted using the challengePassword with the CMS 580 PasswordRecipientInfo mechanism. 582 Once the messageData has been encrypted, it is signed with the 583 sender's public key. This completes the SCEP message that is then 584 sent to the recipient. 586 Note that some earlier implementations of this specification dealt 587 with non-encryption-capable keys by omitting the encryption stage, 588 based on the text in Section 3 that indicated that "the EnvelopedData 589 is omitted". This alternative processing mechanism SHOULD NOT be 590 used since it exposes the challengePassword used to authorise the 591 certificate issue. 593 3.2. SCEP pkiMessage 595 The basic building block of all secured SCEP messages is the SCEP 596 pkiMessage. It consists of a CMS Signed-Data content type. The 597 following restrictions apply: 599 o The eContentType in encapsulatedContentInfo MUST be data ({pkcs-7 600 1}). 601 o The signed content, if present (FAILURE and PENDING CertRep 602 messages will lack any signed content), MUST be a pkcsPKIEnvelope 603 (Section 3.2.2), and MUST match the messageType attribute. 604 o The SignerInfo MUST contain a set of authenticatedAttributes 605 (Section 3.2.1). 607 3.2.1. Signed Transaction Attributes 609 At a minimum, all messages MUST contain the following 610 authenticatedAttributes: 612 o A transactionID attribute (see Section 3.2.1.1). 613 o A messageType attribute (see Section 3.2.1.2). 614 o A fresh senderNonce attribute (see Section 3.2.1.5). 615 o Any attributes required by CMS. 617 If the message is a CertRep, it MUST also include the following 618 authenticatedAttributes: 620 o A pkiStatus attribute (see Section 3.2.1.3). 621 o A failInfo and optional failInfotext attribute (see 622 Section 3.2.1.4) if pkiStatus = FAILURE. 623 o A recipientNonce attribute (see Section 3.2.1.5) copied from the 624 senderNonce in the request that this is a response to. 626 The following transaction attributes are encoded as authenticated 627 attributes, and are carried in the SignerInfo for this Signed-Data. 629 +----------------+-----------------+--------------------------------+ 630 | Attribute | Encoding | Comment | 631 +----------------+-----------------+--------------------------------+ 632 | transactionID | PrintableString | Unique ID for this transaction | 633 | | | as a text string | 634 | | | | 635 | messageType | PrintableString | Decimal value as a numeric | 636 | | | text string | 637 | | | | 638 | pkiStatus | PrintableString | Decimal value as a numeric | 639 | | | text string | 640 | | | | 641 | failInfo | PrintableString | Decimal value as a numeric | 642 | | | text string | 643 | | | | 644 | failInfoText | UTF8String | Descriptive text for the | 645 | | | failInfo value | 646 | | | | 647 | senderNonce | OCTET STRING | Random nonce as a 16-byte | 648 | | | binary data string | 649 | | | | 650 | recipientNonce | OCTET STRING | Random nonce as a 16-byte | 651 | | | binary data string | 652 +----------------+-----------------+--------------------------------+ 653 The OIDs used for these attributes are as follows: 655 +----------------------+--------------------------------------------+ 656 | Name | ASN.1 Definition | 657 +----------------------+--------------------------------------------+ 658 | id-VeriSign | OBJECT_IDENTIFIER ::= {2 16 US(840) 1 | 659 | | VeriSign(113733)} | 660 | | | 661 | id-pki | OBJECT_IDENTIFIER ::= {id-VeriSign pki(1)} | 662 | | | 663 | id-attributes | OBJECT_IDENTIFIER ::= {id-pki | 664 | | attributes(9)} | 665 | | | 666 | id-transactionID | OBJECT_IDENTIFIER ::= {id-attributes | 667 | | transactionID(7)} | 668 | | | 669 | id-messageType | OBJECT_IDENTIFIER ::= {id-attributes | 670 | | messageType(2)} | 671 | | | 672 | id-pkiStatus | OBJECT_IDENTIFIER ::= {id-attributes | 673 | | pkiStatus(3)} | 674 | | | 675 | id-failInfo | OBJECT_IDENTIFIER ::= {id-attributes | 676 | | failInfo(4)} | 677 | | | 678 | id-senderNonce | OBJECT_IDENTIFIER ::= {id-attributes | 679 | | senderNonce(5)} | 680 | | | 681 | id-recipientNonce | OBJECT_IDENTIFIER ::= {id-attributes | 682 | | recipientNonce(6)} | 683 | | | 684 | id-scep | OBJECT IDENTIFIER ::= {id-pkix TBD1} | 685 | | | 686 | id-scep-failInfoText | OBJECT IDENTIFIER ::= {id-scep 1} | 687 +----------------------+--------------------------------------------+ 689 The attributes are detailed in the following sections. 691 3.2.1.1. transactionID 693 A PKI operation is a transaction consisting of the messages exchanged 694 between a client and the CA. The transactionID is a text string 695 provided by the client when starting a transaction. The client MUST 696 use a unique string as the transaction identifier, encoded as a 697 PrintableString, which MUST be used for all PKI messages exchanged 698 for a given operation such as a certificate issue. 700 Note that the transactionID must be unique, but not necessarily 701 randomly generated. For example it may be a value assigned by the CA 702 (alongside the challengePassword) as an equivalent to the traditional 703 user name + password, so that the client is identified by their 704 transactionID. This can be useful when the client doesn't have a 705 pre-assigned Distinguished Name that the CA can identify their 706 request through, for example when enrolling SCADA devices. 708 3.2.1.2. messageType 710 The messageType attribute specifies the type of operation performed 711 by the transaction. This attribute MUST be included in all PKI 712 messages. The following message types are defined: 714 o CertRep ("3") -- Response to certificate or CRL request. 715 o RenewalReq ("17") -- PKCS #10 certificate request authenticated 716 with an existing certificate. 717 o PKCSReq ("19") -- PKCS #10 certificate request authenticated with 718 a password. 719 o CertPoll ("20") -- Certificate polling in manual enrolment. 720 o GetCert ("21") -- Retrieve a certificate. 721 o GetCRL ("22") -- Retrieve a CRL. 723 Undefined message types MUST BE treated as an error. 725 3.2.1.3. pkiStatus 727 All response messages MUST include transaction status information, 728 which is defined as a pkiStatus attribute: 730 o SUCCESS ("0") -- Request granted. 731 o FAILURE ("2") -- Request rejected. In this case the failInfo 732 attribute, as defined in Section 3.2.1.4, MUST also be present. 733 o PENDING ("3") -- Request pending for manual approval. 735 Undefined pkiStatus attributes MUST be treated as an error. 737 3.2.1.4. failInfo and failInfoText 739 The failInfo attribute MUST contain one of the following failure 740 reasons: 742 o badAlg ("0") -- Unrecognized or unsupported algorithm. 743 o badMessageCheck ("1") -- Integrity check (meaning signature 744 verification of the CMS message) failed. 745 o badRequest ("2") -- Transaction not permitted or supported. 746 o badTime ("3") -- The signingTime attribute from the CMS 747 authenticatedAttributes was not sufficiently close to the system 748 time (this failure code is present for legacy reasons and is 749 unlikely to be encountered in practice). 750 o badCertId ("4") -- No certificate could be identified matching the 751 provided criteria. 753 The failInfoText is a free-form UTF-8 text string that provides 754 further information in the case of pkiStatus = FAILURE. In 755 particular it may be used to provide details on why a certificate 756 request was not granted that go beyond what's provided by the near- 757 universal failInfo = badRequest status. Since this is a free-form 758 text string intended for interpretation by humans, implementations 759 SHOULD NOT assume that it has any type of machine-processable 760 content. 762 3.2.1.5. senderNonce and recipientNonce 764 The senderNonce and recipientNonce attributes are a 16 byte random 765 number generated for each transaction. These are intended to prevent 766 replay attacks. 768 When a sender sends a PKI message to a recipient, a fresh senderNonce 769 MUST be included in the message. The recipient MUST copy the 770 senderNonce into the recipientNonce of the reply as a proof of 771 liveliness. The original sender MUST verify that the recipientNonce 772 of the reply matches the senderNonce it sent in the request. If the 773 nonce does not match, the message MUST be rejected. 775 Note that since SCEP exchanges consist of a single request followed 776 by a single response, the use of distinct sender and recipient nonces 777 is redundant since the client sends a nonce in its request and the CA 778 responds with the same nonce in its reply. In effect there's just a 779 single nonce, identified as senderNonce in the client's request and 780 recipientNonce in the CA's reply. 782 3.2.2. SCEP pkcsPKIEnvelope 784 The information portion of a SCEP message is carried inside an 785 EnvelopedData content type, as defined in CMS, with the following 786 restrictions: 788 o contentType in encryptedContentInfo MUST be data ({pkcs-7 1}). 789 o encryptedContent MUST be the SCEP message being transported (see 790 Section 4), and must match the messageType authenticated Attribute 791 in the pkiMessage. 793 3.3. SCEP pkiMessage types 795 All of the messages in this section are pkiMessages (Section 3.2), 796 where the type of the message MUST be specified in the 'messageType' 797 authenticated Attribute. Each section defines a valid message type, 798 the corresponding messageData formats, and mandatory authenticated 799 attributes for that type. 801 3.3.1. PKCSReq/RenewalReq 803 The messageData for this type consists of a PKCS #10 Certificate 804 Request. The certificate request MUST contain at least the following 805 items: 807 o The subject Distinguished Name. 808 o The subject public key. 809 o For a PKCSReq and if authorisation based on a password is being 810 used, a challengePassword attribute. 812 In addition to the authenticatedAttributes required for a valid CMS 813 message, the pkiMessage MUST include the following attributes: 815 o A transactionID attribute (Section 3.2.1.1). 816 o A messageType attribute (Section 3.2.1.2) set to PKCSReq or 817 RenewalReq as appropriate. 818 o A fresh senderNonce attribute (Section 3.2.1.5). 820 3.3.2. CertRep 822 The messageData for this type consists of a degenerate certificates- 823 only CMS Signed-Data message (Section 3.4). The exact content 824 required for the reply depends on the type of request that this 825 message is a response to. The request types are detailed in 826 Section 3.3.2.1 and in Section 4. 828 In addition to the authenticatedAttributes required for a valid CMS 829 message, this pkiMessage MUST include the following attributes: 831 o The transactionID attribute (Section 3.2.1.1) copied from the 832 request that this is a response to. 833 o A messageType attribute (Section 3.2.1.2) set to CertRep. 834 o A recipientNonce attribute (Section 3.2.1.5) copied from the 835 senderNonce in the request that this is a response to. 836 o A pkiStatus attribute (Section 3.2.1.3) set to the status of the 837 reply. 839 Earlier versions of this specification required that this message 840 include a senderNonce alongside the recipientNonce, which was to be 841 used to chain to subsequent polling operations. However if a single 842 message was lost during the potentially extended interval over which 843 polling could take place (see Section 5 for an example of this) then 844 if the implementation were to enforce this requirement the overall 845 transaction would fail even though nothing had actually gone wrong. 846 Because of this issue, implementations mostly ignored the requirement 847 to carry this nonce over to subsequent polling messages or to verify 848 its presence. Current versions of the specification no longer 849 require the chaining of nonces across polling operations. 851 3.3.2.1. CertRep SUCCESS 853 When the pkiStatus attribute is set to SUCCESS, the messageData for 854 this message consists of a degenerate certificates-only CMS Signed- 855 Data message (Section 3.4). The content of this degenerate 856 certificates-only Signed-Data depends on what the original request 857 was, as outlined below. 859 +--------------+----------------------------------------------------+ 860 | Request-type | Reply-contents | 861 +--------------+----------------------------------------------------+ 862 | PKCSReq | The reply MUST contain at least the issued | 863 | | certificate in the certificates field of the | 864 | | Signed-Data. The reply MAY contain additional | 865 | | certificates, but the issued certificate MUST be | 866 | | the leaf certificate. | 867 | | | 868 | RenewalReq | Same as PKCSReq | 869 | | | 870 | CertPoll | Same as PKCSReq | 871 | | | 872 | GetCert | The reply MUST contain at least the requested | 873 | | certificate in the certificates field of the | 874 | | Signed-Data. The reply MAY contain additional | 875 | | certificates, but the requested certificate MUST | 876 | | be the leaf certificate. | 877 | | | 878 | GetCRL | The reply MUST contain the CRL in the crls field | 879 | | of the Signed-Data. | 880 +--------------+----------------------------------------------------+ 882 3.3.2.2. CertRep FAILURE 884 When the pkiStatus attribute is set to FAILURE, the reply MUST also 885 contain a failInfo (Section 3.2.1.4) attribute set to the appropriate 886 error condition describing the failure. The reply MAY also contain a 887 failInfoText attribute providing extended details on why the 888 operation failed, typically to expand on the catch-all failInfo = 889 badRequest status. The pkcsPKIEnvelope (Section 3.2.2) MUST be 890 omitted. 892 3.3.2.3. CertRep PENDING 894 When the pkiStatus attribute is set to PENDING, the pkcsPKIEnvelope 895 (Section 3.2.2) MUST be omitted. 897 3.3.3. CertPoll (GetCertInitial) 899 This message is used for certificate polling. For unknown reasons it 900 was referred to as "GetCertInitial" in earlier versions of this 901 specification. The messageData for this type consists of an 902 IssuerAndSubject: 904 issuerAndSubject ::= SEQUENCE { 905 issuer Name, 906 subject Name 907 } 909 The issuer is set to the subjectName of the CA (in other words the 910 intended issuerName of the certificate that's being requested). The 911 subject is set to the subjectName used when requesting the 912 certificate. 914 Note that both of these fields are redundant, the CA is identified by 915 the recipientInfo in the pkcsPKIEnvelope (or in most cases simply by 916 the server that the message is being sent to) and the client/ 917 transaction being polled is identified by the transactionID. Both of 918 these fields can be processed by the CA without going through the 919 cryptographically expensive process od unwrapping and processing the 920 issuerAndSubject. For this reason implementations SHOULD assume that 921 the polling operation will be controlled by the recipientInfo and 922 transactionID rather than the contents of the messageData. 924 In addition to the authenticatedAttributes required for a valid CMS 925 message, this pkiMessage MUST include the following attributes: 927 o The same transactionID (Section 3.2.1.1) attribute from the 928 original PKCSReq/RenewalReq message. 929 o A messageType attribute (Section 3.2.1.2) set to CertPoll. 930 o A fresh senderNonce attribute (Section 3.2.1.5). 932 3.3.4. GetCert and GetCRL 934 The messageData for these types consist of an IssuerAndSerialNumber 935 as defined in CMS which uniquely identifies the certificate being 936 requested, either the certificate itself for GetCert or its 937 revocation status via a CRL for GetCRL. In addition to the 938 authenticatedAttributes required for a valid CMS message, this 939 pkiMessage MUST include the following attributes: 941 o A transactionID attribute (Section 3.2.1.1). 942 o A messageType attribute (Section 3.2.1.2) set to GetCert or 943 GetCRL. 944 o A fresh senderNonce attribute (Section 3.2.1.5). 946 A self-signed certificate MAY be used in the signed envelope. This 947 enables the client to request their own certificate if they were 948 unable to store it previously. 950 These message types, while included here for completeness, apply 951 unnecessary cryptography and messaging overhead to the simple task of 952 transferring a certificate or CRL (see Section 8.7). Implementations 953 SHOULD prefer HTTP certificate-store access [11] or LDAP over the use 954 of these messages. 956 3.4. Degenerate certificates-only CMS Signed-Data 958 CMS includes a degenerate case of the Signed-Data content type in 959 which there are no signers. The use of such a degenerate case is to 960 disseminate certificates and CRLs. For SCEP the content field of the 961 ContentInfo value of a degenerate certificates-only Signed-Data MUST 962 be omitted. 964 When carrying certificates, the certificates are included in the 965 'certificates' field of the Signed-Data. When carrying a CRL, the 966 CRL is included in the 'crls' field of the Signed-Data. 968 3.5. CA Capabilities 970 In order to provide support for future enhancements to the protocol, 971 CAs MUST implement the GetCACaps message to allow clients to query 972 which functionality is available from the CA. 974 3.5.1. GetCACaps HTTP Message Format 975 This message requests capabilities from a CA, with the format: 977 "GET" CGI-PATH CGI-PROG "?operation=GetCACaps" 979 with the message components as described in Section 4. 981 3.5.2. CA Capabilities Response Format 983 The response for a GetCACaps message is a list of CA capabilities, in 984 plain text, separated by or characters, as follows 985 (quotation marks are NOT sent): 987 +--------------------+----------------------------------------------+ 988 | Keyword | Description | 989 +--------------------+----------------------------------------------+ 990 | "AES" | CA supports the AES encryption algorithm. | 991 | | | 992 | "DES3" | CA supports the triple DES encryption | 993 | | algorithm. | 994 | | | 995 | "GetNextCACert" | CA supports the GetNextCACert message. | 996 | | | 997 | "POSTPKIOperation" | CA supports PKIOPeration messages sent via | 998 | | HTTP POST. | 999 | | | 1000 | "Renewal" | CA supports the Renewal CA operation. | 1001 | | | 1002 | "SHA-1" | CA supports the SHA-1 hashing algorithm. | 1003 | | | 1004 | "SHA-256" | CA supports the SHA-256 hashing algorithm. | 1005 | | | 1006 | "SHA-512" | CA supports the SHA-512 hashing algorithm. | 1007 | | | 1008 | "SCEPStandard" | CA supports all mandatory-to-implement | 1009 | | sections of the SCEP standard. This keyword | 1010 | | implies "AES", "POSTPKIOperation", and | 1011 | | "SHA-256", as well as the provisions of | 1012 | | Section 2.8. | 1013 +--------------------+----------------------------------------------+ 1015 The client SHOULD use SHA-256 in preference to SHA-1 hashing and AES 1016 in preference to triple DES if they are supported by the CA. 1017 Although the CMS format allows any form of AES and SHA-2 to be 1018 specified, in the interests of interoperability the de facto 1019 universal standards of AES128-CBC and SHA-256 SHOULD be used. 1021 Announcing some of these capabilities individually is redundant since 1022 they're required as mandatory-to-implement functionality (see 1023 Section 2.8) whose presence as a whole is signalled by the 1024 "SCEPStandard" capability, but it may be useful to announce them in 1025 order to deal with old implementations that would otherwise default 1026 to obsolete, insecure algorithms and mechanisms. 1028 The CA MUST use the text case specified here, but clients SHOULD 1029 ignore the text case when processing this message. Clients MUST 1030 accept the standard HTTP-style -delimited text as well as the 1031 - delimited text specified in an earlier version of this 1032 specification. A client MUST be able to accept and ignore any 1033 unknown keywords that might be sent back by a CA. 1035 If the CA supports none of the above capabilities it SHOULD return an 1036 empty message. A CA MAY simply return an HTTP error. A client that 1037 receives an empty message or an HTTP error SHOULD interpret the 1038 response as if none of the requested capabilities are supported by 1039 the CA. 1041 (Note that at least one widely-deployed server implementation 1042 supports several of the above operations but doesn't support the 1043 GetCACaps message to indicate that it supports them, and will close 1044 the connection if sent a GetCACaps message. This means that the 1045 equivalent of GetCACaps must be performed through server 1046 fingerprinting, which can be done using the ID string "Microsoft- 1047 IIS". Newer versions of the same server, if sent a SCEP request 1048 using AES and SHA-2, will respond with an invalid response that can't 1049 be decrypted, requiring the use of 3DES and SHA-1 in order to obtain 1050 a response that can be processed even if AES and/or SHA-2 are 1051 allegedly supported. In addition the server will generate CA 1052 certificates that only have one, but not both, of the keyEncipherment 1053 and digitalSignature keyUsage flags set, requiring that the client 1054 ignore the keyUsage flags in order to use the certificates for SCEP). 1056 The Content-type of the reply SHOULD be "text/plain". Clients SHOULD 1057 ignore the Content-type, as older implementations of SCEP may send 1058 various Content-types. 1060 Example: 1062 GET /cgi-bin/pkiclient.exe?operation=GetCACaps 1063 might return: 1065 AES 1066 GetNextCACert 1067 POSTPKIOperation 1068 SCEPStandard 1069 SHA-256 1071 This means that the CA supports modern crypto algorithms, the 1072 GetNextCACert message, allows PKIOperation messages (PKCSReq/ 1073 RenewalReq, GetCert, CertPoll, ...) to be sent using HTTP POST, and 1074 is compliant with the final version of the SCEP standard. 1076 4. SCEP Transactions 1078 This section describes the SCEP Transactions and their HTTP [4] 1079 transport mechanism. 1081 4.1. HTTP POST and GET Message Formats 1083 SCEP uses the HTTP "POST" and "GET" messages to exchange information 1084 with the CA. The following defines the syntax of HTTP POST and GET 1085 messages sent from a client to a CA: 1087 "POST" CGI-PATH CGI-PROG "?operation=" OPERATION 1088 "GET" CGI-PATH CGI-PROG "?operation=" OPERATION "&message=" MESSAGE 1090 where: 1092 o CGI-PATH defines the path to invoke the CGI program that parses 1093 the request. 1094 o CGI-PROG is set to be the string "pkiclient.exe". This is 1095 intended to be the program that the CA will use to handle the SCEP 1096 transactions. 1097 o OPERATION depends on the SCEP transaction and is defined in the 1098 following sections. 1100 The CA will typically ignore CGI-PATH and/or CGI-PROG since it's 1101 unlikely to be issuing certificates via a web server. Clients SHOULD 1102 set CGI-PATH/CGI-PROG to the fixed string "/cgi-bin/pkiclient.exe" 1103 unless directed to do otherwise by the CA. The CA SHOULD ignore the 1104 CGI-PATH and CGI-PROG unless its precise format is critical to the 1105 CA's operation. 1107 Early SCEP drafts performed all communications via "GET" messages, 1108 including non-idempotent ones that should have been sent via "POST" 1109 messages. This has caused problems because of the way that the 1110 (supposedly) idempotent GET interacts with caches and proxies, and 1111 because the extremely large GET requests created by encoding CMS 1112 messages may be truncated in transit. These issues are typically not 1113 visible when testing on a LAN, but crop up during deployment over 1114 WANs. If the remote CA supports it, any of the CMS-encoded SCEP 1115 messages SHOULD be sent via HTTP POST instead of HTTP GET. This 1116 applies to any SCEP message except GetCACert, GetNextCACert, and 1117 GetCACaps, and avoids the need for base64- and URL-encoding that's 1118 required for GET messaging. The client can verify that the CA 1119 supports SCEP messages via POST by looking for the "POSTPKIOperation" 1120 capability (See Section 3.5.2). 1122 If a client or CA uses HTTP GET and encounters HTTP-related problems 1123 such as messages being truncated, seeing errors such as HTTP 414 1124 ("Request URI too long"), or simply having the message not sent/ 1125 received at all, when standard requests to the server (for example 1126 via a web browser) work, then this is a symptom of the problematic 1127 use of HTTP GET. The solution to this problem is typically to move 1128 to HTTP POST instead. In addition when using GET it's recommended to 1129 test your implementation over the public internet from as many 1130 locations as possible to determine whether the use of GET will cause 1131 problems with communications. 1133 When using GET messages to communicate binary data, base64 encoding 1134 as specified in [2] MUST be used. The base64 encoded data is 1135 distinct from "base64url" and may contain URI reserved characters, 1136 thus it MUST be escaped as specified in [8] in addition to being 1137 base64 encoded. Finally, the encoded data is inserted into the 1138 MESSAGE portion of the HTTP GET request. 1140 4.2. Get CA Certificate 1142 To get the CA certificate(s), the client sends a GetCACert message to 1143 the CA. The OPERATION MUST be set to "GetCACert". There is no 1144 request data associated with this message. 1146 4.2.1. Get CA Certificate Response Message Format 1148 The response for GetCACert is different between the case where the CA 1149 directly communicates with the client during the enrolment and the 1150 case where an intermediate CA exists and the client communicates with 1151 this CA during the enrolment. 1153 4.2.1.1. CA Certificate Response Message Format 1155 If the CA does not have any intermediate CA certificates, the 1156 response consists of a single X.509 CA certificate. The response 1157 will have a Content-Type of "application/x-x509-ca-cert". 1159 "Content-Type: application/x-x509-ca-cert" 1161 1163 4.2.1.2. CA Certificate Chain Response Message Format 1165 If the CA has intermediate CA certificates, the response consists of 1166 a degenerate certificates-only CMS Signed-Data message (Section 3.4) 1167 containing the certificates, with the intermediate CA certificate(s) 1168 as the leaf certificate(s). The response will have a Content-Type of 1169 "application/x-x509-ca-ra-cert". Note that this designation is used 1170 for historical reasons due to its use in older versions of this 1171 specification, no special meaning should be attached to the label. 1173 "Content-Type: application/x-x509-ca-ra-cert" 1175 1177 4.3. Certificate Enrolment/Renewal 1179 A PKCSReq/RenewalReq (Section 3.3.1) message is used to perform a 1180 certificate enrolment or renewal transaction. The OPERATION MUST be 1181 set to "PKIOperation". Note that when used with HTTP POST, the only 1182 OPERATION possible is "PKIOperation", so many CAs don't check this 1183 value or even notice its absence. When implemented using HTTP POST 1184 the message might look as follows: 1186 POST /cgi-bin/pkiclient.exe?operation=PKIOperation HTTP/1.1 1187 Content-Length: 1189 1191 When implemented using HTTP GET this might look as follows: 1193 GET /cgi-bin/pkiclient.exe?operation=PKIOperation& \ 1194 message=MIAGCSqGSIb3DQEHA6CAMIACAQAxgDCBzAIBADB2MG \ 1195 IxETAPBgNVBAcTCE......AAAAAA== HTTP/1.1 1197 4.3.1. Certificate Enrolment/Renewal Response Message 1199 If the request is granted, a CertRep message (Section 3.3.2) with 1200 pkiStatus set to SUCCESS is returned. The reply MUST also contain 1201 the certificate (and MAY contain any other certificates needed by the 1202 client). The issued certificate MUST be the first in the list. 1204 If the request is rejected, a CertRep message (Section 3.3.2) with 1205 pkiStatus set to FAILURE is returned. The reply MUST also contain a 1206 failInfo attribute and MAY contain a failInfoText attribute. 1208 If the the CA is configured to manually authenticate the client, a 1209 CertRep message (Section 3.3.2) with pkiStatus set to PENDING MAY be 1210 returned. The CA MAY return a PENDING for other reasons. 1212 The response will have a Content-Type of "application/x-pki-message". 1214 "Content-Type: application/x-pki-message" 1216 1218 4.4. Poll for Client Initial Certificate 1220 When the client receives a CertRep message with pkiStatus set to 1221 PENDING, it will enter the polling state by periodically sending 1222 CertPoll messages to the CA until either the request is granted and 1223 the certificate is sent back or the request is rejected or some 1224 preconfigured time limit for polling or maximum number of polls is 1225 exceeded. The OPERATION MUST be set to "PKIOperation". 1227 CertPoll messages exchanged during the polling period MUST carry the 1228 same transactionID attribute as the previous PKCSReq/RenewalReq. A 1229 CA receiving a CertPoll for which it does not have a matching 1230 PKCSReq/RenewalReq MUST ignore this request. 1232 Since at this time the certificate has not been issued, the client 1233 can only use its own subject name (which was contained in the 1234 original PKCS# 10 sent via PKCSReq/RenewalReq) to identify the polled 1235 certificate request (but see the note on identification during 1236 polling in Section 3.3.3). In theory there can be multiple 1237 outstanding requests from one client (for example, if different keys 1238 and different key-usages were used to request multiple certificates), 1239 so the transactionID must also be included to disambiguate between 1240 multiple requests. In practice however the client SHOULD NOT have 1241 multiple requests outstanding at any one time, since this tends to 1242 confuse some CAs. 1244 4.4.1. Polling Response Message Format 1246 The response messages for CertPoll are the same as in Section 4.3.1. 1248 4.5. Certificate Access 1250 A client can query an issued certificate from the SCEP CA, as long as 1251 the client knows the issuer name and the issuer assigned certificate 1252 serial number. 1254 This transaction consists of one GetCert (Section 3.3.4) message sent 1255 to the CA by a client, and one CertRep (Section 3.3.2) message sent 1256 back from the CA. The OPERATION MUST be set to "PKIOperation". 1258 4.5.1. Certificate Access Response Message Format 1260 In this case, the CertRep from the CA is same as in Section 4.3.1, 1261 except that the CA will either grant the request (SUCCESS) or reject 1262 it (FAILURE). 1264 4.6. CRL Access 1266 Clients can request a CRL from the SCEP CA as described in 1267 Section 2.6. The OPERATION MUST be set to "PKIOperation". 1269 4.6.1. CRL Access Response Message Format 1271 The CRL is sent back to the client in a CertRep (Section 3.3.2) 1272 message. The information portion of this message is a degenerate 1273 certificates-only Signed-Data (Section 3.4) that contains only the 1274 most recent CRL in the crls field of the Signed-Data. 1276 4.7. Get Next Certificate Authority Certificate 1278 When a CA certificate is about to expire, clients need to retrieve 1279 the CA's next CA certificate (i.e. the rollover certificate). This 1280 is done via the GetNextCACert message. The OPERATION MUST be set to 1281 "GetNextCACert". There is no request data associated with this 1282 message. 1284 4.7.1. Get Next CA Response Message Format 1286 The response consists of a Signed-Data CMS message, signed by the 1287 current CA signing key. Clients MUST validate the signature on the 1288 message before accepting any of its contents. The response will have 1289 a Content-Type of "application/x-x509-next-ca-cert". 1291 "Content-Type: application/x-x509-next-ca-cert" 1293 1295 The content of the Signed-Data message is a degenerate certificates- 1296 only Signed-Data message (Section 3.4) containing the new CA 1297 certificate(s) to be used when the current CA certificate expires. 1299 If the CA does not have rollover certificate(s) it MUST reject the 1300 request. It SHOULD also remove the GetNextCACert setting from the CA 1301 capabilities returned by GetCACaps until it does have rollover 1302 certificates. 1304 5. SCEP State Transitions 1306 The following section gives several examples of client to CA 1307 transactions. Client actions are indicated in the left column, CA 1308 actions are indicated in the right column, and the transactionID is 1309 given in parentheses. The first transaction, for example, would read 1310 like this: 1312 "Client Sends PKCSReq message with transactionID 1 to the CA. The CA 1313 signs the certificate and constructs a CertRep Message containing the 1314 signed certificate with a transaction ID 1. The client receives the 1315 message and installs the certificate locally". 1317 5.1. Successful Transactions 1319 Successful Enrolment Case: Automatic processing 1321 PKCSReq (1) ----------> CA issues certificate 1322 <---------- CertRep (1) SUCCESS 1323 Client installs certificate 1324 Successful Enrolment Case: Manual authentication required 1326 PKCSReq (2) ----------> Cert request goes into queue 1327 <---------- CertRep (2) PENDING 1328 CertPoll (2) ----------> Still pending 1329 <---------- CertRep (2) PENDING 1330 CertPoll (2) ----------> CA issues certificate 1331 <---------- CertRep (2) SUCCESS 1332 Client installs certificate 1334 CA certificate rollover case: 1336 GetNextCACert ----------> 1337 <---------- New CA certificate 1339 PKCSReq* ----------> CA issues certificate with 1340 new key 1341 <---------- CertRep SUCCESS 1342 Client stores certificate 1343 for installation when 1344 existing certificate expires. 1346 * Enveloped for the new CA certificate. The CA will use the envelope 1347 to determine which key to use to issue the client certificate. 1349 5.2. Transactions with Errors 1351 In the case of polled transactions that aren't completed 1352 automatically, there are two potential options for dealing with a 1353 transaction that's interrupted due to network or software/hardware 1354 issues. The first is for the client to preserve its transaction 1355 state and resume the CertPoll polling when normal service is 1356 restored. The second is for the client to begin a new transaction by 1357 sending a new PKCSReq/RenewalReq rather than continuing the previous 1358 CertPoll. Both options have their own advantages and disadvantages. 1360 The CertPoll continuation requires that the client maintain its 1361 transaction state for the time when it resumes polling. This is 1362 relatively simple if the problem is a brief network outage, but less 1363 simple when the problem is a client crash and restart. In addition 1364 the CA may treat a lost network connection as the end of a 1365 transaction, so that a new connection followed by a CertPoll will be 1366 treated as an error. 1368 The PKCSReq/RenewalReq continuation doesn't require any state to be 1369 maintained since it's a new transaction, however it may cause 1370 problems on the CA side if the certificate was successfully issued 1371 but the client never received it, since the resumed transaction 1372 attempt will appear to be a request for a duplicate certificate (see 1373 Section 8.4 for more on why this is a problem). In this case the CA 1374 may refuse the transaction, or require manual intervention to remove/ 1375 revoke the previous certificate before the client can request another 1376 one. 1378 Since the new-transaction resume is more robust in the presence of 1379 errors and doesn't require special-case handling by either the client 1380 or CA, clients SHOULD use the new-transaction option in preference to 1381 the resumed-CertPoll option to recover from errors. 1383 Resync Case 1: Client resyncs via new PKCSReq (recommended): 1385 PKCSReq (3) ----------> Cert request goes into queue 1386 <---------- CertRep (3) PENDING 1387 CertPoll (3) ----------> Still pending 1388 X-------- CertRep(3) PENDING 1389 (Network outage) 1390 (Client reconnects) 1391 PKCSReq (4) ----------> 1392 <---------- CertRep (4) PENDING 1393 etc... 1395 Resync Case 2: Client resyncs via resumed CertPoll after a network 1396 outage (not recommended, use PKCSReq to resync): 1398 PKCSReq (5) ----------> Cert request goes into queue 1399 <---------- CertRep (5) PENDING 1400 CertPoll (5) ----------> Still pending 1401 X-------- CertRep(5) PENDING 1402 (Network outage) 1403 (Client reconnects) 1404 CertPoll (5) ----------> CA issues certificate 1405 <---------- CertRep (5) SUCCESS 1406 Client installs certificate 1407 Resync Case 3: Special-case variation of case 2 where the CertRep 1408 SUCCESS rather than the CertRep PENDING is lost (recommended): 1410 PKCSReq (6) ----------> Cert request goes into queue 1411 <---------- CertRep (6) PENDING 1412 CertPoll (6) ----------> Still pending 1413 <---------- CertRep (6) PENDING 1414 CertPoll (6) ----------> CA issues certificate 1415 X-------- CertRep(6) SUCCESS 1416 (Network outage) 1417 (Client reconnects) 1418 PKCSReq (7) ----------> There is already a valid 1419 certificate with this DN. 1420 <---------- CertRep (7) FAILURE 1421 Admin revokes certificate 1422 PKCSReq (7) ----------> CA issues new certificate 1423 <---------- CertRep (7) SUCCESS 1424 Client installs certificate 1426 Resync Case 4: Special-case variation of case 1 where the CertRep 1427 SUCCESS rather than the CertRep PENDING is lost (not recommended, use 1428 PKCSReq to resync): 1430 PKCSReq (8) ----------> Cert request goes into queue 1431 <---------- CertRep (8) PENDING 1432 CertPoll (8) ----------> Still pending 1433 <---------- CertRep (8) PENDING 1434 CertPoll (8) ----------> CA issues certificate 1435 X-------- CertRep(8) SIGNED CERT 1436 (Network outage) 1437 (Client reconnects) 1438 CertPoll (8) ----------> Certificate already issued 1439 <---------- CertRep (8) SUCCESS 1440 Client installs certificate 1442 As these examples indicate, resumption from an error via a resumed 1443 CertPoll is tricky due to the state that needs to be held by both the 1444 client and/or the CA. A PKCSReq/RenewalReq resume is the easiest to 1445 implement since it's stateless and is identical for both polled and 1446 non-polled transactions, while a CertPoll resume treats the two 1447 differently (a non-polled transaction is resumed with a PKCSReq/ 1448 RenewalReq, a polled transaction is resumed with a CertPoll). For 1449 this reason error recovery SHOULD be handled via a new PKCSReq rather 1450 than a resumed CertPoll. 1452 6. Contributors/Acknowledgements 1454 The editor would like to thank all of the previous editors, authors 1455 and contributors: Cheryl Madson, Xiaoyi Liu, David McGrew, David 1456 Cooper, Andy Nourse, Max Pritikin, Jan Vilhuber, and others for their 1457 work maintaining the draft over the years. Numerous other people 1458 have contributed during the long life cycle of the draft and all 1459 deserve thanks. In addition several PKCS #7 / CMS libraries 1460 contributed to interoperability by doing the right thing despite what 1461 earlier SCEP drafts required. 1463 The earlier authors would like to thank Peter William of ValiCert, 1464 Inc. (formerly of VeriSign, Inc.) and Alex Deacon of VeriSign, Inc. 1465 and Christopher Welles of IRE, Inc. for their contributions to early 1466 versions of this protocol and this document. 1468 7. IANA Considerations 1470 One object identifier for the ASN.1 module in the Section 5 was 1471 assigned in the SMI Security for PKIX Module Identifiers 1472 (1.3.6.1.5.5.7.0) registry: 1474 id-mod-scep-attr-2017 OBJECT IDENTIFIER ::= { id-mod(0) TBD0 } 1476 One object identifier for an arc to assign SCEP Attribute Identifiers 1477 was assigned in the SMI Security for PKIX (1.3.6.1.5.5.7) registry: 1479 id-scep OBJECT IDENTIFIER ::= { id-pkix TBD1 } 1481 This assignment created the new SMI Security for SCEP Attribute 1482 Identifiers ((1.3.6.1.5.5.7.TBD1) registry with the following entries 1483 with references to this document: 1485 id-scep-failInfoText OBJECT IDENTIFIER ::= { id-scep 1 } 1487 (Editor's note: When the OID is assigned, the values in the OID table 1488 in Section 3.2 will also need to be updated). 1490 8. Security Considerations 1492 The security goal of SCEP is that no adversary can subvert the public 1493 key/identity binding from that intended. An adversary is any entity 1494 other than the client and the CA participating in the protocol. 1496 This goal is met through the use of CMS and PKCS #10 encryption and 1497 digital signatures using authenticated public keys. The CA's public 1498 key is authenticated via out-of-band means such as the checking of 1499 the CA fingerprint and the SCEP client's public key is authenticated 1500 through manual or pre-shared secret authentication. 1502 8.1. General Security 1504 Common key-management considerations such as keeping private keys 1505 truly private and using adequate lengths for symmetric and asymmetric 1506 keys must be followed in order to maintain the security of this 1507 protocol. This is especially true for CA keys which, when 1508 compromised, 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 being usable for certificate (and CRL) signing exclusively rather 1514 than data signing or encryption. The SCEP protocol however uses the 1515 CA private key to both sign and optionally encrypt CMS transport 1516 messages. This is generally considered undesirable as it widens the 1517 possibility of an implementation weakness and provides an additional 1518 location where the private key must be used (and hence is slightly 1519 more vulnerable to exposure) and where a side-channel attack might be 1520 applied. 1522 8.3. Challenge Password 1524 The challengePassword sent in the PKCS #10 enrolment request is 1525 signed and encrypted by way of being encapsulated in a pkiMessage. 1526 When saved by the CA, care should be taken to protect this password, 1527 for example by storing a salted iterated hash of the password rather 1528 than the password itself. 1530 8.4. Lack of Certificate Issue Confirmation 1532 SCEP provides no confirmation that the issued certificate was 1533 successfully received and processed by the client. This means that 1534 if the CertRep message is lost or can't be processed by the client 1535 then the CA will consider the certificate successfully issued while 1536 the client won't. If this situation is of concern then the correct 1537 issuance of the certificate will need to be verified by out-of-band 1538 means, for example through the client sending a message signed by the 1539 newly-issued certificate to the CA. This also provides the proof of 1540 possession that's not present in the case of a renewal operation, see 1541 Section 8.6. 1543 8.5. GetCACaps Issues 1545 The GetCACaps response is not authenticated by the CA. This allows 1546 an attacker to perform downgrade attacks on the cryptographic 1547 capabilities of the client/CA exchange. In particular if the server 1548 were to support MD5 and single DES then an in-path attacker could 1549 trivially roll back the encryption to use these insecure algorithms. 1550 By taking advantage of the presence of large amounts of static known 1551 plaintext in the SCEP messages, as of 2017 a DES rainbow table attack 1552 can recover most encryption keys in under a minute, and MD5 chosen- 1553 prefix collisions can be calculated for a few tens of cents of 1554 computing time using tools like HashClash. 1556 8.6. Lack of PoP in Renewal Requests 1558 Renewal operations (but not standard certificate-issue operations) 1559 are processed via a previously-issued certificate and its associated 1560 private key, not the key in the PKCS #10 request. This means that a 1561 client no longer demonstrates proof of possession (PoP) of the 1562 private key corresponding to the public key in the PKCS #10 request. 1563 It is therefore possible for a client to re-certify an existing key 1564 used by a third party, so that two or more certificates exist for the 1565 same key. By switching out the certificate in a signature, an 1566 attacker can appear to have a piece of data signed by their 1567 certificate rather than the original signer's certificate. This, and 1568 other, attacks are described in S/MIME ESS [14]. 1570 Avoiding these types of attacks requires situation-specific measures. 1571 For example CMS/SMIME implementations may use the ESSCertID attribute 1572 from S/MIME ESS [14] or its successor S/MIME ESSv2 [15] to 1573 unambiguously identify the signing certificate, however other 1574 mechanisms and protocols typically don't defend against this attack. 1576 8.7. Unnecessary cryptography 1578 Some of the SCEP exchanges use unnecessary signing and encryption 1579 operations. In particular the GetCert and GetCRL exchanges are 1580 encrypted and signed in both directions. The information requested 1581 is public and thus encrypting the requests is of questionable value. 1582 In addition CRLs and certificates sent in responses are already 1583 signed by the CA and can be verified by the recipient without 1584 requiring additional signing and encryption. More lightweight means 1585 of retrieving certificates and CRLs such as HTTP certificate-store 1586 access [11] and LDAP are recommended for this reason. 1588 8.8. Use of SHA-1 1590 Virtually all of the large numbers of devices that use SCEP today 1591 default to SHA-1, with many supporting only that hash algorithm with 1592 no ability to upgrade to a newer one. SHA-1 is no longer regarded as 1593 secure in all situations, but as used in SCEP it's still safe. There 1594 are three reasons for this. The first is that attacking SCEP would 1595 require creating a SHA-1 collision in close to real time, which won't 1596 be feasible for a very long time. 1598 The second reason is that the signature over the message doesn't 1599 serve any critical cryptographic purpose: The PKCS #10 data itself is 1600 authenticated through its own signature, protected by encryption, and 1601 the overall request is authorised by the (encrypted) password. The 1602 sole exception to this will be the small number of implementations 1603 that support the Renewal operation, which may be authorised purely 1604 through a signature, but presumably any implementation recent enough 1605 to support Renewal also supports SHA-2. Any legacy implementation 1606 that supports the historic core SCEP protocol would not be affected. 1608 The third reason is that SCEP uses the same key for encryption and 1609 signing, so that even if an attacker were able to capture an outgoing 1610 Renewal request that didn't include a password (in other words one 1611 that was only authorised through a signature), forge the SHA-1 hash 1612 in real time, and forward the forged request to the CA, they couldn't 1613 decrypt the returned certificate, which is protected with the same 1614 key that was used to generate the signature. While Section 8.7 1615 points out that SCEP uses unnecessary cryptography in places, the 1616 additional level of security provided by the extra crypto makes it 1617 immune to any issues with SHA-1. 1619 This doesn't mean that SCEP implementations should continue to use 1620 SHA-1 in perpetuity, merely that there's no need for a panicked 1621 switch to SHA-2. 1623 9. References 1625 9.1. Normative References 1627 [1] Bradner, S., "Key words for use in RFCs to Indicate 1628 Requirement Levels", BCP 14, RFC 2119, March 1997. 1630 [2] Josefsson, S., "The Base16, Base32, and Base64 Data 1631 Encodings", RFC 4648, October 2006. 1633 [3] Housley, R., "Cryptographic Message Syntax (CMS)", 1634 RFC 5652, September 2009. 1636 [4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1637 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1638 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1640 [5] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 1641 Classes and Attribute Types Version 2.0", RFC 2985, 1642 November 2000. 1644 [6] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1645 Request Syntax Specification Version 1.7", RFC 2986, 1646 November 2000. 1648 [7] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1649 Housley, R., and W. Polk, "Internet X.509 Public Key 1650 Infrastructure Certificate and Certificate Revocation List 1651 (CRL) Profile", RFC 5280, May 2008. 1653 [8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1654 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1655 August 1998. 1657 9.2. Informative References 1659 [9] Schaad, J. and M. Myers, "Certificate Management over CMS 1660 (CMC)", RFC 5272, June 2008. 1662 [10] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1663 "Internet X.509 Public Key Infrastructure Certificate 1664 Management Protocol (CMP)", RFC 4210, September 2005. 1666 [11] Gutmann, P., "Internet X.509 Public Key Infrastructure 1667 Operational Protocols: Certificate Store Access via HTTP", 1668 RFC 4387, February 2006. 1670 [12] Alighieri, D., "Internet Key Exchange (IKEv2) Protocol", 1671 RFC 4306, March 1300. 1673 [13] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1674 Mail Extensions (S/MIME) Version 3.2 Message 1675 Specification", RFC 5751, January 2010. 1677 [14] Hoffman, P., "Enhanced Security Services for S/MIME", 1678 RFC 2634, June 1999. 1680 [15] Schaad, J., "Enhanced Security Services (ESS) Update: 1681 Adding CertID Algorithm Agility", RFC 5035, August 2007. 1683 [16] Dierks, T. and E. Rescorla, "The Transport Layer Security 1684 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1686 Appendix A. Background Notes 1688 This specification has spent more than seventeen years in the draft 1689 stage. Its original goal, provisioning IPsec routers with 1690 certificates, has long since changed to general device/embedded 1691 system/IoT use. To fit this role, extra features were bolted on in a 1692 haphazard manner through the addition of a growing list of appendices 1693 and by inserting additional, often conflicting, paragraphs in various 1694 locations in the body text. Since existing features were never 1695 updated as newer ones were added, the specification accumulated large 1696 amounts of historical baggage over time. If OpenPGP was described as 1697 "a museum of 1990s crypto" then the SCEP draft was its graveyard. 1699 About five years ago the specification, which even at that point had 1700 seen only sporadic re-posts of the existing document, was more or 1701 less abandoned by its original sponsors. Due to its widespread use 1702 in large segments of the industry, the specification was rebooted in 1703 2015, cleaning up fifteen years worth of accumulated cruft, fixing 1704 errors, clarifying ambiguities, and bringing the algorithms and 1705 standards used into the current century (prior to the update, the de- 1706 facto lowest-common denominator algorithms used for interoperability 1707 were the insecure forty-year-old single DES and broken MD5 hash 1708 algorithms). 1710 Note that although the text of the current specification has changed 1711 significantly due to the consolidation of features and appendices 1712 into the main document, the protocol it describes is identical on the 1713 wire to the original (with the exception of the switch from single 1714 DES and MD5 to AES and SHA-2). The only two changes introduced, the 1715 "SCEPStandard" indicator in GetCACaps and the failInfoText attribute, 1716 are both optional values and should be ignored by older 1717 implementations, or can be omitted from messages if they are found to 1718 cause problems. 1720 Other changes include: 1722 o Resolved contradictions in the text, for example a requirement 1723 given as a MUST in one paragraph and a SHOULD in the next, a MUST 1724 NOT in one paragraph and a MAY a few paragraphs later, a SHOULD 1725 NOT contradicted later by a MAY, and so on. 1727 o Merged several later fragmentary addenda placed in appendices (for 1728 example the handling of certificate renewal) with the body of the 1729 text. 1730 o Merged the SCEP Transactions and SCEP Transport sections, since 1731 the latter mostly duplicated (with occasional inconsistencies) the 1732 former. 1733 o Updated the algorithms to ones dating from at least this century. 1734 o Did the same for normative references to other standards. 1735 o Updated the text to use consistent terminology for the client and 1736 CA rather than a mixture of client, requester, end entity, server, 1737 certificate authority, certification authority, and CA. 1738 o Corrected incorrect references to other standards, e.g. 1739 IssuerAndSerial -> IssuerAndSerialNumber. 1740 o Corrected errors such as a statement that when both signature and 1741 encryption certificates existed, the signature certificate was 1742 used for encryption. 1743 o Condensed redundant discussions of the same topic spread across 1744 multiple sections into a single location. For example the 1745 description of intermediate CA handling previously existed in 1746 three different locations, with slightly different reqirements in 1747 each one. 1748 o Added a description of how pkiMessages were processed, which was 1749 never made explicit in the original specification. This led to 1750 creative interpretations that had security problems but were 1751 employed anyway due to the lack of specific guidance on what to 1752 do. 1753 o Relaxed some requirements that didn't serve any obvious purpose 1754 and that major implementations didn't seem to be enforcing. For 1755 example the requirement that the self-signed certificate used with 1756 a request MUST contain a subject name that matched the one in the 1757 PKCS #10 request was relaxed to a SHOULD because a number of 1758 implementations either ignored the issue entirely or at worst 1759 performed some minor action like creating a log entry after which 1760 they continued anyway. 1761 o Removed discussion of the transactionID from the security 1762 considerations, since the instructions there were directly 1763 contradicted by the discussion of the use of the transactionID in 1764 Section 5. 1765 o Added a requirement that the signed message include the signing 1766 certificate(s) in the signedData certificates field. This was 1767 implicit in the original specification (without it, the message 1768 couldn't be verified by the CA) and was handled by the fact that 1769 most PKCS #7/CMS libraries do this by default, but was never 1770 explicitly mentioned. 1771 o Clarified sections that were unclear or even made no sense, for 1772 example the requirement for a "hash on the public key" [sic] 1773 encoded as a PrintableString. 1775 o Renamed "RA certificates" to "intermediate CA certificates". The 1776 original document at some point added mention of RA certificates 1777 without specifying how the client was to determine that an RA was 1778 in use, how the RA operations were identified in the protocol, or 1779 how it was used. It's unclear whether what was meant was a true 1780 RA or merely an intermediate CA, as opposed to the default 1781 practice of having certificates issued directly from a single root 1782 CA certificate. This update uses the term "intermediate CA 1783 certificates", since this seems to have been the original intent 1784 of the text. 1785 o Redid the PKIMessage diagram to match what was specified in CMS, 1786 the original diagram omitted a number of fields and nested data 1787 structures which meant that the diagram didn't match either the 1788 text or the CMS specification. 1789 o Removed the requirement for a CertPoll to contain a 1790 recipientNonce, since CertPoll is a client message and will never 1791 be sent in response to a message containing a senderNonce. See 1792 also the note in Section 3.3.2. 1793 o Clarified certificate renewal. These represent a capability that 1794 was bolted onto the original protocol with (at best) vaguely- 1795 defined semantics, including a requirement by the CA to guess 1796 whether a particular request was a renewal or not. In response to 1797 developer feedback that they either avoided renewal entirely 1798 because of this uncertainty or hardcoded in particular behaviour 1799 on a per-CA basis, this specification explicitly identifies 1800 renewal requests as such, and provides proper semantics for them. 1801 o Added the "SCEPStandard" keyword to GetCACaps to indicate that the 1802 CA complies with the final version of the SCEP standard, since the 1803 definition of what constitutes SCEP standards compliance has 1804 changed significantly over the years. 1805 o Added the optional failInfoText attribute to deal with the fact 1806 that failInfo was incapable of adequately communicating to clients 1807 why a certificate request operation had been rejected. 1808 o Removed the discussion in the security considerations of 1809 revocation issues, since SCEP doesn't support revocation as part 1810 of the protocol. 1811 o Clarified the use of nonces, which if applied as originally 1812 specified would have made the use of polling in the presence of a 1813 lost message impossible. 1814 o Removed the discussion of generating a given transactionID by 1815 hashing the public key, since this implied that there was some 1816 special significance in the value generated this way. Since it 1817 was neither a MUST nor a MAY, it was unsound to imply that servers 1818 could rely on the value being generated a certain way. In 1819 addition it wouldn't work if multiple transactions as discussed in 1820 Section 4.4 were initiated, since the deterministic generation via 1821 hashing would lead to duplicate transactionIDs. 1823 o Added examples of SCEP messages to give implementers something to 1824 aim for. 1826 Appendix B. Sample SCEP Messages 1828 (Omitted from the drafts to keep the size down). 1830 Author's Address 1832 Peter Gutmann 1833 University of Auckland 1834 Department of Computer Science 1835 Auckland 1836 New Zealand 1838 Email: pgut001@cs.auckland.ac.nz