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