idnits 2.17.1 draft-gutmann-scep-10.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 (March 1, 2018) is 2241 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 378 -- Looks like a reference, but probably isn't: 'CERT-REQ-PENDING' on line 378 -- Looks like a reference, but probably isn't: 'CERT-ISSUED' on line 378 ** Obsolete normative reference: RFC 7231 (ref. '4') (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5751 (ref. '14') (Obsoleted by RFC 8551) -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. '17') (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 March 1, 2018 5 Expires: September 2, 2018 7 Simple Certificate Enrolment Protocol 8 draft-gutmann-scep-10 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 September 2, 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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 38 138 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 41 140 1. Introduction 142 X.509 certificates serve as the basis for several standards-based 143 security protocols such as TLS [17], S/MIME [14], and IKE/IPsec [13]. 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) [10] and 158 Certificate Management over CMS (CMC) [9]. 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 [3] and PKCS #10 [6]. 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 data is instead transferred in 230 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 [11]. 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 [6] specifies a PKCS #9 [5] 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). 361 If polling mode is being used then the client will send a single 362 PKCSReq/RenewalReq message (Section 3.3.1), followed by 0 or more 363 CertPoll messages (Section 3.3.3). The CA will in return send 0 or 364 more CertRep messages (Section 3.3.2) with status set to PENDING in 365 response to CertPolls, followed by a single CertRep message 366 (Section 3.3.2) with status set to either SUCCESS or FAILURE. 368 2.5.1. Client State Transitions 370 The client state transitions during the SCEP process are indicated in 371 Figure 1. 373 CertPoll 374 +-----<----+ 375 | | 376 | | CertRep(PENDING) 377 | | 378 [CERT-NONEXISTENT] ------> [CERT-REQ-PENDING] ---------> [CERT-ISSUED] 379 ^ PKCSReq | CertRep(SUCCESS) 380 | RenewalReq | 381 | | 382 +-----------------------+ 383 CertRep(FAILURE) or 384 Max-time/max-polls exceeded 386 Figure 1: State Transition Diagram 388 The certificate issue process starts at state CERT-NONEXISTENT. 389 Sending a PKCSReq/RenewalReq message changes the state to CERT-REQ- 390 PENDING. 392 If the CA returns a CertRep message with pkiStatus set to SUCCESS 393 then the state changes to CERT-ISSUED. 395 If the CA returns a CertRep message with pkiStatus set to FAILURE or 396 there is no response then the state reverts back to CERT-NONEXISTENT. 398 If the CA returns a CertRep message with pkiStatus set to PENDING 399 then the client will keep polling by sending a CertPoll message until 400 either a CertRep message with status set to SUCCESS or FAILURE is 401 received or a timeout occurs or the maximum number of polls has been 402 exceeded. 404 A successful transaction in automatic mode: 406 CLIENT CA SERVER 408 PKCSReq: PKI cert. enrolment message 409 --------------------------------> CertRep: pkiStatus = SUCCESS 410 Certificate attached 411 <------------------------------ 412 Receive issued certificate. 414 A successful transaction in manual mode: 416 CLIENT CA SERVER 418 PKCSReq: PKI cert. enrolment message 419 --------------------------------> CertRep: pkiStatus = PENDING 420 <------------------------------ 421 CertPoll: Polling message 422 --------------------------------> CertRep: pkiStatus = PENDING 423 <------------------------------ 424 ................ ............... 426 CertPoll: Polling message 427 --------------------------------> CertRep: pkiStatus = SUCCESS 428 Certificate attached 429 <------------------------------ 430 Receive issued certificate. 432 2.6. Certificate Access 434 A certificate query message is defined for clients to retrieve a copy 435 of their own certificate from the CA. It allows clients that do not 436 store their certificates locally to obtain a copy when needed. This 437 functionality is not intended to provide a general purpose 438 certificate access service, which may be achieved via HTTP 439 certificate-store access [11] or LDAP. 441 To query a certificate from the CA, a client sends a request 442 consisting of the certificate's issuer name and serial number. This 443 assumes that the client has saved the issuer name and the serial 444 number of the issued certificate from the previous enrolment 445 transaction. The transaction to query a certificate consists of one 446 GetCert (Section 3.3.4) message and one CertRep (Section 3.3.2) 447 message, as shown below. 449 CLIENT CA SERVER 451 GetCert: PKI certificate query message 452 -------------------------------> CertRep: pkiStatus = SUCCESS 453 Certificate attached 454 <----------------------------- 455 Receive the certificate. 457 2.7. CRL Access 459 SCEP clients MAY request a CRL via one of three methods: 461 1. If the CA supports CRL Distribution Points (CRLDPs) [7], then the 462 CRL MAY be retrieved via the mechanism specified in the CRDLP. 463 2. If the CA supports HTTP certificate-store access [11], then the 464 CRL MAY be retrieved via the AuthorityInfoAcces [7] location 465 specified in the certificate. 466 3. Only if the CA does not support CRDLPs or HTTP access should a 467 CRL query be composed by creating a GetCRL message consisting of 468 the issuer name and serial number from the certificate whose 469 revocation status is being queried. 471 The CA SHOULD NOT support the GetCRL method because it does not scale 472 well due to the unnecessary cryptography (see Section 8.7) and it 473 requires the CA to be a high-availability service. 475 The message is sent to the SCEP CA in the same way as the other SCEP 476 requests. The transaction to retrieve a CRL consists of one GetCRL 477 PKI message and one CertRep PKI message, which contains only the CRL 478 (no certificates) in a degenerate certificates-only CMS Signed-Data 479 message (Section 3.4), as shown below. 481 CLIENT CA SERVER 483 GetCRL: PKI CRL query message 484 ----------------------------------> 485 CertRep: CRL attached 486 <----------------------------- 487 Receive the CRL 489 2.8. Certificate Revocation 491 SCEP does not specify a method to request certificate revocation. In 492 order to revoke a certificate, the client must contact the CA using a 493 non-SCEP defined mechanism. 495 2.9. Mandatory-to-Implement Functionality 497 At a minimum, all SCEP implementations compliant with this 498 specification MUST support GetCACaps (Section 3.5.1), GetCACert 499 (Section 4.2), PKCSReq (Section 3.3.1) (and its associated response 500 messages), communication of binary data via HTTP POST (Section 4.1), 501 and the AES and SHA-256 algorithms to secure pkiMessages 502 (Section 3.2). 504 For historical reasons implementations MAY support communications of 505 binary data via HTTP GET (Section 4.1), and the triple DES and SHA-1 506 algorithms to secure pkiMessages (Section 3.2). Implementations MUST 507 NOT support the obsolete and/or insecure single DES and MD5 508 algorithms used in earlier versions of this specification, since the 509 unsecured nature of GetCACaps means that an in-path attacker can 510 trivially roll back the encryption used to these insecure algorithms, 511 see Section 8.5. 513 3. SCEP Secure Message Objects 515 CMS is a general enveloping mechanism that enables both signed and 516 encrypted transmission of arbitrary data. SCEP messages that require 517 confidentiality use two layers of CMS, as shown in Figure 2. By 518 applying both enveloping and signing transformations, the SCEP 519 message is protected both for the integrity of its end-to-end 520 transaction information and the confidentiality of its information 521 portion. Some messages do not require enveloping, in which case the 522 EnvelopedData in Figure 2 is omitted. 524 pkiMessage { 525 contentType = signedData { pkcs-7 2 }, 526 content { 527 digestAlgorithms, 528 encapsulatedContentInfo { 529 eContentType = data { pkcs-7 1 }, 530 eContent { -- pkcsPKIEnvelope, optional 531 contentType = envelopedData { pkcs-7 3 }, 532 content { 533 recipientInfo, 534 encryptedContentInfo { 535 contentType = data { pkcs-7 1 }, 536 contentEncrAlgorithm, 537 encryptedContent { 538 messageData -- Typically PKCS #10 request 539 } 540 } 541 } 542 } 543 }, 544 certificates, -- Optional 545 crls, -- Optional 546 signerInfo { 547 signedAttrs { 548 transactionID, 549 messageType, 550 pkiStatus, 551 failInfo, -- Optional 552 senderNonce / recipientNonce, 553 }, 554 signature 555 } 556 } 557 } 559 Figure 2: CMS Layering 561 When a particular SCEP message carries data, this data is carried in 562 the messageData. CertRep messages will lack any signed content and 563 consist only of a pkcsPKIEnvelope (Section 3.2.2). 565 The remainder of this document will refer only to 'messageData', but 566 it is understood to always be encapsulated in the pkcsPKIEnvelope 567 (Section 3.2.2). The format of the data in the messageData is 568 defined by the messageType attribute (see Section 3.2) of the Signed- 569 Data. If there is no messageData to be transmitted, the entire 570 pkcsPKIEnvelope MUST be omitted. 572 Samples of SCEP messages are available through the JSCEP project [12] 573 in the src/samples directory. 575 3.1. SCEP Message Object Processing 577 Creating a SCEP message consists of several stages. The content to 578 be conveyed (in other words the messageData) is first encrypted, and 579 the encrypted content is then signed. 581 The form of encryption to be applied depends on the capabilities of 582 the recipient's public key. If the key is encryption-capable (for 583 example RSA) then the messageData is encrypted using the recipient's 584 public key with the CMS KeyTransRecipientInfo mechanism. If the key 585 is not encryption-capable (for example DSA or ECDSA) then the 586 messageData is encrypted using the challengePassword with the CMS 587 PasswordRecipientInfo mechanism. 589 Once the messageData has been encrypted, it is signed with the 590 sender's public key. This completes the SCEP message that is then 591 sent to the recipient. 593 Note that some earlier implementations of this specification dealt 594 with non-encryption-capable keys by omitting the encryption stage, 595 based on the text in Section 3 that indicated that "the EnvelopedData 596 is omitted". This alternative processing mechanism SHOULD NOT be 597 used since it exposes the challengePassword used to authorise the 598 certificate issue. 600 3.2. SCEP pkiMessage 602 The basic building block of all secured SCEP messages is the SCEP 603 pkiMessage. It consists of a CMS Signed-Data content type. The 604 following restrictions apply: 606 o The eContentType in encapsulatedContentInfo MUST be data ({pkcs-7 607 1}). 608 o The signed content, if present (FAILURE and PENDING CertRep 609 messages will lack any signed content), MUST be a pkcsPKIEnvelope 610 (Section 3.2.2), and MUST match the messageType attribute. 611 o The SignerInfo MUST contain a set of authenticatedAttributes 612 (Section 3.2.1). 614 3.2.1. Signed Transaction Attributes 616 At a minimum, all messages MUST contain the following 617 authenticatedAttributes: 619 o A transactionID attribute (see Section 3.2.1.1). 621 o A messageType attribute (see Section 3.2.1.2). 622 o A fresh senderNonce attribute (see Section 3.2.1.5). 623 o Any attributes required by CMS. 625 If the message is a CertRep, it MUST also include the following 626 authenticatedAttributes: 628 o A pkiStatus attribute (see Section 3.2.1.3). 629 o A failInfo and optional failInfotext attribute (see 630 Section 3.2.1.4) if pkiStatus = FAILURE. 631 o A recipientNonce attribute (see Section 3.2.1.5) copied from the 632 senderNonce in the request that this is a response to. 634 The following transaction attributes are encoded as authenticated 635 attributes, and are carried in the SignerInfo for this Signed-Data. 637 +----------------+-----------------+--------------------------------+ 638 | Attribute | Encoding | Comment | 639 +----------------+-----------------+--------------------------------+ 640 | transactionID | PrintableString | Unique ID for this transaction | 641 | | | as a text string | 642 | | | | 643 | messageType | PrintableString | Decimal value as a numeric | 644 | | | text string | 645 | | | | 646 | pkiStatus | PrintableString | Decimal value as a numeric | 647 | | | text string | 648 | | | | 649 | failInfo | PrintableString | Decimal value as a numeric | 650 | | | text string | 651 | | | | 652 | failInfoText | UTF8String | Descriptive text for the | 653 | | | failInfo value | 654 | | | | 655 | senderNonce | OCTET STRING | Random nonce as a 16-byte | 656 | | | binary data string | 657 | | | | 658 | recipientNonce | OCTET STRING | Random nonce as a 16-byte | 659 | | | binary data string | 660 +----------------+-----------------+--------------------------------+ 661 The OIDs used for these attributes are as follows: 663 +----------------------+--------------------------------------------+ 664 | Name | ASN.1 Definition | 665 +----------------------+--------------------------------------------+ 666 | id-VeriSign | OBJECT_IDENTIFIER ::= {2 16 US(840) 1 | 667 | | VeriSign(113733)} | 668 | | | 669 | id-pki | OBJECT_IDENTIFIER ::= {id-VeriSign pki(1)} | 670 | | | 671 | id-attributes | OBJECT_IDENTIFIER ::= {id-pki | 672 | | attributes(9)} | 673 | | | 674 | id-transactionID | OBJECT_IDENTIFIER ::= {id-attributes | 675 | | transactionID(7)} | 676 | | | 677 | id-messageType | OBJECT_IDENTIFIER ::= {id-attributes | 678 | | messageType(2)} | 679 | | | 680 | id-pkiStatus | OBJECT_IDENTIFIER ::= {id-attributes | 681 | | pkiStatus(3)} | 682 | | | 683 | id-failInfo | OBJECT_IDENTIFIER ::= {id-attributes | 684 | | failInfo(4)} | 685 | | | 686 | id-senderNonce | OBJECT_IDENTIFIER ::= {id-attributes | 687 | | senderNonce(5)} | 688 | | | 689 | id-recipientNonce | OBJECT_IDENTIFIER ::= {id-attributes | 690 | | recipientNonce(6)} | 691 | | | 692 | id-scep | OBJECT IDENTIFIER ::= {id-pkix TBD1} | 693 | | | 694 | id-scep-failInfoText | OBJECT IDENTIFIER ::= {id-scep 1} | 695 +----------------------+--------------------------------------------+ 697 The attributes are detailed in the following sections. 699 3.2.1.1. transactionID 701 A PKI operation is a transaction consisting of the messages exchanged 702 between a client and the CA. The transactionID is a text string 703 provided by the client when starting a transaction. The client MUST 704 use a unique string as the transaction identifier, encoded as a 705 PrintableString, which MUST be used for all PKI messages exchanged 706 for a given operation such as a certificate issue. 708 Note that the transactionID must be unique, but not necessarily 709 randomly generated. For example it may be a value assigned by the CA 710 (alongside the challengePassword) as an equivalent to the traditional 711 user name + password, so that the client is identified by their 712 transactionID. This can be useful when the client doesn't have a 713 pre-assigned Distinguished Name that the CA can identify their 714 request through, for example when enrolling SCADA devices. 716 3.2.1.2. messageType 718 The messageType attribute specifies the type of operation performed 719 by the transaction. This attribute MUST be included in all PKI 720 messages. The following message types are defined: 722 o CertRep ("3") -- Response to certificate or CRL request. 723 o RenewalReq ("17") -- PKCS #10 certificate request authenticated 724 with an existing certificate. 725 o PKCSReq ("19") -- PKCS #10 certificate request authenticated with 726 a password. 727 o CertPoll ("20") -- Certificate polling in manual enrolment. 728 o GetCert ("21") -- Retrieve a certificate. 729 o GetCRL ("22") -- Retrieve a CRL. 731 Undefined message types MUST BE treated as an error. 733 3.2.1.3. pkiStatus 735 All response messages MUST include transaction status information, 736 which is defined as a pkiStatus attribute: 738 o SUCCESS ("0") -- Request granted. 739 o FAILURE ("2") -- Request rejected. In this case the failInfo 740 attribute, as defined in Section 3.2.1.4, MUST also be present. 741 o PENDING ("3") -- Request pending for manual approval. 743 Undefined pkiStatus attributes MUST be treated as an error. 745 3.2.1.4. failInfo and failInfoText 747 The failInfo attribute MUST contain one of the following failure 748 reasons: 750 o badAlg ("0") -- Unrecognized or unsupported algorithm. 751 o badMessageCheck ("1") -- Integrity check (meaning signature 752 verification of the CMS message) failed. 753 o badRequest ("2") -- Transaction not permitted or supported. 754 o badTime ("3") -- The signingTime attribute from the CMS 755 authenticatedAttributes was not sufficiently close to the system 756 time (this failure code is present for legacy reasons and is 757 unlikely to be encountered in practice). 758 o badCertId ("4") -- No certificate could be identified matching the 759 provided criteria. 761 The failInfoText is a free-form UTF-8 text string that provides 762 further information in the case of pkiStatus = FAILURE. In 763 particular it may be used to provide details on why a certificate 764 request was not granted that go beyond what's provided by the near- 765 universal failInfo = badRequest status. Since this is a free-form 766 text string intended for interpretation by humans, implementations 767 SHOULD NOT assume that it has any type of machine-processable 768 content. 770 3.2.1.5. senderNonce and recipientNonce 772 The senderNonce and recipientNonce attributes are a 16 byte random 773 number generated for each transaction. These are intended to prevent 774 replay attacks. 776 When a sender sends a PKI message to a recipient, a fresh senderNonce 777 MUST be included in the message. The recipient MUST copy the 778 senderNonce into the recipientNonce of the reply as a proof of 779 liveliness. The original sender MUST verify that the recipientNonce 780 of the reply matches the senderNonce it sent in the request. If the 781 nonce does not match, the message MUST be rejected. 783 Note that since SCEP exchanges consist of a single request followed 784 by a single response, the use of distinct sender and recipient nonces 785 is redundant since the client sends a nonce in its request and the CA 786 responds with the same nonce in its reply. In effect there's just a 787 single nonce, identified as senderNonce in the client's request and 788 recipientNonce in the CA's reply. 790 3.2.2. SCEP pkcsPKIEnvelope 792 The information portion of a SCEP message is carried inside an 793 EnvelopedData content type, as defined in CMS, with the following 794 restrictions: 796 o contentType in encryptedContentInfo MUST be data ({pkcs-7 1}). 797 o encryptedContent MUST be the SCEP message being transported (see 798 Section 4), and must match the messageType authenticated Attribute 799 in the pkiMessage. 801 3.3. SCEP pkiMessage types 803 All of the messages in this section are pkiMessages (Section 3.2), 804 where the type of the message MUST be specified in the 'messageType' 805 authenticated Attribute. Each section defines a valid message type, 806 the corresponding messageData formats, and mandatory authenticated 807 attributes for that type. 809 3.3.1. PKCSReq/RenewalReq 811 The messageData for this type consists of a PKCS #10 Certificate 812 Request. The certificate request MUST contain at least the following 813 items: 815 o The subject Distinguished Name. 816 o The subject public key. 817 o For a PKCSReq and if authorisation based on a password is being 818 used, a challengePassword attribute. 820 In addition to the authenticatedAttributes required for a valid CMS 821 message, the pkiMessage MUST include the following attributes: 823 o A transactionID attribute (Section 3.2.1.1). 824 o A messageType attribute (Section 3.2.1.2) set to PKCSReq or 825 RenewalReq as appropriate. 826 o A fresh senderNonce attribute (Section 3.2.1.5). 828 3.3.2. CertRep 830 The messageData for this type consists of a degenerate certificates- 831 only CMS Signed-Data message (Section 3.4). The exact content 832 required for the reply depends on the type of request that this 833 message is a response to. The request types are detailed in 834 Section 3.3.2.1 and in Section 4. 836 In addition to the authenticatedAttributes required for a valid CMS 837 message, this pkiMessage MUST include the following attributes: 839 o The transactionID attribute (Section 3.2.1.1) copied from the 840 request that this is a response to. 841 o A messageType attribute (Section 3.2.1.2) set to CertRep. 842 o A recipientNonce attribute (Section 3.2.1.5) copied from the 843 senderNonce in the request that this is a response to. 844 o A pkiStatus attribute (Section 3.2.1.3) set to the status of the 845 reply. 847 Earlier versions of this specification required that this message 848 include a senderNonce alongside the recipientNonce, which was to be 849 used to chain to subsequent polling operations. However if a single 850 message was lost during the potentially extended interval over which 851 polling could take place (see Section 5 for an example of this) then 852 if the implementation were to enforce this requirement the overall 853 transaction would fail even though nothing had actually gone wrong. 854 Because of this issue, implementations mostly ignored the requirement 855 to carry this nonce over to subsequent polling messages or to verify 856 its presence. Current versions of the specification no longer 857 require the chaining of nonces across polling operations. 859 3.3.2.1. CertRep SUCCESS 861 When the pkiStatus attribute is set to SUCCESS, the messageData for 862 this message consists of a degenerate certificates-only CMS Signed- 863 Data message (Section 3.4). The content of this degenerate 864 certificates-only Signed-Data depends on what the original request 865 was, as outlined below. 867 +--------------+----------------------------------------------------+ 868 | Request-type | Reply-contents | 869 +--------------+----------------------------------------------------+ 870 | PKCSReq | The reply MUST contain at least the issued | 871 | | certificate in the certificates field of the | 872 | | Signed-Data. The reply MAY contain additional | 873 | | certificates, but the issued certificate MUST be | 874 | | the leaf certificate. | 875 | | | 876 | RenewalReq | Same as PKCSReq | 877 | | | 878 | CertPoll | Same as PKCSReq | 879 | | | 880 | GetCert | The reply MUST contain at least the requested | 881 | | certificate in the certificates field of the | 882 | | Signed-Data. The reply MAY contain additional | 883 | | certificates, but the requested certificate MUST | 884 | | be the leaf certificate. | 885 | | | 886 | GetCRL | The reply MUST contain the CRL in the crls field | 887 | | of the Signed-Data. | 888 +--------------+----------------------------------------------------+ 890 3.3.2.2. CertRep FAILURE 892 When the pkiStatus attribute is set to FAILURE, the reply MUST also 893 contain a failInfo (Section 3.2.1.4) attribute set to the appropriate 894 error condition describing the failure. The reply MAY also contain a 895 failInfoText attribute providing extended details on why the 896 operation failed, typically to expand on the catch-all failInfo = 897 badRequest status. The pkcsPKIEnvelope (Section 3.2.2) MUST be 898 omitted. 900 3.3.2.3. CertRep PENDING 902 When the pkiStatus attribute is set to PENDING, the pkcsPKIEnvelope 903 (Section 3.2.2) MUST be omitted. 905 3.3.3. CertPoll (GetCertInitial) 907 This message is used for certificate polling. For unknown reasons it 908 was referred to as "GetCertInitial" in earlier versions of this 909 specification. The messageData for this type consists of an 910 IssuerAndSubject: 912 issuerAndSubject ::= SEQUENCE { 913 issuer Name, 914 subject Name 915 } 917 The issuer is set to the subjectName of the CA (in other words the 918 intended issuerName of the certificate that's being requested). The 919 subject is set to the subjectName used when requesting the 920 certificate. 922 Note that both of these fields are redundant, the CA is identified by 923 the recipientInfo in the pkcsPKIEnvelope (or in most cases simply by 924 the server that the message is being sent to) and the client/ 925 transaction being polled is identified by the transactionID. Both of 926 these fields can be processed by the CA without going through the 927 cryptographically expensive process od unwrapping and processing the 928 issuerAndSubject. For this reason implementations SHOULD assume that 929 the polling operation will be controlled by the recipientInfo and 930 transactionID rather than the contents of the messageData. 932 In addition to the authenticatedAttributes required for a valid CMS 933 message, this pkiMessage MUST include the following attributes: 935 o The same transactionID (Section 3.2.1.1) attribute from the 936 original PKCSReq/RenewalReq message. 937 o A messageType attribute (Section 3.2.1.2) set to CertPoll. 938 o A fresh senderNonce attribute (Section 3.2.1.5). 940 3.3.4. GetCert and GetCRL 942 The messageData for these types consist of an IssuerAndSerialNumber 943 as defined in CMS which uniquely identifies the certificate being 944 requested, either the certificate itself for GetCert or its 945 revocation status via a CRL for GetCRL. In addition to the 946 authenticatedAttributes required for a valid CMS message, this 947 pkiMessage MUST include the following attributes: 949 o A transactionID attribute (Section 3.2.1.1). 950 o A messageType attribute (Section 3.2.1.2) set to GetCert or 951 GetCRL. 952 o A fresh senderNonce attribute (Section 3.2.1.5). 954 A self-signed certificate MAY be used in the signed envelope. This 955 enables the client to request their own certificate if they were 956 unable to store it previously. 958 These message types, while included here for completeness, apply 959 unnecessary cryptography and messaging overhead to the simple task of 960 transferring a certificate or CRL (see Section 8.7). Implementations 961 SHOULD prefer HTTP certificate-store access [11] or LDAP over the use 962 of these messages. 964 3.4. Degenerate certificates-only CMS Signed-Data 966 CMS includes a degenerate case of the Signed-Data content type in 967 which there are no signers. The use of such a degenerate case is to 968 disseminate certificates and CRLs. For SCEP the content field of the 969 ContentInfo value of a degenerate certificates-only Signed-Data MUST 970 be omitted. 972 When carrying certificates, the certificates are included in the 973 'certificates' field of the Signed-Data. When carrying a CRL, the 974 CRL is included in the 'crls' field of the Signed-Data. 976 3.5. CA Capabilities 978 In order to provide support for future enhancements to the protocol, 979 CAs MUST implement the GetCACaps message to allow clients to query 980 which functionality is available from the CA. 982 3.5.1. GetCACaps HTTP Message Format 983 This message requests capabilities from a CA, with the format: 985 "GET" CGI-PATH CGI-PROG "?operation=GetCACaps" 987 with the message components as described in Section 4. 989 3.5.2. CA Capabilities Response Format 991 The response for a GetCACaps message is a list of CA capabilities, in 992 plain text, separated by or characters, as follows 993 (quotation marks are NOT sent): 995 +--------------------+----------------------------------------------+ 996 | Keyword | Description | 997 +--------------------+----------------------------------------------+ 998 | "AES" | CA supports the AES encryption algorithm. | 999 | | | 1000 | "DES3" | CA supports the triple DES encryption | 1001 | | algorithm. | 1002 | | | 1003 | "GetNextCACert" | CA supports the GetNextCACert message. | 1004 | | | 1005 | "POSTPKIOperation" | CA supports PKIOPeration messages sent via | 1006 | | HTTP POST. | 1007 | | | 1008 | "Renewal" | CA supports the Renewal CA operation. | 1009 | | | 1010 | "SHA-1" | CA supports the SHA-1 hashing algorithm. | 1011 | | | 1012 | "SHA-256" | CA supports the SHA-256 hashing algorithm. | 1013 | | | 1014 | "SHA-512" | CA supports the SHA-512 hashing algorithm. | 1015 | | | 1016 | "SCEPStandard" | CA supports all mandatory-to-implement | 1017 | | sections of the SCEP standard. This keyword | 1018 | | implies "AES", "POSTPKIOperation", and | 1019 | | "SHA-256", as well as the provisions of | 1020 | | Section 2.9. | 1021 +--------------------+----------------------------------------------+ 1023 The client SHOULD use SHA-256 in preference to SHA-1 hashing and AES 1024 in preference to triple DES if they are supported by the CA. 1025 Although the CMS format allows any form of AES and SHA-2 to be 1026 specified, in the interests of interoperability the de facto 1027 universal standards of AES128-CBC and SHA-256 SHOULD be used. 1029 Announcing some of these capabilities individually is redundant since 1030 they're required as mandatory-to-implement functionality (see 1031 Section 2.9) whose presence as a whole is signalled by the 1032 "SCEPStandard" capability, but it may be useful to announce them in 1033 order to deal with old implementations that would otherwise default 1034 to obsolete, insecure algorithms and mechanisms. 1036 The CA MUST use the text case specified here, but clients SHOULD 1037 ignore the text case when processing this message. Clients MUST 1038 accept the standard HTTP-style -delimited text as well as the 1039 - delimited text specified in an earlier version of this 1040 specification. A client MUST be able to accept and ignore any 1041 unknown keywords that might be sent back by a CA. 1043 If the CA supports none of the above capabilities it SHOULD return an 1044 empty message. A CA MAY simply return an HTTP error. A client that 1045 receives an empty message or an HTTP error SHOULD interpret the 1046 response as if none of the requested capabilities are supported by 1047 the CA. 1049 (Note that at least one widely-deployed server implementation 1050 supports several of the above operations but doesn't support the 1051 GetCACaps message to indicate that it supports them, and will close 1052 the connection if sent a GetCACaps message. This means that the 1053 equivalent of GetCACaps must be performed through server 1054 fingerprinting, which can be done using the ID string "Microsoft- 1055 IIS". Newer versions of the same server, if sent a SCEP request 1056 using AES and SHA-2, will respond with an invalid response that can't 1057 be decrypted, requiring the use of 3DES and SHA-1 in order to obtain 1058 a response that can be processed even if AES and/or SHA-2 are 1059 allegedly supported. In addition the server will generate CA 1060 certificates that only have one, but not both, of the keyEncipherment 1061 and digitalSignature keyUsage flags set, requiring that the client 1062 ignore the keyUsage flags in order to use the certificates for SCEP). 1064 The Content-type of the reply SHOULD be "text/plain". Clients SHOULD 1065 ignore the Content-type, as older implementations of SCEP may send 1066 various Content-types. 1068 Example: 1070 GET /cgi-bin/pkiclient.exe?operation=GetCACaps 1071 might return: 1073 AES 1074 GetNextCACert 1075 POSTPKIOperation 1076 SCEPStandard 1077 SHA-256 1079 This means that the CA supports modern crypto algorithms, the 1080 GetNextCACert message, allows PKIOperation messages (PKCSReq/ 1081 RenewalReq, GetCert, CertPoll, ...) to be sent using HTTP POST, and 1082 is compliant with the final version of the SCEP standard. 1084 4. SCEP Transactions 1086 This section describes the SCEP Transactions and their HTTP [4] 1087 transport mechanism. 1089 4.1. HTTP POST and GET Message Formats 1091 SCEP uses the HTTP "POST" and "GET" messages to exchange information 1092 with the CA. The following defines the syntax of HTTP POST and GET 1093 messages sent from a client to a CA: 1095 "POST" CGI-PATH CGI-PROG "?operation=" OPERATION 1096 "GET" CGI-PATH CGI-PROG "?operation=" OPERATION "&message=" MESSAGE 1098 where: 1100 o CGI-PATH defines the path to invoke the CGI program that parses 1101 the request. 1102 o CGI-PROG is set to be the string "pkiclient.exe". This is 1103 intended to be the program that the CA will use to handle the SCEP 1104 transactions. 1105 o OPERATION depends on the SCEP transaction and is defined in the 1106 following sections. 1108 The CA will typically ignore CGI-PATH and/or CGI-PROG since it's 1109 unlikely to be issuing certificates via a web server. Clients SHOULD 1110 set CGI-PATH/CGI-PROG to the fixed string "/cgi-bin/pkiclient.exe" 1111 unless directed to do otherwise by the CA. The CA SHOULD ignore the 1112 CGI-PATH and CGI-PROG unless its precise format is critical to the 1113 CA's operation. 1115 Early SCEP drafts performed all communications via "GET" messages, 1116 including non-idempotent ones that should have been sent via "POST" 1117 messages. This has caused problems because of the way that the 1118 (supposedly) idempotent GET interacts with caches and proxies, and 1119 because the extremely large GET requests created by encoding CMS 1120 messages may be truncated in transit. These issues are typically not 1121 visible when testing on a LAN, but crop up during deployment over 1122 WANs. If the remote CA supports POST, the CMS-encoded SCEP messages 1123 MUST be sent via HTTP POST instead of HTTP GET. This applies to any 1124 SCEP message except GetCACert, GetNextCACert, and GetCACaps, and 1125 avoids the need for base64- and URL-encoding that's required for GET 1126 messaging. The client can verify that the CA supports SCEP messages 1127 via POST by looking for the "POSTPKIOperation" capability (See 1128 Section 3.5.2). 1130 If a client or CA uses HTTP GET and encounters HTTP-related problems 1131 such as messages being truncated, seeing errors such as HTTP 414 1132 ("Request URI too long"), or simply having the message not sent/ 1133 received at all, when standard requests to the server (for example 1134 via a web browser) work, then this is a symptom of the problematic 1135 use of HTTP GET. The solution to this problem is to update the 1136 implementation to use HTTP POST instead. In addition when using GET 1137 it's recommended to test your implementation over the public internet 1138 from as many locations as possible to determine whether the use of 1139 GET will cause problems with communications. 1141 When using GET messages to communicate binary data, base64 encoding 1142 as specified in [2] MUST be used. The base64 encoded data is 1143 distinct from "base64url" and may contain URI reserved characters, 1144 thus it MUST be escaped as specified in [8] in addition to being 1145 base64 encoded. Finally, the encoded data is inserted into the 1146 MESSAGE portion of the HTTP GET request. 1148 4.2. Get CA Certificate 1150 To get the CA certificate(s), the client sends a GetCACert message to 1151 the CA. The OPERATION MUST be set to "GetCACert". There is no 1152 request data associated with this message. 1154 4.2.1. Get CA Certificate Response Message Format 1156 The response for GetCACert is different between the case where the CA 1157 directly communicates with the client during the enrolment and the 1158 case where an intermediate CA exists and the client communicates with 1159 this CA during the enrolment. 1161 4.2.1.1. CA Certificate Response Message Format 1163 If the CA does not have any intermediate CA certificates, the 1164 response consists of a single X.509 CA certificate. The response 1165 will have a Content-Type of "application/x-x509-ca-cert". 1167 "Content-Type: application/x-x509-ca-cert" 1169 1171 4.2.1.2. CA Certificate Chain Response Message Format 1173 If the CA has intermediate CA certificates, the response consists of 1174 a degenerate certificates-only CMS Signed-Data message (Section 3.4) 1175 containing the certificates, with the intermediate CA certificate(s) 1176 as the leaf certificate(s). The response will have a Content-Type of 1177 "application/x-x509-ca-ra-cert". Note that this designation is used 1178 for historical reasons due to its use in older versions of this 1179 specification, no special meaning should be attached to the label. 1181 "Content-Type: application/x-x509-ca-ra-cert" 1183 1185 4.3. Certificate Enrolment/Renewal 1187 A PKCSReq/RenewalReq (Section 3.3.1) message is used to perform a 1188 certificate enrolment or renewal transaction. The OPERATION MUST be 1189 set to "PKIOperation". Note that when used with HTTP POST, the only 1190 OPERATION possible is "PKIOperation", so many CAs don't check this 1191 value or even notice its absence. When implemented using HTTP POST 1192 the message might look as follows: 1194 POST /cgi-bin/pkiclient.exe?operation=PKIOperation HTTP/1.1 1195 Content-Length: 1197 1199 When implemented using HTTP GET this might look as follows: 1201 GET /cgi-bin/pkiclient.exe?operation=PKIOperation& \ 1202 message=MIAGCSqGSIb3DQEHA6CAMIACAQAxgDCBzAIBADB2MG \ 1203 IxETAPBgNVBAcTCE......AAAAAA== HTTP/1.1 1205 4.3.1. Certificate Enrolment/Renewal Response Message 1207 If the request is granted, a CertRep message (Section 3.3.2) with 1208 pkiStatus set to SUCCESS is returned. The reply MUST also contain 1209 the certificate (and MAY contain any other certificates needed by the 1210 client). The issued certificate MUST be the first in the list. 1212 If the request is rejected, a CertRep message (Section 3.3.2) with 1213 pkiStatus set to FAILURE is returned. The reply MUST also contain a 1214 failInfo attribute and MAY contain a failInfoText attribute. 1216 If the the CA is configured to manually authenticate the client, a 1217 CertRep message (Section 3.3.2) with pkiStatus set to PENDING MAY be 1218 returned. The CA MAY return a PENDING for other reasons. 1220 The response will have a Content-Type of "application/x-pki-message". 1222 "Content-Type: application/x-pki-message" 1224 1226 4.4. Poll for Client Initial Certificate 1228 When the client receives a CertRep message with pkiStatus set to 1229 PENDING, it will enter the polling state by periodically sending 1230 CertPoll messages to the CA until either the request is granted and 1231 the certificate is sent back or the request is rejected or some 1232 preconfigured time limit for polling or maximum number of polls is 1233 exceeded. The OPERATION MUST be set to "PKIOperation". 1235 CertPoll messages exchanged during the polling period MUST carry the 1236 same transactionID attribute as the previous PKCSReq/RenewalReq. A 1237 CA receiving a CertPoll for which it does not have a matching 1238 PKCSReq/RenewalReq MUST ignore this request. 1240 Since at this time the certificate has not been issued, the client 1241 can only use its own subject name (which was contained in the 1242 original PKCS# 10 sent via PKCSReq/RenewalReq) to identify the polled 1243 certificate request (but see the note on identification during 1244 polling in Section 3.3.3). In theory there can be multiple 1245 outstanding requests from one client (for example, if different keys 1246 and different key-usages were used to request multiple certificates), 1247 so the transactionID must also be included to disambiguate between 1248 multiple requests. In practice however the client SHOULD NOT have 1249 multiple requests outstanding at any one time, since this tends to 1250 confuse some CAs. 1252 4.4.1. Polling Response Message Format 1254 The response messages for CertPoll are the same as in Section 4.3.1. 1256 4.5. Certificate Access 1258 A client can query an issued certificate from the SCEP CA, as long as 1259 the client knows the issuer name and the issuer assigned certificate 1260 serial number. 1262 This transaction consists of one GetCert (Section 3.3.4) message sent 1263 to the CA by a client, and one CertRep (Section 3.3.2) message sent 1264 back from the CA. The OPERATION MUST be set to "PKIOperation". 1266 4.5.1. Certificate Access Response Message Format 1268 In this case, the CertRep from the CA is same as in Section 4.3.1, 1269 except that the CA will either grant the request (SUCCESS) or reject 1270 it (FAILURE). 1272 4.6. CRL Access 1274 Clients can request a CRL from the SCEP CA as described in 1275 Section 2.7. The OPERATION MUST be set to "PKIOperation". 1277 4.6.1. CRL Access Response Message Format 1279 The CRL is sent back to the client in a CertRep (Section 3.3.2) 1280 message. The information portion of this message is a degenerate 1281 certificates-only Signed-Data (Section 3.4) that contains only the 1282 most recent CRL in the crls field of the Signed-Data. 1284 4.7. Get Next Certificate Authority Certificate 1286 When a CA certificate is about to expire, clients need to retrieve 1287 the CA's next CA certificate (i.e. the rollover certificate). This 1288 is done via the GetNextCACert message. The OPERATION MUST be set to 1289 "GetNextCACert". There is no request data associated with this 1290 message. 1292 4.7.1. Get Next CA Response Message Format 1294 The response consists of a Signed-Data CMS message, signed by the 1295 current CA signing key. Clients MUST validate the signature on the 1296 message before accepting any of its contents. The response will have 1297 a Content-Type of "application/x-x509-next-ca-cert". 1299 "Content-Type: application/x-x509-next-ca-cert" 1301 1303 The content of the Signed-Data message is a degenerate certificates- 1304 only Signed-Data message (Section 3.4) containing the new CA 1305 certificate(s) to be used when the current CA certificate expires. 1307 If the CA does not have rollover certificate(s) it MUST reject the 1308 request. It SHOULD also remove the GetNextCACert setting from the CA 1309 capabilities returned by GetCACaps until it does have rollover 1310 certificates. 1312 5. SCEP Transaction Examples 1314 The following section gives several examples of client to CA 1315 transactions. Client actions are indicated in the left column, CA 1316 actions are indicated in the right column, and the transactionID is 1317 given in parentheses. The first transaction, for example, would read 1318 like this: 1320 "Client Sends PKCSReq message with transactionID 1 to the CA. The CA 1321 signs the certificate and constructs a CertRep Message containing the 1322 signed certificate with a transaction ID 1. The client receives the 1323 message and installs the certificate locally". 1325 5.1. Successful Transactions 1327 Successful Enrolment Case: Automatic processing 1329 PKCSReq (1) ----------> CA issues certificate 1330 <---------- CertRep (1) SUCCESS 1331 Client installs certificate 1332 Successful Enrolment Case: Manual authentication required 1334 PKCSReq (2) ----------> Cert request goes into queue 1335 <---------- CertRep (2) PENDING 1336 CertPoll (2) ----------> Still pending 1337 <---------- CertRep (2) PENDING 1338 CertPoll (2) ----------> CA issues certificate 1339 <---------- CertRep (2) SUCCESS 1340 Client installs certificate 1342 CA certificate rollover case: 1344 GetNextCACert ----------> 1345 <---------- New CA certificate 1347 PKCSReq* ----------> CA issues certificate with 1348 new key 1349 <---------- CertRep SUCCESS 1350 Client stores certificate 1351 for installation when 1352 existing certificate expires. 1354 * Enveloped for the new CA certificate. The CA will use the envelope 1355 to determine which key to use to issue the client certificate. 1357 5.2. Transactions with Errors 1359 In the case of polled transactions that aren't completed 1360 automatically, there are two potential options for dealing with a 1361 transaction that's interrupted due to network or software/hardware 1362 issues. The first is for the client to preserve its transaction 1363 state and resume the CertPoll polling when normal service is 1364 restored. The second is for the client to begin a new transaction by 1365 sending a new PKCSReq/RenewalReq rather than continuing the previous 1366 CertPoll. Both options have their own advantages and disadvantages. 1368 The CertPoll continuation requires that the client maintain its 1369 transaction state for the time when it resumes polling. This is 1370 relatively simple if the problem is a brief network outage, but less 1371 simple when the problem is a client crash and restart. In addition 1372 the CA may treat a lost network connection as the end of a 1373 transaction, so that a new connection followed by a CertPoll will be 1374 treated as an error. 1376 The PKCSReq/RenewalReq continuation doesn't require any state to be 1377 maintained since it's a new transaction, however it may cause 1378 problems on the CA side if the certificate was successfully issued 1379 but the client never received it, since the resumed transaction 1380 attempt will appear to be a request for a duplicate certificate (see 1381 Section 8.4 for more on why this is a problem). In this case the CA 1382 may refuse the transaction, or require manual intervention to remove/ 1383 revoke the previous certificate before the client can request another 1384 one. 1386 Since the new-transaction resume is more robust in the presence of 1387 errors and doesn't require special-case handling by either the client 1388 or CA, clients SHOULD use the new-transaction option in preference to 1389 the resumed-CertPoll option to recover from errors. 1391 Resync Case 1: Client resyncs via new PKCSReq (recommended): 1393 PKCSReq (3) ----------> Cert request goes into queue 1394 <---------- CertRep (3) PENDING 1395 CertPoll (3) ----------> Still pending 1396 X-------- CertRep(3) PENDING 1397 (Network outage) 1398 (Client reconnects) 1399 PKCSReq (4) ----------> 1400 <---------- CertRep (4) PENDING 1401 etc... 1403 Resync Case 2: Client resyncs via resumed CertPoll after a network 1404 outage (not recommended, use PKCSReq to resync): 1406 PKCSReq (5) ----------> Cert request goes into queue 1407 <---------- CertRep (5) PENDING 1408 CertPoll (5) ----------> Still pending 1409 X-------- CertRep(5) PENDING 1410 (Network outage) 1411 (Client reconnects) 1412 CertPoll (5) ----------> CA issues certificate 1413 <---------- CertRep (5) SUCCESS 1414 Client installs certificate 1415 Resync Case 3: Special-case variation of case 2 where the CertRep 1416 SUCCESS rather than the CertRep PENDING is lost (recommended): 1418 PKCSReq (6) ----------> Cert request goes into queue 1419 <---------- CertRep (6) PENDING 1420 CertPoll (6) ----------> Still pending 1421 <---------- CertRep (6) PENDING 1422 CertPoll (6) ----------> CA issues certificate 1423 X-------- CertRep(6) SUCCESS 1424 (Network outage) 1425 (Client reconnects) 1426 PKCSReq (7) ----------> There is already a valid 1427 certificate with this DN. 1428 <---------- CertRep (7) FAILURE 1429 Admin revokes certificate 1430 PKCSReq (7) ----------> CA issues new certificate 1431 <---------- CertRep (7) SUCCESS 1432 Client installs certificate 1434 Resync Case 4: Special-case variation of case 1 where the CertRep 1435 SUCCESS rather than the CertRep PENDING is lost (not recommended, use 1436 PKCSReq to resync): 1438 PKCSReq (8) ----------> Cert request goes into queue 1439 <---------- CertRep (8) PENDING 1440 CertPoll (8) ----------> Still pending 1441 <---------- CertRep (8) PENDING 1442 CertPoll (8) ----------> CA issues certificate 1443 X-------- CertRep(8) SIGNED CERT 1444 (Network outage) 1445 (Client reconnects) 1446 CertPoll (8) ----------> Certificate already issued 1447 <---------- CertRep (8) SUCCESS 1448 Client installs certificate 1450 As these examples indicate, resumption from an error via a resumed 1451 CertPoll is tricky due to the state that needs to be held by both the 1452 client and/or the CA. A PKCSReq/RenewalReq resume is the easiest to 1453 implement since it's stateless and is identical for both polled and 1454 non-polled transactions, while a CertPoll resume treats the two 1455 differently (a non-polled transaction is resumed with a PKCSReq/ 1456 RenewalReq, a polled transaction is resumed with a CertPoll). For 1457 this reason error recovery SHOULD be handled via a new PKCSReq rather 1458 than a resumed CertPoll. 1460 6. Contributors/Acknowledgements 1462 The editor would like to thank all of the previous editors, authors 1463 and contributors: Cheryl Madson, Xiaoyi Liu, David McGrew, David 1464 Cooper, Andy Nourse, Max Pritikin, Jan Vilhuber, and others for their 1465 work maintaining the draft over the years. Numerous other people 1466 have contributed during the long life cycle of the draft and all 1467 deserve thanks. In addition several PKCS #7 / CMS libraries 1468 contributed to interoperability by doing the right thing despite what 1469 earlier SCEP drafts required. 1471 The earlier authors would like to thank Peter William of ValiCert, 1472 Inc. (formerly of VeriSign, Inc.) and Alex Deacon of VeriSign, Inc. 1473 and Christopher Welles of IRE, Inc. for their contributions to early 1474 versions of this protocol and this document. 1476 7. IANA Considerations 1478 One object identifier for an arc to assign SCEP Attribute Identifiers 1479 was assigned in the SMI Security for PKIX (1.3.6.1.5.5.7) registry: 1481 id-scep OBJECT IDENTIFIER ::= { id-pkix TBD1 } 1483 This assignment created the new SMI Security for SCEP Attribute 1484 Identifiers ((1.3.6.1.5.5.7.TBD1) registry with the following entries 1485 with references to this document: 1487 id-scep-failInfoText OBJECT IDENTIFIER ::= { id-scep 1 } 1489 (Editor's note: When the OID is assigned, the values in the OID table 1490 in Section 3.2 will also need to be updated). 1492 8. Security Considerations 1494 The security goal of SCEP is that no adversary can subvert the public 1495 key/identity binding from that intended. An adversary is any entity 1496 other than the client and the CA participating in the protocol. 1498 This goal is met through the use of CMS and PKCS #10 encryption and 1499 digital signatures using authenticated public keys. The CA's public 1500 key is authenticated via out-of-band means such as the checking of 1501 the CA fingerprint and the SCEP client's public key is authenticated 1502 through manual or pre-shared secret authentication. 1504 8.1. General Security 1506 Common key-management considerations such as keeping private keys 1507 truly private and using adequate lengths for symmetric and asymmetric 1508 keys must be followed in order to maintain the security of this 1509 protocol. This is especially true for CA keys which, when 1510 compromised, compromise the security of all relying parties. 1512 8.2. Use of the CA keypair 1514 A CA key pair is generally meant for, and is usually flagged as, 1515 being usable for certificate (and CRL) signing exclusively rather 1516 than data signing or encryption. The SCEP protocol however uses the 1517 CA private key to both sign and optionally encrypt CMS transport 1518 messages. This is generally considered undesirable as it widens the 1519 possibility of an implementation weakness and provides an additional 1520 location where the private key must be used (and hence is slightly 1521 more vulnerable to exposure) and where a side-channel attack might be 1522 applied. 1524 8.3. Challenge Password 1526 The challengePassword sent in the PKCS #10 enrolment request is 1527 signed and encrypted by way of being encapsulated in a pkiMessage. 1528 When saved by the CA, care should be taken to protect this password, 1529 for example by storing a salted iterated hash of the password rather 1530 than the password itself. 1532 8.4. Lack of Certificate Issue Confirmation 1534 SCEP provides no confirmation that the issued certificate was 1535 successfully received and processed by the client. This means that 1536 if the CertRep message is lost or can't be processed by the client 1537 then the CA will consider the certificate successfully issued while 1538 the client won't. If this situation is of concern then the correct 1539 issuance of the certificate will need to be verified by out-of-band 1540 means, for example through the client sending a message signed by the 1541 newly-issued certificate to the CA. This also provides the proof of 1542 possession that's not present in the case of a renewal operation, see 1543 Section 8.6. 1545 8.5. GetCACaps Issues 1547 The GetCACaps response is not authenticated by the CA. This allows 1548 an attacker to perform downgrade attacks on the cryptographic 1549 capabilities of the client/CA exchange. In particular if the server 1550 were to support MD5 and single DES then an in-path attacker could 1551 trivially roll back the encryption to use these insecure algorithms. 1553 By taking advantage of the presence of large amounts of static known 1554 plaintext in the SCEP messages, as of 2017 a DES rainbow table attack 1555 can recover most encryption keys in under a minute, and MD5 chosen- 1556 prefix collisions can be calculated for a few tens of cents of 1557 computing time using tools like HashClash. 1559 8.6. Lack of PoP in Renewal Requests 1561 Renewal operations (but not standard certificate-issue operations) 1562 are processed via a previously-issued certificate and its associated 1563 private key, not the key in the PKCS #10 request. This means that a 1564 client no longer demonstrates proof of possession (PoP) of the 1565 private key corresponding to the public key in the PKCS #10 request. 1566 It is therefore possible for a client to re-certify an existing key 1567 used by a third party, so that two or more certificates exist for the 1568 same key. By switching out the certificate in a signature, an 1569 attacker can appear to have a piece of data signed by their 1570 certificate rather than the original signer's certificate. This, and 1571 other, attacks are described in S/MIME ESS [15]. 1573 Avoiding these types of attacks requires situation-specific measures. 1574 For example CMS/SMIME implementations may use the ESSCertID attribute 1575 from S/MIME ESS [15] or its successor S/MIME ESSv2 [16] to 1576 unambiguously identify the signing certificate, however other 1577 mechanisms and protocols typically don't defend against this attack. 1579 8.7. Unnecessary cryptography 1581 Some of the SCEP exchanges use unnecessary signing and encryption 1582 operations. In particular the GetCert and GetCRL exchanges are 1583 encrypted and signed in both directions. The information requested 1584 is public and thus encrypting the requests is of questionable value. 1585 In addition CRLs and certificates sent in responses are already 1586 signed by the CA and can be verified by the recipient without 1587 requiring additional signing and encryption. More lightweight means 1588 of retrieving certificates and CRLs such as HTTP certificate-store 1589 access [11] and LDAP are recommended for this reason. 1591 8.8. Use of SHA-1 1593 Virtually all of the large numbers of devices that use SCEP today 1594 default to SHA-1, with many supporting only that hash algorithm with 1595 no ability to upgrade to a newer one. SHA-1 is no longer regarded as 1596 secure in all situations, but as used in SCEP it's still safe. There 1597 are three reasons for this. The first is that attacking SCEP would 1598 require creating a SHA-1 collision in close to real time, which won't 1599 be feasible for a very long time. 1601 The second reason is that the signature over the message doesn't 1602 serve any critical cryptographic purpose: The PKCS #10 data itself is 1603 authenticated through its own signature, protected by encryption, and 1604 the overall request is authorised by the (encrypted) password. The 1605 sole exception to this will be the small number of implementations 1606 that support the Renewal operation, which may be authorised purely 1607 through a signature, but presumably any implementation recent enough 1608 to support Renewal also supports SHA-2. Any legacy implementation 1609 that supports the historic core SCEP protocol would not be affected. 1611 The third reason is that SCEP uses the same key for encryption and 1612 signing, so that even if an attacker were able to capture an outgoing 1613 Renewal request that didn't include a password (in other words one 1614 that was only authorised through a signature), forge the SHA-1 hash 1615 in real time, and forward the forged request to the CA, they couldn't 1616 decrypt the returned certificate, which is protected with the same 1617 key that was used to generate the signature. While Section 8.7 1618 points out that SCEP uses unnecessary cryptography in places, the 1619 additional level of security provided by the extra crypto makes it 1620 immune to any issues with SHA-1. 1622 This doesn't mean that SCEP implementations should continue to use 1623 SHA-1 in perpetuity, merely that there's no need for a panicked 1624 switch to SHA-2. 1626 9. References 1628 9.1. Normative References 1630 [1] Bradner, S., "Key words for use in RFCs to Indicate 1631 Requirement Levels", BCP 14, RFC 2119, March 1997. 1633 [2] Josefsson, S., "The Base16, Base32, and Base64 Data 1634 Encodings", RFC 4648, October 2006. 1636 [3] Housley, R., "Cryptographic Message Syntax (CMS)", 1637 RFC 5652, September 2009. 1639 [4] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1640 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 1642 [5] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 1643 Classes and Attribute Types Version 2.0", RFC 2985, 1644 November 2000. 1646 [6] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1647 Request Syntax Specification Version 1.7", RFC 2986, 1648 November 2000. 1650 [7] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1651 Housley, R., and W. Polk, "Internet X.509 Public Key 1652 Infrastructure Certificate and Certificate Revocation List 1653 (CRL) Profile", RFC 5280, May 2008. 1655 [8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1656 Resource Identifiers (URI): Generic Syntax", RFC 3986, 1657 January 2005. 1659 9.2. Informative References 1661 [9] Schaad, J. and M. Myers, "Certificate Management over CMS 1662 (CMC)", RFC 5272, June 2008. 1664 [10] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1665 "Internet X.509 Public Key Infrastructure Certificate 1666 Management Protocol (CMP)", RFC 4210, September 2005. 1668 [11] Gutmann, P., "Internet X.509 Public Key Infrastructure 1669 Operational Protocols: Certificate Store Access via HTTP", 1670 RFC 4387, February 2006. 1672 [12] "A Java implementation of the Simple Certificate Enrolment 1673 Protocol", . 1675 [13] Alighieri, D., "Internet Key Exchange (IKEv2) Protocol", 1676 RFC 7296, March 1300. 1678 [14] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1679 Mail Extensions (S/MIME) Version 3.2 Message 1680 Specification", RFC 5751, January 2010. 1682 [15] Hoffman, P., "Enhanced Security Services for S/MIME", 1683 RFC 2634, June 1999. 1685 [16] Schaad, J., "Enhanced Security Services (ESS) Update: 1686 Adding CertID Algorithm Agility", RFC 5035, August 2007. 1688 [17] Dierks, T. and E. Rescorla, "The Transport Layer Security 1689 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1691 Appendix A. Background Notes 1693 This specification has spent more than seventeen years in the draft 1694 stage. Its original goal, provisioning IPsec routers with 1695 certificates, has long since changed to general device/embedded 1696 system/IoT use. To fit this role, extra features were bolted on in a 1697 haphazard manner through the addition of a growing list of appendices 1698 and by inserting additional, often conflicting, paragraphs in various 1699 locations in the body text. Since existing features were never 1700 updated as newer ones were added, the specification accumulated large 1701 amounts of historical baggage over time. If OpenPGP was described as 1702 "a museum of 1990s crypto" then the SCEP draft was its graveyard. 1704 About five years ago the specification, which even at that point had 1705 seen only sporadic re-posts of the existing document, was more or 1706 less abandoned by its original sponsors. Due to its widespread use 1707 in large segments of the industry, the specification was rebooted in 1708 2015, cleaning up fifteen years worth of accumulated cruft, fixing 1709 errors, clarifying ambiguities, and bringing the algorithms and 1710 standards used into the current century (prior to the update, the de- 1711 facto lowest-common denominator algorithms used for interoperability 1712 were the insecure forty-year-old single DES and broken MD5 hash 1713 algorithms). 1715 Note that although the text of the current specification has changed 1716 significantly due to the consolidation of features and appendices 1717 into the main document, the protocol it describes is identical on the 1718 wire to the original (with the exception of the switch from single 1719 DES and MD5 to AES and SHA-2). The only two changes introduced, the 1720 "SCEPStandard" indicator in GetCACaps and the failInfoText attribute, 1721 are both optional values and would be ignored by older 1722 implementations that don't support them, or can be omitted from 1723 messages if they are found to cause problems. 1725 Other changes include: 1727 o Resolved contradictions in the text, for example a requirement 1728 given as a MUST in one paragraph and a SHOULD in the next, a MUST 1729 NOT in one paragraph and a MAY a few paragraphs later, a SHOULD 1730 NOT contradicted later by a MAY, and so on. 1731 o Merged several later fragmentary addenda placed in appendices (for 1732 example the handling of certificate renewal) with the body of the 1733 text. 1734 o Merged the SCEP Transactions and SCEP Transport sections, since 1735 the latter mostly duplicated (with occasional inconsistencies) the 1736 former. 1737 o Updated the algorithms to ones dating from at least this century. 1738 o Did the same for normative references to other standards. 1739 o Updated the text to use consistent terminology for the client and 1740 CA rather than a mixture of client, requester, end entity, server, 1741 certificate authority, certification authority, and CA. 1742 o Corrected incorrect references to other standards, e.g. 1743 IssuerAndSerial -> IssuerAndSerialNumber. 1745 o Corrected errors such as a statement that when both signature and 1746 encryption certificates existed, the signature certificate was 1747 used for encryption. 1748 o Condensed redundant discussions of the same topic spread across 1749 multiple sections into a single location. For example the 1750 description of intermediate CA handling previously existed in 1751 three different locations, with slightly different reqirements in 1752 each one. 1753 o Added a description of how pkiMessages were processed, which was 1754 never made explicit in the original specification. This led to 1755 creative interpretations that had security problems but were 1756 employed anyway due to the lack of specific guidance on what to 1757 do. 1758 o Relaxed some requirements that didn't serve any obvious purpose 1759 and that major implementations didn't seem to be enforcing. For 1760 example the requirement that the self-signed certificate used with 1761 a request MUST contain a subject name that matched the one in the 1762 PKCS #10 request was relaxed to a SHOULD because a number of 1763 implementations either ignored the issue entirely or at worst 1764 performed some minor action like creating a log entry after which 1765 they continued anyway. 1766 o Removed discussion of the transactionID from the security 1767 considerations, since the instructions there were directly 1768 contradicted by the discussion of the use of the transactionID in 1769 Section 5. 1770 o Added a requirement that the signed message include the signing 1771 certificate(s) in the signedData certificates field. This was 1772 implicit in the original specification (without it, the message 1773 couldn't be verified by the CA) and was handled by the fact that 1774 most PKCS #7/CMS libraries do this by default, but was never 1775 explicitly mentioned. 1776 o Clarified sections that were unclear or even made no sense, for 1777 example the requirement for a "hash on the public key" [sic] 1778 encoded as a PrintableString. 1779 o Renamed "RA certificates" to "intermediate CA certificates". The 1780 original document at some point added mention of RA certificates 1781 without specifying how the client was to determine that an RA was 1782 in use, how the RA operations were identified in the protocol, or 1783 how it was used. It's unclear whether what was meant was a true 1784 RA or merely an intermediate CA, as opposed to the default 1785 practice of having certificates issued directly from a single root 1786 CA certificate. This update uses the term "intermediate CA 1787 certificates", since this seems to have been the original intent 1788 of the text. 1789 o Redid the PKIMessage diagram to match what was specified in CMS, 1790 the original diagram omitted a number of fields and nested data 1791 structures which meant that the diagram didn't match either the 1792 text or the CMS specification. 1794 o Removed the requirement for a CertPoll to contain a 1795 recipientNonce, since CertPoll is a client message and will never 1796 be sent in response to a message containing a senderNonce. See 1797 also the note in Section 3.3.2. 1798 o Clarified certificate renewal. These represent a capability that 1799 was bolted onto the original protocol with (at best) vaguely- 1800 defined semantics, including a requirement by the CA to guess 1801 whether a particular request was a renewal or not. In response to 1802 developer feedback that they either avoided renewal entirely 1803 because of this uncertainty or hardcoded in particular behaviour 1804 on a per-CA basis, this specification explicitly identifies 1805 renewal requests as such, and provides proper semantics for them. 1806 o Added the "SCEPStandard" keyword to GetCACaps to indicate that the 1807 CA complies with the final version of the SCEP standard, since the 1808 definition of what constitutes SCEP standards compliance has 1809 changed significantly over the years. 1810 o Added the optional failInfoText attribute to deal with the fact 1811 that failInfo was incapable of adequately communicating to clients 1812 why a certificate request operation had been rejected. 1813 o Removed the discussion in the security considerations of 1814 revocation issues, since SCEP doesn't support revocation as part 1815 of the protocol. 1816 o Clarified the use of nonces, which if applied as originally 1817 specified would have made the use of polling in the presence of a 1818 lost message impossible. 1819 o Removed the discussion of generating a given transactionID by 1820 hashing the public key, since this implied that there was some 1821 special significance in the value generated this way. Since it 1822 was neither a MUST nor a MAY, it was unsound to imply that servers 1823 could rely on the value being generated a certain way. In 1824 addition it wouldn't work if multiple transactions as discussed in 1825 Section 4.4 were initiated, since the deterministic generation via 1826 hashing would lead to duplicate transactionIDs. 1827 o Added examples of SCEP messages to give implementers something to 1828 aim for. 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