idnits 2.17.1 draft-gutmann-scep-06.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 date (May 24, 2017) is 2529 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'CERT-NONEXISTENT' on line 368 -- Looks like a reference, but probably isn't: 'CERT-REQ-PENDING' on line 368 -- Looks like a reference, but probably isn't: 'CERT-ISSUED' on line 368 ** Obsolete normative reference: RFC 2616 (ref. '4') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Downref: Normative reference to an Informational RFC: RFC 2985 (ref. '5') ** Downref: Normative reference to an Informational RFC: RFC 2986 (ref. '6') ** Obsolete normative reference: RFC 2396 (ref. '8') (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. '12') (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 5751 (ref. '13') (Obsoleted by RFC 8551) -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. '16') (Obsoleted by RFC 8446) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Gutmann 3 Internet-Draft University of Auckland 4 Intended status: Standards Track May 24, 2017 5 Expires: November 25, 2017 7 Simple Certificate Enrolment Protocol 8 draft-gutmann-scep-06 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 http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 25, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 56 2. SCEP Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1. SCEP Entities . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1.1. Client . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1.2. Certificate Authority . . . . . . . . . . . . . . . . 5 60 2.1.3. CA Certificate Distribution . . . . . . . . . . . . . 5 61 2.2. Client authentication . . . . . . . . . . . . . . . . . . 6 62 2.3. Enrolment authorization . . . . . . . . . . . . . . . . . 7 63 2.4. Certificate Enrolment/Renewal/Update . . . . . . . . . . 7 64 2.4.1. Client State Transitions . . . . . . . . . . . . . . 8 65 2.5. Certificate Access . . . . . . . . . . . . . . . . . . . 10 66 2.6. CRL Access . . . . . . . . . . . . . . . . . . . . . . . 10 67 2.7. Certificate Revocation . . . . . . . . . . . . . . . . . 11 68 2.8. Mandatory-to-Implement Functionality . . . . . . . . . . 11 69 3. SCEP Secure Message Objects . . . . . . . . . . . . . . . . . 11 70 3.1. SCEP Message Object Processing . . . . . . . . . . . . . 13 71 3.2. SCEP pkiMessage . . . . . . . . . . . . . . . . . . . . . 13 72 3.2.1. Signed Transaction Attributes . . . . . . . . . . . . 13 73 3.2.1.1. transactionID . . . . . . . . . . . . . . . . . . 15 74 3.2.1.2. messageType . . . . . . . . . . . . . . . . . . . 15 75 3.2.1.3. pkiStatus . . . . . . . . . . . . . . . . . . . . 16 76 3.2.1.4. failInfo . . . . . . . . . . . . . . . . . . . . 16 77 3.2.1.5. senderNonce and recipientNonce . . . . . . . . . 17 78 3.2.2. SCEP pkcsPKIEnvelope . . . . . . . . . . . . . . . . 17 79 3.3. SCEP pkiMessage types . . . . . . . . . . . . . . . . . . 17 80 3.3.1. PKCSReq/RenewalReq/UpdateReq . . . . . . . . . . . . 17 81 3.3.2. CertRep . . . . . . . . . . . . . . . . . . . . . . . 18 82 3.3.2.1. CertRep SUCCESS . . . . . . . . . . . . . . . . . 18 83 3.3.2.2. CertRep FAILURE . . . . . . . . . . . . . . . . . 19 84 3.3.2.3. CertRep PENDING . . . . . . . . . . . . . . . . . 19 85 3.3.3. CertPoll (GetCertInitial) . . . . . . . . . . . . . . 19 86 3.3.4. GetCert . . . . . . . . . . . . . . . . . . . . . . . 20 87 3.3.5. GetCRL . . . . . . . . . . . . . . . . . . . . . . . 21 88 3.4. Degenerate certificates-only CMS Signed-Data . . . . . . 21 89 3.5. CA Capabilities . . . . . . . . . . . . . . . . . . . . . 21 90 3.5.1. GetCACaps HTTP Message Format . . . . . . . . . . . . 21 91 3.5.2. CA Capabilities Response Format . . . . . . . . . . . 22 92 4. SCEP Transactions . . . . . . . . . . . . . . . . . . . . . . 24 93 4.1. HTTP POST and GET Message Formats . . . . . . . . . . . . 24 94 4.2. Get CA Certificate . . . . . . . . . . . . . . . . . . . 25 95 4.2.1. Get CA Certificate Response Message Format . . . . . 25 96 4.2.1.1. CA Certificate Response Message Format . . . . . 26 97 4.2.1.2. CA Certificate Chain Response Message Format . . 26 98 4.3. Certificate Enrolment/Renewal/Update . . . . . . . . . . 26 99 4.3.1. Certificate Enrolment/Renewal/Update Response Message 27 100 4.4. Poll for Client Initial Certificate . . . . . . . . . . . 27 101 4.4.1. Polling Response Message Format . . . . . . . . . . . 28 102 4.5. Certificate Access . . . . . . . . . . . . . . . . . . . 28 103 4.5.1. Certificate Access Response Message Format . . . . . 28 104 4.6. CRL Access . . . . . . . . . . . . . . . . . . . . . . . 28 105 4.6.1. CRL Access Response Message Format . . . . . . . . . 28 106 4.7. Get Next Certificate Authority Certificate . . . . . . . 28 107 4.7.1. Get Next CA Response Message Format . . . . . . . . . 29 108 5. SCEP State Transitions . . . . . . . . . . . . . . . . . . . 29 109 5.1. Successful Transactions . . . . . . . . . . . . . . . . . 30 110 5.2. Transactions with Errors . . . . . . . . . . . . . . . . 30 111 6. Contributors/Acknowledgements . . . . . . . . . . . . . . . . 33 112 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 113 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 114 8.1. General Security . . . . . . . . . . . . . . . . . . . . 34 115 8.2. Use of the CA keypair . . . . . . . . . . . . . . . . . . 34 116 8.3. Challenge Password . . . . . . . . . . . . . . . . . . . 34 117 8.4. Lack of Certificate Issue Confirmation . . . . . . . . . 35 118 8.5. GetCACaps Issues . . . . . . . . . . . . . . . . . . . . 35 119 8.6. Lack of PoP in Renewal and Update Requests . . . . . . . 35 120 8.7. Unnecessary cryptography . . . . . . . . . . . . . . . . 35 121 8.8. Use of SHA-1 . . . . . . . . . . . . . . . . . . . . . . 36 122 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 123 9.1. Normative References . . . . . . . . . . . . . . . . . . 36 124 9.2. Informative References . . . . . . . . . . . . . . . . . 37 125 Appendix A. Background Notes . . . . . . . . . . . . . . . . . . 38 126 Appendix B. Sample SCEP Messages . . . . . . . . . . . . . . . . 40 127 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 40 129 1. Introduction 131 X.509 certificates serve as the basis for several standards-based 132 security protocols such as TLS [16], S/MIME [13], and IKE/IPsec [12]. 133 When an X.509 certificate is issued there typically is a need for a 134 certificate management protocol to enable a PKI client to request a 135 certificate, certificate renewal, or certificate update from a 136 Certificate Authority (CA). 138 This specification defines a protocol, Simple Certificate Enrolment 139 Protocol (SCEP), for certificate management and certificate and CRL 140 queries. While widely deployed, this protocol omits some certificate 141 management features, e.g. certificate revocation transactions, which 142 may enhance the security achieved in a PKI. The IETF protocol suite 143 currently includes two further certificate management protocols with 144 more comprehensive functionality, Certificate Management Protocol 145 (CMP) [10] and Certificate Management over CMS (CMC) [9]. 146 Environments that do not require interoperability with SCEP 147 implementations MAY consider using the above-mentioned certificate 148 management protocols, however anyone considering this step should be 149 aware that the high level of complexity of these two protocols has 150 resulted in serious interoperability problems and corresponding lack 151 of industry support. SCEP's simplicity, while being a drawback in 152 terms of its slightly restricted functionality, also makes deployment 153 relatively straightforward, so that it enjoys widespread support and 154 ready interoperability across a range of platforms. While 155 implementers are encouraged to investigate one of the more 156 comprehensive alternative certificate management protocols in 157 addition to the protocol defined in this specification, anyone 158 wishing to deploy them should proceed with caution, and consider 159 support and interoperability issues before committing to their use. 161 The SCEP protocol supports the following general operations: 163 o CA public key distribution. 164 o Certificate enrolment and issue. 165 o Certificate renewal/update. 166 o Certificate query. 167 o CRL query. 169 SCEP makes extensive use of CMS [3] and PKCS #10 [6]. 171 1.1. Conventions Used in This Document 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in [1]. 177 2. SCEP Overview 179 This section provides a high level overview of the functionality of 180 SCEP. 182 2.1. SCEP Entities 184 The entity types defined in SCEP are a client requesting a 185 certificate and a Certificate Authority (CA) that issues the 186 certificate. These are described in the following sections. 188 2.1.1. Client 190 A client MUST have the following information locally configured: 192 1. The CA fully qualified domain name or IP address. 194 2. The CA HTTP CGI script path (this usually has a default value, 195 see Section 4.1). 196 3. The identifying information that is used for authentication of 197 the CA in Section 4.2.1, typically a certificate fingerprint. 199 2.1.2. Certificate Authority 201 A SCEP CA is the entity that signs client certificates. A CA MAY 202 enforce any arbitrary policies and apply them to certificate 203 requests, and MAY reject any request. 205 Since the client is expected to perform signature verification and 206 optionally encryption using the CA certificate, the keyUsage 207 extension in the CA certificate MUST indicate that it is valid for 208 digitalSignature and keyEncipherment (if required) alongside the 209 usual CA usages of keyCertSign and/or cRLSign. 211 2.1.3. CA Certificate Distribution 213 If the CA certificate(s) have not previously been acquired by the 214 client through some other means, the client MUST retrieve them before 215 any PKI operation (Section 3) can be started. Since no public key 216 has yet been exchanged between the client and the CA, the messages 217 cannot be secured using CMS, and the data is instead transferred in 218 the clear. 220 If an intermediate CA is in use, a certificates-only CMS Signed-Data 221 message with a certificate chain consisting of all CA certificates is 222 returned. Otherwise the CA certificate itself is returned. The 223 transport protocol (Section 4) MUST indicate which one is returned. 225 The CA certificate MAY be provided out-of-band to the client. 226 Alternatively, the CA certificate fingerprint MAY be used to 227 authenticate a CA Certificate distributed by the GetCACert response 228 (Section 4.2) or via HTTP certificate-store access [11]. The 229 fingerprint is created by calculating a SHA-256 hash over the whole 230 CA certificate (for legacy reasons, a SHA-1 hash may be used by some 231 implementations). 233 After the client gets the CA certificate, it SHOULD authenticate the 234 certificate by comparing its fingerprint with the locally configured, 235 out-of-band distributed, identifying information. Intermediate CA 236 certificates, if any, are signed by a higher-level CA so there is no 237 need to authenticate them against the out-of-band data. Clients 238 SHOULD verify intermediate-level CA certificate signatures using the 239 issuing CA's certificate before use during protocol exchanges. 241 Because a long time can pass between queries from a client to a CA 242 and because intermediate CA certificates can change over time, it is 243 recommended that a client not store intermediate CA certificates. 244 Instead, the client SHOULD retrieve them before each operation. 246 2.2. Client authentication 248 As with every protocol that uses public-key cryptography, the 249 association between the public keys used in the protocol and the 250 identities with which they are associated must be authenticated in a 251 cryptographically secure manner. The communications between the 252 client and the CA are secured using SCEP Secure Message Objects as 253 explained in Section 3, which specifies how CMS is used to encrypt 254 and sign the data. In order to perform the signing operation the 255 client uses an appropriate local certificate: 257 1. If the client does not have an appropriate existing certificate 258 then a locally generated self-signed certificate MUST be used. 259 The keyUsage extension in the certificate MUST indicate that it 260 is valid for digitalSignature and keyEncipherment (if required). 261 The self-signed certificate SHOULD use the same subject name as 262 in the PKCS #10 request. In this case the messageType is 263 PKCS10Req (see Section 3.2.1.2). 264 2. If the requesting system already has a certificate issued by the 265 SCEP CA, and the CA supports renewal (see Section 2.4), that 266 certificate SHOULD be used. In this case the messageType is 267 RenewalReq (see Section 3.2.1.2). 268 3. If the requesting system has no certificate issued by the new CA, 269 but has credentials from an alternate CA the certificate issued 270 by the alternate CA MAY be used. Policy settings on the new CA 271 will determine if the request can be accepted or not. This is 272 useful when enrolling with a new administrative domain using a 273 certificate from the old domain as credentials. In this case the 274 messageType is UpdateReq (see Section 3.2.1.2). 276 Note that although the above text describes three different types of 277 operations, in practice most implementations always apply the first 278 one even if an existing certificate already exists. For this reason 279 support for the first case is mandatory while support for the latter 280 two are optional (see Section 2.8). 282 During the certificate enrolment process, the client MUST use the 283 selected certificate's key when signing the CMS envelope (see 284 Section 3). This certificate will be either the self-signed one 285 matching the PKCS #10 request or the CA-issued one used to authorise 286 a renewal or update. If the key being certified allows encryption 287 then the CA's CertResp will use the same certificate's public key 288 when encrypting the response. 290 Note that this means that, in the case of renewal and update 291 operations, the request is signed with, and the returned response may 292 be encrypted with, the key in the previously-issued certificate used 293 to authenticate the request, not the key in the PKCS #10 request. 294 This has security implications, see Section 8.6. 296 2.3. Enrolment authorization 298 PKCS #10 [6] specifies a PKCS #9 [5] challengePassword attribute to 299 be sent as part of the enrolment request. When utilizing the 300 challengePassword, the CA distributes a shared secret to the client 301 which will uniquely associate the enrolment request with the client. 303 Inclusion of the challengePassword by the SCEP client is OPTIONAL and 304 allows for unauthenticated authorization of enrolment requests 305 (which, however, requires manual approval of each certificate issue, 306 see below), or for renewal or update requests that are authenticated 307 by being signed with an existing certificate. The CMS envelope 308 protects the privacy of the challengePassword. 310 A client that is performing certificate renewal or update as per 311 Section 2.4 SHOULD omit the challengePassword but MAY send the 312 originally distributed password in the challengePassword attribute. 313 In the former case the SCEP CA MUST authenticate the request based on 314 the certificate used to sign the renewal or update request. In the 315 latter case the SCEP CA MAY use either the challengePassword or the 316 previously issued certificate (or both), depending on CA policy, to 317 authenticate the request. The SCEP CA MUST NOT attempt to 318 authenticate a client based on a self-signed certificate unless it 319 has been verified through out-of-band means such as a certificate 320 fingerprint. 322 To perform the authorization in manual mode the client's request is 323 placed in the PENDING state until the CA operator authorizes or 324 rejects it. Manual authorization is used when the client has only a 325 self-signed certificate that hasn't been previously authenticated by 326 the CA and/or a challengePassword is not available. The SCEP CA MAY 327 either reject unauthorized requests or mark them for manual 328 authorization according to CA policy. 330 2.4. Certificate Enrolment/Renewal/Update 332 A client starts an enrolment transaction (Section 3.3.1) by creating 333 a certificate request using PKCS #10 and sends it to the CA enveloped 334 using CMS (Section 3). 336 If the CA supports certificate renewal or update and if the CA policy 337 permits then a new certificate with new validity dates can be issued 338 even though the old one is still valid. The CA MAY automatically 339 revoke the old client certificate. To renew or update an existing 340 certificate, the client uses the RenewalReq or UpdateReq message (see 341 Section 3.3) and signs it with the existing client certificate. The 342 client SHOULD use a new keypair when requesting a new certificate, 343 but MAY request a new certificate using the old keypair. 345 If the CA returns a CertRep message (Section 3.3.2) with status set 346 to PENDING, the client enters into polling mode by periodically 347 sending a CertPoll message (Section 3.3.3) to the CA until the CA 348 operator completes the manual authentication (approving or denying 349 the request). 351 If polling mode is being used then the client will send a single 352 PKCSReq/RenewalReq/UpdateReq message (Section 3.3.1), followed by 0 353 or more CertPoll messages (Section 3.3.3). The CA will in return 354 send 0 or more CertRep messages (Section 3.3.2) with status set to 355 PENDING in response to CertPolls, followed by a single CertRep 356 message (Section 3.3.2) with status set to either SUCCESS or FAILURE. 358 2.4.1. Client State Transitions 360 The client state transitions during the SCEP process are indicated in 361 Figure 1. 363 CertPoll 364 +-----<----+ 365 | | 366 | | CertRep(PENDING) 367 | | 368 [CERT-NONEXISTENT] ------> [CERT-REQ-PENDING] ---------> [CERT-ISSUED] 369 ^ PKCSReq | CertRep(SUCCESS) 370 | RenewalReq | 371 | UpdateReq | 372 | | 373 +-----------------------+ 374 CertRep(FAILURE) or 375 Max-time/max-polls exceeded 377 Figure 1: State Transition Diagram 379 The certificate issue process starts at the state CERT-NONEXISTENT. 380 Sending a PKCSReq/RenewalReq/UpdateReq message changes the state to 381 CERT-REQ-PENDING. 383 If the CA returns a CertRep message with pkiStatus set to SUCCESS 384 then the state changes to CERT-ISSUED. 386 If the CA returns a CertRep message with pkiStatus set to FAILURE or 387 there is no response then the state reverts back to CERT-NONEXISTENT. 389 If the CA returns a CertRep message with pkiStatus set to PENDING 390 then the client will keep polling by sending a CertPoll message until 391 either a CertRep message with status set to SUCCESS or FAILURE is 392 received or a timeout occurs or the maximum number of polls has been 393 exceeded. 395 A successful transaction in automatic mode: 397 CLIENT CA SERVER 399 PKCSReq: PKI cert. enrolment message 400 --------------------------------> CertRep: pkiStatus = SUCCESS 401 Certificate attached 402 <------------------------------ 403 Receive issued certificate. 405 A successful transaction in manual mode: 407 CLIENT CA SERVER 409 PKCSReq: PKI cert. enrolment message 410 --------------------------------> CertRep: pkiStatus = PENDING 411 <------------------------------ 412 CertPoll: Polling message 413 --------------------------------> CertRep: pkiStatus = PENDING 414 <------------------------------ 415 ................ ............... 417 CertPoll: Polling message 418 --------------------------------> CertRep: pkiStatus = SUCCESS 419 Certificate attached 420 <------------------------------ 421 Receive issued certificate. 423 2.5. Certificate Access 425 A certificate query message is defined for clients to retrieve a copy 426 of their own certificate from the CA. It allows clients that do not 427 store their certificates locally to obtain a copy when needed. This 428 functionality is not intended to provide a general purpose 429 certificate access service, which may be achieved via HTTP 430 certificate-store access [11] or LDAP. 432 To query a certificate from the CA, a client sends a request 433 consisting of the certificate's issuer name and serial number. This 434 assumes that the client has saved the issuer name and the serial 435 number of the issued certificate from the previous enrolment 436 transaction. The transaction to query a certificate consists of one 437 GetCert (Section 3.3.4) message and one CertRep (Section 3.3.2) 438 message, as shown below. 440 CLIENT CA SERVER 442 GetCert: PKI certificate query message 443 -------------------------------> CertRep: pkiStatus = SUCCESS 444 Certificate attached 445 <----------------------------- 446 Receive the certificate. 448 2.6. CRL Access 450 SCEP clients MAY request a CRL via one of three methods: 452 1. If the CA supports CRL Distribution Points (CRLDPs) [7], then the 453 CRL MAY be retrieved via the mechanism specified in the CRDLP. 454 2. If the CA supports HTTP certificate-store access [11], then the 455 CRL MAY be retrieved via the AuthorityInfoAcces [7] location 456 specified in the certificate. 457 3. Only if the CA does not support CRDLPs or HTTP access should a 458 CRL query be composed by creating a GetCRL message consisting of 459 the issuer name and serial number from the certificate whose 460 revocation status is being queried. 462 The CA SHOULD NOT support the GetCRL method because it does not scale 463 well due to the unnecessary cryptography (see Section 8.7) and it 464 requires the CA to be a high-availability service. 466 The message is sent to the SCEP CA in the same way as the other SCEP 467 requests. The transaction to retrieve a CRL consists of one GetCRL 468 PKI message and one CertRep PKI message, which contains only the CRL 469 (no certificates) in a degenerate certificates-only CMS Signed-Data 470 message (Section 3.4), as shown below. 472 CLIENT CA SERVER 474 GetCRL: PKI CRL query message 475 ----------------------------------> 476 CertRep: CRL attached 477 <----------------------------- 478 Receive the CRL 480 2.7. Certificate Revocation 482 SCEP does not specify a method to request certificate revocation. In 483 order to revoke a certificate, the client must contact the CA using a 484 non-SCEP defined mechanism. 486 2.8. Mandatory-to-Implement Functionality 488 At a minimum, all SCEP implementations compliant with this 489 specification MUST support GetCACaps (Section 3.5.1), GetCACert 490 (Section 4.2), PKCSReq (Section 3.3.1) (and its associated response 491 messages), communication of binary data via HTTP POST (Section 4.1), 492 and the AES and SHA-256 algorithms to secure pkiMessages 493 (Section 3.2). 495 For historical reasons implementations MAY support communications of 496 binary data via HTTP GET (Section 4.1), and the triple DES and SHA-1 497 algorithms to secure pkiMessages (Section 3.2). Implementations 498 SHOULD NOT support the obsolete and/or insecure single DES and MD5 499 algorithms used in earlier versions of this specification. 501 3. SCEP Secure Message Objects 503 CMS is a general enveloping mechanism that enables both signed and 504 encrypted transmission of arbitrary data. SCEP messages that require 505 confidentiality use two layers of CMS, as shown in Figure 2. By 506 applying both enveloping and signing transformations, the SCEP 507 message is protected both for the integrity of its end-to-end 508 transaction information and the confidentiality of its information 509 portion. Some messages do not require enveloping, in which case the 510 EnvelopedData in Figure 2 is omitted. 512 pkiMessage { 513 contentType = signedData { pkcs-7 2 }, 514 content { 515 digestAlgorithms, 516 encapsulatedContentInfo { 517 eContentType = data { pkcs-7 1 }, 518 eContent { -- pkcsPKIEnvelope, optional 519 contentType = envelopedData { pkcs-7 3 }, 520 content { 521 recipientInfo, 522 encryptedContentInfo { 523 contentType = data { pkcs-7 1 }, 524 contentEncrAlgorithm, 525 encryptedContent { 526 messageData -- Typically PKCS #10 request 527 } 528 } 529 } 530 } 531 }, 532 certificates, -- Optional 533 crls, -- Optional 534 signerInfo { 535 signedAttrs { 536 transactionID, 537 messageType, 538 pkiStatus, 539 failInfo, -- Optional 540 senderNonce / recipientNonce, 541 }, 542 signature 543 } 544 } 545 } 547 Figure 2: CMS Layering 549 When a particular SCEP message carries data, this data is carried in 550 the messageData. CertRep messages will lack any signed content and 551 consist only of a pkcsPKIEnvelope (Section 3.2.2). 553 The remainder of this document will refer only to 'messageData', but 554 it is understood to always be encapsulated in the pkcsPKIEnvelope 555 (Section 3.2.2). The format of the data in the messageData is 556 defined by the messageType attribute (see Section 3.2) of the Signed- 557 Data. If there is no messageData to be transmitted, the entire 558 pkcsPKIEnvelope MUST be omitted. 560 3.1. SCEP Message Object Processing 562 Creating a SCEP message consists of several stages. The content to 563 be conveyed (in other words the messageData) is first encrypted, and 564 the encrypted content is then signed. 566 The form of encryption to be applied depends on the capabilities of 567 the recipient's public key. If the key is encryption-capable (for 568 example RSA) then the messageData is encrypted using the recipient's 569 public key with the CMS KeyTransRecipientInfo mechanism. If the key 570 is not encryption-capable (for example ECDSA) then the messageData is 571 encrypted using the challengePassword with the CMS 572 PasswordRecipientInfo mechanism. 574 Once the messageData has been encrypted, it is signed with the 575 sender's public key. This completes the SCEP message that is then 576 sent to the recipient. 578 Note that some earlier implementations of this specification dealt 579 with non-encryption-capable keys by omitting the encryption stage, 580 based on the text in Section 3 that indicated that "the EnvelopedData 581 is omitted". This alternative processing mechanism SHOULD NOT be 582 used since it exposes the challengePassword used to authorise the 583 certificate issue. 585 3.2. SCEP pkiMessage 587 The basic building block of all secured SCEP messages is the SCEP 588 pkiMessage. It consists of a CMS Signed-Data content type. The 589 following restrictions apply: 591 o The eContentType in encapsulatedContentInfo MUST be data ({pkcs-7 592 1}). 593 o The signed content, if present (FAILURE and PENDING CertRep 594 messages will lack any signed content), MUST be a pkcsPKIEnvelope 595 (Section 3.2.2), and MUST match the messageType attribute. 596 o The SignerInfo MUST contain a set of authenticatedAttributes 597 (Section 3.2.1). 599 3.2.1. Signed Transaction Attributes 601 At a minimum, all messages MUST contain the following 602 authenticatedAttributes: 604 o A transactionID attribute (see Section 3.2.1.1). 605 o A messageType attribute (see Section 3.2.1.2). 606 o A fresh senderNonce attribute (see Section 3.2.1.5). 607 o Any attributes required by CMS. 609 If the message is a CertRep, it MUST also include the following 610 authenticatedAttributes: 612 o A pkiStatus attribute (see Section 3.2.1.3). 613 o A failInfo attribute (see Section 3.2.1.4) if pkiStatus = FAILURE. 614 o A recipientNonce attribute (see Section 3.2.1.5) copied from the 615 senderNonce in the request that this is a response to. 617 The following transaction attributes are encoded as authenticated 618 attributes, and are carried in the SignerInfo for this Signed-Data. 620 +----------------+-----------------+--------------------------------+ 621 | Attribute | Encoding | Comment | 622 +----------------+-----------------+--------------------------------+ 623 | transactionID | PrintableString | Unique ID for this transaction | 624 | | | as a text string | 625 | | | | 626 | messageType | PrintableString | Decimal value as a numeric | 627 | | | text string | 628 | | | | 629 | pkiStatus | PrintableString | Decimal value as a numeric | 630 | | | text string | 631 | | | | 632 | failInfo | PrintableString | Decimal value as a numeric | 633 | | | text string | 634 | | | | 635 | senderNonce | OCTET STRING | Random nonce as a 16-byte | 636 | | | binary data string | 637 | | | | 638 | recipientNonce | OCTET STRING | Random nonce as a 16-byte | 639 | | | binary data string | 640 +----------------+-----------------+--------------------------------+ 641 The OIDs used for these attributes are as follows: 643 +-------------------+-----------------------------------------------+ 644 | Name | ASN.1 Definition | 645 +-------------------+-----------------------------------------------+ 646 | id-VeriSign | OBJECT_IDENTIFIER ::= {2 16 US(840) 1 | 647 | | VeriSign(113733)} | 648 | | | 649 | id-pki | OBJECT_IDENTIFIER ::= {id-VeriSign pki(1)} | 650 | | | 651 | id-attributes | OBJECT_IDENTIFIER ::= {id-pki attributes(9)} | 652 | | | 653 | id-transactionID | OBJECT_IDENTIFIER ::= {id-attributes | 654 | | transactionID(7)} | 655 | | | 656 | id-messageType | OBJECT_IDENTIFIER ::= {id-attributes | 657 | | messageType(2)} | 658 | | | 659 | id-pkiStatus | OBJECT_IDENTIFIER ::= {id-attributes | 660 | | pkiStatus(3)} | 661 | | | 662 | id-failInfo | OBJECT_IDENTIFIER ::= {id-attributes | 663 | | failInfo(4)} | 664 | | | 665 | id-senderNonce | OBJECT_IDENTIFIER ::= {id-attributes | 666 | | senderNonce(5)} | 667 | | | 668 | id-recipientNonce | OBJECT_IDENTIFIER ::= {id-attributes | 669 | | recipientNonce(6)} | 670 +-------------------+-----------------------------------------------+ 672 The attributes are detailed in the following sections. 674 3.2.1.1. transactionID 676 A PKI operation is a transaction consisting of the messages exchanged 677 between a client and the CA. The transactionID is a text string 678 generated by the client when starting a transaction. The client MUST 679 generate a unique string as the transaction identifier, encoded as a 680 PrintableString, which MUST be used for all PKI messages exchanged 681 for a given operation such as a certificate issue. 683 3.2.1.2. messageType 685 The messageType attribute specifies the type of operation performed 686 by the transaction. This attribute MUST be included in all PKI 687 messages. The following message types are defined: 689 o CertRep ("3") -- Response to certificate or CRL request. 690 o RenewalReq ("17") -- PKCS #10 certificate request for renewal of 691 an existing certificate. 692 o UpdateReq ("18") -- PKCS #10 certificate request for update of a 693 certificate issued by a different CA. 694 o PKCSReq ("19") -- PKCS #10 certificate request. 695 o CertPoll ("20") -- Certificate polling in manual enrolment. 696 o GetCert ("21") -- Retrieve a certificate. 697 o GetCRL ("22") -- Retrieve a CRL. 699 Undefined message types MUST BE treated as an error. 701 3.2.1.3. pkiStatus 703 All response messages MUST include transaction status information, 704 which is defined as a pkiStatus attribute: 706 o SUCCESS ("0") -- Request granted. 707 o FAILURE ("2") -- Request rejected. In this case the failInfo 708 attribute, as defined in Section 3.2.1.4, MUST also be present. 709 o PENDING ("3") -- Request pending for manual approval. 711 Undefined pkiStatus attributes MUST be treated as an error. 713 3.2.1.4. failInfo 715 The failInfo attribute MUST contain one of the following failure 716 reasons: 718 o badAlg ("0") -- Unrecognized or unsupported algorithm. 719 o badMessageCheck ("1") -- Integrity check (meaning signature 720 verification of the CMS message) failed. 721 o badRequest ("2") -- Transaction not permitted or supported. 722 o badTime ("3") -- The signingTime attribute from the CMS 723 authenticatedAttributes was not sufficiently close to the system 724 time (this failure code is present for legacy reasons and is 725 unlikely to be encountered in practice). 726 o badCertId ("4") -- No certificate could be identified matching the 727 provided criteria. 729 [Question: Is there any demand for a free-form UTF8String 730 attribute to explain what really went wrong? Trying to sort 731 out an error when all you ever get back is the near-universal 732 badRequest is almost impossible, adding a failInfoText 733 attribute to address this could be quite useful since it 734 would allow expressing information such as a failure to meet 735 CA policy, or indeed anything more complex than "no go away"]. 737 Undefined failInfo attributes are treated as an error. 739 3.2.1.5. senderNonce and recipientNonce 741 The senderNonce and recipientNonce attributes are a 16 byte random 742 number generated for each transaction. These are intended to prevent 743 replay attacks. 745 When a sender sends a PKI message to a recipient, a fresh senderNonce 746 MUST be included in the message. The recipient MUST copy the 747 senderNonce into the recipientNonce of the reply as a proof of 748 liveliness. The original sender MUST verify that the recipientNonce 749 of the reply matches the senderNonce it sent in the request. If the 750 nonce does not match, the message MUST be rejected. 752 Note that since SCEP exchanges consist of a single request followed 753 by a single response, the use of distinct sender and recipient nonces 754 is redundant since the client sends a nonce in its request and the CA 755 responds with the same nonce in its reply. In effect there's just a 756 single nonce, identified as senderNonce in the client's request and 757 recipientNonce in the CA's reply. 759 3.2.2. SCEP pkcsPKIEnvelope 761 The information portion of a SCEP message is carried inside an 762 EnvelopedData content type, as defined in CMS, with the following 763 restrictions: 765 o contentType in encryptedContentInfo MUST be data ({pkcs-7 1}). 766 o encryptedContent MUST be the SCEP message being transported (see 767 Section 4), and must match the messageType authenticated Attribute 768 in the pkiMessage. 770 3.3. SCEP pkiMessage types 772 All of the messages in this section are pkiMessages (Section 3.2), 773 where the type of the message MUST be specified in the 'messageType' 774 authenticated Attribute. Each section defines a valid message type, 775 the corresponding messageData formats, and mandatory authenticated 776 attributes for that type. 778 3.3.1. PKCSReq/RenewalReq/UpdateReq 780 The messageData for this type consists of a PKCS #10 Certificate 781 Request. The certificate request MUST contain at least the following 782 items: 784 o The subject Distinguished Name. 786 o The subject public key. 787 o For a PKCSReq and if authorisation based on a password is being 788 used, a challengePassword attribute. 790 In addition to the authenticatedAttributes required for a valid CMS 791 message, the pkiMessage MUST include the following attributes: 793 o A transactionID attribute (Section 3.2.1.1). 794 o A messageType attribute (Section 3.2.1.2) set to PKCSReq, 795 RenewalReq, or UpdateReq as appropriate. 796 o A fresh senderNonce attribute (Section 3.2.1.5). 798 3.3.2. CertRep 800 The messageData for this type consists of a degenerate certificates- 801 only CMS Signed-Data message (Section 3.4). The exact content 802 required for the reply depends on the type of request that this 803 message is a response to. The request types are detailed in 804 Section 3.3.2.1 and in Section 4. 806 In addition to the authenticatedAttributes required for a valid CMS 807 message, this pkiMessage MUST include the following attributes: 809 o The transactionID attribute (Section 3.2.1.1) copied from the 810 request that this is a response to. 811 o A messageType attribute (Section 3.2.1.2) set to CertRep. 812 o A recipientNonce attribute (Section 3.2.1.5) copied from the 813 senderNonce in the request that this is a response to. 814 o A pkiStatus attribute (Section 3.2.1.3) set to the status of the 815 reply. 817 Earlier versions of this specification required that this message 818 include a senderNonce alongside the recipientNonce, which was to be 819 used to chain to subsequent polling operations. However if a single 820 message was lost during the potentially extended interval over which 821 polling could take place (see Section 5 for an example of this) then 822 if the implementation were to enforce this requirement the overall 823 transaction would fail even though nothing had actually gone wrong. 824 Because of this issue, implementations mostly ignored the requirement 825 to carry this nonce over to subsequent polling messages or to verify 826 its presence. Current versions of the specification no longer 827 require the chaining of nonces across polling operations. 829 3.3.2.1. CertRep SUCCESS 831 When the pkiStatus attribute is set to SUCCESS, the messageData for 832 this message consists of a degenerate certificates-only CMS Signed- 833 Data message (Section 3.4). The content of this degenerate 834 certificates-only Signed-Data depends on what the original request 835 was, as outlined below. 837 +--------------+----------------------------------------------------+ 838 | Request-type | Reply-contents | 839 +--------------+----------------------------------------------------+ 840 | PKCSReq | The reply MUST contain at least the issued | 841 | | certificate in the certificates field of the | 842 | | Signed-Data. The reply MAY contain additional | 843 | | certificates, but the issued certificate MUST be | 844 | | the leaf certificate. | 845 | | | 846 | RenewalReq | Same as PKCSReq | 847 | | | 848 | UpdateReq | Same as PKCSReq | 849 | | | 850 | CertPoll | Same as PKCSReq | 851 | | | 852 | GetCert | The reply MUST contain at least the requested | 853 | | certificate in the certificates field of the | 854 | | Signed-Data. The reply MAY contain additional | 855 | | certificates, but the requested certificate MUST | 856 | | be the leaf certificate. | 857 | | | 858 | GetCRL | The reply MUST contain the CRL in the crls field | 859 | | of the Signed-Data. | 860 +--------------+----------------------------------------------------+ 862 3.3.2.2. CertRep FAILURE 864 When the pkiStatus attribute is set to FAILURE, the reply MUST also 865 contain a failInfo (Section 3.2.1.4) attribute set to the appropriate 866 error condition describing the failure. The pkcsPKIEnvelope 867 (Section 3.2.2) MUST be omitted. 869 3.3.2.3. CertRep PENDING 871 When the pkiStatus attribute is set to PENDING, the pkcsPKIEnvelope 872 (Section 3.2.2) MUST be omitted. 874 3.3.3. CertPoll (GetCertInitial) 876 This message is used for certificate polling. For unknown reasons it 877 was referred to as "GetCertInitial" in earlier versions of this 878 specification. The messageData for this type consists of an 879 IssuerAndSubject: 881 issuerAndSubject ::= SEQUENCE { 882 issuer Name, 883 subject Name 884 } 886 The issuer is set to the subjectName of the CA (in other words the 887 intended issuerName of the certificate that's being requested). The 888 subject is set to the subjectName used when requesting the 889 certificate. 891 Note that both of these fields are redundant, the CA is identified by 892 the recipientInfo in the pkcsPKIEnvelope (or in most cases simply by 893 the server that the message is being sent to) and the client/ 894 transaction being polled is identified by the transactionID. Both of 895 these fields can be processed by the CA without having to unwrap and 896 process the issuerAndSubject. For this reason implementations SHOULD 897 assume that the polling operation will be controlled by the 898 recipientInfo and transactionID rather than the contents of the 899 messageData. 901 In addition to the authenticatedAttributes required for a valid CMS 902 message, this pkiMessage MUST include the following attributes: 904 o The same transactionID (Section 3.2.1.1) attribute from the 905 original PKCSReq/RenewalReq/UpdateReq message. 906 o A messageType attribute (Section 3.2.1.2) set to CertPoll. 907 o A fresh senderNonce attribute (Section 3.2.1.5). 909 3.3.4. GetCert 911 The messageData for this type consists of an IssuerAndSerialNumber as 912 defined in CMS which uniquely identifies the certificate being 913 requested. In addition to the authenticatedAttributes required for a 914 valid CMS message, this pkiMessage MUST include the following 915 attributes: 917 o A transactionID attribute (Section 3.2.1.1). 918 o A messageType attribute (Section 3.2.1.2) set to GetCert. 919 o A fresh senderNonce attribute (Section 3.2.1.5). 921 A self-signed certificate MAY be used in the signed envelope. This 922 enables the client to request their own certificate if they were 923 unable to store it previously. 925 This message type, while included here for completeness, applies 926 unnecessary cryptography and messaging overhead to the simple task of 927 transferring a certificate (see Section 8.7). Implementations SHOULD 928 prefer HTTP certificate-store access [11] or LDAP over the use of 929 this message. 931 3.3.5. GetCRL 933 The messageData for this type consists of a IssuerAndSerialNumber as 934 defined in CMS containing the issuer name and serial number of the 935 certificate whose revocation status is being checked. 937 In addition to the authenticatedAttributes required for a valid CMS 938 message, this pkiMessage MUST include the following attributes: 940 o A transactionID attribute (Section 3.2.1.1). 941 o A messageType attribute (Section 3.2.1.2) set to GetCRL. 942 o A fresh senderNonce attribute (Section 3.2.1.5). 944 This message type, while included here for completeness, applies 945 unnecessary cryptography and messaging overhead to the simple task of 946 transferring a CRL (see Section 8.7). Implementations SHOULD prefer 947 HTTP certificate-store access [11] or LDAP over the use of this 948 message. 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 970 This message requests capabilities from a CA, with the format: 972 "GET" CGI-PATH CGI-PROG "?operation=GetCACaps" 973 with the message components as described in Section 4. 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.8. | 1007 | | | 1008 | "Update" | CA supports the Update CA operation. | 1009 +--------------------+----------------------------------------------+ 1011 The client SHOULD use SHA-256 in preference to SHA-1 hashing and AES 1012 in preference to triple DES if they are supported by the CA. 1013 Although the CMS format allows any form of SHA-2 and AES to be 1014 specified, in the interests of interoperability the de facto 1015 universal standards of AES128-CBC and SHA-256 SHOULD be used. 1017 Announcing some of these capabilities individually is redundant since 1018 they're required as mandatory-to-implement functionality (see 1019 Section 2.8) whose presence as a whole is signalled by the 1020 "SCEPStandard" capability, but it may be useful to announce them in 1021 order to deal with old implementations that would otherwise default 1022 to obsolete, insecure algorithms and mechanisms. 1024 The CA MUST use the text case specified here, but clients SHOULD 1025 ignore the text case when processing this message. Clients MUST 1026 accept the standard HTTP-style -delimited text as well as the 1027 - delimited text specified in an earlier version of this 1028 specification. A client MUST be able to accept and ignore any 1029 unknown keywords that might be sent back by a CA. 1031 If the CA supports none of the above capabilities it SHOULD return an 1032 empty message. A CA MAY simply return an HTTP error. A client that 1033 receives an empty message or an HTTP error SHOULD interpret the 1034 response as if none of the requested capabilities are supported by 1035 the CA. 1037 (Note that at least one widely-deployed server implementation 1038 supports several of the above operations but doesn't support the 1039 GetCACaps message to indicate that it supports them, and will close 1040 the connection if sent a GetCACaps message. This means that the 1041 equivalent of GetCACaps must be performed through server 1042 fingerprinting, which can be done using the ID string "Microsoft- 1043 IIS". Newer versions of the same server, if sent a SCEP request 1044 using AES and SHA-2, will respond with an invalid response that can't 1045 be decrypted, requiring the use of 3DES and SHA-1 in order to obtain 1046 a response that can be processed even if AES and/or SHA-2 are 1047 allegedly supported. In addition the server will generate CA 1048 certificates that only have one, but not both, of the keyEncipherment 1049 and digitalSignature keyUsage flags set, requiring that the client 1050 ignore the keyUsage flags in order to use the certificates for SCEP). 1052 The Content-type of the reply SHOULD be "text/plain". Clients SHOULD 1053 ignore the Content-type, as older implementations of SCEP may send 1054 various Content-types. 1056 Example: 1058 GET /cgi-bin/pkiclient.exe?operation=GetCACaps 1059 might return: 1061 AES 1062 GetNextCACert 1063 POSTPKIOperation 1064 SCEPStandard 1065 SHA-256 1067 This means that the CA supports modern crypto algorithms, the 1068 GetNextCACert message, allows PKIOperation messages 1069 (PKCSReq/RenewalReq/UpdateReq, GetCert, CertPoll, ...) to be sent 1070 using HTTP POST, and is compliant with the final version of the SCEP 1071 standard. 1073 4. SCEP Transactions 1075 This section describes the SCEP Transactions and their HTTP [4] 1076 transport mechanism. 1078 4.1. HTTP POST and GET Message Formats 1080 SCEP uses the HTTP "POST" and "GET" messages to exchange information 1081 with the CA. The following defines the syntax of HTTP POST and GET 1082 messages sent from a client to a CA: 1084 "POST" CGI-PATH CGI-PROG "?operation=" OPERATION 1085 "GET" CGI-PATH CGI-PROG "?operation=" OPERATION "&message=" MESSAGE 1087 where: 1089 o CGI-PATH defines the path to invoke the CGI program that parses 1090 the request. 1091 o CGI-PROG is set to be the string "pkiclient.exe". This is 1092 intended to be the program that the CA will use to handle the SCEP 1093 transactions. 1094 o OPERATION depends on the SCEP transaction and is defined in the 1095 following sections. 1097 The CA will typically ignore CGI-PATH and/or CGI-PROG since it's 1098 unlikely to be issuing certificates via a web server. Clients SHOULD 1099 set CGI-PATH/CGI-PROG to the fixed string "/cgi-bin/pkiclient.exe" 1100 unless directed to do otherwise to by the CA. 1102 Early SCEP drafts performed all communications via "GET" messages, 1103 including non-idempotent ones that should have been sent via "POST" 1104 messages. This has caused problems because of the way that the 1105 (supposedly) idempotent GET interacts with caches and proxies, and 1106 because the extremely large GET requests created by encoding CMS 1107 messages may be truncated in transit. These issues are typically not 1108 visible when testing on a LAN, but crop up during deployment over 1109 WANs. If the remote CA supports it, any of the CMS-encoded SCEP 1110 messages SHOULD be sent via HTTP POST instead of HTTP GET. This 1111 applies to any SCEP message except GetCACert, GetNextCACert, and 1112 GetCACaps, and avoids the need for base64- and URL-encoding that's 1113 required for GET messaging. The client can verify that the CA 1114 supports SCEP messages via POST by looking for the "POSTPKIOperation" 1115 capability (See Section 3.5.2). 1117 If a client or CA uses HTTP GET and encounters HTTP-related problems 1118 such as messages being truncated, seeing errors such as HTTP 414 1119 ("Request URI too long"), or simply having the message not sent/ 1120 received at all, when standard requests to the server (for example 1121 via a web browser) work, then this is a symptom of the problematic 1122 use of HTTP GET. The solution to this problem is typically to move 1123 to HTTP POST instead. In addition when using GET it's recommended to 1124 test your implementation over the public internet from as many 1125 locations as possible to determine whether the use of GET will cause 1126 problems with communications. 1128 When using GET messages to communicate binary data, base64 encoding 1129 as specified in [2] MUST be used. The base64 encoded data is 1130 distinct from "base64url" and may contain URI reserved characters, 1131 thus it MUST be escaped as specified in [8] in addition to being 1132 base64 encoded. Finally, the encoded data is inserted into the 1133 MESSAGE portion of the HTTP GET request. 1135 4.2. Get CA Certificate 1137 To get the CA certificate(s), the client sends a GetCACert message to 1138 the CA. The OPERATION MUST be set to "GetCACert". There is no 1139 request data associated with this message. 1141 4.2.1. Get CA Certificate Response Message Format 1143 The response for GetCACert is different between the case where the CA 1144 directly communicates with the client during the enrolment, and the 1145 case where an intermediate CA exists and the client communicates with 1146 this CA during the enrolment. 1148 4.2.1.1. CA Certificate Response Message Format 1150 If the CA does not have any intermediate CA certificates, the 1151 response consists of a single X.509 CA certificate. The response 1152 will have a Content-Type of "application/x-x509-ca-cert". 1154 "Content-Type: application/x-x509-ca-cert" 1156 1158 4.2.1.2. CA Certificate Chain Response Message Format 1160 If the CA has intermediate CA certificates, the response consists of 1161 a degenerate certificates-only CMS Signed-Data message (Section 3.4) 1162 containing the certificates, with the intermediate CA certificate(s) 1163 as the leaf certificate(s). The response will have a Content-Type of 1164 "application/x-x509-ca-ra-cert". Note that this designation is used 1165 for historical reasons due to its use in older versions of this 1166 specification, no special meaning should be attached to the label. 1168 "Content-Type: application/x-x509-ca-ra-cert" 1170 1172 4.3. Certificate Enrolment/Renewal/Update 1174 A PKCSReq/RenewalReq/UpdateReq (Section 3.3.1) message is used to 1175 perform a certificate enrolment, renewal, or update transaction. The 1176 OPERATION MUST be set to "PKIOperation". Note that when used with 1177 HTTP POST, the only OPERATION possible is "PKIOperation", so many CAs 1178 don't check this value or even notice its absence. When implemented 1179 using HTTP POST the message might look as follows: 1181 POST /cgi-bin/pkiclient.exe?operation=PKIOperation HTTP/1.1 1182 Content-Length: 1184 1186 When implemented using HTTP GET this might look as follows: 1188 GET /cgi-bin/pkiclient.exe?operation=PKIOperation& \ 1189 message=MIAGCSqGSIb3DQEHA6CAMIACAQAxgDCBzAIBADB2MG \ 1190 IxETAPBgNVBAcTCE......AAAAAA== HTTP/1.1 1192 4.3.1. Certificate Enrolment/Renewal/Update Response Message 1194 If the request is granted, a CertRep message (Section 3.3.2) with 1195 pkiStatus set to SUCCESS is returned. The reply MUST also contain 1196 the certificate (and MAY contain any other certificates needed by the 1197 client). The issued certificate MUST be the first in the list. 1199 If the request is rejected, a CertRep message (Section 3.3.2) with 1200 pkiStatus set to FAILURE is returned. The reply MUST also contain a 1201 failInfo attribute. 1203 If the the CA is configured to manually authenticate the client, a 1204 CertRep message (Section 3.3.2) with pkiStatus set to PENDING MAY be 1205 returned. The CA MAY return a PENDING for other reasons. 1207 The response will have a Content-Type of "application/x-pki-message". 1209 "Content-Type: application/x-pki-message" 1211 1213 4.4. Poll for Client Initial Certificate 1215 When the client receives a CertRep message with pkiStatus set to 1216 PENDING, it will enter the polling state by periodically sending 1217 CertPoll messages to the CA until either the request is granted and 1218 the certificate is sent back or the request is rejected or some 1219 preconfigured time limit for polling or maximum number of polls is 1220 exceeded. The OPERATION MUST be set to "PKIOperation". 1222 CertPoll messages exchanged during the polling period MUST carry the 1223 same transactionID attribute as the previous PKCSReq/RenewalReq/ 1224 UpdateReq. A CA receiving a CertPoll for which it does not have a 1225 matching PKCSReq/RenewalReq/UpdateReq MUST ignore this request. 1227 Since at this time the certificate has not been issued, the client 1228 can only use its own subject name (which was contained in the 1229 original PKCS# 10 sent via PKCSReq/RenewalReq/UpdateReq) to identify 1230 the polled certificate request (but see the note on identification 1231 during polling in Section 3.3.3). In theory there can be multiple 1232 outstanding requests from one client (for example, if different keys 1233 and different key-usages were used to request multiple certificates), 1234 so the transactionID must also be included to disambiguate between 1235 multiple requests. In practice however it's safer for the client to 1236 not have multiple requests outstanding at any one time, since this 1237 tends to confuse some CAs. 1239 4.4.1. Polling Response Message Format 1241 The response messages for CertPoll are the same as in Section 4.3.1. 1243 4.5. Certificate Access 1245 A client can query an issued certificate from the SCEP CA, as long as 1246 the client knows the issuer name and the issuer assigned certificate 1247 serial number. 1249 This transaction consists of one GetCert (Section 3.3.4) message sent 1250 to the CA by a client, and one CertRep (Section 3.3.2) message sent 1251 back from the CA. The OPERATION MUST be set to "PKIOperation". 1253 4.5.1. Certificate Access Response Message Format 1255 In this case, the CertRep from the CA is same as in Section 4.3.1, 1256 except that the CA will either grant the request (SUCCESS) or reject 1257 it (FAILURE). 1259 4.6. CRL Access 1261 Clients can request a CRL from the SCEP CA as described in 1262 Section 2.6. The OPERATION MUST be set to "PKIOperation". 1264 4.6.1. CRL Access Response Message Format 1266 The CRL is sent back to the client in a CertRep (Section 3.3.2) 1267 message. The information portion of this message is a degenerate 1268 certificates-only Signed-Data (Section 3.4) that contains only the 1269 most recent CRL in the crls field of the Signed-Data. 1271 4.7. Get Next Certificate Authority Certificate 1273 When a CA certificate expires then, depending on client and CA 1274 policy, certificates that have been signed by it may no longer be 1275 regarded as valid. CA key rollover provides a mechanism by which the 1276 CA MAY distribute a new CA certificate which is valid in the future 1277 once the current certificate has expired. When a CA certificate is 1278 about to expire, clients need to retrieve the CA's next CA 1279 certificate (i.e. the rollover certificate). This is done via the 1280 GetNextCACert message. The OPERATION MUST be set to "GetNextCACert". 1281 There is no request data associated with this message. 1283 Clients MAY store the not-yet-valid CA certificate, and any not-yet- 1284 valid client certificates obtained, until such time that they are 1285 valid, at which point clients switch over to using the newly valid 1286 certificates (but see the note in Section 2.1.3 about storing CA 1287 certificates). 1289 4.7.1. Get Next CA Response Message Format 1291 The response consists of a Signed-Data CMS message, signed by the 1292 current CA signing key. Clients MUST validate the signature on the 1293 message before accepting any of its contents. The response will have 1294 a Content-Type of "application/x-x509-next-ca-cert". 1296 "Content-Type: application/x-x509-next-ca-cert" 1298 1300 The content of the Signed-Data message is a degenerate certificates- 1301 only Signed-Data message (Section 3.4) containing the new CA 1302 certificate(s) to be used when the current CA certificate expires. 1304 If the CA does not have rollover certificate(s) it MUST reject the 1305 request. It SHOULD also remove the GetNextCACert setting from the CA 1306 capabilities returned by GetCACaps until it does have rollover 1307 certificates. 1309 5. SCEP State Transitions 1311 The following section gives several examples of client to CA 1312 transactions. Client actions are indicated in the left column, CA 1313 actions are indicated in the right column, and the transactionID is 1314 given in parentheses. The first transaction, for example, would read 1315 like this: 1317 "Client Sends PKCSReq message with transactionID 1 to the CA. The CA 1318 signs the certificate and constructs a CertRep Message containing the 1319 signed certificate with a transaction ID 1. The client receives the 1320 message and installs the certificate locally". 1322 5.1. Successful Transactions 1324 Successful Enrolment Case: Automatic processing 1326 PKCSReq (1) ----------> CA issues certificate 1327 <---------- CertRep (1) SUCCESS 1328 Client installs certificate 1330 Successful Enrolment Case: Manual authentication required 1332 PKCSReq (2) ----------> Cert request goes into queue 1333 <---------- CertRep (2) PENDING 1334 CertPoll (2) ----------> Still pending 1335 <---------- CertRep (2) PENDING 1336 CertPoll (2) ----------> CA issues certificate 1337 <---------- CertRep (2) SUCCESS 1338 Client installs certificate 1340 CA certificate rollover case: 1342 GetNextCACert ----------> 1343 <---------- New CA certificate 1345 PKCSReq* ----------> CA issues certificate with 1346 new key 1347 <---------- CertRep SUCCESS 1348 Client stores certificate 1349 for installation when 1350 existing certificate expires. 1352 * Enveloped for the new CA certificate. The CA will use the envelope 1353 to determine which key to use to issue the client certificate. 1355 5.2. Transactions with Errors 1357 In the case of polled transactions that aren't completed 1358 automatically, there are two potential options for dealing with a 1359 transaction that's interrupted due to network or software/hardware 1360 issues. The first is for the client to preserve its transaction 1361 state and resume the CertPoll polling when normal service is 1362 restored. The second is for the client to begin a new transaction by 1363 sending a new PKCSReq/RenewalReq/UpdateReq rather than continuing the 1364 previous CertPoll. Both options have their own advantages and 1365 disadvantages. 1367 The CertPoll continuation requires that the client maintain its 1368 transaction state for then time when it resumes polling. This is 1369 relatively simple if the problem is a brief network outage, but less 1370 simple when the problem is a client crash and restart. In addition 1371 the CA may treat a lost network connection as the end of a 1372 transaction, so that a new connection followed by a CertPoll will be 1373 treated as an error. 1375 The PKCSReq/RenewalReq/UpdateReq continuation doesn't require any 1376 state to be maintained since it's a new transaction, however it may 1377 cause problems on the CA side if the certificate was successfully 1378 issued but the client never received it, since the resumed 1379 transaction attempt will appear to be a request for a duplicate 1380 certificate (see Section 8.4 for more on why this is a problem). In 1381 this case the CA may refuse the transaction, or require manual 1382 intervention to remove/revoke the previous certificate before the 1383 client can request another one. 1385 Since the new-transaction resume is more robust in the presence of 1386 errors and doesn't require special-case handling by either the client 1387 or CA, clients SHOULD use the new-transaction option in preference to 1388 the resumed-CertPoll option to recover from errors. 1390 Resync Case 1: Client resyncs via new PKCSReq (recommended): 1392 PKCSReq (3) ----------> Cert request goes into queue 1393 <---------- CertRep (3) PENDING 1394 CertPoll (3) ----------> Still pending 1395 X-------- CertRep(3) PENDING 1396 (Network outage) 1397 (Client reconnects) 1398 PKCSReq (4) ----------> 1399 <---------- CertRep (4) PENDING 1400 etc... 1402 Resync Case 2: Client resyncs via resumed CertPoll after a network 1403 outage (not recommended, use PKCSReq to resync): 1405 PKCSReq (5) ----------> Cert request goes into queue 1406 <---------- CertRep (5) PENDING 1407 CertPoll (5) ----------> Still pending 1408 X-------- CertRep(5) PENDING 1409 (Network outage) 1410 (Client reconnects) 1411 CertPoll (5) ----------> CA issues certificate 1412 <---------- CertRep (5) SUCCESS 1413 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 1433 Resync Case 4: Special-case variation of case 1 where the CertRep 1434 SUCCESS rather than the CertRep PENDING is lost (not recommended, use 1435 PKCSReq to resync): 1437 PKCSReq (8) ----------> Cert request goes into queue 1438 <---------- CertRep (8) PENDING 1439 CertPoll (8) ----------> Still pending 1440 <---------- CertRep (8) PENDING 1441 CertPoll (8) ----------> CA issues certificate 1442 X-------- CertRep(8) SIGNED CERT 1443 (Network outage) 1444 (Client reconnects) 1445 CertPoll (8) ----------> Certificate already issued 1446 <---------- CertRep (8) SUCCESS 1447 Client installs certificate 1449 As these examples indicate, resumption from an error via a resumed 1450 CertPoll is tricky due to the state that needs to be held by both the 1451 client and/or the CA. A PKCSReq/RenewalReq/UpdateReq resume is the 1452 easiest to implement since it's stateless and is identical for both 1453 polled and non-polled transactions, while a CertPoll resume treats 1454 the two differently (a non-polled transaction is resumed with a 1455 PKCSReq/RenewalReq/UpdateReq, a polled transaction is resumed with a 1456 CertPoll). For this reason this specification recommends that error 1457 recovery be handled via a new PKCSReq rather than a resumed CertPoll. 1459 6. Contributors/Acknowledgements 1461 The editor would like to thank all of the previous editors, authors 1462 and contributors: Cheryl Madson, Xiaoyi Liu, David McGrew, David 1463 Cooper, Andy Nourse, Max Pritikin, Jan Vilhuber, and others for their 1464 work maintaining the draft over the years. Numerous other people 1465 have contributed during the long life cycle of the draft and all 1466 deserve thanks. In addition several PKCS #7 / CMS libraries 1467 contributed to interoperability by doing the right thing despite what 1468 earlier SCEP drafts required. 1470 The earlier authors would like to thank Peter William of ValiCert, 1471 Inc. (formerly of VeriSign, Inc.) and Alex Deacon of VeriSign, Inc. 1472 and Christopher Welles of IRE, Inc. for their contributions to early 1473 versions of this protocol and this document. 1475 7. IANA Considerations 1477 This memo includes no request to IANA. 1479 8. Security Considerations 1481 The security goal of SCEP is that no adversary can subvert the public 1482 key/identity binding from that intended. An adversary is any entity 1483 other than the client and the CA participating in the protocol. 1485 This goal is met through the use of CMS and PKCS #10 encryption and 1486 digital signatures using authenticated public keys. The CA's public 1487 key is authenticated via out-of-band means such as the checking of 1488 the CA fingerprint and the SCEP client's public key is authenticated 1489 through manual or pre-shared secret authentication. 1491 8.1. General Security 1493 Common key-management considerations such as keeping private keys 1494 truly private and using adequate lengths for symmetric and asymmetric 1495 keys must be followed in order to maintain the security of this 1496 protocol. This is especially true for CA keys which, when 1497 compromised, compromise the security of all relying parties. 1499 8.2. Use of the CA keypair 1501 A CA key pair is generally meant for, and is usually flagged as, 1502 being usable for certificate (and CRL) signing exclusively rather 1503 than data signing or encryption. The SCEP protocol however uses the 1504 CA private key to both sign and optionally encrypt CMS transport 1505 messages. This is generally considered undesirable as it widens the 1506 possibility of an implementation weakness and provides an additional 1507 location where the private key must be used (and hence is slightly 1508 more vulnerable to exposure) and where a side-channel attack might be 1509 applied. 1511 8.3. Challenge Password 1513 The challengePassword sent in the PKCS #10 enrolment request is 1514 signed and encrypted by way of being encapsulated in a pkiMessage. 1515 When saved by the CA, care should be taken to protect this password, 1516 for example by storing a salted iterated hash of the password rather 1517 than the password itself. 1519 8.4. Lack of Certificate Issue Confirmation 1521 SCEP provides no confirmation that the issued certificate was 1522 successfully received and processed by the client. This means that 1523 if the CertRep message is lost or can't be processed by the client 1524 then the CA will consider the certificate successfully issued while 1525 the client won't. If this situation is of concern then the correct 1526 issuance of the certificate will need to be verified by out-of-band 1527 means, for example through the client sending a message signed by the 1528 newly-issued certificate to the CA. This also provides the proof of 1529 possession that's not present in the case of an update or renewal 1530 operation, see Section 8.6. 1532 8.5. GetCACaps Issues 1534 The GetCACaps response is not authenticated by the CA. This allows 1535 an attacker to perform downgrade attacks on the cryptographic 1536 capabilities of the client/CA exchange. 1538 8.6. Lack of PoP in Renewal and Update Requests 1540 Renewal and update operations (but not standard certificate-issue 1541 operations) are processed via a previously-issued certificate and its 1542 associated private key, not the key in the PKCS #10 request. This 1543 means that a client no longer demonstrates proof of possession (PoP) 1544 of the private key corresponding to the public key in the PKCS #10 1545 request. It is therefore possible for a client to re-certify an 1546 existing key used by a third party, so that two or more certificates 1547 exist for the same key. By switching out the certificate in a 1548 signature, an attacker can appear to have a piece of data signed by 1549 their certificate rather than the original signer's certificate. 1550 This, and other, attacks are described in S/MIME ESS [14]. 1552 Avoiding these types of attacks requires situation-specific measures. 1553 For example CMS/SMIME implementations may use the ESSCertID attribute 1554 from S/MIME ESS [14] or its successor S/MIME ESSv2 [15] to 1555 unambiguously identify the signing certificate, however other 1556 mechanisms and protocols typically don't defend against this attack. 1558 8.7. Unnecessary cryptography 1560 Some of the SCEP exchanges use unnecessary signing and encryption 1561 operations. In particular the GetCert and GetCRL exchanges are 1562 encrypted and signed in both directions. The information requested 1563 is public and thus encrypting the requests is of questionable value. 1564 In addition CRLs and certificates sent in responses are already 1565 signed by the CA and can be verified by the recipient without 1566 requiring additional signing and encryption. More lightweight means 1567 of retrieving certificates and CRLs such as HTTP certificate-store 1568 access [11] and LDAP are recommended for this reason. 1570 8.8. Use of SHA-1 1572 Virtually all of the large numbers of devices that use SCEP today 1573 default to SHA-1, with many supporting only that hash algorithm with 1574 no ability to upgrade to a newer one. SHA-1 is no longer regarded as 1575 secure in all situations, but as used in SCEP it's still safe. There 1576 are three reasons for this. The first is that attacking SCEP would 1577 require creating a SHA-1 collision in close to real time, which won't 1578 be feasible for a very long time. 1580 The second reason is that the signature over the message doesn't 1581 serve any critical cryptographic purpose: The PKCS #10 data itself is 1582 authenticated through its own signature, protected by encryption, and 1583 the overall request is authorised by the (encrypted) password. The 1584 sole exception to this will be the small number of implementations 1585 that support the Renewal operation, which may be authorised purely 1586 through a signature, but presumably any implementation recent enough 1587 to support Renewal also supports SHA-2. Any legacy implementation 1588 that supports the historic core SCEP protocol would not be affected. 1590 The third reason is that SCEP uses the same key for encryption and 1591 signing, so that even if an attacker were able to capture an outgoing 1592 Renewal request that didn't include a password (in other words one 1593 that was only authorised through a signature), forge the SHA-1 hash 1594 in real time, and forward the forged request to the CA, they couldn't 1595 decrypt the returned certificate, which is protected with the same 1596 key that was used to generate the signature. While Section 8.7 1597 points out that SCEP uses unnecessary cryptography in places, the 1598 additional level of security provided by the extra crypto makes it 1599 immune to any issues with SHA-1. 1601 This doesn't mean that SCEP implementations should continue to use 1602 SHA-1 in perpetuity, merely that there's no need for a panicked 1603 switch to SHA-2. 1605 9. References 1607 9.1. Normative References 1609 [1] Bradner, S., "Key words for use in RFCs to Indicate 1610 Requirement Levels", BCP 14, RFC 2119, March 1997. 1612 [2] Josefsson, S., "The Base16, Base32, and Base64 Data 1613 Encodings", RFC 4648, October 2006. 1615 [3] Housley, R., "Cryptographic Message Syntax (CMS)", 1616 RFC 5652, September 2009. 1618 [4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1619 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1620 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1622 [5] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 1623 Classes and Attribute Types Version 2.0", RFC 2985, 1624 November 2000. 1626 [6] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1627 Request Syntax Specification Version 1.7", RFC 2986, 1628 November 2000. 1630 [7] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1631 Housley, R., and W. Polk, "Internet X.509 Public Key 1632 Infrastructure Certificate and Certificate Revocation List 1633 (CRL) Profile", RFC 5280, May 2008. 1635 [8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1636 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1637 August 1998. 1639 9.2. Informative References 1641 [9] Schaad, J. and M. Myers, "Certificate Management over CMS 1642 (CMC)", RFC 5272, June 2008. 1644 [10] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1645 "Internet X.509 Public Key Infrastructure Certificate 1646 Management Protocol (CMP)", RFC 4210, September 2005. 1648 [11] Gutmann, P., "Internet X.509 Public Key Infrastructure 1649 Operational Protocols: Certificate Store Access via HTTP", 1650 RFC 4387, February 2006. 1652 [12] Alighieri, D., "Internet Key Exchange (IKEv2) Protocol", 1653 RFC 4306, March 1300. 1655 [13] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1656 Mail Extensions (S/MIME) Version 3.2 Message 1657 Specification", RFC 5751, January 2010. 1659 [14] Hoffman, P., "Enhanced Security Services for S/MIME", 1660 RFC 2634, June 1999. 1662 [15] Schaad, J., "Enhanced Security Services (ESS) Update: 1663 Adding CertID Algorithm Agility", RFC 5035, August 2007. 1665 [16] Dierks, T. and E. Rescorla, "The Transport Layer Security 1666 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1668 Appendix A. Background Notes 1670 This specification has spent more than sixteen years in the draft 1671 stage. Its original goal, provisioning IPsec routers with 1672 certificates, has long since changed to general device/embedded 1673 system/IoT use. To fit this role, extra features were bolted on in a 1674 haphazard manner through the addition of a growing list of appendices 1675 and by inserting additional, often conflicting, paragraphs in various 1676 locations in the body text. Since existing features were never 1677 updated as newer ones were added, the specification accumulated large 1678 amounts of historical baggage over time. If OpenPGP was described as 1679 "a museum of 1990s crypto" then the SCEP draft was its graveyard. 1681 About five years ago the specification, which even at that point had 1682 seen only sporadic re-posts of the existing document, was more or 1683 less abandoned by its original sponsors. Due to its widespread use 1684 in large segments of the industry, the specification was rebooted in 1685 2015, cleaning up fifteen years worth of accumulated cruft, fixing 1686 errors, clarifying ambiguities, and bringing the algorithms and 1687 standards used into the current century (prior to the update, the de- 1688 facto lowest-common denominator algorithms used for interoperability 1689 were the forty-year-old single DES and broken MD5 hash algorithms). 1691 Other changes include: 1693 o Resolved contradictions in the text, for example a requirement 1694 given as a MUST in one paragraph and a SHOULD in the next, a MUST 1695 NOT in one paragraph and a MAY a few paragraphs later, a SHOULD 1696 NOT contradicted later by a MAY, and so on. 1697 o Merged several later fragmentary addenda placed in appendices (for 1698 example the handling of certificate renewal and update) with the 1699 body of the text. 1700 o Merged the SCEP Transactions and SCEP Transport sections, since 1701 the latter mostly duplicated (with occasional inconsistencies) the 1702 former. 1703 o Updated the algorithms to ones dating from at least this century. 1704 o Did the same for normative references to other standards. 1705 o Updated the text to use consistent terminology for the client and 1706 CA rather than a mixture of client, requester, end entity, server, 1707 certificate authority, certification authority, and CA. 1708 o Corrected incorrect references to other standards, e.g. 1709 IssuerAndSerial -> IssuerAndSerialNumber. 1711 o Corrected errors such as a statement that when both signature and 1712 encryption certificates existed, the signature certificate was 1713 used for encryption. 1714 o Condensed redundant discussions of the same topic spread across 1715 multiple sections into a single location. For example the 1716 description of intermediate CA handling previously existed in 1717 three different locations, with slightly different reqirements in 1718 each one. 1719 o Added a description of how pkiMessages were processed, which was 1720 never made explicit in the original specification. This led to 1721 creative interpretations that had security problems but were 1722 employed anyway due to the lack of specific guidance on what to 1723 do. 1724 o Relaxed some requirements that didn't serve any obvious purpose 1725 and that major implementations didn't seem to be enforcing. For 1726 example the requirement that the self-signed certificate used with 1727 a request MUST contain a subject name that matched the one in the 1728 PKCS #10 request was relaxed to a SHOULD because a number of 1729 implementations either ignored the issue entirely or at worst 1730 performed some minor action like creating a log entry after which 1731 they continued anyway. 1732 o Removed discussion of the transactionID from the security 1733 considerations, since the instructions there were directly 1734 contradicted by the discussion of the use of the transactionID in 1735 Section 5. 1736 o Clarified sections that were unclear or even made no sense, for 1737 example the requirement for a "hash on the public key" [sic] 1738 encoded as a PrintableString. 1739 o Renamed "RA certificates" to "intermediate CA certificates". The 1740 original document at some point added mention of RA certificates 1741 without specifying how the client was to determine that an RA was 1742 in use, how the RA operations were identified in the protocol, or 1743 how it was used. It's unclear whether what was meant was a true 1744 RA or merely an intermediate CA, as opposed to the default 1745 practice of having certificates issued directly from a single root 1746 CA certificate. This update uses the term "intermediate CA 1747 certificates", since this seems to have been the original intent 1748 of the text. 1749 o Redid the PKIMessage diagram to match what was specified in CMS, 1750 the original diagram omitted a number of fields and nested data 1751 structures which meant that the diagram didn't match either the 1752 text or the CMS specification. 1753 o Removed the requirement for a CertPoll to contain a 1754 recipientNonce, since CertPoll is a client message and will never 1755 be sent in response to a message containing a senderNonce. See 1756 also the note in Section 3.3.2. 1757 o Clarified certificate renewal and update. These represent a 1758 capability that was bolted onto the original protocol with (at 1759 best) vaguely-defined semantics, including a requirement by the CA 1760 to guess whether a particular request was a renewal or not 1761 (updates were even more vaguely defined). In response to 1762 developer feedback that they either avoided renewal/update 1763 entirely because of this uncertainty or hardcoded in particular 1764 behaviour on a per-CA basis, this specification explicitly 1765 identifies renewal and update requests as such, and provides 1766 proper semantics for both. 1767 o Added the "SCEPStandard" keyword to GetCACaps to indicate that the 1768 CA complies with the final version of the SCEP standard, since the 1769 definition of what constitutes SCEP standards compliance has 1770 changed significantly over the years. 1771 o Removed the discussion in the security considerations of 1772 revocation issues, since SCEP doesn't support revocation as part 1773 of the protocol. 1774 o Clarified the use of nonces, which if applied as originally 1775 specified would have made the use of polling in the presence of a 1776 lost message impossible. 1777 o Removed the discussion of generating a given transactionID by 1778 hashing the public key, since this implied that there was some 1779 special significance in the value generated this way. Since it 1780 was neither a MUST nor a MAY, it was unsound to imply that servers 1781 could rely on the value being generated a certain way. In 1782 addition it wouldn't work if multiple transactions as discussed in 1783 Section 4.4 were initiated, since the deterministic generation via 1784 hashing would lead to duplicate transactionIDs. 1785 o Added examples of SCEP messages to give implementers something to 1786 aim for. 1788 Appendix B. Sample SCEP Messages 1790 (Omitted from the drafts to keep the size down). 1792 Author's Address 1794 Peter Gutmann 1795 University of Auckland 1796 Department of Computer Science 1797 Auckland 1798 New Zealand 1800 Email: pgut001@cs.auckland.ac.nz