idnits 2.17.1 draft-gutmann-scep-05.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 (November 24, 2016) is 2703 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 November 24, 2016 5 Expires: May 28, 2017 7 Simple Certificate Enrolment Protocol 8 draft-gutmann-scep-05 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 May 28, 2017. 37 Copyright Notice 39 Copyright (c) 2016 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 . . . . . 25 97 4.2.1.2. CA Certificate Chain Response Message Format . . 25 98 4.3. Certificate Enrolment/Renewal/Update . . . . . . . . . . 26 99 4.3.1. Certificate Enrolment/Renewal/Update Response Message 26 100 4.4. Poll for Client Initial Certificate . . . . . . . . . . . 27 101 4.4.1. Polling Response Message Format . . . . . . . . . . . 27 102 4.5. Certificate Access . . . . . . . . . . . . . . . . . . . 27 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 . . . . . . . . . 28 108 5. SCEP State Transitions . . . . . . . . . . . . . . . . . . . 29 109 5.1. Successful Transactions . . . . . . . . . . . . . . . . . 29 110 5.2. Transactions with Errors . . . . . . . . . . . . . . . . 30 111 6. Contributors/Acknowledgements . . . . . . . . . . . . . . . . 33 112 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 113 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 114 8.1. General Security . . . . . . . . . . . . . . . . . . . . 33 115 8.2. Use of the CA keypair . . . . . . . . . . . . . . . . . . 33 116 8.3. Challenge Password . . . . . . . . . . . . . . . . . . . 34 117 8.4. Lack of Certificate Issue Confirmation . . . . . . . . . 34 118 8.5. GetCACaps Issues . . . . . . . . . . . . . . . . . . . . 34 119 8.6. Lack of PoP in Renewal and Update Requests . . . . . . . 34 120 8.7. Unnecessary cryptography . . . . . . . . . . . . . . . . 35 121 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 122 9.1. Normative References . . . . . . . . . . . . . . . . . . 35 123 9.2. Informative References . . . . . . . . . . . . . . . . . 36 124 Appendix A. Background Notes . . . . . . . . . . . . . . . . . . 36 125 Appendix B. Sample SCEP Messages . . . . . . . . . . . . . . . . 39 126 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 39 128 1. Introduction 130 X.509 certificates serve as the basis for several standards-based 131 security protocols such as TLS [16], S/MIME [13], and IKE/IPsec [12]. 132 When an X.509 certificate is issued there typically is a need for a 133 certificate management protocol to enable a PKI client to request a 134 certificate, certificate renewal, or certificate update from a 135 Certificate Authority (CA). 137 This specification defines a protocol, Simple Certificate Enrolment 138 Protocol (SCEP), for certificate management and certificate and CRL 139 queries. While widely deployed, this protocol omits some certificate 140 management features, e.g. certificate revocation transactions, which 141 may enhance the security achieved in a PKI. The IETF protocol suite 142 currently includes two further certificate management protocols with 143 more comprehensive functionality, Certificate Management Protocol 144 (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 the them 215 before any PKI operation (Section 3) can be started. Since no public 216 key has yet been exchanged between the client and the CA, the 217 messages cannot be secured using CMS, and the data is instead 218 transferred in 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. This means that 1040 the equivalent of GetCACaps must be performed through server 1041 fingerprinting, which can be done using the ID string "Microsoft- 1042 IIS"). 1044 The Content-type of the reply SHOULD be "text/plain". Clients SHOULD 1045 ignore the Content-type, as older implementations of SCEP may send 1046 various Content-types. 1048 Example: 1050 GET /cgi-bin/pkiclient.exe?operation=GetCACaps 1052 might return: 1054 AES 1055 GetNextCACert 1056 POSTPKIOperation 1057 SCEPStandard 1058 SHA-256 1060 This means that the CA supports modern crypto algorithms, the 1061 GetNextCACert message, allows PKIOperation messages 1062 (PKCSReq/RenewalReq/UpdateReq, GetCert, CertPoll, ...) to be sent 1063 using HTTP POST, and is compliant with the final version of the SCEP 1064 standard. 1066 4. SCEP Transactions 1068 This section describes the SCEP Transactions and their HTTP [4] 1069 transport mechanism. 1071 4.1. HTTP POST and GET Message Formats 1073 SCEP uses the HTTP "POST" and "GET" messages to exchange information 1074 with the CA. The following defines the syntax of HTTP POST and GET 1075 messages sent from a client to a CA: 1077 "POST" CGI-PATH CGI-PROG "?operation=" OPERATION 1078 "GET" CGI-PATH CGI-PROG "?operation=" OPERATION "&message=" MESSAGE 1080 where: 1082 o CGI-PATH defines the path to invoke the CGI program that parses 1083 the request. 1084 o CGI-PROG is set to be the string "pkiclient.exe". This is 1085 intended to be the program that the CA will use to handle the SCEP 1086 transactions. 1087 o OPERATION depends on the SCEP transaction and is defined in the 1088 following sections. 1090 The CA will typically ignore CGI-PATH and/or CGI-PROG since it's 1091 unlikely to be issuing certificates via a web server. Clients SHOULD 1092 set CGI-PATH/CGI-PROG to the fixed string "/cgi-bin/pkiclient.exe" 1093 unless directed to do otherwise to by the CA. 1095 Early SCEP drafts performed all communications via "GET" messages, 1096 including non-idempotent ones that should have been sent via "POST" 1097 messages. This has caused problems because of the way that the 1098 (supposedly) idempotent GET interacts with caches and proxies, and 1099 because the extremely large GET requests created by encoding CMS 1100 messages may be truncated in transit. These issues are typically not 1101 visible when testing on a LAN, but crop up during deployment over 1102 WANs. If the remote CA supports it, any of the CMS-encoded SCEP 1103 messages SHOULD be sent via HTTP POST instead of HTTP GET. This 1104 applies to any SCEP message except GetCACert, GetNextCACert, and 1105 GetCACaps, and avoids the need for base64- and URL-encoding that's 1106 required for GET messaging. The client can verify that the CA 1107 supports SCEP messages via POST by looking for the "POSTPKIOperation" 1108 capability (See Section 3.5.2). 1110 If a client or CA uses HTTP GET and encounters HTTP-related problems 1111 such as messages being truncated, seeing errors such as HTTP 414 1112 ("Request URI too long"), or simply having the message not sent/ 1113 received at all, when standard requests to the server (for example 1114 via a web browser) work, then this is a symptom of the problematic 1115 use of HTTP GET. The solution to this problem is typically to move 1116 to HTTP POST instead. In addition when using GET it's recommended to 1117 test your implementation over the public internet from as many 1118 locations as possible to determine whether the use of GET will cause 1119 problems with communications. 1121 When using GET messages to communicate binary data, base64 encoding 1122 as specified in [2] MUST be used. The base64 encoded data is 1123 distinct from "base64url" and may contain URI reserved characters, 1124 thus it MUST be escaped as specified in [8] in addition to being 1125 base64 encoded. Finally, the encoded data is inserted into the 1126 MESSAGE portion of the HTTP GET request. 1128 4.2. Get CA Certificate 1130 To get the CA certificate(s), the client sends a GetCACert message to 1131 the CA. The OPERATION MUST be set to "GetCACert". There is no 1132 request data associated with this message. 1134 4.2.1. Get CA Certificate Response Message Format 1136 The response for GetCACert is different between the case where the CA 1137 directly communicates with the client during the enrolment, and the 1138 case where an intermediate CA exists and the client communicates with 1139 this CA during the enrolment. 1141 4.2.1.1. CA Certificate Response Message Format 1143 If the CA does not have any intermediate CA certificates, the 1144 response consists of a single X.509 CA certificate. The response 1145 will have a Content-Type of "application/x-x509-ca-cert". 1147 "Content-Type: application/x-x509-ca-cert" 1149 1151 4.2.1.2. CA Certificate Chain Response Message Format 1153 If the CA has intermediate CA certificates, the response consists of 1154 a degenerate certificates-only CMS Signed-Data message (Section 3.4) 1155 containing the certificates, with the intermediate CA certificate(s) 1156 as the leaf certificate(s). The response will have a Content-Type of 1157 "application/x-x509-ca-ra-cert". Note that this designation is used 1158 for historical reasons due to its use in older versions of this 1159 specification, no special meaning should be attached to the label. 1161 "Content-Type: application/x-x509-ca-ra-cert" 1163 1165 4.3. Certificate Enrolment/Renewal/Update 1167 A PKCSReq/RenewalReq/UpdateReq (Section 3.3.1) message is used to 1168 perform a certificate enrolment, renewal, or update transaction. The 1169 OPERATION MUST be set to "PKIOperation". Note that when used with 1170 HTTP POST, the only OPERATION possible is "PKIOperation", so many CAs 1171 don't check this value or even notice its absence. When implemented 1172 using HTTP POST the message might look as follows: 1174 POST /cgi-bin/pkiclient.exe?operation=PKIOperation HTTP/1.1 1175 Content-Length: 1177 1179 When implemented using HTTP GET this might look as follows: 1181 GET /cgi-bin/pkiclient.exe?operation=PKIOperation& \ 1182 message=MIAGCSqGSIb3DQEHA6CAMIACAQAxgDCBzAIBADB2MG \ 1183 IxETAPBgNVBAcTCE......AAAAAA== HTTP/1.1 1185 4.3.1. Certificate Enrolment/Renewal/Update Response Message 1187 If the request is granted, a CertRep message (Section 3.3.2) with 1188 pkiStatus set to SUCCESS is returned. The reply MUST also contain 1189 the certificate (and MAY contain any other certificates needed by the 1190 client). The issued certificate MUST be the first in the list. 1192 If the request is rejected, a CertRep message (Section 3.3.2) with 1193 pkiStatus set to FAILURE is returned. The reply MUST also contain a 1194 failInfo attribute. 1196 If the the CA is configured to manually authenticate the client, a 1197 CertRep message (Section 3.3.2) with pkiStatus set to PENDING MAY be 1198 returned. The CA MAY return a PENDING for other reasons. 1200 The response will have a Content-Type of "application/x-pki-message". 1202 "Content-Type: application/x-pki-message" 1204 1206 4.4. Poll for Client Initial Certificate 1208 Whe the client receives a CertRep message with pkiStatus set to 1209 PENDING, it will enter the polling state by periodically sending 1210 CertPoll messages to the CA until either the request is granted and 1211 the certificate is sent back or the request is rejected or some 1212 preconfigured time limit for polling or maximum number of polls is 1213 exceeded. The OPERATION MUST be set to "PKIOperation". 1215 CertPoll messages exchanged during the polling period MUST carry the 1216 same transactionID attribute as the previous PKCSReq/RenewalReq/ 1217 UpdateReq. A CA receiving a CertPoll for which it does not have a 1218 matching PKCSReq/RenewalReq/UpdateReq MUST ignore this request. 1220 Since at this time the certificate has not been issued, the client 1221 can only use its own subject name (which was contained in the 1222 original PKCS# 10 sent via PKCSReq/RenewalReq/UpdateReq) to identify 1223 the polled certificate request (but see the note on identification 1224 during polling in Section 3.3.3). In theory there can be multiple 1225 outstanding requests from one client (for example, if different keys 1226 and different key-usages were used to request multiple certificates), 1227 so the transactionID must also be included to disambiguate between 1228 multiple requests. In practice however it's safer for the client to 1229 not have multiple requests outstanding at any one time, since this 1230 tends to confuse some CAs. 1232 4.4.1. Polling Response Message Format 1234 The response messages for CertPoll are the same as in Section 4.3.1. 1236 4.5. Certificate Access 1238 A client can query an issued certificate from the SCEP CA, as long as 1239 the client knows the issuer name and the issuer assigned certificate 1240 serial number. 1242 This transaction consists of one GetCert (Section 3.3.4) message sent 1243 to the CA by a client, and one CertRep (Section 3.3.2) message sent 1244 back from the CA. The OPERATION MUST be set to "PKIOperation". 1246 4.5.1. Certificate Access Response Message Format 1248 In this case, the CertRep from the CA is same as in Section 4.3.1, 1249 except that the CA will either grant the request (SUCCESS) or reject 1250 it (FAILURE). 1252 4.6. CRL Access 1254 Clients can request a CRL from the SCEP CA as described in 1255 Section 2.6. The OPERATION MUST be set to "PKIOperation". 1257 4.6.1. CRL Access Response Message Format 1259 The CRL is sent back to the client in a CertRep (Section 3.3.2) 1260 message. The information portion of this message is a degenerate 1261 certificates-only Signed-Data (Section 3.4) that contains only the 1262 most recent CRL in the crls field of the Signed-Data. 1264 4.7. Get Next Certificate Authority Certificate 1266 When a CA certificate expires then, depending on client and CA 1267 policy, certificates that have been signed by it may no longer be 1268 regarded as valid. CA key rollover provides a mechanism by which the 1269 CA MAY distribute a new CA certificate which is valid in the future 1270 once the current certificate has expired. When a CA certificate is 1271 about to expire, clients need to retrieve the CA's next CA 1272 certificate (i.e. the rollover certificate). This is done via the 1273 GetNextCACert message. The OPERATION MUST be set to "GetNextCACert". 1274 There is no request data associated with this message. 1276 Clients MAY store the not-yet-valid CA certificate, and any not-yet- 1277 valid client certificates obtained, until such time that they are 1278 valid, at which point clients switch over to using the newly valid 1279 certificates (but see the note in Section 2.1.3 about storing CA 1280 certificates). 1282 4.7.1. Get Next CA Response Message Format 1284 The response consists of a Signed-Data CMS message, signed by the 1285 current CA signing key. Clients MUST validate the signature on the 1286 message before accepting any of its contents. The response will have 1287 a Content-Type of "application/x-x509-next-ca-cert". 1289 "Content-Type: application/x-x509-next-ca-cert" 1291 1292 The content of the Signed-Data message is a degenerate certificates- 1293 only Signed-Data message (Section 3.4) containing the new CA 1294 certificate(s) to be used when the current CA certificate expires. 1296 If the CA does not have rollover certificate(s) it MUST reject the 1297 request. It SHOULD also remove the GetNextCACert setting from the CA 1298 capabilities returned by GetCACaps until it does have rollover 1299 certificates. 1301 5. SCEP State Transitions 1303 The following section gives several examples of client to CA 1304 transactions. Client actions are indicated in the left column, CA 1305 actions are indicated in the right column, and the transactionID is 1306 given in parentheses. The first transaction, for example, would read 1307 like this: 1309 "Client Sends PKCSReq message with transactionID 1 to the CA. The CA 1310 signs the certificate and constructs a CertRep Message containing the 1311 signed certificate with a transaction ID 1. The client receives the 1312 message and installs the certificate locally". 1314 5.1. Successful Transactions 1316 Successful Enrolment Case: Automatic processing 1318 PKCSReq (1) ----------> CA issues certificate 1319 <---------- CertRep (1) SUCCESS 1320 Client installs certificate 1322 Successful Enrolment Case: Manual authentication required 1324 PKCSReq (2) ----------> Cert request goes into queue 1325 <---------- CertRep (2) PENDING 1326 CertPoll (2) ----------> Still pending 1327 <---------- CertRep (2) PENDING 1328 CertPoll (2) ----------> CA issues certificate 1329 <---------- CertRep (2) SUCCESS 1330 Client installs certificate 1331 CA certificate rollover case: 1333 GetNextCACert ----------> 1334 <---------- New CA certificate 1336 PKCSReq* ----------> CA issues certificate with 1337 new key 1338 <---------- CertRep SUCCESS 1339 Client stores certificate 1340 for installation when 1341 existing certificate expires. 1343 * Enveloped for the new CA certificate. The CA will use the envelope 1344 to determine which key to use to issue the client certificate. 1346 5.2. Transactions with Errors 1348 In the case of polled transactions that aren't completed 1349 automatically, there are two potential options for dealing with a 1350 transaction that's interrupted due to network or software/hardware 1351 issues. The first is for the client to preserve its transaction 1352 state and resume the CertPoll polling when normal service is 1353 restored. The second is for the client to begin a new transaction by 1354 sending a new PKCSReq/RenewalReq/UpdateReq rather than continuing the 1355 previous CertPoll. Both options have their own advantages and 1356 disadvantages. 1358 The CertPoll continuation requires that the client maintain its 1359 transaction state for then time when it resumes polling. This is 1360 relatively simple if the problem is a brief network outage, but less 1361 simple when the problem is a client crash and restart. In addition 1362 the CA may treat a lost network connection as the end of a 1363 transaction, so that a new connection followed by a CertPoll will be 1364 treated as an error. 1366 The PKCSReq/RenewalReq/UpdateReq continuation doesn't require any 1367 state to be maintained since it's a new transaction, however it may 1368 cause problems on the CA side if the certificate was successfully 1369 issued but the client never received it, since the resumed 1370 transaction attempt will appear to be a request for a duplicate 1371 certificate (see Section 8.4 for more on why this is a problem). In 1372 this case the CA may refuse the transaction, or require manual 1373 intervention to remove/revoke the previous certificate before the 1374 client can request another one. 1376 Since the new-transaction resume is more robust in the presence of 1377 errors and doesn't require special-case handling by either the client 1378 or CA, clients SHOULD use the new-transaction option in preference to 1379 the resumed-CertPoll option to recover from errors. 1381 Resync Case 1: Client resyncs via new PKCSReq (recommended): 1383 PKCSReq (3) ----------> Cert request goes into queue 1384 <---------- CertRep (3) PENDING 1385 CertPoll (3) ----------> Still pending 1386 X-------- CertRep(3) PENDING 1387 (Network outage) 1388 (Client reconnects) 1389 PKCSReq (4) ----------> 1390 <---------- CertRep (4) PENDING 1391 etc... 1393 Resync Case 2: Client resyncs via resumed CertPoll after a network 1394 outage (not recommended, use PKCSReq to resync): 1396 PKCSReq (5) ----------> Cert request goes into queue 1397 <---------- CertRep (5) PENDING 1398 CertPoll (5) ----------> Still pending 1399 X-------- CertRep(5) PENDING 1400 (Network outage) 1401 (Client reconnects) 1402 CertPoll (5) ----------> CA issues certificate 1403 <---------- CertRep (5) SUCCESS 1404 Client installs certificate 1405 Resync Case 3: Special-case variation of case 2 where the CertRep 1406 SUCCESS rather than the CertRep PENDING is lost (recommended): 1408 PKCSReq (6) ----------> Cert request goes into queue 1409 <---------- CertRep (6) PENDING 1410 CertPoll (6) ----------> Still pending 1411 <---------- CertRep (6) PENDING 1412 CertPoll (6) ----------> CA issues certificate 1413 X-------- CertRep(6) SUCCESS 1414 (Network outage) 1415 (Client reconnects) 1416 PKCSReq (7) ----------> There is already a valid 1417 certificate with this DN. 1418 <---------- CertRep (7) FAILURE 1419 Admin revokes certificate 1420 PKCSReq (7) ----------> CA issues new certificate 1421 <---------- CertRep (7) SUCCESS 1422 Client installs certificate 1424 Resync Case 4: Special-case variation of case 1 where the CertRep 1425 SUCCESS rather than the CertRep PENDING is lost (not recommended, use 1426 PKCSReq to resync): 1428 PKCSReq (8) ----------> Cert request goes into queue 1429 <---------- CertRep (8) PENDING 1430 CertPoll (8) ----------> Still pending 1431 <---------- CertRep (8) PENDING 1432 CertPoll (8) ----------> CA issues certificate 1433 X-------- CertRep(8) SIGNED CERT 1434 (Network outage) 1435 (Client reconnects) 1436 CertPoll (8) ----------> Certificate already issued 1437 <---------- CertRep (8) SUCCESS 1438 Client installs certificate 1440 As these examples indicate, resumption from an error via a resumed 1441 CertPoll is tricky due to the state that needs to be held by both the 1442 client and/or the CA. A PKCSReq/RenewalReq/UpdateReq resume is the 1443 easiest to implement since it's stateless and is identical for both 1444 polled and non-polled transactions, while a CertPoll resume treats 1445 the two differently (a non-polled transaction is resumed with a 1446 PKCSReq/RenewalReq/UpdateReq, a polled transaction is resumed with a 1447 CertPoll). For this reason this specification recommends that error 1448 recovery be handled via a new PKCSReq rather than a resumed CertPoll. 1450 6. Contributors/Acknowledgements 1452 The editor would like to thank all of the previous editors, authors 1453 and contributors: Cheryl Madson, Xiaoyi Liu, David McGrew, David 1454 Cooper, Andy Nourse, Max Pritikin, Jan Vilhuber, and others for their 1455 work maintaining the draft over the years. Numerous other people 1456 have contributed during the long life cycle of the draft and all 1457 deserve thanks. In addition several PKCS #7 / CMS libraries 1458 contributed to interoperability by doing the right thing despite what 1459 earlier SCEP drafts required. 1461 The earlier authors would like to thank Peter William of ValiCert, 1462 Inc. (formerly of VeriSign, Inc.) and Alex Deacon of VeriSign, Inc. 1463 and Christopher Welles of IRE, Inc. for their contributions to early 1464 versions of this protocol and this document. 1466 7. IANA Considerations 1468 This memo includes no request to IANA. 1470 8. Security Considerations 1472 The security goal of SCEP is that no adversary can subvert the public 1473 key/identity binding from that intended. An adversary is any entity 1474 other than the client and the CA participating in the protocol. 1476 This goal is met through the use of CMS and PKCS #10 encryption and 1477 digital signatures using authenticated public keys. The CA's public 1478 key is authenticated via out-of-band means such as the checking of 1479 the CA fingerprint and the SCEP client's public key is authenticated 1480 through manual or pre-shared secret authentication. 1482 8.1. General Security 1484 Common key-management considerations such as keeping private keys 1485 truly private and using adequate lengths for symmetric and asymmetric 1486 keys must be followed in order to maintain the security of this 1487 protocol. This is especially true for CA keys which, when 1488 compromised, compromise the security of all relying parties. 1490 8.2. Use of the CA keypair 1492 A CA key pair is generally meant for, and is usually flagged as, 1493 being usable for certificate (and CRL) signing exclusively rather 1494 than data signing or encryption. The SCEP protocol however uses the 1495 CA private key to both sign and optionally encrypt CMS transport 1496 messages. This is generally considered undesirable as it widens the 1497 possibility of an implementation weakness and provides an additional 1498 location where the private key must be used (and hence is slightly 1499 more vulnerable to exposure) and where a side-channel attack might be 1500 applied. 1502 8.3. Challenge Password 1504 The challengePassword sent in the PKCS #10 enrolment request is 1505 signed and encrypted by way of being encapsulated in a pkiMessage. 1506 When saved by the CA, care should be taken to protect this password, 1507 for example by storing a salted iterated hash of the password rather 1508 than the password itself. 1510 8.4. Lack of Certificate Issue Confirmation 1512 SCEP provides no confirmation that the issued certificate was 1513 successfully received and processed by the client. This means that 1514 if the CertRep message is lost or can't be processed by the client 1515 then the CA will consider the certificate successfully issued while 1516 the client won't. If this situation is of concern then the correct 1517 issuance of the certificate will need to be verified by out-of-band 1518 means, for example through the client sending a message signed by the 1519 newly-issued certificate to the CA. This also provides the proof of 1520 possession that's not present in the case of an update or renewal 1521 operation, see Section 8.6. 1523 8.5. GetCACaps Issues 1525 The GetCACaps response is not authenticated by the CA. This allows 1526 an attacker to perform downgrade attacks on the cryptographic 1527 capabilities of the client/CA exchange. 1529 8.6. Lack of PoP in Renewal and Update Requests 1531 Renewal and update operations (but not standard certificate-issue 1532 operations) are processed via a previously-issued certificate and its 1533 associated private key, not the key in the PKCS #10 request. This 1534 means that a client no longer demonstrates proof of possession (PoP) 1535 of the private key corresponding to the public key in the PKCS #10 1536 request. It is therefore possible for a client to re-certify an 1537 existing key used by a third party, so that two or more certificates 1538 exist for the same key. By switching out the certificate in a 1539 signature, an attacker can appear to have a piece of data signed by 1540 their certificate rather than the original signer's certificate. 1541 This, and other, attacks are described in S/MIME ESS [14]. 1543 Avoiding these types of attacks requires situation-specific measures. 1544 For example CMS/SMIME implementations may use the ESSCertID attribute 1545 from S/MIME ESS [14] or its successor S/MIME ESSv2 [15] to 1546 unambiguously identify the signing certificate, however other 1547 mechanisms and protocols typically don't defend against this attack. 1549 8.7. Unnecessary cryptography 1551 Some of the SCEP exchanges use unnecessary signing and encryption 1552 operations. In particular the GetCert and GetCRL exchanges are 1553 encrypted and signed in both directions. The information requested 1554 is public and thus encrypting the requests is of questionable value. 1555 In addition CRLs and certificates sent in responses are already 1556 signed by the CA and can be verified by the recipient without 1557 requiring additional signing and encryption. More lightweight means 1558 of retrieving certificates and CRLs such as HTTP certificate-store 1559 access [11] and LDAP are recommended for this reason. 1561 9. References 1563 9.1. Normative References 1565 [1] Bradner, S., "Key words for use in RFCs to Indicate 1566 Requirement Levels", BCP 14, RFC 2119, March 1997. 1568 [2] Josefsson, S., "The Base16, Base32, and Base64 Data 1569 Encodings", RFC 4648, October 2006. 1571 [3] Housley, R., "Cryptographic Message Syntax (CMS)", 1572 RFC 5652, September 2009. 1574 [4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1575 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1576 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1578 [5] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 1579 Classes and Attribute Types Version 2.0", RFC 2985, 1580 November 2000. 1582 [6] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1583 Request Syntax Specification Version 1.7", RFC 2986, 1584 November 2000. 1586 [7] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1587 Housley, R., and W. Polk, "Internet X.509 Public Key 1588 Infrastructure Certificate and Certificate Revocation List 1589 (CRL) Profile", RFC 5280, May 2008. 1591 [8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1592 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1593 August 1998. 1595 9.2. Informative References 1597 [9] Schaad, J. and M. Myers, "Certificate Management over CMS 1598 (CMC)", RFC 5272, June 2008. 1600 [10] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1601 "Internet X.509 Public Key Infrastructure Certificate 1602 Management Protocol (CMP)", RFC 4210, September 2005. 1604 [11] Gutmann, P., "Internet X.509 Public Key Infrastructure 1605 Operational Protocols: Certificate Store Access via HTTP", 1606 RFC 4387, February 2006. 1608 [12] Alighieri, D., "Internet Key Exchange (IKEv2) Protocol", 1609 RFC 4306, March 1300. 1611 [13] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1612 Mail Extensions (S/MIME) Version 3.2 Message 1613 Specification", RFC 5751, January 2010. 1615 [14] Hoffman, P., "Enhanced Security Services for S/MIME", 1616 RFC 2634, June 1999. 1618 [15] Schaad, J., "Enhanced Security Services (ESS) Update: 1619 Adding CertID Algorithm Agility", RFC 5035, August 2007. 1621 [16] Dierks, T. and E. Rescorla, "The Transport Layer Security 1622 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1624 Appendix A. Background Notes 1626 This specification has spent more than sixteen years in the draft 1627 stage. Its original goal, provisioning IPsec routers with 1628 certificates, has long since changed to general device/embedded 1629 system/IoT use. To fit this role, extra features were bolted on in a 1630 haphazard manner through the addition of a growing list of appendices 1631 and by inserting additional, often conflicting, paragraphs in various 1632 locations in the body text. Since existing features were never 1633 updated as newer ones were added, the specification accumulated large 1634 amounts of historical baggage over time. If OpenPGP was described as 1635 "a museum of 1990s crypto" then the SCEP draft was its graveyard. 1637 About five years ago the specification, which even at that point had 1638 seen only sporadic re-posts of the existing document, was more or 1639 less abandoned by its original sponsors. Due to its widespread use 1640 in large segments of the industry, the specification was rebooted in 1641 2015, cleaning up fifteen years worth of accumulated cruft, fixing 1642 errors, clarifying ambiguities, and bringing the algorithms and 1643 standards used into the current century (prior to the update, the de- 1644 facto lowest-common denominator algorithms used for interoperability 1645 were the forty-year-old single DES and broken MD5 hash algorithms). 1647 Other changes include: 1649 o Resolved contradictions in the text, for example a requirement 1650 given as a MUST in one paragraph and a SHOULD in the next, a MUST 1651 NOT in one paragraph and a MAY a few paragraphs later, a SHOULD 1652 NOT contradicted later by a MAY, and so on. 1653 o Merged several later fragmentary addenda placed in appendices (for 1654 example the handling of certificate renewal and update) with the 1655 body of the text. 1656 o Merged the SCEP Transactions and SCEP Transport sections, since 1657 the latter mostly duplicated (with occasional inconsistencies) the 1658 former. 1659 o Updated the algorithms to ones dating from at least this century. 1660 o Did the same for normative references to other standards. 1661 o Updated the text to use consistent terminology for the client and 1662 CA rather than a mixture of client, requester, end entity, server, 1663 certificate authority, certification authority, and CA. 1664 o Corrected incorrect references to other standards, e.g. 1665 IssuerAndSerial -> IssuerAndSerialNumber. 1666 o Corrected errors such as a statement that when both signature and 1667 encryption certificates existed, the signature certificate was 1668 used for encryption. 1669 o Condensed redundant discussions of the same topic spread across 1670 multiple sections into a single location. For example the 1671 description of intermediate CA handling previously existed in 1672 three different locations, with slightly different reqirements in 1673 each one. 1674 o Added a description of how pkiMessages were processed, which was 1675 never made explicit in the original specification. This led to 1676 creative interpretations that had security problems but were 1677 employed anyway due to the lack of specific guidance on what to 1678 do. 1679 o Relaxed some requirements that didn't serve any obvious purpose 1680 and that major implementations didn't seem to be enforcing. For 1681 example the requirement that the self-signed certificate used with 1682 a request MUST contain a subject name that matched the one in the 1683 PKCS #10 request was relaxed to a SHOULD because a number of 1684 implementations either ignored the issue entirely or at worst 1685 performed some minor action like creating a log entry after which 1686 they continued anyway. 1687 o Removed discussion of the transactionID from the security 1688 considerations, since the instructions there were directly 1689 contradicted by the discussion of the use of the transactionID in 1690 Section 5. 1692 o Clarified sections that were unclear or even made no sense, for 1693 example the requirement for a "hash on the public key" [sic] 1694 encoded as a PrintableString. 1695 o Renamed "RA certificates" to "intermediate CA certificates". The 1696 original document at some point added mention of RA certificates 1697 without specifying how the client was to determine that an RA was 1698 in use, how the RA operations were identified in the protocol, or 1699 how it was used. It's unclear whether what was meant was a true 1700 RA or merely an intermediate CA, as opposed to the default 1701 practice of having certificates issued directly from a single root 1702 CA certificate. This update uses the term "intermediate CA 1703 certificates", since this seems to have been the original intent 1704 of the text. 1705 o Redid the PKIMessage diagram to match what was specified in CMS, 1706 the original diagram omitted a number of fields and nested data 1707 structures which meant that the diagram didn't match either the 1708 text or the CMS specification. 1709 o Removed the requirement for a CertPoll to contain a 1710 recipientNonce, since CertPoll is a client message and will never 1711 be sent in response to a message containing a senderNonce. See 1712 also the note in Section 3.3.2. 1713 o Clarified certificate renewal and update. These represent a 1714 capability that was bolted onto the original protocol with (at 1715 best) vaguely-defined semantics, including a requirement by the CA 1716 to guess whether a particular request was a renewal or not 1717 (updates were even more vaguely defined). In response to 1718 developer feedback that they either avoided renewal/update 1719 entirely because of this uncertainty or hardcoded in particular 1720 behaviour on a per-CA basis, this specification explicitly 1721 identifies renewal and update requests as such, and provides 1722 proper semantics for both. 1723 o Added the "SCEPStandard" keyword to GetCACaps to indicate that the 1724 CA complies with the final version of the SCEP standard, since the 1725 definition of what constitutes SCEP standards compliance has 1726 changed significantly over the years. 1727 o Removed the discussion in the security considerations of 1728 revocation issues, since SCEP doesn't support revocation as part 1729 of the protocol. 1730 o Clarified the use of nonces, which if applied as originally 1731 specified would have made the use of polling in the presence of a 1732 lost message impossible. 1733 o Removed the discussion of generating a given transactionID by 1734 hashing the public key, since this implied that there was some 1735 special significance in the value generated this way. Since it 1736 was neither a MUST nor a MAY, it was unsound to imply that servers 1737 could rely on the value being generated a certain way. In 1738 addition it wouldn't work if multiple transactions as discussed in 1739 Section 4.4 were initiated, since the deterministic generation via 1740 hashing would lead to duplicate transactionIDs. 1741 o Added examples of SCEP messages to give implementers something to 1742 aim for. 1744 Appendix B. Sample SCEP Messages 1746 (Omitted from the drafts to keep the size down). 1748 Author's Address 1750 Peter Gutmann 1751 University of Auckland 1752 Department of Computer Science 1753 Auckland 1754 New Zealand 1756 Email: pgut001@cs.auckland.ac.nz