idnits 2.17.1 draft-gutmann-scep-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 28, 2019) is 1914 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 363 -- Looks like a reference, but probably isn't: 'CERT-REQ-PENDING' on line 363 -- Looks like a reference, but probably isn't: 'CERT-ISSUED' on line 363 ** Obsolete normative reference: RFC 7230 (ref. '7') (Obsoleted by RFC 9110, RFC 9112) -- 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 January 28, 2019 5 Expires: August 1, 2019 7 Simple Certificate Enrolment Protocol 8 draft-gutmann-scep-13 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 August 1, 2019. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 68 2. SCEP Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.1. SCEP Entities . . . . . . . . . . . . . . . . . . . . . . 4 70 2.1.1. Client . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . 7 76 2.5.1. Client State Transitions . . . . . . . . . . . . . . 8 77 2.6. Certificate Access . . . . . . . . . . . . . . . . . . . 9 78 2.7. CRL Access . . . . . . . . . . . . . . . . . . . . . . . 10 79 2.8. Certificate Revocation . . . . . . . . . . . . . . . . . 11 80 2.9. Mandatory-to-Implement Functionality . . . . . . . . . . 11 81 3. SCEP Secure Message Objects . . . . . . . . . . . . . . . . . 11 82 3.1. SCEP Message Object Processing . . . . . . . . . . . . . 13 83 3.2. SCEP pkiMessage . . . . . . . . . . . . . . . . . . . . . 13 84 3.2.1. Signed Transaction Attributes . . . . . . . . . . . . 13 85 3.2.1.1. transactionID . . . . . . . . . . . . . . . . . . 15 86 3.2.1.2. messageType . . . . . . . . . . . . . . . . . . . 16 87 3.2.1.3. pkiStatus . . . . . . . . . . . . . . . . . . . . 16 88 3.2.1.4. failInfo and failInfoText . . . . . . . . . . . . 16 89 3.2.1.5. senderNonce and recipientNonce . . . . . . . . . 17 90 3.2.2. SCEP pkcsPKIEnvelope . . . . . . . . . . . . . . . . 17 91 3.3. SCEP pkiMessage types . . . . . . . . . . . . . . . . . . 18 92 3.3.1. PKCSReq/RenewalReq . . . . . . . . . . . . . . . . . 18 93 3.3.2. CertRep . . . . . . . . . . . . . . . . . . . . . . . 18 94 3.3.2.1. CertRep SUCCESS . . . . . . . . . . . . . . . . . 19 95 3.3.2.2. CertRep FAILURE . . . . . . . . . . . . . . . . . 19 96 3.3.2.3. CertRep PENDING . . . . . . . . . . . . . . . . . 20 98 3.3.3. CertPoll (GetCertInitial) . . . . . . . . . . . . . . 20 99 3.3.4. GetCert and GetCRL . . . . . . . . . . . . . . . . . 21 100 3.4. Degenerate certificates-only CMS Signed-Data . . . . . . 21 101 3.5. CA Capabilities . . . . . . . . . . . . . . . . . . . . . 21 102 3.5.1. GetCACaps HTTP Message Format . . . . . . . . . . . . 21 103 3.5.2. CA Capabilities Response Format . . . . . . . . . . . 22 104 4. SCEP Transactions . . . . . . . . . . . . . . . . . . . . . . 24 105 4.1. HTTP POST and GET Message Formats . . . . . . . . . . . . 24 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 . . . . . 26 109 4.2.1.2. CA Certificate Chain Response Message Format . . 26 110 4.3. Certificate Enrolment/Renewal . . . . . . . . . . . . . . 26 111 4.3.1. Certificate Enrolment/Renewal Response Message . . . 27 112 4.4. Poll for Client Initial Certificate . . . . . . . . . . . 27 113 4.4.1. Polling Response Message Format . . . . . . . . . . . 28 114 4.5. Certificate Access . . . . . . . . . . . . . . . . . . . 28 115 4.5.1. Certificate Access Response Message Format . . . . . 28 116 4.6. CRL Access . . . . . . . . . . . . . . . . . . . . . . . 28 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 . . . . . . . . . 29 120 5. SCEP Transaction Examples . . . . . . . . . . . . . . . . . . 29 121 5.1. Successful Transactions . . . . . . . . . . . . . . . . . 30 122 5.2. Transactions with Errors . . . . . . . . . . . . . . . . 30 123 6. Contributors/Acknowledgements . . . . . . . . . . . . . . . . 33 124 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 125 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 126 8.1. General Security . . . . . . . . . . . . . . . . . . . . 34 127 8.2. Use of the CA keypair . . . . . . . . . . . . . . . . . . 34 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 . . . . . . . . . . . . . 35 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 [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). This 147 specification defines a protocol, Simple Certificate Enrolment 148 Protocol (SCEP), for certificate management and certificate and CRL 149 queries. 151 The SCEP protocol supports the following general operations: 153 o CA public key distribution. 154 o Certificate enrolment and issue. 155 o Certificate renewal. 156 o Certificate query. 157 o CRL query. 159 SCEP makes extensive use of CMS [6] and PKCS #10 [9]. 161 1.1. Conventions Used in This Document 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in [1]. 167 This document uses the Augmented Backus-Naur Form (ABNF) notation as 168 specified in [2] for defining formal syntax of commands. Non 169 terminals not defined in this document (for example "HTTP-version") 170 are defined in either [2] or Section 4.1. 172 2. SCEP Overview 174 This section provides a high level overview of the functionality of 175 SCEP. 177 2.1. SCEP Entities 179 The entity types defined in SCEP are a client requesting a 180 certificate and a Certificate Authority (CA) that issues the 181 certificate. These are described in the following sections. 183 2.1.1. Client 185 A client MUST have the following information locally configured: 187 1. The CA fully qualified domain name or IP address. 188 2. The CA HTTP SCEP path (this usually has a default value, see 189 Section 4.1). 190 3. The identifying information that is used for authentication of 191 the CA in Section 4.2.1, typically a certificate fingerprint. 193 2.1.2. Certificate Authority 195 A SCEP CA is the entity that signs client certificates. A CA MAY 196 enforce any arbitrary policies and apply them to certificate 197 requests, and MAY reject a request for any reason. 199 Since the client is expected to perform signature verification and 200 optionally encryption using the CA certificate, the keyUsage 201 extension in the CA certificate MUST indicate that it is valid for 202 digitalSignature and keyEncipherment (if available) alongside the 203 usual CA usages of keyCertSign and/or cRLSign. 205 2.2. CA Certificate Distribution 207 If the CA certificate(s) have not previously been acquired by the 208 client through some other means, the client MUST retrieve them before 209 any PKI operation (Section 3) can be started. Since no public key 210 has yet been exchanged between the client and the CA, the messages 211 cannot be secured using CMS, and the CA certificate request and 212 response data is instead transferred in the clear. 214 If an intermediate CA is in use, a certificates-only CMS Signed-Data 215 message with a certificate chain consisting of all CA certificates is 216 returned. Otherwise the CA certificate itself is returned. 218 The CA certificate MAY be provided out-of-band to the client. 219 Alternatively, the CA certificate fingerprint MAY be used to 220 authenticate a CA Certificate distributed by the GetCACert response 221 (Section 4.2) or via HTTP certificate-store access [13]. The 222 fingerprint is created by calculating a SHA-256 hash over the whole 223 CA certificate (for legacy reasons, a SHA-1 hash may be used by some 224 implementations). 226 After the client gets the CA certificate, it SHOULD authenticate the 227 certificate by comparing its fingerprint with the locally configured, 228 out-of-band distributed, identifying information, or by some 229 equivalent means such as a direct comparison with a locally-stored 230 copy of the certificate. Intermediate CA certificates, if any, are 231 signed by a higher-level CA so there is no need to authenticate them 232 against the out-of-band data. Clients SHOULD verify intermediate- 233 level CA certificate signatures using the issuing CA's certificate 234 before use during protocol exchanges. 236 When a CA certificate expires, certificates that have been signed by 237 it may no longer be regarded as valid. CA key rollover provides a 238 mechanism by which the CA MAY distribute a new CA certificate which 239 is valid in the future once the current certificate has expired. 240 This is done in the GetNextCACert message (section Section 4.7). 242 2.3. Client authentication 244 As with every protocol that uses public-key cryptography, the 245 association between the public keys used in the protocol and the 246 identities with which they are associated must be authenticated in a 247 cryptographically secure manner. The communications between the 248 client and the CA are secured using SCEP Secure Message Objects as 249 explained in Section 3, which specifies how CMS is used to encrypt 250 and sign the data. In order to perform the signing operation the 251 client uses an appropriate local certificate: 253 1. If the client does not have an appropriate existing certificate 254 then a locally generated self-signed certificate MUST be used. 255 The keyUsage extension in the certificate MUST indicate that it 256 is valid for digitalSignature and keyEncipherment (if available). 257 The self-signed certificate SHOULD use the same subject name as 258 in the PKCS #10 request. In this case the messageType is PKCSReq 259 (see Section 3.2.1.2). 260 2. If the requesting system already has a certificate issued by the 261 SCEP CA and the CA supports renewal (see Section 2.5), that 262 certificate SHOULD be used. In this case the messageType is 263 RenewalReq (see Section 3.2.1.2). 264 3. Alternatively, if the requesting system has no certificate issued 265 by the SCEP CA but has credentials from an alternate CA then the 266 certificate issued by the alternate CA MAY be used in a renewal 267 request as described above. Policy settings on the SCEP CA will 268 determine if the request can be accepted or not. 270 Note that although the above text describes several different types 271 of operations, in practice most implementations always apply the 272 first one even if an existing certificate already exists. For this 273 reason support for the first case is mandatory while support for the 274 latter ones are optional (see Section 2.9). 276 During the certificate enrolment process, the client MUST use the 277 selected certificate's key when signing the CMS envelope (see 278 Section 3). This certificate will be either the self-signed one 279 matching the PKCS #10 request or the CA-issued one used to authorise 280 a renewal, and MUST be included in the signedData certificates field 281 (possibly as part of a full certificate chain). If the key being 282 certified allows encryption then the CA's CertResp will use the same 283 certificate's public key when encrypting the response. 285 Note that this means that, in the case of renewal operations, the 286 request is signed with, and the returned response may be encrypted 287 with, the key in the previously-issued certificate used to 288 authenticate the request, not the key in the PKCS #10 request. This 289 has security implications, see Section 8.6. 291 2.4. Enrolment authorization 293 PKCS #10 [9] specifies a PKCS #9 [8] challengePassword attribute to 294 be sent as part of the enrolment request. When utilizing the 295 challengePassword, the CA distributes a shared secret to the client 296 which will uniquely associate the enrolment request with the client. 298 Inclusion of the challengePassword by the SCEP client is OPTIONAL and 299 allows for unauthenticated authorization of enrolment requests 300 (which, however, requires manual approval of each certificate issue, 301 see below), or for renewal requests that are authenticated by being 302 signed with an existing certificate. The CMS envelope protects the 303 privacy of the challengePassword. 305 A client that is performing certificate renewal as per Section 2.5 306 SHOULD omit the challengePassword but MAY send the originally 307 distributed password in the challengePassword attribute. The SCEP CA 308 MAY use the challengePassword in addition to the previously issued 309 certificate that signs the request to authenticate the request. The 310 SCEP CA MUST NOT attempt to authenticate a client based on a self- 311 signed certificate unless it has been verified through out-of-band 312 means such as a certificate fingerprint. 314 To perform the authorization in manual mode the client's request is 315 placed in the PENDING state until the CA operator authorizes or 316 rejects it. Manual authorization is used when the client has only a 317 self-signed certificate that hasn't been previously authenticated by 318 the CA and/or a challengePassword is not available. The SCEP CA MAY 319 either reject unauthorized requests or mark them for manual 320 authorization according to CA policy. 322 2.5. Certificate Enrolment/Renewal 324 A client starts an enrolment transaction (Section 3.3.1) by creating 325 a certificate request using PKCS #10 and sends it to the CA enveloped 326 using CMS (Section 3). 328 If the CA supports certificate renewal and if the CA policy permits 329 then a new certificate with new validity dates can be issued even 330 though the old one is still valid. The CA MAY automatically revoke 331 the old client certificate. To renew an existing certificate, the 332 client uses the RenewalReq message (see Section 3.3) and signs it 333 with the existing client certificate. The client SHOULD use a new 334 keypair when requesting a new certificate, but MAY request a new 335 certificate using the old keypair. 337 If the CA returns a CertRep message (Section 3.3.2) with status set 338 to PENDING, the client enters into polling mode by periodically 339 sending a CertPoll message (Section 3.3.3) to the CA until the CA 340 operator completes the manual authentication (approving or denying 341 the request). The frequency of the polling operation is a CA/client 342 configuration issue, and may range from seconds or minutes when the 343 issue process is automatic but not instantaneous, through to hours or 344 days if the certificate issue operation requires manual approval. 346 If polling mode is being used then the client will send a single 347 PKCSReq/RenewalReq message (Section 3.3.1), followed by 0 or more 348 CertPoll messages (Section 3.3.3). The CA will in return send 0 or 349 more CertRep messages (Section 3.3.2) with status set to PENDING in 350 response to CertPolls, followed by a single CertRep message 351 (Section 3.3.2) with status set to either SUCCESS or FAILURE. 353 2.5.1. Client State Transitions 355 The client state transitions during the SCEP process are indicated in 356 Figure 1. 358 CertPoll 359 +-----<----+ 360 | | 361 | | CertRep(PENDING) 362 | | 363 [CERT-NONEXISTENT] ------> [CERT-REQ-PENDING] ---------> [CERT-ISSUED] 364 ^ PKCSReq | CertRep(SUCCESS) 365 | RenewalReq | 366 | | 367 +-----------------------+ 368 CertRep(FAILURE) or 369 Max-time/max-polls exceeded 371 Figure 1: State Transition Diagram 373 The certificate issue process starts at state CERT-NONEXISTENT. 374 Sending a PKCSReq/RenewalReq message changes the state to CERT-REQ- 375 PENDING. 377 If the CA returns a CertRep message with pkiStatus set to SUCCESS 378 then the state changes to CERT-ISSUED. 380 If the CA returns a CertRep message with pkiStatus set to FAILURE or 381 there is no response then the state reverts back to CERT-NONEXISTENT. 383 If the CA returns a CertRep message with pkiStatus set to PENDING 384 then the client will keep polling by sending a CertPoll message until 385 either a CertRep message with status set to SUCCESS or FAILURE is 386 received or a timeout occurs or the maximum number of polls has been 387 exceeded. 389 A successful transaction in automatic mode: 391 CLIENT CA SERVER 393 PKCSReq: PKI cert. enrolment message 394 --------------------------------> CertRep: pkiStatus = SUCCESS 395 Certificate attached 396 <------------------------------ 397 Receive issued certificate. 399 A successful transaction in manual mode: 401 CLIENT CA SERVER 403 PKCSReq: PKI cert. enrolment message 404 --------------------------------> CertRep: pkiStatus = PENDING 405 <------------------------------ 406 CertPoll: Polling message 407 --------------------------------> CertRep: pkiStatus = PENDING 408 <------------------------------ 409 ................ ............... 411 CertPoll: Polling message 412 --------------------------------> CertRep: pkiStatus = SUCCESS 413 Certificate attached 414 <------------------------------ 415 Receive issued certificate. 417 2.6. Certificate Access 419 A certificate query message is defined for clients to retrieve a copy 420 of their own certificate from the CA. It allows clients that do not 421 store their certificates locally to obtain a copy when needed. This 422 functionality is not intended to provide a general purpose 423 certificate access service, which may be achieved via HTTP 424 certificate-store access [13] or LDAP. 426 To query a certificate from the CA, a client sends a request 427 consisting of the certificate's issuer name and serial number. This 428 assumes that the client has saved the issuer name and the serial 429 number of the issued certificate from the previous enrolment 430 transaction. The transaction to query a certificate consists of one 431 GetCert (Section 3.3.4) message and one CertRep (Section 3.3.2) 432 message, as shown below. 434 CLIENT CA SERVER 436 GetCert: PKI certificate query message 437 -------------------------------> CertRep: pkiStatus = SUCCESS 438 Certificate attached 439 <----------------------------- 440 Receive the certificate. 442 2.7. CRL Access 444 SCEP clients MAY request a CRL via one of three methods: 446 1. If the CA supports CRL Distribution Points (CRLDPs) [10], then 447 the CRL MAY be retrieved via the mechanism specified in the 448 CRDLP. 449 2. If the CA supports HTTP certificate-store access [13], then the 450 CRL MAY be retrieved via the AuthorityInfoAcces [10] location 451 specified in the certificate. 452 3. Only if the CA does not support CRDLPs or HTTP access should a 453 CRL query be composed by creating a GetCRL message consisting of 454 the issuer name and serial number from the certificate whose 455 revocation status is being queried. 457 The CA SHOULD NOT support the GetCRL method because it does not scale 458 well due to the unnecessary cryptography (see Section 8.7) and it 459 requires the CA to be a high-availability service. 461 The message is sent to the SCEP CA in the same way as the other SCEP 462 requests. The transaction to retrieve a CRL consists of one GetCRL 463 PKI message and one CertRep PKI message, which contains only the CRL 464 (no certificates) in a degenerate certificates-only CMS Signed-Data 465 message (Section 3.4), as shown below. 467 CLIENT CA SERVER 469 GetCRL: PKI CRL query message 470 ----------------------------------> 471 CertRep: CRL attached 472 <----------------------------- 473 Receive the CRL 475 2.8. Certificate Revocation 477 SCEP does not specify a method to request certificate revocation. In 478 order to revoke a certificate, the client must contact the CA using a 479 non-SCEP defined mechanism. 481 2.9. Mandatory-to-Implement Functionality 483 At a minimum, all SCEP implementations compliant with this 484 specification MUST support GetCACaps (Section 3.5.1), GetCACert 485 (Section 4.2), PKCSReq (Section 3.3.1) (and its associated response 486 messages), communication of binary data via HTTP POST (Section 4.1), 487 and the AES [3] and SHA-256 [4] algorithms to secure pkiMessages 488 (Section 3.2). 490 For historical reasons implementations MAY support communications of 491 binary data via HTTP GET (Section 4.1), and the triple DES and SHA-1 492 algorithms to secure pkiMessages (Section 3.2). Implementations MUST 493 NOT support the obsolete and/or insecure single DES and MD5 494 algorithms used in earlier versions of this specification, since the 495 unsecured nature of GetCACaps means that an in-path attacker can 496 trivially roll back the encryption used to these insecure algorithms, 497 see Section 8.5. 499 3. SCEP Secure Message Objects 501 CMS is a general enveloping mechanism that enables both signed and 502 encrypted transmission of arbitrary data. SCEP messages that require 503 confidentiality use two layers of CMS, as shown in Figure 2. By 504 applying both enveloping and signing transformations, the SCEP 505 message is protected both for the integrity of its end-to-end 506 transaction information and the confidentiality of its information 507 portion. Some messages do not require enveloping, in which case the 508 EnvelopedData in Figure 2 is omitted. 510 pkiMessage { 511 contentType = signedData { pkcs-7 2 }, 512 content { 513 digestAlgorithms, 514 encapsulatedContentInfo { 515 eContentType = data { pkcs-7 1 }, 516 eContent { -- pkcsPKIEnvelope, optional 517 contentType = envelopedData { pkcs-7 3 }, 518 content { 519 recipientInfo, 520 encryptedContentInfo { 521 contentType = data { pkcs-7 1 }, 522 contentEncrAlgorithm, 523 encryptedContent { 524 messageData -- Typically PKCS #10 request 525 } 526 } 527 } 528 } 529 }, 530 certificates, -- Optional 531 crls, -- Optional 532 signerInfo { 533 signedAttrs { 534 transactionID, 535 messageType, 536 pkiStatus, 537 failInfo, -- Optional 538 senderNonce / recipientNonce, 539 }, 540 signature 541 } 542 } 543 } 545 Figure 2: CMS Layering 547 When a particular SCEP message carries data, this data is carried in 548 the messageData. CertRep messages will lack any signed content and 549 consist only of a pkcsPKIEnvelope (Section 3.2.2). 551 The remainder of this document will refer only to 'messageData', but 552 it is understood to always be encapsulated in the pkcsPKIEnvelope 553 (Section 3.2.2). The format of the data in the messageData is 554 defined by the messageType attribute (see Section 3.2) of the Signed- 555 Data. If there is no messageData to be transmitted, the entire 556 pkcsPKIEnvelope MUST be omitted. 558 Samples of SCEP messages are available through the JSCEP project [14] 559 in the src/samples directory. 561 3.1. SCEP Message Object Processing 563 Creating a SCEP message consists of several stages. The content to 564 be conveyed (in other words the messageData) is first encrypted, and 565 the encrypted content is then signed. 567 The form of encryption to be applied depends on the capabilities of 568 the recipient's public key. If the key is encryption-capable (for 569 example RSA) then the messageData is encrypted using the recipient's 570 public key with the CMS KeyTransRecipientInfo mechanism. If the key 571 is not encryption-capable (for example DSA or ECDSA) then the 572 messageData is encrypted using the challengePassword with the CMS 573 PasswordRecipientInfo mechanism. 575 Once the messageData has been encrypted, it is signed with the 576 sender's public key. This completes the SCEP message that is then 577 sent to the recipient. 579 Note that some earlier implementations of this specification dealt 580 with non-encryption-capable keys by omitting the encryption stage, 581 based on the text in Section 3 that indicated that "the EnvelopedData 582 is omitted". This alternative processing mechanism SHOULD NOT be 583 used since it exposes the challengePassword used to authorise the 584 certificate issue. 586 3.2. SCEP pkiMessage 588 The basic building block of all secured SCEP messages is the SCEP 589 pkiMessage. It consists of a CMS Signed-Data content type. The 590 following restrictions apply: 592 o The eContentType in encapsulatedContentInfo MUST be data ({pkcs-7 593 1}). 594 o The signed content, if present (FAILURE and PENDING CertRep 595 messages will lack any signed content), MUST be a pkcsPKIEnvelope 596 (Section 3.2.2), and MUST match the messageType attribute. 597 o The SignerInfo MUST contain a set of authenticatedAttributes 598 (Section 3.2.1). 600 3.2.1. Signed Transaction Attributes 602 At a minimum, all messages MUST contain the following 603 authenticatedAttributes: 605 o A transactionID attribute (see Section 3.2.1.1). 607 o A messageType attribute (see Section 3.2.1.2). 608 o A fresh senderNonce attribute (see Section 3.2.1.5). 609 o Any attributes required by CMS. 611 If the message is a CertRep, it MUST also include the following 612 authenticatedAttributes: 614 o A pkiStatus attribute (see Section 3.2.1.3). 615 o A failInfo and optional failInfotext attribute (see 616 Section 3.2.1.4) if pkiStatus = FAILURE. 617 o A recipientNonce attribute (see Section 3.2.1.5) copied from the 618 senderNonce in the request that this is a response to. 620 The following transaction attributes are encoded as authenticated 621 attributes, and are carried in the SignerInfo for this Signed-Data. 623 +----------------+-----------------+--------------------------------+ 624 | Attribute | Encoding | Comment | 625 +----------------+-----------------+--------------------------------+ 626 | transactionID | PrintableString | Unique ID for this transaction | 627 | | | as a text string | 628 | | | | 629 | messageType | PrintableString | Decimal value as a numeric | 630 | | | text string | 631 | | | | 632 | pkiStatus | PrintableString | Decimal value as a numeric | 633 | | | text string | 634 | | | | 635 | failInfo | PrintableString | Decimal value as a numeric | 636 | | | text string | 637 | | | | 638 | failInfoText | UTF8String | Descriptive text for the | 639 | | | failInfo value | 640 | | | | 641 | senderNonce | OCTET STRING | Random nonce as a 16-byte | 642 | | | binary data string | 643 | | | | 644 | recipientNonce | OCTET STRING | Random nonce as a 16-byte | 645 | | | binary data string | 646 +----------------+-----------------+--------------------------------+ 647 The OIDs used for these attributes are as follows: 649 +----------------------+--------------------------------------------+ 650 | Name | ASN.1 Definition | 651 +----------------------+--------------------------------------------+ 652 | id-VeriSign | OBJECT_IDENTIFIER ::= {2 16 US(840) 1 | 653 | | VeriSign(113733)} | 654 | | | 655 | id-pki | OBJECT_IDENTIFIER ::= {id-VeriSign pki(1)} | 656 | | | 657 | id-attributes | OBJECT_IDENTIFIER ::= {id-pki | 658 | | attributes(9)} | 659 | | | 660 | id-transactionID | OBJECT_IDENTIFIER ::= {id-attributes | 661 | | transactionID(7)} | 662 | | | 663 | id-messageType | OBJECT_IDENTIFIER ::= {id-attributes | 664 | | messageType(2)} | 665 | | | 666 | id-pkiStatus | OBJECT_IDENTIFIER ::= {id-attributes | 667 | | pkiStatus(3)} | 668 | | | 669 | id-failInfo | OBJECT_IDENTIFIER ::= {id-attributes | 670 | | failInfo(4)} | 671 | | | 672 | id-senderNonce | OBJECT_IDENTIFIER ::= {id-attributes | 673 | | senderNonce(5)} | 674 | | | 675 | id-recipientNonce | OBJECT_IDENTIFIER ::= {id-attributes | 676 | | recipientNonce(6)} | 677 | | | 678 | id-scep | OBJECT IDENTIFIER ::= {id-pkix TBD1} | 679 | | | 680 | id-scep-failInfoText | OBJECT IDENTIFIER ::= {id-scep 1} | 681 +----------------------+--------------------------------------------+ 683 The attributes are detailed in the following sections. 685 3.2.1.1. transactionID 687 A PKI operation is a transaction consisting of the messages exchanged 688 between a client and the CA. The transactionID is a text string 689 provided by the client when starting a transaction. The client MUST 690 use a unique string as the transaction identifier, encoded as a 691 PrintableString, which MUST be used for all PKI messages exchanged 692 for a given operation such as a certificate issue. 694 Note that the transactionID must be unique, but not necessarily 695 randomly generated. For example it may be a value assigned by the CA 696 (alongside the challengePassword) as an equivalent to the traditional 697 user name + password, so that the client is identified by their 698 transactionID. This can be useful when the client doesn't have a 699 pre-assigned Distinguished Name that the CA can identify their 700 request through, for example when enrolling SCADA devices. 702 3.2.1.2. messageType 704 The messageType attribute specifies the type of operation performed 705 by the transaction. This attribute MUST be included in all PKI 706 messages. The following message types are defined: 708 o CertRep ("3") -- Response to certificate or CRL request. 709 o RenewalReq ("17") -- PKCS #10 certificate request authenticated 710 with an existing certificate. 711 o PKCSReq ("19") -- PKCS #10 certificate request authenticated with 712 a password. 713 o CertPoll ("20") -- Certificate polling in manual enrolment. 714 o GetCert ("21") -- Retrieve a certificate. 715 o GetCRL ("22") -- Retrieve a CRL. 717 Undefined message types MUST BE treated as an error. 719 3.2.1.3. pkiStatus 721 All response messages MUST include transaction status information, 722 which is defined as a pkiStatus attribute: 724 o SUCCESS ("0") -- Request granted. 725 o FAILURE ("2") -- Request rejected. In this case the failInfo 726 attribute, as defined in Section 3.2.1.4, MUST also be present. 727 o PENDING ("3") -- Request pending for manual approval. 729 Undefined pkiStatus attributes MUST be treated as an error. 731 3.2.1.4. failInfo and failInfoText 733 The failInfo attribute MUST contain one of the following failure 734 reasons: 736 o badAlg ("0") -- Unrecognized or unsupported algorithm. 737 o badMessageCheck ("1") -- Integrity check (meaning signature 738 verification of the CMS message) failed. 739 o badRequest ("2") -- Transaction not permitted or supported. 740 o badTime ("3") -- The signingTime attribute from the CMS 741 authenticatedAttributes was not sufficiently close to the system 742 time (this failure code is present for legacy reasons and is 743 unlikely to be encountered in practice). 744 o badCertId ("4") -- No certificate could be identified matching the 745 provided criteria. 747 The failInfoText is a free-form UTF-8 text string that provides 748 further information in the case of pkiStatus = FAILURE. In 749 particular it may be used to provide details on why a certificate 750 request was not granted that go beyond what's provided by the near- 751 universal failInfo = badRequest status. Since this is a free-form 752 text string intended for interpretation by humans, implementations 753 SHOULD NOT assume that it has any type of machine-processable 754 content. 756 3.2.1.5. senderNonce and recipientNonce 758 The senderNonce and recipientNonce attributes are a 16 byte random 759 number generated for each transaction. These are intended to prevent 760 replay attacks. 762 When a sender sends a PKI message to a recipient, a fresh senderNonce 763 MUST be included in the message. The recipient MUST copy the 764 senderNonce into the recipientNonce of the reply as a proof of 765 liveliness. The original sender MUST verify that the recipientNonce 766 of the reply matches the senderNonce it sent in the request. If the 767 nonce does not match, the message MUST be rejected. 769 Note that since SCEP exchanges consist of a single request followed 770 by a single response, the use of distinct sender and recipient nonces 771 is redundant since the client sends a nonce in its request and the CA 772 responds with the same nonce in its reply. In effect there's just a 773 single nonce, identified as senderNonce in the client's request and 774 recipientNonce in the CA's reply. 776 3.2.2. SCEP pkcsPKIEnvelope 778 The information portion of a SCEP message is carried inside an 779 EnvelopedData content type, as defined in CMS, with the following 780 restrictions: 782 o contentType in encryptedContentInfo MUST be data ({pkcs-7 1}). 783 o encryptedContent MUST be the SCEP message being transported (see 784 Section 4), and must match the messageType authenticated Attribute 785 in the pkiMessage. 787 3.3. SCEP pkiMessage types 789 All of the messages in this section are pkiMessages (Section 3.2), 790 where the type of the message MUST be specified in the 'messageType' 791 authenticated Attribute. Each section defines a valid message type, 792 the corresponding messageData formats, and mandatory authenticated 793 attributes for that type. 795 3.3.1. PKCSReq/RenewalReq 797 The messageData for this type consists of a PKCS #10 Certificate 798 Request. The certificate request MUST contain at least the following 799 items: 801 o The subject Distinguished Name. 802 o The subject public key. 803 o For a PKCSReq and if authorisation based on a password is being 804 used, a challengePassword attribute. 806 In addition to the authenticatedAttributes required for a valid CMS 807 message, the pkiMessage MUST include the following attributes: 809 o A transactionID attribute (Section 3.2.1.1). 810 o A messageType attribute (Section 3.2.1.2) set to PKCSReq or 811 RenewalReq as appropriate. 812 o A fresh senderNonce attribute (Section 3.2.1.5). 814 3.3.2. CertRep 816 The messageData for this type consists of a degenerate certificates- 817 only CMS Signed-Data message (Section 3.4). The exact content 818 required for the reply depends on the type of request that this 819 message is a response to. The request types are detailed in 820 Section 3.3.2.1 and in Section 4. 822 In addition to the authenticatedAttributes required for a valid CMS 823 message, this pkiMessage MUST include the following attributes: 825 o The transactionID attribute (Section 3.2.1.1) copied from the 826 request that this is a response to. 827 o A messageType attribute (Section 3.2.1.2) set to CertRep. 828 o A recipientNonce attribute (Section 3.2.1.5) copied from the 829 senderNonce in the request that this is a response to. 830 o A pkiStatus attribute (Section 3.2.1.3) set to the status of the 831 reply. 833 Earlier versions of this specification required that this message 834 include a senderNonce alongside the recipientNonce, which was to be 835 used to chain to subsequent polling operations. However if a single 836 message was lost during the potentially extended interval over which 837 polling could take place (see Section 5 for an example of this) then 838 if the implementation were to enforce this requirement the overall 839 transaction would fail even though nothing had actually gone wrong. 840 Because of this issue, implementations mostly ignored the requirement 841 to carry this nonce over to subsequent polling messages or to verify 842 its presence. Current versions of the specification no longer 843 require the chaining of nonces across polling operations. 845 3.3.2.1. CertRep SUCCESS 847 When the pkiStatus attribute is set to SUCCESS, the messageData for 848 this message consists of a degenerate certificates-only CMS Signed- 849 Data message (Section 3.4). The content of this degenerate 850 certificates-only Signed-Data depends on what the original request 851 was, as outlined below. 853 +--------------+----------------------------------------------------+ 854 | Request-type | Reply-contents | 855 +--------------+----------------------------------------------------+ 856 | PKCSReq | The reply MUST contain at least the issued | 857 | | certificate in the certificates field of the | 858 | | Signed-Data. The reply MAY contain additional | 859 | | certificates, but the issued certificate MUST be | 860 | | the leaf certificate. | 861 | | | 862 | RenewalReq | Same as PKCSReq | 863 | | | 864 | CertPoll | Same as PKCSReq | 865 | | | 866 | GetCert | The reply MUST contain at least the requested | 867 | | certificate in the certificates field of the | 868 | | Signed-Data. The reply MAY contain additional | 869 | | certificates, but the requested certificate MUST | 870 | | be the leaf certificate. | 871 | | | 872 | GetCRL | The reply MUST contain the CRL in the crls field | 873 | | of the Signed-Data. | 874 +--------------+----------------------------------------------------+ 876 3.3.2.2. CertRep FAILURE 878 When the pkiStatus attribute is set to FAILURE, the reply MUST also 879 contain a failInfo (Section 3.2.1.4) attribute set to the appropriate 880 error condition describing the failure. The reply MAY also contain a 881 failInfoText attribute providing extended details on why the 882 operation failed, typically to expand on the catch-all failInfo = 883 badRequest status. The pkcsPKIEnvelope (Section 3.2.2) MUST be 884 omitted. 886 3.3.2.3. CertRep PENDING 888 When the pkiStatus attribute is set to PENDING, the pkcsPKIEnvelope 889 (Section 3.2.2) MUST be omitted. 891 3.3.3. CertPoll (GetCertInitial) 893 This message is used for certificate polling. For unknown reasons it 894 was referred to as "GetCertInitial" in earlier versions of this 895 specification. The messageData for this type consists of an 896 IssuerAndSubject: 898 issuerAndSubject ::= SEQUENCE { 899 issuer Name, 900 subject Name 901 } 903 The issuer is set to the subjectName of the CA (in other words the 904 intended issuerName of the certificate that's being requested). The 905 subject is set to the subjectName used when requesting the 906 certificate. 908 Note that both of these fields are redundant, the CA is identified by 909 the recipientInfo in the pkcsPKIEnvelope (or in most cases simply by 910 the server that the message is being sent to) and the client/ 911 transaction being polled is identified by the transactionID. Both of 912 these fields can be processed by the CA without going through the 913 cryptographically expensive process of unwrapping and processing the 914 issuerAndSubject. For this reason implementations SHOULD assume that 915 the polling operation will be controlled by the recipientInfo and 916 transactionID rather than the contents of the messageData. 918 In addition to the authenticatedAttributes required for a valid CMS 919 message, this pkiMessage MUST include the following attributes: 921 o The same transactionID (Section 3.2.1.1) attribute from the 922 original PKCSReq/RenewalReq message. 923 o A messageType attribute (Section 3.2.1.2) set to CertPoll. 924 o A fresh senderNonce attribute (Section 3.2.1.5). 926 3.3.4. GetCert and GetCRL 928 The messageData for these types consist of an IssuerAndSerialNumber 929 as defined in CMS which uniquely identifies the certificate being 930 requested, either the certificate itself for GetCert or its 931 revocation status via a CRL for GetCRL. In addition to the 932 authenticatedAttributes required for a valid CMS message, this 933 pkiMessage MUST include the following attributes: 935 o A transactionID attribute (Section 3.2.1.1). 936 o A messageType attribute (Section 3.2.1.2) set to GetCert or 937 GetCRL. 938 o A fresh senderNonce attribute (Section 3.2.1.5). 940 A self-signed certificate MAY be used in the signed envelope. This 941 enables the client to request their own certificate if they were 942 unable to store it previously. 944 These message types, while included here for completeness, apply 945 unnecessary cryptography and messaging overhead to the simple task of 946 transferring a certificate or CRL (see Section 8.7). Implementations 947 SHOULD prefer HTTP certificate-store access [13] or LDAP over the use 948 of these messages. 950 3.4. Degenerate certificates-only CMS Signed-Data 952 CMS includes a degenerate case of the Signed-Data content type in 953 which there are no signers. The use of such a degenerate case is to 954 disseminate certificates and CRLs. For SCEP the content field of the 955 ContentInfo value of a degenerate certificates-only Signed-Data MUST 956 be omitted. 958 When carrying certificates, the certificates are included in the 959 'certificates' field of the Signed-Data. When carrying a CRL, the 960 CRL is included in the 'crls' field of the Signed-Data. 962 3.5. CA Capabilities 964 In order to provide support for future enhancements to the protocol, 965 CAs MUST implement the GetCACaps message to allow clients to query 966 which functionality is available from the CA. 968 3.5.1. GetCACaps HTTP Message Format 969 This message requests capabilities from a CA, with the format: 971 "GET" SP SCEPPATH "?operation=GetCACaps" SP HTTP-version CRLF 973 as described in Section 4.1. 975 3.5.2. CA Capabilities Response Format 977 The response for a GetCACaps message is a list of CA capabilities, in 978 plain text, separated by or characters, as follows 979 (quotation marks are NOT sent): 981 +--------------------+----------------------------------------------+ 982 | Keyword | Description | 983 +--------------------+----------------------------------------------+ 984 | "AES" | CA supports the AES encryption algorithm. | 985 | | | 986 | "DES3" | CA supports the triple DES encryption | 987 | | algorithm. | 988 | | | 989 | "GetNextCACert" | CA supports the GetNextCACert message. | 990 | | | 991 | "POSTPKIOperation" | CA supports PKIOPeration messages sent via | 992 | | HTTP POST. | 993 | | | 994 | "Renewal" | CA supports the Renewal CA operation. | 995 | | | 996 | "SHA-1" | CA supports the SHA-1 hashing algorithm. | 997 | | | 998 | "SHA-256" | CA supports the SHA-256 hashing algorithm. | 999 | | | 1000 | "SHA-512" | CA supports the SHA-512 hashing algorithm. | 1001 | | | 1002 | "SCEPStandard" | CA supports all mandatory-to-implement | 1003 | | sections of the SCEP standard. This keyword | 1004 | | implies "AES", "POSTPKIOperation", and | 1005 | | "SHA-256", as well as the provisions of | 1006 | | Section 2.9. | 1007 +--------------------+----------------------------------------------+ 1009 The client SHOULD use SHA-256 in preference to SHA-1 hashing and AES 1010 in preference to triple DES if they are supported by the CA. 1011 Although the CMS format allows any form of AES and SHA-2 to be 1012 specified, in the interests of interoperability the de facto 1013 universal standards of AES128-CBC and SHA-256 SHOULD be used. 1015 Announcing some of these capabilities individually is redundant since 1016 they're required as mandatory-to-implement functionality (see 1017 Section 2.9) whose presence as a whole is signalled by the 1018 "SCEPStandard" capability, but it may be useful to announce them in 1019 order to deal with old implementations that would otherwise default 1020 to obsolete, insecure algorithms and mechanisms. 1022 The CA MUST use the text case specified here, but clients SHOULD 1023 ignore the text case when processing this message. Clients MUST 1024 accept the standard HTTP-style -delimited text as well as the 1025 - delimited text specified in an earlier version of this 1026 specification. A client MUST be able to accept and ignore any 1027 unknown keywords that might be sent back by a CA. 1029 If the CA supports none of the above capabilities it SHOULD return an 1030 empty message. A CA MAY simply return an HTTP error. A client that 1031 receives an empty message or an HTTP error SHOULD interpret the 1032 response as if none of the requested capabilities are supported by 1033 the CA. 1035 (Note that at least one widely-deployed server implementation 1036 supports several of the above operations but doesn't support the 1037 GetCACaps message to indicate that it supports them, and will close 1038 the connection if sent a GetCACaps message. This means that the 1039 equivalent of GetCACaps must be performed through server 1040 fingerprinting, which can be done using the ID string "Microsoft- 1041 IIS". Newer versions of the same server, if sent a SCEP request 1042 using AES and SHA-2, will respond with an invalid response that can't 1043 be decrypted, requiring the use of 3DES and SHA-1 in order to obtain 1044 a response that can be processed even if AES and/or SHA-2 are 1045 allegedly supported. In addition the server will generate CA 1046 certificates that only have one, but not both, of the keyEncipherment 1047 and digitalSignature keyUsage flags set, requiring that the client 1048 ignore the keyUsage flags in order to use the certificates for SCEP). 1050 The Content-type of the reply SHOULD be "text/plain". Clients SHOULD 1051 ignore the Content-type, as older implementations of SCEP may send 1052 various Content-types. 1054 Example: 1056 GET /cgi-bin/pkiclient.exe?operation=GetCACaps 1057 might return: 1059 AES 1060 GetNextCACert 1061 POSTPKIOperation 1062 SCEPStandard 1063 SHA-256 1065 This means that the CA supports modern crypto algorithms, the 1066 GetNextCACert message, allows PKIOperation messages (PKCSReq/ 1067 RenewalReq, GetCert, CertPoll, ...) to be sent using HTTP POST, and 1068 is compliant with the final version of the SCEP standard. 1070 4. SCEP Transactions 1072 This section describes the SCEP Transactions and their HTTP [7] 1073 transport mechanism. 1075 Note that SCEP doesn't follow best current practices on usage of 1076 HTTP. In particular, it uses unregistered Media Types, it recommends 1077 ignoring Media Types, and hardcodes specific URI paths. Guidance on 1078 the appropriate application of HTTP in these circumstances may be 1079 found in [12] 1081 4.1. HTTP POST and GET Message Formats 1083 SCEP uses the HTTP "POST" and "GET" HTTP methods [7] to exchange 1084 information with the CA. The following defines the ABNF syntax of 1085 HTTP POST and GET methods sent from a client to a CA: 1087 POSTREQUEST = "POST" SP SCEPPATH "?operation=" OPERATION 1088 SP HTTP-version CRLF 1090 GETREQUEST = "GET" SP SCEPPATH "?operation=" OPERATION 1091 "&message=" MESSAGE SP HTTP-version CRLF 1093 where: 1095 o SCEPPATH is the HTTP URL path for accessing CA. Clients SHOULD 1096 set SCEPPATH to the fixed string "/cgi-bin/pkiclient.exe" unless 1097 directed to do otherwise by the CA. 1098 o OPERATION depends on the SCEP transaction and is defined in the 1099 following sections. 1101 o HTTP-version is the HTTP version string, which is "HTTP/1.1" for 1102 [7]. 1103 o SP and CRLF are space and carriage return/linefeed as defined in 1104 [2]. 1106 The CA will typically ignore CGI-PATH and/or CGI-PROG since it's 1107 unlikely to be issuing certificates via a web server. Clients SHOULD 1108 set CGI-PATH/CGI-PROG to the fixed string "/cgi-bin/pkiclient.exe" 1109 unless directed to do otherwise by the CA. The CA SHOULD ignore the 1110 CGI-PATH and CGI-PROG unless its precise format is critical to the 1111 CA's operation. 1113 Early SCEP drafts performed all communications via "GET" messages, 1114 including non-idempotent ones that should have been sent via "POST" 1115 messages, see [12] for details. This has caused problems because of 1116 the way that the (supposedly) idempotent GET interacts with caches 1117 and proxies, and because the extremely large GET requests created by 1118 encoding CMS messages may be truncated in transit. These issues are 1119 typically not visible when testing on a LAN, but crop up during 1120 deployment over WANs. If the remote CA supports POST, the CMS- 1121 encoded SCEP messages MUST be sent via HTTP POST instead of HTTP GET. 1122 This applies to any SCEP message except GetCACert, GetNextCACert, and 1123 GetCACaps, and avoids the need for base64- and URL-encoding that's 1124 required for GET messaging. The client can verify that the CA 1125 supports SCEP messages via POST by looking for the "POSTPKIOperation" 1126 capability (See Section 3.5.2). 1128 If a client or CA uses HTTP GET and encounters HTTP-related problems 1129 such as messages being truncated, seeing errors such as HTTP 414 1130 ("Request URI too long"), or simply having the message not sent/ 1131 received at all, when standard requests to the server (for example 1132 via a web browser) work, then this is a symptom of the problematic 1133 use of HTTP GET. The solution to this problem is to update the 1134 implementation to use HTTP POST instead. In addition when using GET 1135 it's recommended to test your implementation over the public internet 1136 from as many locations as possible to determine whether the use of 1137 GET will cause problems with communications. 1139 When using GET messages to communicate binary data, base64 encoding 1140 as specified in [5] Section 4 MUST be used. The base64 encoded data 1141 is distinct from "base64url" and may contain URI reserved characters, 1142 thus it MUST be escaped as specified in [11] in addition to being 1143 base64 encoded. Finally, the encoded data is inserted into the 1144 MESSAGE portion of the HTTP GET request. 1146 4.2. Get CA Certificate 1148 To get the CA certificate(s), the client sends a GetCACert message to 1149 the CA. The OPERATION MUST be set to "GetCACert". There is no 1150 request data associated with this message. 1152 4.2.1. Get CA Certificate Response Message Format 1154 The response for GetCACert is different between the case where the CA 1155 directly communicates with the client during the enrolment and the 1156 case where an intermediate CA exists and the client communicates with 1157 this CA during the enrolment. 1159 4.2.1.1. CA Certificate Response Message Format 1161 If the CA does not have any intermediate CA certificates, the 1162 response consists of a single X.509 CA certificate. The response 1163 will have a Content-Type of "application/x-x509-ca-cert". 1165 "Content-Type: application/x-x509-ca-cert" 1167 1169 4.2.1.2. CA Certificate Chain Response Message Format 1171 If the CA has intermediate CA certificates, the response consists of 1172 a degenerate certificates-only CMS Signed-Data message (Section 3.4) 1173 containing the certificates, with the intermediate CA certificate(s) 1174 as the leaf certificate(s). The response will have a Content-Type of 1175 "application/x-x509-ca-ra-cert". Note that this designation is used 1176 for historical reasons due to its use in older versions of this 1177 specification, no special meaning should be attached to the label. 1179 "Content-Type: application/x-x509-ca-ra-cert" 1181 1183 4.3. Certificate Enrolment/Renewal 1185 A PKCSReq/RenewalReq (Section 3.3.1) message is used to perform a 1186 certificate enrolment or renewal transaction. The OPERATION MUST be 1187 set to "PKIOperation". Note that when used with HTTP POST, the only 1188 OPERATION possible is "PKIOperation", so many CAs don't check this 1189 value or even notice its absence. When implemented using HTTP POST 1190 the message might look as follows: 1192 POST /cgi-bin/pkiclient.exe?operation=PKIOperation HTTP/1.1 1193 Content-Length: 1195 1197 When implemented using HTTP GET this might look as follows: 1199 GET /cgi-bin/pkiclient.exe?operation=PKIOperation& \ 1200 message=MIAGCSqGSIb3DQEHA6CAMIACAQAxgDCBzAIBADB2MG \ 1201 IxETAPBgNVBAcTCE......AAAAAA== HTTP/1.1 1203 4.3.1. Certificate Enrolment/Renewal Response Message 1205 If the request is granted, a CertRep message (Section 3.3.2) with 1206 pkiStatus set to SUCCESS is returned. The reply MUST also contain 1207 the certificate, and MAY contain any other certificates needed by the 1208 client (for example intermediate CA certificates) in the returned 1209 certificate chain. 1211 If the request is rejected, a CertRep message (Section 3.3.2) with 1212 pkiStatus set to FAILURE is returned. The reply MUST also contain a 1213 failInfo attribute and MAY contain a failInfoText attribute. 1215 If the CA is configured to manually authenticate the client, a 1216 CertRep message (Section 3.3.2) with pkiStatus set to PENDING MAY be 1217 returned. The CA MAY return a PENDING for other reasons. 1219 The response will have a Content-Type of "application/x-pki-message". 1221 "Content-Type: application/x-pki-message" 1223 1225 4.4. Poll for Client Initial Certificate 1227 When the client receives a CertRep message with pkiStatus set to 1228 PENDING, it will enter the polling state by periodically sending 1229 CertPoll messages to the CA until either the request is granted and 1230 the certificate is sent back or the request is rejected or some 1231 preconfigured time limit for polling or maximum number of polls is 1232 exceeded. The OPERATION MUST be set to "PKIOperation". 1234 CertPoll messages exchanged during the polling period MUST carry the 1235 same transactionID attribute as the previous PKCSReq/RenewalReq. A 1236 CA receiving a CertPoll for which it does not have a matching 1237 PKCSReq/RenewalReq MUST ignore this request. 1239 Since at this time the certificate has not been issued, the client 1240 can only use its own subject name (which was contained in the 1241 original PKCS# 10 sent via PKCSReq/RenewalReq) to identify the polled 1242 certificate request (but see the note on identification during 1243 polling in Section 3.3.3). In theory there can be multiple 1244 outstanding requests from one client (for example, if different keys 1245 and different key-usages were used to request multiple certificates), 1246 so the transactionID must also be included to disambiguate between 1247 multiple requests. In practice however the client SHOULD NOT have 1248 multiple requests outstanding at any one time, since this tends to 1249 confuse some CAs. 1251 4.4.1. Polling Response Message Format 1253 The response messages for CertPoll are the same as in Section 4.3.1. 1255 4.5. Certificate Access 1257 A client can query an issued certificate from the SCEP CA, as long as 1258 the client knows the issuer name and the issuer assigned certificate 1259 serial number. 1261 This transaction consists of one GetCert (Section 3.3.4) message sent 1262 to the CA by a client, and one CertRep (Section 3.3.2) message sent 1263 back from the CA. The OPERATION MUST be set to "PKIOperation". 1265 4.5.1. Certificate Access Response Message Format 1267 In this case, the CertRep from the CA is same as in Section 4.3.1, 1268 except that the CA will either grant the request (SUCCESS) or reject 1269 it (FAILURE). 1271 4.6. CRL Access 1273 Clients can request a CRL from the SCEP CA as described in 1274 Section 2.7. The OPERATION MUST be set to "PKIOperation". 1276 4.6.1. CRL Access Response Message Format 1278 The CRL is sent back to the client in a CertRep (Section 3.3.2) 1279 message. The information portion of this message is a degenerate 1280 certificates-only Signed-Data (Section 3.4) that contains only the 1281 most recent CRL in the crls field of the Signed-Data. 1283 4.7. Get Next Certificate Authority Certificate 1285 When a CA certificate is about to expire, clients need to retrieve 1286 the CA's next CA certificate (i.e. the rollover certificate). This 1287 is done via the GetNextCACert message. The OPERATION MUST be set to 1288 "GetNextCACert". There is no request data associated with this 1289 message. 1291 4.7.1. Get Next CA Response Message Format 1293 The response consists of a Signed-Data CMS message, signed by the 1294 current CA signing key. Clients MUST validate the signature on the 1295 message before accepting any of its contents. The response will have 1296 a Content-Type of "application/x-x509-next-ca-cert". 1298 "Content-Type: application/x-x509-next-ca-cert" 1300 1302 The content of the Signed-Data message is a degenerate certificates- 1303 only Signed-Data message (Section 3.4) containing the new CA 1304 certificate(s) to be used when the current CA certificate expires. 1306 If the CA does not have rollover certificate(s) it MUST reject the 1307 request. It SHOULD also remove the GetNextCACert setting from the CA 1308 capabilities returned by GetCACaps until it does have rollover 1309 certificates. 1311 5. SCEP Transaction Examples 1313 The following section gives several examples of client to CA 1314 transactions. Client actions are indicated in the left column, CA 1315 actions are indicated in the right column, and the transactionID is 1316 given in parentheses. The first transaction, for example, would read 1317 like this: 1319 "Client Sends PKCSReq message with transactionID 1 to the CA. The CA 1320 signs the certificate and constructs a CertRep Message containing the 1321 signed certificate with a transaction ID 1. The client receives the 1322 message and installs the certificate locally". 1324 5.1. Successful Transactions 1326 Successful Enrolment Case: Automatic processing 1328 PKCSReq (1) ----------> CA issues certificate 1329 <---------- CertRep (1) SUCCESS 1330 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 1416 Resync Case 3: Special-case variation of case 2 where the CertRep 1417 SUCCESS rather than the CertRep PENDING is lost (recommended): 1419 PKCSReq (6) ----------> Cert request goes into queue 1420 <---------- CertRep (6) PENDING 1421 CertPoll (6) ----------> Still pending 1422 <---------- CertRep (6) PENDING 1423 CertPoll (6) ----------> CA issues certificate 1424 X-------- CertRep(6) SUCCESS 1425 (Network outage) 1426 (Client reconnects) 1427 PKCSReq (7) ----------> There is already a valid 1428 certificate with this DN. 1429 <---------- CertRep (7) FAILURE 1430 Admin revokes certificate 1431 PKCSReq (7) ----------> CA issues new certificate 1432 <---------- CertRep (7) SUCCESS 1433 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. 1552 By taking advantage of the presence of large amounts of static known 1553 plaintext in the SCEP messages, as of 2017 a DES rainbow table attack 1554 can recover most encryption keys in under a minute, and MD5 chosen- 1555 prefix collisions can be calculated for a few tens of cents of 1556 computing time using tools like HashClash. 1558 8.6. Lack of PoP in Renewal Requests 1560 Renewal operations (but not standard certificate-issue operations) 1561 are processed via a previously-issued certificate and its associated 1562 private key, not the key in the PKCS #10 request. This means that a 1563 client no longer demonstrates proof of possession (PoP) of the 1564 private key corresponding to the public key in the PKCS #10 request. 1565 It is therefore possible for a client to re-certify an existing key 1566 used by a third party, so that two or more certificates exist for the 1567 same key. By switching out the certificate in a signature, an 1568 attacker can appear to have a piece of data signed by their 1569 certificate rather than the original signer's certificate. This, and 1570 other, attacks are described in S/MIME ESS [17]. 1572 Avoiding these types of attacks requires situation-specific measures. 1573 For example CMS/SMIME implementations may use the ESSCertID attribute 1574 from S/MIME ESS [17] or its successor S/MIME ESSv2 [18] to 1575 unambiguously identify the signing certificate, however other 1576 mechanisms and protocols typically don't defend against this attack. 1578 8.7. Unnecessary cryptography 1580 Some of the SCEP exchanges use unnecessary signing and encryption 1581 operations. In particular the GetCert and GetCRL exchanges are 1582 encrypted and signed in both directions. The information requested 1583 is public and thus encrypting the requests is of questionable value. 1584 In addition CRLs and certificates sent in responses are already 1585 signed by the CA and can be verified by the recipient without 1586 requiring additional signing and encryption. More lightweight means 1587 of retrieving certificates and CRLs such as HTTP certificate-store 1588 access [13] and LDAP are recommended for this reason. 1590 8.8. Use of SHA-1 1592 Virtually all of the large numbers of devices that use SCEP today 1593 default to SHA-1, with many supporting only that hash algorithm with 1594 no ability to upgrade to a newer one. SHA-1 is no longer regarded as 1595 secure in all situations, but as used in SCEP it's still safe. There 1596 are three reasons for this. The first is that attacking SCEP would 1597 require creating a SHA-1 collision in close to real time, which won't 1598 be feasible for a very long time. 1600 The second reason is that the signature over the message doesn't 1601 serve any critical cryptographic purpose: The PKCS #10 data itself is 1602 authenticated through its own signature, protected by encryption, and 1603 the overall request is authorised by the (encrypted) password. The 1604 sole exception to this will be the small number of implementations 1605 that support the Renewal operation, which may be authorised purely 1606 through a signature, but presumably any implementation recent enough 1607 to support Renewal also supports SHA-2. Any legacy implementation 1608 that supports the historic core SCEP protocol would not be affected. 1610 The third reason is that SCEP uses the same key for encryption and 1611 signing, so that even if an attacker were able to capture an outgoing 1612 Renewal request that didn't include a password (in other words one 1613 that was only authorised through a signature), forge the SHA-1 hash 1614 in real time, and forward the forged request to the CA, they couldn't 1615 decrypt the returned certificate, which is protected with the same 1616 key that was used to generate the signature. While Section 8.7 1617 points out that SCEP uses unnecessary cryptography in places, the 1618 additional level of security provided by the extra crypto makes it 1619 immune to any issues with SHA-1. 1621 This doesn't mean that SCEP implementations should continue to use 1622 SHA-1 in perpetuity, merely that there's no need for a panicked 1623 switch to SHA-2. 1625 9. References 1627 9.1. Normative References 1629 [1] Bradner, S., "Key words for use in RFCs to Indicate 1630 Requirement Levels", BCP 14, RFC 2119, March 1997. 1632 [2] Crocker, R. and P. Overell, "Augmented BNF for Syntax 1633 Specifications: ABNF", RFC 5234, January 2008. 1635 [3] NIST, "The Advanced Encryption Standard (AES)", FIPS 197, 1636 November 2001. 1638 [4] NIST, "Secure Hash Standard (SHS)", FIPS 180-3, October 1639 2008. 1641 [5] Josefsson, S., "The Base16, Base32, and Base64 Data 1642 Encodings", RFC 4648, October 2006. 1644 [6] Housley, R., "Cryptographic Message Syntax (CMS)", 1645 RFC 5652, September 2009. 1647 [7] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1648 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 1649 2014. 1651 [8] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 1652 Classes and Attribute Types Version 2.0", RFC 2985, 1653 November 2000. 1655 [9] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1656 Request Syntax Specification Version 1.7", RFC 2986, 1657 November 2000. 1659 [10] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1660 Housley, R., and W. Polk, "Internet X.509 Public Key 1661 Infrastructure Certificate and Certificate Revocation List 1662 (CRL) Profile", RFC 5280, May 2008. 1664 [11] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1665 Resource Identifiers (URI): Generic Syntax", RFC 3986, 1666 January 2005. 1668 9.2. Informative References 1670 [12] Nottingham, M., "Building Protocols with HTTP", November 1671 2018. 1673 [13] Gutmann, P., "Internet X.509 Public Key Infrastructure 1674 Operational Protocols: Certificate Store Access via HTTP", 1675 RFC 4387, February 2006. 1677 [14] "A Java implementation of the Simple Certificate Enrolment 1678 Protocol", . 1680 [15] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1681 Kivinen, "Internet Key Exchange (IKEv2) Protocol", 1682 RFC 7296, December 2005. 1684 [16] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1685 Mail Extensions (S/MIME) Version 3.2 Message 1686 Specification", RFC 5751, January 2010. 1688 [17] Hoffman, P., "Enhanced Security Services for S/MIME", 1689 RFC 2634, June 1999. 1691 [18] Schaad, J., "Enhanced Security Services (ESS) Update: 1692 Adding CertID Algorithm Agility", RFC 5035, August 2007. 1694 [19] Dierks, T. and E. Rescorla, "The Transport Layer Security 1695 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1697 Appendix A. Background Notes 1699 This specification has spent more than seventeen years in the draft 1700 stage. Its original goal, provisioning IPsec routers with 1701 certificates, has long since changed to general device/embedded 1702 system/IoT use. To fit this role, extra features were bolted on in a 1703 haphazard manner through the addition of a growing list of appendices 1704 and by inserting additional, often conflicting, paragraphs in various 1705 locations in the body text. Since existing features were never 1706 updated as newer ones were added, the specification accumulated large 1707 amounts of historical baggage over time. If OpenPGP was described as 1708 "a museum of 1990s crypto" then the SCEP draft was its graveyard. 1710 About five years ago the specification, which even at that point had 1711 seen only sporadic re-posts of the existing document, was more or 1712 less abandoned by its original sponsors. Due to its widespread use 1713 in large segments of the industry, the specification was rebooted in 1714 2015, cleaning up fifteen years worth of accumulated cruft, fixing 1715 errors, clarifying ambiguities, and bringing the algorithms and 1716 standards used into the current century (prior to the update, the de- 1717 facto lowest-common denominator algorithms used for interoperability 1718 were the insecure forty-year-old single DES and broken MD5 hash 1719 algorithms). 1721 Note that although the text of the current specification has changed 1722 significantly due to the consolidation of features and appendices 1723 into the main document, the protocol it describes is identical on the 1724 wire to the original (with the exception of the switch from single 1725 DES and MD5 to AES and SHA-2). The only two changes introduced, the 1726 "SCEPStandard" indicator in GetCACaps and the failInfoText attribute, 1727 are both optional values and would be ignored by older 1728 implementations that don't support them, or can be omitted from 1729 messages if they are found to cause problems. 1731 Other changes include: 1733 o Resolved contradictions in the text, for example a requirement 1734 given as a MUST in one paragraph and a SHOULD in the next, a MUST 1735 NOT in one paragraph and a MAY a few paragraphs later, a SHOULD 1736 NOT contradicted later by a MAY, and so on. 1737 o Merged several later fragmentary addenda placed in appendices (for 1738 example the handling of certificate renewal) with the body of the 1739 text. 1740 o Merged the SCEP Transactions and SCEP Transport sections, since 1741 the latter mostly duplicated (with occasional inconsistencies) the 1742 former. 1743 o Updated the algorithms to ones dating from at least this century. 1744 o Did the same for normative references to other standards. 1745 o Updated the text to use consistent terminology for the client and 1746 CA rather than a mixture of client, requester, end entity, server, 1747 certificate authority, certification authority, and CA. 1748 o Corrected incorrect references to other standards, e.g. 1749 IssuerAndSerial -> IssuerAndSerialNumber. 1750 o Corrected errors such as a statement that when both signature and 1751 encryption certificates existed, the signature certificate was 1752 used for encryption. 1753 o Condensed redundant discussions of the same topic spread across 1754 multiple sections into a single location. For example the 1755 description of intermediate CA handling previously existed in 1756 three different locations, with slightly different reqirements in 1757 each one. 1758 o Added a description of how pkiMessages were processed, which was 1759 never made explicit in the original specification. This led to 1760 creative interpretations that had security problems but were 1761 employed anyway due to the lack of specific guidance on what to 1762 do. 1763 o Relaxed some requirements that didn't serve any obvious purpose 1764 and that major implementations didn't seem to be enforcing. For 1765 example the requirement that the self-signed certificate used with 1766 a request MUST contain a subject name that matched the one in the 1767 PKCS #10 request was relaxed to a SHOULD because a number of 1768 implementations either ignored the issue entirely or at worst 1769 performed some minor action like creating a log entry after which 1770 they continued anyway. 1771 o Removed discussion of the transactionID from the security 1772 considerations, since the instructions there were directly 1773 contradicted by the discussion of the use of the transactionID in 1774 Section 5. 1775 o Added a requirement that the signed message include the signing 1776 certificate(s) in the signedData certificates field. This was 1777 implicit in the original specification (without it, the message 1778 couldn't be verified by the CA) and was handled by the fact that 1779 most PKCS #7/CMS libraries do this by default, but was never 1780 explicitly mentioned. 1781 o Clarified sections that were unclear or even made no sense, for 1782 example the requirement for a "hash on the public key" [sic] 1783 encoded as a PrintableString. 1784 o Renamed "RA certificates" to "intermediate CA certificates". The 1785 original document at some point added mention of RA certificates 1786 without specifying how the client was to determine that an RA was 1787 in use, how the RA operations were identified in the protocol, or 1788 how it was used. It's unclear whether what was meant was a true 1789 RA or merely an intermediate CA, as opposed to the default 1790 practice of having certificates issued directly from a single root 1791 CA certificate. This update uses the term "intermediate CA 1792 certificates", since this seems to have been the original intent 1793 of the text. 1794 o Redid the PKIMessage diagram to match what was specified in CMS, 1795 the original diagram omitted a number of fields and nested data 1796 structures which meant that the diagram didn't match either the 1797 text or the CMS specification. 1798 o Removed the requirement for a CertPoll to contain a 1799 recipientNonce, since CertPoll is a client message and will never 1800 be sent in response to a message containing a senderNonce. See 1801 also the note in Section 3.3.2. 1802 o Clarified certificate renewal. These represent a capability that 1803 was bolted onto the original protocol with (at best) vaguely- 1804 defined semantics, including a requirement by the CA to guess 1805 whether a particular request was a renewal or not. In response to 1806 developer feedback that they either avoided renewal entirely 1807 because of this uncertainty or hardcoded in particular behaviour 1808 on a per-CA basis, this specification explicitly identifies 1809 renewal requests as such, and provides proper semantics for them. 1810 o Added the "SCEPStandard" keyword to GetCACaps to indicate that the 1811 CA complies with the final version of the SCEP standard, since the 1812 definition of what constitutes SCEP standards compliance has 1813 changed significantly over the years. 1814 o Added the optional failInfoText attribute to deal with the fact 1815 that failInfo was incapable of adequately communicating to clients 1816 why a certificate request operation had been rejected. 1817 o Removed the discussion in the security considerations of 1818 revocation issues, since SCEP doesn't support revocation as part 1819 of the protocol. 1820 o Clarified the use of nonces, which if applied as originally 1821 specified would have made the use of polling in the presence of a 1822 lost message impossible. 1823 o Removed the discussion of generating a given transactionID by 1824 hashing the public key, since this implied that there was some 1825 special significance in the value generated this way. Since it 1826 was neither a MUST nor a MAY, it was unsound to imply that servers 1827 could rely on the value being generated a certain way. In 1828 addition it wouldn't work if multiple transactions as discussed in 1829 Section 4.4 were initiated, since the deterministic generation via 1830 hashing would lead to duplicate transactionIDs. 1831 o Added examples of SCEP messages to give implementers something to 1832 aim for. 1834 Author's Address 1836 Peter Gutmann 1837 University of Auckland 1838 Department of Computer Science 1839 Auckland 1840 New Zealand 1842 Email: pgut001@cs.auckland.ac.nz