idnits 2.17.1 draft-gutmann-scep-04.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 (October 28, 2016) is 2738 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 382 -- Looks like a reference, but probably isn't: 'CERT-REQ-PENDING' on line 382 -- Looks like a reference, but probably isn't: 'CERT-ISSUED' on line 382 ** 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 M. Pritikin 5 Expires: May 1, 2017 Cisco 6 October 28, 2016 8 Simple Certificate Enrolment Protocol 9 draft-gutmann-scep-04.txt 11 Abstract 13 This document specifies the Simple Certificate Enrolment Protocol 14 (SCEP), a PKI communication protocol that leverages existing 15 technology by using CMS (formerly known as PKCS #7) and PKCS #10 over 16 HTTP. SCEP is the evolution of the enrolment protocol sponsored by 17 Cisco Systems, which enjoys wide support in both client and server 18 implementations, as well as being relied upon by numerous other 19 industry standards that work with certificates. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 1, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 57 2. SCEP Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. SCEP Entities . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1.1. Client . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.1.2. Certification Authority . . . . . . . . . . . . . . . 5 61 2.1.3. CA Certificate Distribution . . . . . . . . . . . . . 5 62 2.2. Client authentication . . . . . . . . . . . . . . . . . . 6 63 2.3. Enrolment authorization . . . . . . . . . . . . . . . . . 7 64 2.4. Certificate Enrolment/Renewal/Update . . . . . . . . . . 8 65 2.4.1. Client State Transitions . . . . . . . . . . . . . . 8 66 2.5. Certificate Access . . . . . . . . . . . . . . . . . . . 10 67 2.6. CRL Access . . . . . . . . . . . . . . . . . . . . . . . 11 68 2.7. Certificate Revocation . . . . . . . . . . . . . . . . . 11 69 2.8. Mandatory-to-Implement Functionality . . . . . . . . . . 11 70 3. SCEP Secure Message Objects . . . . . . . . . . . . . . . . . 12 71 3.1. SCEP Message Object Processing . . . . . . . . . . . . . 14 72 3.2. SCEP pkiMessage . . . . . . . . . . . . . . . . . . . . . 14 73 3.2.1. Signed Transaction Attributes . . . . . . . . . . . . 15 74 3.2.1.1. transactionID . . . . . . . . . . . . . . . . . . 16 75 3.2.1.2. messageType . . . . . . . . . . . . . . . . . . . 16 76 3.2.1.3. pkiStatus . . . . . . . . . . . . . . . . . . . . 17 77 3.2.1.4. failInfo . . . . . . . . . . . . . . . . . . . . 17 78 3.2.1.5. senderNonce and recipientNonce . . . . . . . . . 18 79 3.2.2. SCEP pkcsPKIEnvelope . . . . . . . . . . . . . . . . 18 80 3.3. SCEP pkiMessage types . . . . . . . . . . . . . . . . . . 18 81 3.3.1. PKCSReq/RenewalReq/UpdateReq . . . . . . . . . . . . 18 82 3.3.2. CertRep . . . . . . . . . . . . . . . . . . . . . . . 19 83 3.3.2.1. CertRep SUCCESS . . . . . . . . . . . . . . . . . 19 84 3.3.2.2. CertRep FAILURE . . . . . . . . . . . . . . . . . 20 85 3.3.2.3. CertRep PENDING . . . . . . . . . . . . . . . . . 20 86 3.3.3. CertPoll (GetCertInitial) . . . . . . . . . . . . . . 20 87 3.3.4. GetCert . . . . . . . . . . . . . . . . . . . . . . . 21 88 3.3.5. GetCRL . . . . . . . . . . . . . . . . . . . . . . . 22 89 3.4. Degenerate certificates-only CMS Signed-Data . . . . . . 22 90 3.5. CA Capabilities . . . . . . . . . . . . . . . . . . . . . 22 91 3.5.1. GetCACaps HTTP Message Format . . . . . . . . . . . . 22 92 3.5.2. CA Capabilities Response Format . . . . . . . . . . . 23 93 4. SCEP Transactions . . . . . . . . . . . . . . . . . . . . . . 25 94 4.1. HTTP GET and POST Message Formats . . . . . . . . . . . . 25 95 4.2. Get CA Certificate . . . . . . . . . . . . . . . . . . . 26 96 4.2.1. Get CA Certificate Response Message Format . . . . . 26 97 4.2.1.1. CA Certificate Response Message Format . . . . . 26 98 4.2.1.2. CA Certificate Chain Response Message Format . . 26 99 4.3. Certificate Enrolment/Renewal/Update . . . . . . . . . . 27 100 4.3.1. Certificate Enrolment/Renewal/Update Response Message 27 101 4.4. Poll for Client Initial Certificate . . . . . . . . . . . 28 102 4.4.1. Polling Response Message Format . . . . . . . . . . . 28 103 4.5. Certificate Access . . . . . . . . . . . . . . . . . . . 29 104 4.5.1. Certificate Access Response Message Format . . . . . 29 105 4.6. CRL Access . . . . . . . . . . . . . . . . . . . . . . . 29 106 4.6.1. CRL Access Response Message Format . . . . . . . . . 29 107 4.7. Get Next Certification Authority Certificate . . . . . . 29 108 4.7.1. Get Next CA Response Message Format . . . . . . . . . 30 109 5. SCEP State Transitions . . . . . . . . . . . . . . . . . . . 30 110 6. Contributors/Acknowledgements . . . . . . . . . . . . . . . . 34 111 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 112 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 113 8.1. General Security . . . . . . . . . . . . . . . . . . . . 34 114 8.2. Use of the CA keypair . . . . . . . . . . . . . . . . . . 35 115 8.3. Challenge Password . . . . . . . . . . . . . . . . . . . 35 116 8.4. Lack of Certificate Issue Confirmation . . . . . . . . . 35 117 8.5. GetCACaps Issues . . . . . . . . . . . . . . . . . . . . 35 118 8.6. Lack of PoP in Renewal and Update Requests . . . . . . . 36 119 8.7. Unnecessary cryptography . . . . . . . . . . . . . . . . 36 120 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 121 9.1. Normative References . . . . . . . . . . . . . . . . . . 36 122 9.2. Informative References . . . . . . . . . . . . . . . . . 37 123 Appendix A. Background Notes . . . . . . . . . . . . . . . . . . 38 124 Appendix B. Sample SCEP Messages . . . . . . . . . . . . . . . . 40 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 127 1. Introduction 129 X.509 certificates serve as the basis for several standards-based 130 security protocols in the IETF, such as TLS [16], S/MIME [13], and 131 and IKE/IPsec [12]. When an X.509 certificate is issued by other 132 than the certificate subject (a self-issued certificate), there 133 typically is a need for a certificate management protocol. Such a 134 protocol enables a PKI client to request a certificate, certificate 135 renewal, or certificate update from a Certification 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 can 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 limited functionality, also makes deployment relatively 153 straightforward, so that it enjoys widespread support and ready 154 interoperability across a range of platforms. While implementers are 155 encouraged to investigate one of the more comprehensive alternative 156 certificate management protocols in addition to the protocol defined 157 in this specification, anyone wishing to deploy them should proceed 158 with caution, and consider support and interoperability issues before 159 committing to their use. 161 The 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 186 o The client requesting a certificate (Section 2.1.1). 187 o The Certification Authority (CA) that issues the certificate 188 (Section 2.1.2). 190 2.1.1. Client 192 A client MUST have the following information locally configured: 194 1. The CA fully qualified domain name or IP address. 195 2. The CA HTTP CGI script path (this usually has a default value, 196 see Section 4.1). 197 3. The identifying information that is used for authentication of 198 the CA in Section 4.2.1, typically a certificate fingerprint. 199 This information MAY be obtained from the user, or presented to 200 the user for manual authorization during the protocol exchange. 201 For example the user may indicate acceptance of a fingerprint via 202 a user-interface element. 204 2.1.2. Certification Authority 206 A SCEP Certification Authority (CA) is the entity that signs client 207 certificates. A CA MAY enforce any arbitrary policies and apply them 208 to certification requests. The CA MAY reject any request. 210 Since the client is expected to perform signature verification and 211 optionally encryption using the CA certificate, the keyUsage 212 extension in the CA certificate MUST indicate that it is valid for 213 digitalSignature and keyEncipherment (if required) alongside the 214 usual CA usages of keyCertSign and/or cRLSign. 216 If a client times out from polling for a pending request it can 217 resynchronize by reissuing the original request with the original 218 subject name, key, and transactionID. The CA SHOULD return the 219 status of the original transaction, including the certificate if it 220 was granted. 222 2.1.3. CA Certificate Distribution 224 If the CA certificate(s) have not previously been acquired by the 225 client through some other means, the client MUST retrieve the CA 226 certificate(s) before any PKI operation (Section 3) can be started. 228 Since no public key has yet been exchanged between the client and the 229 CA, the messages cannot be secured using CMS, and the data is instead 230 transferred in the clear. 232 If an intermediate CA is in use, a certificates-only CMS Signed-Data 233 message with a certificate chain consisting of all CA certificates is 234 returned. Otherwise the CA certificate itself is returned. The 235 transport protocol (Section 4) MUST indicate which one is returned. 237 The SCEP server CA certificate MAY be provided out-of-band to the 238 SCEP client. Alternatively, the CA certificate fingerprint MAY be 239 used to authenticate a CA Certificate distributed by the GetCACert 240 response (Section 4.2) or via HTTP certificate-store access [11]. 241 The fingerprint is created by calculating a SHA-256 hash over the 242 whole CA certificate (for legacy reasons, a SHA-1 hash may be used by 243 some implementations). 245 After the client gets the CA certificate, it SHOULD authenticate the 246 certificate by comparing its fingerprint with the locally configured, 247 out-of-band distributed, identifying information. Intermediate CA 248 certificates, if any, are signed by a higher-level CA so there is no 249 need to authenticate them against the out-of-band data. Clients 250 SHOULD verify intermediate-level CA certificate signatures using the 251 issuing CA's certificate before use during protocol exchanges. 253 Because a long time can pass between queries from a client to a CA 254 and because intermediate CA certificates can change over time, it is 255 recommended that a client not store intermediate CA certificates. 256 Instead, the client SHOULD retrieve the CA certificates before each 257 operation. 259 2.2. Client authentication 261 As with every protocol that uses public-key cryptography, the 262 association between the public keys used in the protocol and the 263 identities with which they are associated must be authenticated in a 264 cryptographically secure manner. The communication between the 265 client and the CA are secured using SCEP Secure Message Objects as 266 explained in Section 3, which specifies how CMS is used to encrypt 267 and sign the data. In order to perform the signing operation the 268 client uses an appropriate local certificate: 270 1. If the client does not have an appropriate existing certificate 271 then a locally generated self-signed certificate MUST be used. 272 The keyUsage extension in the certificate MUST indicate that it 273 is valid for digitalSignature and keyEncipherment (if required). 274 The self-signed certificate SHOULD use the same subject name as 275 in the PKCS #10 request. In this case the messageType is 276 PKCS10Req (see Section 3.2.1.2). 277 2. If the requesting system already has a certificate issued by the 278 SCEP CA, and the CA supports renewal (see Section 2.4), that 279 certificate SHOULD be used. In this case the messageType is 280 RenewalReq (see Section 3.2.1.2). 281 3. If the requesting system has no certificate issued by the new CA, 282 but has credentials from an alternate CA the certificate issued 283 by the alternate CA MAY be used. Policy settings on the new CA 284 will determine if the request can be accepted or not. This is 285 useful when enrolling with a new administrative domain using a 286 certificate from the old domain as credentials. In this case the 287 messageType is UpdateReq (see Section 3.2.1.2). 289 Note that although the above text describes three different types of 290 operations, in practice most implementations always apply the first 291 one even if an existing certificate already exists. For this reason 292 support for the first case is mandatory while support for the latter 293 two are optional (see Section 2.8). 295 During the certificate enrolment process, the client MUST use the 296 selected certificate's key when signing the CMS envelope (see 297 Section 3). This certificate will be either the self-signed one 298 matching the PKCS #10 request or the CA-issued one used to authorise 299 a renewal or update. If the key being certified allows encryption 300 then the CA's CertResp will use the same certificate's public key 301 when encrypting the response. 303 Note that this means that, in the case of renewal and update 304 operations, the request is signed with, and the returned response may 305 be encrypted with, the key in the previously-issued certificate used 306 to authenticate the request, not the key in the PKCS #10 request. 307 This has security implications, see Section 8.6. 309 2.3. Enrolment authorization 311 PKCS #10 [6] specifies a PKCS #9 [5] challengePassword attribute to 312 be sent as part of the enrolment request. When utilizing the 313 challengePassword, the CA distributes a shared secret to the client 314 which will uniquely associate the enrolment request with the client. 316 Inclusion of the challengePassword by the SCEP client is OPTIONAL and 317 allows for unauthenticated authorization of enrolment requests 318 (which, however, requires manual approval of each certificate issue, 319 see below), or for renewal or update requests which are authenticated 320 by being signed with an existing certificate. The CMS envelope 321 protects the privacy of the challengePassword. 323 A client that is performing certificate renewal or update as per 324 Section 2.4 SHOULD omit the challengePassword but MAY send the 325 originally distributed password in the challengePassword attribute. 326 In the former case the SCEP CA MUST authenticate the request based on 327 the certificate used to sign the renewal or update request. In the 328 latter case the SCEP CA MAY use either the challengePassword or the 329 previously issued certificate (or both), depending on CA policy, to 330 authenticate the request. The SCEP CA MUST NOT attempt to 331 authenticate a client based on a self-signed certificate unless it 332 has been verified through out-of-band means such as a certificate 333 fingerprint. 335 To perform the authorization in manual mode the client's messages are 336 placed in the PENDING state until the CA operator authorizes or 337 rejects them. Manual authorization is used when the client has only 338 a self-signed certificate that hasn't been previously authenticated 339 by the CA and/or a challengePassword is not available. The SCEP CA 340 MAY either reject unauthorized certification requests or mark them 341 for manual authorization according to CA policy. 343 2.4. Certificate Enrolment/Renewal/Update 345 A client starts an enrolment transaction (Section 3.3.1) by creating 346 a certificate request using PKCS #10 and sends it to the CA enveloped 347 using CMS (Section 3). 349 If the CA supports certificate renewal or update then a new 350 certificate with new validity dates can be issued, even though the 351 old one is still valid, if the CA policy permits. The CA MAY 352 automatically revoke the old client certificate. To renew or update 353 an existing certificate, the client uses the RenewalReq or UpdateReq 354 message (see Section 3.3) and signs it with the existing client 355 certificate. The client SHOULD use a new keypair when requesting a 356 new certificate, but MAY request a new certificate using the old 357 keypair. 359 If the CA returns a CertRep message (Section 3.3.2) with status set 360 to PENDING, the client enters into polling mode by periodically 361 sending a CertPoll message (Section 3.3.3) to the CA until the CA 362 operator completes the manual authentication (approving or denying 363 the request). 365 If polling mode is being used then the client will send a single 366 PKCSReq/RenewalReq/UpdateReq message (Section 3.3.1), followed by 0 367 or more CertPoll messages (Section 3.3.3). The CA will in return 368 send 0 or more CertRep messages (Section 3.3.2) with status set to 369 PENDING in response to CertPolls, followed by a single CertRep 370 message (Section 3.3.2) with status set to either SUCCESS or FAILURE. 372 2.4.1. Client State Transitions 374 The client state transitions during the SCEP process are indicated in 375 Figure 1. 377 CertPoll 378 +-----<----+ 379 | | CertRep(PENDING) or 380 | | CertPoll timeout 381 | | 382 [CERT-NONEXISTENT] ------> [CERT-REQ-PENDING] ---------> [CERT-ISSUED] 383 ^ PKCSReq | CertRep(SUCCESS) 384 | RenewalReq | 385 | UpdateReq | 386 | | 387 +-----------------------+ 388 CertRep(FAILURE) or 389 Max-time/max-polls exceeded 391 Figure 1: State Transition Diagram 393 The certificate issue process starts at the state CERT-NONEXISTENT. 394 Sending a PKCSReq/RenewalReq/UpdateReq message changes the state to 395 CERT-REQ-PENDING. 397 If the CA returns a CertRep message with pkiStatus set to SUCCESS 398 then the state changes to CERT-ISSUED. 400 If the CA returns a CertRep message with pkiStatus set to FAILURE or 401 there is no response then the state reverts back to CERT-NONEXISTENT. 403 If the CA returns a CertRep message with pkiStatus set to PENDING 404 then the client will keep polling by sending a CertPoll message until 405 either a CertRep message with status set to SUCCESS or FAILURE is 406 received or a timeout occurs or the maximum number of polls has been 407 exceeded. 409 A successful transaction in automatic mode: 411 CLIENT CA SERVER 413 PKCSReq: PKI cert. enrolment message 414 --------------------------------> CertRep: pkiStatus = SUCCESS 415 Certificate attached 416 <------------------------------ 417 Receive issued certificate. 419 A successful transaction in manual mode: 421 CLIENT CA SERVER 423 PKCSReq: PKI cert. enrolment message 424 --------------------------------> CertRep: pkiStatus = PENDING 425 <------------------------------ 426 CertPoll: Polling message 427 --------------------------------> CertRep: pkiStatus = PENDING 428 <------------------------------ 429 ................ ............... 431 CertPoll: Polling message 432 --------------------------------> CertRep: pkiStatus = SUCCESS 433 Certificate attached 434 <------------------------------ 435 Receive issued certificate. 437 2.5. Certificate Access 439 A certificate query message is defined for clients to retrieve a copy 440 of their own certificate from the CA. It allows clients that do not 441 store their certificates locally to obtain a copy when needed. This 442 functionality is not intended to provide a general purpose 443 certificate access service, which may be achieved via HTTP 444 certificate-store access [11] or LDAP. 446 To query a certificate from the CA, a client sends a request 447 consisting of the certificate's issuer name and serial number. This 448 assumes that the client has saved the issuer name and the serial 449 number of the issued certificate from the previous enrolment 450 transaction. The transaction to query a certificate consists of one 451 GetCert (Section 3.3.4) message and one CertRep (Section 3.3.2) 452 message, as shown below. 454 CLIENT CA SERVER 456 GetCert: PKI certificate query message 457 -------------------------------> CertRep: pkiStatus = SUCCESS 458 Certificate attached 459 <----------------------------- 460 Receive the certificate. 462 2.6. CRL Access 464 SCEP clients MAY request a CRL via one of three methods: 466 1. If the CA supports CRL Distribution Points (CRLDPs) [7], then the 467 CRL MAY be retrieved via the mechanism specified in the CRDLP. 468 2. If the CA supports HTTP certificate-store access [11], then the 469 CRL MAY be retrieved via the AuthorityInfoAcces [7] location 470 specified in the certificate. 471 3. Only if the CA does not support CRDLPs or HTTP access should a 472 CRL query be composed by creating a GetCRL message consisting of 473 the issuer name and serial number from the certificate whose 474 revocation status is being queried. 476 The CA SHOULD NOT support the GetCRL method because it does not scale 477 well due to the unnecessary cryptography (see Section 8) and it 478 requires the CA to be a high-availability service. 480 The message is sent to the SCEP CA in the same way as the other SCEP 481 requests. The transaction to retrieve a CRL consists of one GetCRL 482 PKI message and one CertRep PKI message, which contains only the CRL 483 (no certificates) in a degenerate certificates-only CMS Signed-Data 484 message (Section 3.4), as shown below. 486 CLIENT CA SERVER 488 GetCRL: PKI CRL query message 489 ----------------------------------> 490 CertRep: CRL attached 491 <----------------------------- 492 Receive the CRL 494 2.7. Certificate Revocation 496 SCEP does not specify a method to request certificate revocation. In 497 order to revoke a certificate, the client must contact the CA using a 498 non-SCEP defined mechanism. 500 2.8. Mandatory-to-Implement Functionality 502 At a minimum, all SCEP implementations compliant with this 503 specification MUST support GetCACaps (Section 3.5.1), GetCACert 504 (Section 4.2), PKCSReq (Section 3.3.1) (and its associated response 505 messages), communication of binary data via HTTP POST (Section 4.1), 506 and the AES and SHA-256 algorithms to secure pkiMessages 507 (Section 3.2). 509 For historical reasons implementations MAY support communications of 510 binary data via HTTP GET (Section 4.1), and the triple DES and SHA-1 511 algorithms to secure pkiMessages (Section 3.2). 513 3. SCEP Secure Message Objects 515 CMS is a general enveloping mechanism that enables both signed and 516 encrypted transmission of arbitrary data. SCEP messages that require 517 confidentiality use two layers of CMS, as shown in Figure 2. By 518 applying both enveloping and signing transformations, the SCEP 519 message is protected both for the integrity of its end-to-end 520 transaction information and the confidentiality of its information 521 portion. Some messages do not require enveloping, in which case the 522 EnvelopedData in Figure 2 is omitted. 524 pkiMessage { 525 contentType = signedData { pkcs-7 2 }, 526 content { 527 digestAlgorithms, 528 encapsulatedContentInfo { 529 eContentType = data { pkcs-7 1 }, 530 eContent { -- pkcsPKIEnvelope, optional 531 contentType = envelopedData { pkcs-7 3 }, 532 content { 533 recipientInfo, 534 encryptedContentInfo { 535 contentType = data { pkcs-7 1 }, 536 contentEncrAlgorithm, 537 encryptedContent { 538 messageData -- Typically PKCS #10 request 539 } 540 } 541 } 542 } 543 }, 544 certificates, -- Optional 545 crls, -- Optional 546 signerInfo { 547 signedAttrs { 548 transactionID, 549 messageType, 550 pkiStatus, 551 failInfo, -- Optional 552 senderNonce / recipientNonce, 553 }, 554 signature 555 } 556 } 557 } 559 Figure 2: CMS Layering 561 When a particular SCEP message carries data, this data is carried in 562 the messageData. CertRep messages will lack any signed content and 563 consist only of a pkcsPKIEnvelope (Section 3.2.2). 565 The remainder of this document will refer only to 'messageData', but 566 it is understood to always be encapsulated in the pkcsPKIEnvelope 567 (Section 3.2.2). The format of the data in the messageData is 568 defined by the messageType attribute (see Section 3.2) of the Signed- 569 Data. If there is no messageData to be transmitted, the entire 570 pkcsPKIEnvelope MUST be omitted. 572 3.1. SCEP Message Object Processing 574 Creating a SCEP message consists of several stages. The content to 575 be conveyed (in other words the messageData) is first encrypted, and 576 the encrypted content is then signed. 578 The form of encryption to be applied depends on the capabilities of 579 the recipient's public key. If the key is encryption-capable (for 580 example RSA) then the messageData is encrypted using the recipient's 581 public key with the CMS KeyTransRecipientInfo mechanism. If the key 582 is not encryption-capable (for example ECDSA) then the messageData is 583 encrypted using the challengePassword with the CMS 584 PasswordRecipientInfo mechanism. 586 Once the messageData has been encrypted, it is signed with the 587 sender's public key. This completes the SCEP message that is then 588 sent to the recipient. 590 Note that some earlier implementations of this specification dealt 591 with non-encryption-capable keys by omitting the encryption stage, 592 based on the text in Section 3 that indicated that "the EnvelopedData 593 is omitted". This alternative processing mechanism SHOULD NOT be 594 used since it exposes the challengePassword used to authorise the 595 certificate issue. 597 3.2. SCEP pkiMessage 599 The basic building block of all secured SCEP messages is the SCEP 600 pkiMessage. It consists of a CMS Signed-Data content type. The 601 following restrictions apply: 603 o The eContentType in encapsulatedContentInfo MUST be data ({pkcs-7 604 1}). 605 o The signed content, if present (FAILURE and PENDING CertRep 606 messages will lack any signed content), MUST be a pkcsPKIEnvelope 607 (Section 3.2.2), and MUST match the messageType attribute. 608 o The SignerInfo MUST contain a set of authenticatedAttributes (see 609 CMS as well as Section 3.2.1 in this document). 611 At a minimum, all messages MUST contain the following 612 authenticatedAttributes: 614 o A transactionID attribute (see Section 3.2.1.1). 615 o A messageType attribute (see Section 3.2.1.2). 616 o A fresh senderNonce attribute (see Section 3.2.1.5). 617 o Any attributes required by CMS. 619 If the message is a CertRep, it MUST also include the following 620 authenticatedAttributes: 622 o A pkiStatus attribute (see Section 3.2.1.3). 623 o A failInfo attribute (see Section 3.2.1.4) if pkiStatus = FAILURE. 624 o A recipientNonce attribute (see Section 3.2.1.5) copied from the 625 senderNonce in the request that this is a response to. 627 3.2.1. Signed Transaction Attributes 629 The following transaction attributes are encoded as authenticated 630 attributes, and are carried in the SignerInfo for this Signed-Data. 632 +----------------+-----------------+--------------------------------+ 633 | Attribute | Encoding | Comment | 634 +----------------+-----------------+--------------------------------+ 635 | transactionID | PrintableString | Unique ID for this transaction | 636 | | | as a text string | 637 | | | | 638 | messageType | PrintableString | Decimal value as a numeric | 639 | | | text string | 640 | | | | 641 | pkiStatus | PrintableString | Decimal value as a numeric | 642 | | | text string | 643 | | | | 644 | failInfo | PrintableString | Decimal value as a numeric | 645 | | | text string | 646 | | | | 647 | senderNonce | OCTET STRING | Random nonce as a 16-byte | 648 | | | binary data string | 649 | | | | 650 | recipientNonce | OCTET STRING | Random nonce as a 16-byte | 651 | | | binary data string | 652 +----------------+-----------------+--------------------------------+ 653 The OIDs used for these attributes are as follows: 655 +-------------------+-----------------------------------------------+ 656 | Name | ASN.1 Definition | 657 +-------------------+-----------------------------------------------+ 658 | id-VeriSign | OBJECT_IDENTIFIER ::= {2 16 US(840) 1 | 659 | | VeriSign(113733)} | 660 | | | 661 | id-pki | OBJECT_IDENTIFIER ::= {id-VeriSign pki(1)} | 662 | | | 663 | id-attributes | OBJECT_IDENTIFIER ::= {id-pki attributes(9)} | 664 | | | 665 | id-transactionID | OBJECT_IDENTIFIER ::= {id-attributes | 666 | | transactionID(7)} | 667 | | | 668 | id-messageType | OBJECT_IDENTIFIER ::= {id-attributes | 669 | | messageType(2)} | 670 | | | 671 | id-pkiStatus | OBJECT_IDENTIFIER ::= {id-attributes | 672 | | pkiStatus(3)} | 673 | | | 674 | id-failInfo | OBJECT_IDENTIFIER ::= {id-attributes | 675 | | failInfo(4)} | 676 | | | 677 | id-senderNonce | OBJECT_IDENTIFIER ::= {id-attributes | 678 | | senderNonce(5)} | 679 | | | 680 | id-recipientNonce | OBJECT_IDENTIFIER ::= {id-attributes | 681 | | recipientNonce(6)} | 682 +-------------------+-----------------------------------------------+ 684 The attributes are detailed in the following sections. 686 3.2.1.1. transactionID 688 A PKI operation is a transaction consisting of the messages exchanged 689 between a client and the CA. The transactionID is a text string 690 generated by the client when starting a transaction. The client MUST 691 generate a unique string as the transaction identifier, encoded as a 692 PrintableString, which MUST be used for all PKI messages exchanged 693 for a given operation such as a certificate issue. 695 3.2.1.2. messageType 697 The messageType attribute specifies the type of operation performed 698 by the transaction. This attribute MUST be included in all PKI 699 messages. The following message types are defined: 701 o CertRep ("3") -- Response to certificate or CRL request. 702 o RenewalReq ("17") -- PKCS #10 certificate request for renewal of 703 an existing certificate. 704 o UpdateReq ("18") -- PKCS #10 certificate request for update of a 705 certificate issued by a different CA. 706 o PKCSReq ("19") -- PKCS #10 certificate request. 707 o CertPoll ("20") -- Certificate polling in manual enrolment. 708 o GetCert ("21") -- Retrieve a certificate. 709 o GetCRL ("22") -- Retrieve a CRL. 711 Undefined message types MUST BE treated as an error. 713 3.2.1.3. pkiStatus 715 All response messages MUST include transaction status information, 716 which is defined as a pkiStatus attribute: 718 o SUCCESS ("0") -- Request granted. 719 o FAILURE ("2") -- Request rejected. In this case the failInfo 720 attribute, as defined in Section 3.2.1.4, MUST also be present. 721 o PENDING ("3") -- Request pending for manual approval. 723 Undefined pkiStatus attributes MUST be treated as an error. 725 3.2.1.4. failInfo 727 The failInfo attribute MUST contain one of the following failure 728 reasons: 730 o badAlg ("0") -- Unrecognized or unsupported algorithm. 731 o badMessageCheck ("1") -- Integrity check (meaning signature 732 verification of the CMS message) failed. 733 o badRequest ("2") -- Transaction not permitted or supported. 734 o badTime ("3") -- The signingTime attribute from the CMS 735 authenticatedAttributes was not sufficiently close to the system 736 time (this failure code is present for legacy reasons and is 737 unlikely to be encountered in practice). 738 o badCertId ("4") -- No certificate could be identified matching the 739 provided criteria. 741 [Question: Is there any demand for a free-form UTF8String 742 attribute to explain what really went wrong? Trying to sort 743 out an error when all you ever get back is the near-universal 744 badRequest is almost impossible, adding a failInfoText 745 attribute to address this could be quite useful since it 746 would allow expressing information such as a failure to meet 747 CA policy, or indeed anything more complex than "no go away"]. 749 Undefined failInfo attributes are treated as an error. 751 3.2.1.5. senderNonce and recipientNonce 753 The attributes of senderNonce and recipientNonce are a 16 byte random 754 number generated for each transaction. These are intended to prevent 755 replay attacks. 757 When a sender sends a PKI message to a recipient, a fresh senderNonce 758 MUST be included in the message. The recipient MUST copy the 759 senderNonce into the recipientNonce of the reply as a proof of 760 liveliness. The original sender MUST verify that the recipientNonce 761 of the reply matches the senderNonce it sent in the request. If the 762 nonce does not match, the message MUST be rejected. 764 Note that since SCEP exchanges consist of a single request followed 765 by a single response, the use of distinct sender and recipient nonces 766 is redundant since the client sends a nonce in its request and the CA 767 responds with the same nonce in its reply. In effect there's just a 768 single nonce, identified as senderNonce in the client's request and 769 recipientNonce in the CA's reply. 771 3.2.2. SCEP pkcsPKIEnvelope 773 The information portion of a SCEP message is carried inside an 774 EnvelopedData content type, as defined in CMS, with the following 775 restrictions: 777 o contentType in encryptedContentInfo MUST be data ({pkcs-7 1}). 778 o encryptedContent MUST be the SCEP message being transported (see 779 Section 4), and must match the messageType authenticated Attribute 780 in the pkiMessage. 782 3.3. SCEP pkiMessage types 784 All of the messages in this section are pkiMessages (Section 3.2), 785 where the type of the message MUST be specified in the 'messageType' 786 authenticated Attribute. Each section defines a valid message type, 787 the corresponding messageData formats, and mandatory authenticated 788 attributes for that type. 790 3.3.1. PKCSReq/RenewalReq/UpdateReq 792 The messageData for this type consists of a PKCS #10 Certification 793 Request. The certification request MUST contain at least the 794 following items: 796 o The subject Distinguished Name. 798 o The subject public key. 799 o For a PKCSReq and if authorisation based on a password is being 800 used, a challengePassword attribute. 802 In addition to the authenticatedAttributes required for a valid CMS 803 message, the pkiMessage MUST include the following attributes: 805 o A transactionID attribute (Section 3.2.1.1). 806 o A messageType attribute (Section 3.2.1.2) set to PKCSReq, 807 RenewalReq, or UpdateReq as appropriate. 808 o A fresh senderNonce attribute (Section 3.2.1.5). 810 3.3.2. CertRep 812 The messageData for this type consists of a degenerate certificates- 813 only CMS Signed-Data message (Section 3.4). The exact content 814 required for the reply depends on the type of request this message is 815 a response to. The request types are detailed in Section 3.3.2.1 and 816 in Section 4. 818 In addition to the authenticatedAttributes required for a valid CMS 819 message, this pkiMessage MUST include the following attributes: 821 o The transactionID attribute (Section 3.2.1.1) copied from the 822 request that this is a response to. 823 o A messageType attribute (Section 3.2.1.2) set to CertRep. 824 o A recipientNonce attribute (Section 3.2.1.5) copied from the 825 senderNonce in the request that this is a response to. 826 o A pkiStatus attribute (Section 3.2.1.3) set to the status of the 827 reply. 829 Earlier versions of this specification required that this message 830 include a senderNonce alongside the recipientNonce, which was to be 831 used to chain to subsequent polling operations. However if a single 832 message was lost during the potentially extended interval over which 833 polling could take place (see Section 5 for an example of this) then 834 if the implementation were to enforce this requirement the overall 835 transaction would fail even though nothing had actually gone wrong. 836 Because of this issue, implementations mostly ignored the requirement 837 to carry this nonce over to subsequent polling messages or to verify 838 its presence. Current versions of the specification no longer 839 require the chaining of nonces across polling operations. 841 3.3.2.1. CertRep SUCCESS 843 When the pkiStatus attribute is set to SUCCESS, the messageData for 844 this message consists of a degenerate certificates-only CMS Signed- 845 Data message (Section 3.4). The content of this degenerate 846 certificates-only Signed-Data depends on what the original request 847 was, as outlined below. 849 +--------------+----------------------------------------------------+ 850 | Request-type | Reply-contents | 851 +--------------+----------------------------------------------------+ 852 | PKCSReq | The reply MUST contain at least the issued | 853 | | certificate in the certificates field of the | 854 | | Signed-Data. The reply MAY contain additional | 855 | | certificates, but the issued certificate MUST be | 856 | | the leaf certificate. | 857 | | | 858 | RenewalReq | Same as PKCSReq | 859 | | | 860 | UpdateReq | Same as PKCSReq | 861 | | | 862 | CertPoll | Same as PKCSReq | 863 | | | 864 | GetCert | The reply MUST contain at least the requested | 865 | | certificate in the certificates field of the | 866 | | Signed-Data. The reply MAY contain additional | 867 | | certificates, but the requested certificate MUST | 868 | | be the leaf certificate. | 869 | | | 870 | GetCRL | The reply MUST contain the CRL in the crls field | 871 | | of the Signed-Data. | 872 +--------------+----------------------------------------------------+ 874 3.3.2.2. CertRep FAILURE 876 When the pkiStatus attribute is set to FAILURE, the reply MUST also 877 contain a failInfo (Section 3.2.1.4) attribute set to the appropriate 878 error condition describing the failure. The pkcsPKIEnvelope 879 (Section 3.2.2) MUST be omitted. 881 3.3.2.3. CertRep PENDING 883 When the pkiStatus attribute is set to PENDING, the pkcsPKIEnvelope 884 (Section 3.2.2) MUST be omitted. 886 3.3.3. CertPoll (GetCertInitial) 888 This message is used for certificate polling. For unknown reasons it 889 was referred to as "GetCertInitial" in earlier versions of this 890 specification. The messageData for this type consists of an 891 IssuerAndSubject: 893 issuerAndSubject ::= SEQUENCE { 894 issuer Name, 895 subject Name 896 } 898 The issuer is set to the subjectName of the CA (in other words the 899 intended issuerName of the certificate that's being requested). The 900 subject is set to the subjectName used when requesting the 901 certificate. 903 Note that both of these fields are redundant, the CA is identified by 904 the recipientInfo in the pkcsPKIEnvelope (or in most cases simply by 905 the server that the message is sent to) and the client/transaction 906 being polled is identified by the transactionID. Both of these 907 fields can be processed by the CA without having to unwrap and 908 process the issuerAndSubject. For this reason implementations SHOULD 909 assume that the polling operation will be controlled by the 910 recipientInfo and transactionID rather than the contents of the 911 messageData. 913 In addition to the authenticatedAttributes required for a valid CMS 914 message, this pkiMessage MUST include the following attributes: 916 o The same transactionID (Section 3.2.1.1) attribute from the 917 original PKCSReq/RenewalReq/UpdateReq message. 918 o A messageType attribute (Section 3.2.1.2) set to CertPoll. 919 o A fresh senderNonce attribute (Section 3.2.1.5). 921 3.3.4. GetCert 923 The messageData for this type consists of an IssuerAndSerialNumber as 924 defined in CMS which uniquely identifies the certificate being 925 requested. In addition to the authenticatedAttributes required for a 926 valid CMS message, this pkiMessage MUST include the following 927 attributes: 929 o A transactionID attribute (Section 3.2.1.1). 930 o A messageType attribute (Section 3.2.1.2) set to GetCert. 931 o A fresh senderNonce attribute (Section 3.2.1.5). 933 A self-signed certificate MAY be used in the signed envelope. This 934 enables the client to request their own certificate if they were 935 unable to store it previously. 937 This message type, while included here for completeness, applies 938 unnecessary cryptography and messaging overhead to the simple task of 939 transferring a certificate. Implementations SHOULD prefer HTTP 940 certificate-store access [11] or LDAP over the use of this message. 942 3.3.5. GetCRL 944 The messageData for this type consists of a IssuerAndSerialNumber as 945 defined in CMS containing the issuer name and serial number of the 946 certificate whose revocation status is being checked. 948 In addition to the authenticatedAttributes required for a valid CMS 949 message, this pkiMessage MUST include the following attributes: 951 o A transactionID attribute (Section 3.2.1.1). 952 o A messageType attribute (Section 3.2.1.2) set to GetCRL. 953 o A fresh senderNonce attribute (Section 3.2.1.5). 955 This message type, while included here for completeness, applies 956 unnecessary cryptography and messaging overhead to the simple task of 957 transferring a CRL. Implementations SHOULD prefer HTTP certificate- 958 store access [11] or LDAP over the use of this message. 960 3.4. Degenerate certificates-only CMS Signed-Data 962 CMS includes a degenerate case of the Signed-Data content type in 963 which there are no signers. The use of such a degenerate case is to 964 disseminate certificates and CRLs. For SCEP the content field of the 965 ContentInfo value of a degenerate certificates-only Signed-Data MUST 966 be omitted. 968 When carrying certificates, the certificates are included in the 969 'certificates' field of the Signed-Data. When carrying a CRL, the 970 CRL is included in the 'crls' field of the Signed-Data. 972 3.5. CA Capabilities 974 In order to provide support for future enhancements to the protocol, 975 CAs MUST implement the GetCACaps message to allow clients to query 976 which functionality is available from the CA. 978 3.5.1. GetCACaps HTTP Message Format 980 This message requests capabilities from a CA, with the format: 982 "GET" CGI-PATH CGI-PROG "?operation=GetCACaps" 984 with the message components as described in Section 4. 986 3.5.2. CA Capabilities Response Format 988 The response for a GetCACaps message is a list of CA capabilities, in 989 plain text, separated by or characters, as follows 990 (quotation marks are NOT sent): 992 +--------------------+----------------------------------------------+ 993 | Keyword | Description | 994 +--------------------+----------------------------------------------+ 995 | "AES" | CA supports the AES encryption algorithm. | 996 | | | 997 | "DES3" | CA supports the triple DES encryption | 998 | | algorithm. | 999 | | | 1000 | "GetNextCACert" | CA supports the GetNextCACert message. | 1001 | | | 1002 | "POSTPKIOperation" | CA supports PKIOPeration messages sent via | 1003 | | HTTP POST. | 1004 | | | 1005 | "Renewal" | CA supports the Renewal CA operation. | 1006 | | | 1007 | "SHA-1" | CA supports the SHA-1 hashing algorithm. | 1008 | | | 1009 | "SHA-256" | CA supports the SHA-256 hashing algorithm. | 1010 | | | 1011 | "SHA-512" | CA supports the SHA-512 hashing algorithm. | 1012 | | | 1013 | "SCEPStandard" | CA supports all mandatory-to-implement | 1014 | | sections of the SCEP standard. This keyword | 1015 | | implies "AES", "POSTPKIOperation", and | 1016 | | "SHA-256", as well as the provisions of | 1017 | | Section 2.8. | 1018 | | | 1019 | "Update" | CA supports the Update CA operation. | 1020 +--------------------+----------------------------------------------+ 1022 The client SHOULD use SHA-256 in preference to SHA-1 hashing and AES 1023 in preference to triple DES if they are supported by the CA. 1024 Although the CMS format allows any form of SHA-2 and AES to be 1025 specified, in the interests of interoperability the de facto 1026 universal standards of AES128-CBC and SHA-256 SHOULD be used. 1028 Announcing some of these capabilities individually is redundant since 1029 they're required as mandatory-to-implement functionality (see 1030 Section 2.8) whose presence as a whole is signalled by the 1031 "SCEPStandard" capability, but it may be useful to announce them in 1032 order to deal with old implementations that would otherwise default 1033 to obsolete, insecure algorithms and mechanisms. 1035 The CA MUST use the text case specified here, but clients SHOULD 1036 ignore the text case when processing this message. Clients MUST 1037 accept the standard HTTP-style -delimited text as well as the 1038 - delimited text specified in an earlier version of this 1039 specification. A client MUST be able to accept and ignore any 1040 unknown keywords that might be sent back by a CA. 1042 If the CA supports none of the above capabilities it SHOULD return an 1043 empty message. A CA MAY simply return an HTTP error. A client that 1044 receives an empty message or an HTTP error SHOULD interpret the 1045 response as if none of the requested capabilities are supported by 1046 the CA. 1048 (Note that at least one widely-deployed server implementation 1049 supports several of the above operations but doesn't support the 1050 GetCACaps message to indicate that it supports them. This means that 1051 the equivalent of GetCACaps must be performed through server 1052 fingerprinting, which can be done using the ID string "Microsoft- 1053 IIS"). 1055 The Content-type of the reply SHOULD be "text/plain". Clients SHOULD 1056 ignore the Content-type, as older implementations of SCEP may send 1057 various Content-types. 1059 Example: 1061 GET /cgi-bin/pkiclient.exe?operation=GetCACaps 1063 might return: 1065 AES 1066 GetNextCACert 1067 POSTPKIOperation 1068 SCEPStandard 1069 SHA-256 1071 This means that the CA supports modern crypto algorithms, the 1072 GetNextCACert message, and allows PKIOperation messages 1073 (PKCSReq/RenewalReq/UpdateReq, GetCert, CertPoll, ...) to be sent 1074 using HTTP POST, and is compliant with the final version of the SCEP 1075 standard. 1077 4. SCEP Transactions 1079 This section describes the SCEP Transactions and their HTTP [4] 1080 transport mechanism. 1082 4.1. HTTP GET and POST Message Formats 1084 SCEP uses the HTTP "GET" and "POST" messages to exchange information 1085 with the CA. The following defines the syntax of HTTP GET and POST 1086 messages sent from a client to a CA: 1088 "GET" CGI-PATH CGI-PROG "?operation=" OPERATION "&message=" MESSAGE 1089 "POST" CGI-PATH CGI-PROG "?operation=" OPERATION 1091 where: 1093 o CGI-PATH defines the actual CGI path to invoke the CGI program 1094 that parses the request. 1095 o CGI-PROG is set to be the string "pkiclient.exe". This is 1096 intended to be the program that the CA will use to handle the SCEP 1097 transactions, though the CA may ignore CGI-PROG and use only the 1098 CGI-PATH, or ignore both if it's not issuing certificates via a 1099 web server. Typically, setting CGI-PATH/CGI-PROG to "/cgi-bin/ 1100 pkiclient.exe" will satisfy most servers. 1101 o OPERATION depends on the SCEP transaction and is defined in the 1102 following sections. 1103 o MESSAGE depends on the SCEP transaction and is defined in the 1104 following sections. 1106 Early SCEP drafts performed all communications via "GET" messages, 1107 including non-idempotent ones that should have been sent via "POST" 1108 messages. This has caused problems because of the way that the 1109 (supposedly) idempotent GET interacts with caches and proxies, and 1110 because the extremely large GET requests created by encoding CMS 1111 messages may be truncated in transit. These issues are typically not 1112 visible when testing on a LAN, but crop up during deployment over 1113 WANs. If the remote CA supports it, any of the CMS-encoded SCEP 1114 messages SHOULD be sent via HTTP POST instead of HTTP GET. This 1115 applies to any SCEP message except GetCACert, GetNextCACert, and 1116 GetCACaps, and avoids the need for base64- and URL-encoding that's 1117 required for GET messaging. The client can verify that the CA 1118 supports SCEP messages via POST by looking for the "POSTPKIOperation" 1119 capability (See Section 3.5.2). 1121 If a client or CA uses HTTP GET and encounters HTTP-related problems 1122 such as messages being truncated, seeing errors such as HTTP 414 1123 ("Request URI too long"), or simply having the message not sent/ 1124 received at all, when standard requests to the server (for example 1125 via a web browser) work, then this is a symptom of the problematic 1126 use of HTTP GET. The solution to this problem is typically to move 1127 to HTTP POST instead. In addition when using GET it's recommended to 1128 test your implementation over the public internet from as many 1129 locations as possible to determine whether the use of GET will cause 1130 problems with communications. 1132 When using GET messages to communicate binary data, base64 encoding 1133 as specified in [2] MUST be used. The base64 encoded data is 1134 distinct from "base64url" and may contain URI reserved characters, 1135 thus it MUST be escaped as specified in [8] in addition to being 1136 base64 encoded. 1138 4.2. Get CA Certificate 1140 To get the CA certificate(s), the client sends a GetCACert message to 1141 the CA. The OPERATION MUST be set to "GetCACert". There is no 1142 request data associated with this message. 1144 4.2.1. Get CA Certificate Response Message Format 1146 The response for GetCACert is different between the case where the CA 1147 directly communicates with the client during the enrolment, and the 1148 case where an intermediate CA exists and the client communicates with 1149 this CA during the enrolment. If the client does not have a 1150 certificate path to a trust anchor certificate, the fingerprint of 1151 the returned CA certificate, communicated via out-of-band means, MAY 1152 be used to verify it. 1154 4.2.1.1. CA Certificate Response Message Format 1156 If the CA does not have any intermediate CA certificates, the 1157 response consists of a single X.509 CA certificate. The response 1158 will have a Content-Type of "application/x-x509-ca-cert". 1160 "Content-Type: application/x-x509-ca-cert" 1162 1164 4.2.1.2. CA Certificate Chain Response Message Format 1166 If the CA has intermediate CA certificates, the response consists of 1167 a degenerate certificates-only CMS Signed-Data message (Section 3.4) 1168 containing the certificates, with the intermediate CA certificate(s) 1169 as the leaf certificate(s). The response will have a Content-Type of 1170 "application/x-x509-ca-ra-cert". Note that this designation is used 1171 for historical reasons due to its use in older versions of this 1172 specification, no special meaning should be attached to the label. 1174 "Content-Type: application/x-x509-ca-ra-cert" 1176 1178 4.3. Certificate Enrolment/Renewal/Update 1180 A PKCSReq/RenewalReq/UpdateReq (Section 3.3.1) message is used to 1181 perform a certificate enrolment, renewal, or update transaction. The 1182 reply MUST be a CertRep (Section 3.3.2) message sent back from the 1183 CA, indicating SUCCESS, FAILURE, or PENDING. 1185 The OPERATION MAY be set to "PKIOperation". When used with HTTP 1186 POST, the only OPERATION possible is "PKIOperation", so many CAs 1187 don't check this value or even notice its absence. 1189 The MESSAGE consists of a PKCSReq, RenewalReq, or UpdateReq SCEP 1190 message. When implemented using HTTP POST this might look as 1191 follows: 1193 POST /cgi-bin/pkiclient.exe?operation=PKIOperation HTTP/1.1 1194 Content-Length: 1196 1198 When implemented using HTTP GET this might look as follows: 1200 GET /cgi-bin/pkiclient.exe?operation=PKIOperation& \ 1201 message=MIAGCSqGSIb3DQEHA6CAMIACAQAxgDCBzAIBADB2MG \ 1202 IxETAPBgNVBAcTCE......AAAAAA== HTTP/1.1 1204 4.3.1. Certificate Enrolment/Renewal/Update Response Message 1206 If the request is granted, a CertRep message (Section 3.3.2) with 1207 pkiStatus set to SUCCESS is returned. The reply MUST also contain 1208 the certificate (and MAY contain any other certificates needed by the 1209 client). The issued certificate MUST be the first in the list. 1211 If the request is rejected, a CertRep message (Section 3.3.2) with 1212 pkiStatus set to FAILURE is returned. The reply MUST also contain a 1213 failInfo attribute. 1215 If the the CA is configured to manually authenticate the client, a 1216 CertRep message (Section 3.3.2) with pkiStatus set to PENDING MAY be 1217 returned. The CA MAY return a PENDING for other reasons. 1219 The response will have a Content-Type of "application/x-pki-message". 1221 "Content-Type: application/x-pki-message" 1223 1225 4.4. Poll for Client Initial Certificate 1227 Triggered by a CertRep message with pkiStatus set to PENDING, a 1228 client will enter the polling state by periodically sending CertPoll 1229 messages to the CA until either the request is granted and the 1230 certificate is sent back or the request is rejected or some 1231 preconfigured time limit for polling or maximum number of polls is 1232 exceeded. The OPERATION MUST be set to "PKIOperation". The MESSAGE 1233 consists of a CertPoll SCEP message. 1235 CertPoll messages exchanged during the polling period MUST carry the 1236 same transactionID attribute as the previous PKCSReq/RenewalReq/ 1237 UpdateReq. A CA receiving a CertPoll for which it does not have a 1238 matching PKCSReq/RenewalReq/UpdateReq MUST ignore this request. 1240 Since at this time the certificate has not been issued, the client 1241 can only use its own subject name (which was contained in the 1242 original PKCS# 10 sent via PKCSReq/RenewalReq/UpdateReq) to identify 1243 the polled certificate request (but see the note on identification 1244 during polling in Section 3.3.3). In theory there can be multiple 1245 outstanding requests from one client (for example, if different keys 1246 and different key-usages were used to request multiple certificates), 1247 so the transactionID must also be included to disambiguate between 1248 multiple requests. In practice however it's safer for the client to 1249 not have multiple requests outstanding at any one time, since this 1250 tends to confuse some CAs. 1252 4.4.1. Polling Response Message Format 1254 The response messages for CertPoll are the same as in Section 4.3.1. 1256 4.5. Certificate Access 1258 A client can query an issued certificate from the SCEP CA, as long as 1259 the client knows the issuer name and the issuer assigned certificate 1260 serial number. 1262 This transaction consists of one GetCert (Section 3.3.4) message sent 1263 to the CA by a client, and one CertRep (Section 3.3.2) message sent 1264 back from the CA. The OPERATION MUST be set to "PKIOperation". The 1265 MESSAGE consists of a GetCert SCEP message. 1267 4.5.1. Certificate Access Response Message Format 1269 In this case, the CertRep from the CA is same as in 1270 Section Section 4.3.1, except that the CA will only either grant the 1271 request (SUCCESS) or reject the request (FAILURE). 1273 4.6. CRL Access 1275 Clients can request a CRL from the SCEP CA as described in 1276 Section 2.6. The OPERATION MUST be set to "PKIOperation". The 1277 MESSAGE consists of a GetCRL SCEP message. 1279 4.6.1. CRL Access Response Message Format 1281 The CRL is sent back to the client in a CertRep (Section 3.3.2) 1282 message. The information portion of this message is a degenerate 1283 certificates-only Signed-Data (Section 3.4) that contains only the 1284 most recent CRL in the crls field of the Signed-Data. 1286 4.7. Get Next Certification Authority Certificate 1288 When the CA certificate expires all certificates that have been 1289 signed by it are no longer valid. CA key rollover provides a 1290 mechanism by which the CA MAY distribute a new CA certificate which 1291 is valid in the future when the current certificate has expired. 1292 When a CA certificate is about to expire, clients need to retrieve 1293 the CA's next CA certificate (i.e. the rollover certificate). This 1294 is done via the GetNextCACert message. The OPERATION MUST be set to 1295 "GetNextCACert". There is no request data associated with this 1296 message. 1298 Clients MAY store the not-yet-valid CA certificate, and any not-yet- 1299 valid client certificates obtained, until such time that they are 1300 valid, at which point clients switch over to using the newly valid 1301 certificates (but see the note in Section 2.1.3 about storing CA 1302 certificates). 1304 4.7.1. Get Next CA Response Message Format 1306 The response consists of a Signed-Data CMS message, signed by the 1307 current CA signing key. Clients MUST validate the signature on the 1308 message before accepting any of its contents. The response will have 1309 a Content-Type of "application/x-x509-next-ca-cert". 1311 "Content-Type: application/x-x509-next-ca-cert" 1313 1315 The content of the Signed-Data message is a degenerate certificates- 1316 only Signed-Data (Section 3.4) message containing the new CA 1317 certificate(s), to be used when the current CA certificate expires. 1319 If the CA does not have rollover certificate(s) it MUST reject the 1320 request. It SHOULD also remove the GetNextCACert setting from the 1321 capabilities until it does have rollover certificates. 1323 If there are any intermediate CA certificates in this response, 1324 clients MUST check that these certificates are signed by the CA, and 1325 MUST check authorization of these intermediate CA certificates (see 1326 Section 2.1.2). 1328 5. SCEP State Transitions 1330 The following section gives several examples of client to CA 1331 transactions. Client actions are indicated in the left column, CA 1332 actions are indicated in the right column, and the transactionID is 1333 given in parentheses. The first transaction, for example, would read 1334 like this: 1336 "Client Sends PKCSReq message with transactionID 1 to the CA. The CA 1337 signs the certificate and constructs a CertRep Message containing the 1338 signed certificate with a transaction ID 1. The client receives the 1339 message and installs the certificate locally". 1341 In the case of polled transactions that aren't completed 1342 automatically, there are two options for dealing with a transaction 1343 that's interrupted due to network or software/hardware issues. The 1344 first is for the client to preserve its transaction state and resume 1345 the polling when normal service is restored. The second is for the 1346 client to begin a new transaction by sending a PKCSReq/RenewalReq/ 1347 UpdateReq rather than continuing the previous CertPoll. Both options 1348 have their own advantages and disadvantages. 1350 The CertPoll continuation requires that the client maintain its 1351 transaction state for when it resumes polling. This is relatively 1352 simple if the problem is a brief network outage, but less simple when 1353 the problem is a client crash and restart. In addition the server 1354 may treat a lost network connection as the end of a transaction, so 1355 that a new connection followed by a CertPoll will be treated as an 1356 error. 1358 The PKCSReq/RenewalReq/UpdateReq continuation doesn't require any 1359 state to be maintained since it's a new transaction, however it may 1360 cause problems on the server side if the certificate was successfully 1361 issued but the client never received it, since the resumed 1362 transaction attempt will appear to be a request for a duplicate 1363 certificate (see Section 8.4 for more on why this is a problem). In 1364 this case the server may refuse the transaction, or require manual 1365 intervention to remove/revoke the previous certificate before the 1366 client can request another one. 1368 Successful Enrolment Case: Automatic processing 1370 PKCSReq (1) ----------> CA issues certificate 1371 <---------- CertRep (1) SUCCESS 1372 Client installs certificate 1374 Successful Enrolment Case: Manual authentication required 1376 PKCSReq (2) ----------> Cert request goes into queue 1377 <---------- CertRep (2) PENDING 1378 CertPoll (2) ----------> Still pending 1379 <---------- CertRep (2) PENDING 1380 CertPoll (2) ----------> CA issues certificate 1381 <---------- CertRep (2) SUCCESS 1382 Client installs certificate 1383 Resync Case 1: Client resyncs via resumed CertPoll after a network 1384 outage: 1386 PKCSReq (3) ----------> Cert request goes into queue 1387 <---------- CertRep (3) PENDING 1388 CertPoll (3) ----------> Still pending 1389 X-------- CertRep(3) PENDING 1390 (Network outage) 1391 (Client reconnects) 1392 CertPoll (3) ----------> CA issues certificate 1393 <---------- CertRep (3) SUCCESS 1394 Client installs certificate 1396 Resync Case 2: Client resyncs via new PKCSReq: 1398 PKCSReq (4) ----------> Cert request goes into queue 1399 <---------- CertRep (4) PENDING 1400 CertPoll (4) ----------> Still pending 1401 X-------- CertRep(4) PENDING 1402 (Network outage) 1403 (Client reconnects) 1404 PKCSReq (5) ----------> 1405 <---------- CertRep (5) PENDING 1406 etc... 1408 Resync Case 3: Special-case variation of case 1 where the CertRep 1409 SUCCESS rather than the CertRep PENDING is lost: 1411 PKCSReq (6) ----------> Cert request goes into queue 1412 <---------- CertRep (6) PENDING 1413 CertPoll (6) ----------> Still pending 1414 <---------- CertRep (6) PENDING 1415 CertPoll (6) ----------> CA issues certificate 1416 X-------- CertRep(6) SIGNED CERT 1417 (Network outage) 1418 (Client reconnects) 1419 CertPoll (6) ----------> Certificate already issued 1420 <---------- CertRep (6) SUCCESS 1421 Client installs certificate 1422 Resync Case 4: Special-case variation of case 2 where the CertRep 1423 SUCCESS rather than the CertRep PENDING is lost: 1425 PKCSReq (7) ----------> Cert request goes into queue 1426 <---------- CertRep (7) PENDING 1427 CertPoll (7) ----------> Still pending 1428 <---------- CertRep (7) PENDING 1429 CertPoll (7) ----------> CA issues certificate 1430 X-------- CertRep(7) SUCCESS 1431 (Network outage) 1432 (Client reconnects) 1433 PKCSReq (8) ----------> There is already a valid 1434 certificate with this DN. 1435 <---------- CertRep (8) FAILURE 1436 Admin revokes certificate 1437 PKCSReq (8) ----------> CA issues new certificate 1438 <---------- CertRep (8) SUCCESS 1439 Client installs certificate 1441 CA certificate rollover case: 1443 GetNextCACert ----------> 1444 <---------- New CA certificate 1446 PKCSReq* ----------> CA issues certificate with 1447 new key 1448 <---------- CertRep SUCCESS 1449 Client stores certificate 1450 for installation when 1451 existing certificate expires. 1453 * Enveloped for the new CA certificate. The CA will use the envelope 1454 to determine which key to use to issue the client certificate. 1456 As these examples indicate, resumption from an error is tricky due to 1457 the state that needs to be held by both client and/or server. A 1458 CertPoll resume is technically the cleanest option but requires the 1459 most careful management of state, while a PKCSReq/RenewalReq/ 1460 UpdateReq resume is the easiest to implement since it's stateless, 1461 but can lead to complications if the message that gets lost is the 1462 one that would complete the certificate issue. On the other hand a 1463 PKCSReq/RenewalReq/UpdateReq resume is identical for both polled and 1464 non-polled transactions, while a CertPoll resume treats the two 1465 differently (a non-polled transaction is resumed with a 1466 PKCSReq/RenewalReq/UpdateReq, a polled transaction is resumed with a 1467 CertPoll). 1469 6. Contributors/Acknowledgements 1471 The editor would like to thank all of the previous editors, authors 1472 and contributors: Cheryl Madson, Xiaoyi Liu, David McGrew, David 1473 Cooper, Andy Nourse, Max Pritikin, Jan Vilhuber, and others for their 1474 work maintaining the draft over the years. Numerous other people 1475 have contributed during the long life cycle of the draft and all 1476 deserve thanks. In addition several PKCS #7 / CMS libraries 1477 contributed to interoperability by doing the right thing despite what 1478 earlier SCEP drafts required. 1480 The earlier authors would like to thank Peter William of ValiCert, 1481 Inc. (formerly of VeriSign, Inc.) and Alex Deacon of VeriSign, Inc. 1482 and Christopher Welles of IRE, Inc. for their contributions to early 1483 versions of this protocol and this document. 1485 7. IANA Considerations 1487 This memo includes no request to IANA. 1489 8. Security Considerations 1491 The security goal of SCEP is that no adversary can subvert the public 1492 key/identity binding from that intended. An adversary is any entity 1493 other than the client and the CA participating in the protocol. 1495 This goal is met through the use of CMS and PKCS #10 encryption and 1496 digital signatures using authenticated public keys. The CA's public 1497 key is authenticated via out-of-band means such as the checking of 1498 the CA fingerprint as specified in Section 2.1.2, and the SCEP 1499 client's public key is authenticated through manual or pre-shared 1500 secret authentication as specified in Section 2.2. 1502 8.1. General Security 1504 Common key-management considerations such as keeping private keys 1505 truly private and using adequate lengths for symmetric and asymmetric 1506 keys must be followed in order to maintain the security of this 1507 protocol. This is especially true for CA keys, which, when 1508 compromised, compromise the security of all relying parties. 1510 8.2. Use of the CA keypair 1512 A CA key pair is generally meant for (and is usually flagged as) 1513 being usable for certificate (and CRL) signing exclusively, rather 1514 than data signing or encryption. The SCEP protocol, however, uses 1515 the CA private key to both sign and optionally encrypt CMS transport 1516 messages. This is generally considered undesirable as it widens the 1517 possibility of an implementation weakness and provides: 1519 o Another place that the private key must be used (and hence is 1520 slightly more vulnerable to exposure). 1521 o Another place where a side channel attack (say, timing or power 1522 analysis) might be used. 1523 o Another place that the attacker might somehow insert their own 1524 data and get it signed by the CA's private key. Note though that 1525 this issue is purely theoretical since the CMS data signed by the 1526 CA is nothing like a certificate and could not be passed off as 1527 such. 1529 8.3. Challenge Password 1531 The challengePassword sent in the PKCS #10 enrolment request is 1532 signed and encrypted by way of being encapsulated in a pkiMessage. 1533 When saved by the CA, care should be taken to protect this password, 1534 for example by storing a salted iterated hash of the password rather 1535 than the password itself. 1537 8.4. Lack of Certificate Issue Confirmation 1539 SCEP provides no confirmation that the issued certificate was 1540 successfully received and processed by the client. This means that 1541 if the CertRep message is lost or can't be processed by the client 1542 then the CA will consider the certificate successfully issued while 1543 the client won't. If this situation is of concern then the correct 1544 issuance of the certificate will need to be verified by out-of-band 1545 means, for example through the client sending a message signed by the 1546 newly-issued certificate to the CA. This also provides the proof of 1547 possession that's not present in the case of an update or renewal 1548 operation, see Section 8.6. 1550 8.5. GetCACaps Issues 1552 The GetCACaps response is not signed. This allows an attacker to 1553 perform downgrade attacks on the cryptographic capabilities of the 1554 client/CA exchange. 1556 8.6. Lack of PoP in Renewal and Update Requests 1558 Renewal and update operations (but not standard certificate-issue 1559 operations) are processed via a previously-issued certificate and its 1560 associated private key, not the key in the PKCS #10 request. This 1561 means that a client no longer demonstrates proof of possession (PoP) 1562 of the private key corresponding to the public key in the PKCS #10 1563 request. It is therefore possible for a client to re-certify an 1564 existing key used by a third party, so that two or more certificates 1565 exist for the same key. By switching out the certificate in a 1566 signature, an attacker can appear to have a piece of data signed by 1567 their certificate rather than the original signer's certificate. 1568 This, and other, attacks are described in S/MIME ESS [14]. 1570 Avoiding these types of attacks requires situation-specific measures. 1571 For example CMS/SMIME implementations may use the ESSCertID attribute 1572 from S/MIME ESS [14] or its successor S/MIME ESSv2 [15] to 1573 unambiguously identify the signing certificate, however other 1574 mechanisms and protocols typically don't defend against this attack. 1576 8.7. Unnecessary cryptography 1578 Some of the SCEP exchanges use unnecessary signing and encryption 1579 operations. In particular the GetCert and GetCRL exchanges are 1580 encrypted and signed in both directions. The information requested 1581 is public and thus signing the requests is of questionable value. In 1582 addition CRLs and certificates sent in responses are already signed 1583 by the CA and can be verified by the recipient without requiring 1584 additional signing and encryption. More lightweight means of 1585 retrieving certificates and CRLs such as HTTP certificate-store 1586 access [11] and LDAP are recommended for this reason. 1588 9. References 1590 9.1. Normative References 1592 [1] Bradner, S., "Key words for use in RFCs to Indicate 1593 Requirement Levels", BCP 14, RFC 2119, March 1997. 1595 [2] Josefsson, S., "The Base16, Base32, and Base64 Data 1596 Encodings", RFC 4648, October 2006. 1598 [3] Housley, R., "Cryptographic Message Syntax (CMS)", 1599 RFC 5652, September 2009. 1601 [4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1602 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1603 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1605 [5] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 1606 Classes and Attribute Types Version 2.0", RFC 2985, 1607 November 2000. 1609 [6] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1610 Request Syntax Specification Version 1.7", RFC 2986, 1611 November 2000. 1613 [7] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1614 Housley, R., and W. Polk, "Internet X.509 Public Key 1615 Infrastructure Certificate and Certificate Revocation List 1616 (CRL) Profile", RFC 5280, May 2008. 1618 [8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1619 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1620 August 1998. 1622 9.2. Informative References 1624 [9] Schaad, J. and M. Myers, "Certificate Management over CMS 1625 (CMC)", RFC 5272, June 2008. 1627 [10] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1628 "Internet X.509 Public Key Infrastructure Certificate 1629 Management Protocol (CMP)", RFC 4210, September 2005. 1631 [11] Gutmann, P., "Internet X.509 Public Key Infrastructure 1632 Operational Protocols: Certificate Store Access via HTTP", 1633 RFC 4387, February 2006. 1635 [12] Alighieri, D., "Internet Key Exchange (IKEv2) Protocol", 1636 RFC 4306, March 1300. 1638 [13] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1639 Mail Extensions (S/MIME) Version 3.2 Message 1640 Specification", RFC 5751, January 2010. 1642 [14] Hoffman, P., "Enhanced Security Services for S/MIME", 1643 RFC 2634, June 1999. 1645 [15] Schaad, J., "Enhanced Security Services (ESS) Update: 1646 Adding CertID Algorithm Agility", RFC 5035, August 2007. 1648 [16] Dierks, T. and E. Rescorla, "The Transport Layer Security 1649 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1651 Appendix A. Background Notes 1653 This specification has spent more than sixteen years in the draft 1654 stage. Its original goal, provisioning IPsec routers with RSA 1655 certificates, has long since changed to general device/embedded 1656 system/IoT use. To fit this role, extra features were bolted on in a 1657 haphazard manner through the addition of a growing list of appendices 1658 and by inserting additional, often conflicting, paragraphs in various 1659 locations in the body text. Since existing features were never 1660 updated as newer ones were added, the specification accumulated large 1661 amounts of historical baggage over time. If OpenPGP was described as 1662 "a museum of 1990s crypto" then the SCEP draft was its graveyard. 1664 About five years ago the specification, which even at that point had 1665 seen only sporadic re-posts of the existing document, was more or 1666 less abandoned by its original sponsors. Due to its widespread use 1667 in large segments of the industry, the specification was rebooted in 1668 2015, cleaning up fifteen years worth of accumulated cruft, fixing 1669 errors, clarifying ambiguities, and bringing the algorithms and 1670 standards used into the current century (prior to the update, the de- 1671 facto lowest-common denominator algorithms used for interoperability 1672 were the forty-year-old single DES and broken MD5 hash algorithms). 1674 Other changes include: 1676 o Resolved contradictions in the text, for example a requirement 1677 given as a MUST in one paragraph and a SHOULD in the next, a MUST 1678 NOT in one paragraph and a MAY a few paragraphs later, a SHOULD 1679 NOT contradicted later by a MAY, and so on. 1680 o Merged several later fragmentary addenda placed in appendices (for 1681 example the handling of certificate renewal and update) with the 1682 body of the text. 1683 o Merged the SCEP Transactions and SCEP Transport sections, since 1684 the latter mostly duplicated (with occasional inconsistencies) the 1685 former. 1686 o Updated the algorithms to ones dating from at least this century. 1687 o Did the same for normative references to other standards. 1688 o Updated the text to use consistent terminology for the client and 1689 CA rather than a mixture of client, requester, end entity, server, 1690 certificate authority, and CA. 1691 o Corrected incorrect references to other standards, e.g. 1692 IssuerAndSerial -> IssuerAndSerialNumber. 1693 o Corrected errors such as a statement that when both signature and 1694 encryption certificates existed, the signature certificate was 1695 used for encryption. 1696 o Condensed redundant discussions of the same topic spread across 1697 multiple sections into a single location. For example the 1698 description of intermediate CA handling previously existed in 1699 three different locations, with slightly different reqirements in 1700 each one. 1701 o Added a description of how pkiMessages were processed, which was 1702 never made explicit in the original specification. This led to 1703 creative interpretations that had security problems but were 1704 employed anyway due to the lack of specific guidance on what to 1705 do. 1706 o Relaxed some requirements that didn't serve any obvious purpose 1707 and that major implementations didn't seem to be enforcing. For 1708 example the requirement that the self-signed certificate used with 1709 a request MUST contain a subject name that matched the one in the 1710 PKCS #10 request was relaxed to a SHOULD because a number of 1711 implementations either ignored the issue entirely or at worst 1712 performed some minor action like creating a log entry after which 1713 they continued anyway. 1714 o Removed discussion of the transactionID from the security 1715 considerations, since the instructions there were directly 1716 contradicted by the discussion of the use of the transactionID in 1717 Section 5. 1718 o Clarified sections that were unclear or even made no sense, for 1719 example the requirement for a "hash on the public key" [sic] 1720 encoded as a PrintableString. 1721 o Renamed "RA certificates" to "intermediate CA certificates". The 1722 original document at some point added mention of RA certificates 1723 without specifying how the client was to determine that an RA was 1724 in use, how the RA operations were identified in the protocol, or 1725 how it was used. It's unclear whether what was meant was a true 1726 RA or merely an intermediate CA, as opposed to the default 1727 practice of having certificates issued directly from a single root 1728 CA certificate. This update uses the term "intermediate CA 1729 certificates", since this seems to have been the original intent 1730 of the text. 1731 o Redid the PKIMessage diagram to match what was specified in CMS, 1732 the previous diagram omitted a number of fields and nested data 1733 structures which meant the text didn't match the diagram. 1734 o Removed the requirement for a CertPoll to contain a 1735 recipientNonce, since CertPoll is a client message and will never 1736 be sent in response to a message containing a senderNonce. See 1737 also the note in Section 3.3.2. 1738 o Clarified certificate renewal and update. These represent a 1739 capability that was bolted onto the original protocol with (at 1740 best) vaguely-defined semantics, including a requirement by the CA 1741 to guess whether a particular request was a renewal or not 1742 (updates were even more vaguely defined). In response to 1743 developer feedback that they either avoided renewal/update 1744 entirely because of this uncertainty or hardcoded in particular 1745 behaviour on a per-CA basis, this specification explicitly 1746 identifies renewal and update requests as such, and provides 1747 proper semantics for both. 1748 o Added the "SCEPStandard" keyword to GetCACaps to indicate that the 1749 CA complies with the final version of the SCEP standard, since the 1750 definition of what constitutes SCEP standards compliance has 1751 changed significantly over the years. 1752 o Removed the discussion in the security considerations of 1753 revocation issues, since SCEP doesn't support revocation as part 1754 of the protocol. 1755 o Clarified the use of nonces, which if applied as originally 1756 specified would have made the use of polling in the presence of a 1757 lost message impossible. 1758 o Removed the discussion of generating a given transactionID by 1759 hashing the public key, since this implied that there was some 1760 special significance in the value generated this way. Since it 1761 was neither a MUST nor a MAY, it was unsound to imply that servers 1762 could rely on the value being generated a certain way. In 1763 addition it wouldn't work if multiple transactions as discussed in 1764 Section 4.4 were initiated, since the deterministic generation via 1765 hashing would lead to duplicate transactionIDs. 1766 o Added examples of SCEP messages to give implementers something to 1767 aim for. 1769 Appendix B. Sample SCEP Messages 1771 (Omitted from the drafts to keep the size down). 1773 Authors' Addresses 1775 Peter Gutmann 1776 University of Auckland 1777 Department of Computer Science 1778 Auckland 1779 New Zealand 1781 Email: pgut001@cs.auckland.ac.nz 1783 Max Pritikin 1784 Cisco Systems, Inc