idnits 2.17.1 draft-gutmann-scep-02.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 (March 15, 2016) is 2958 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 440 -- Looks like a reference, but probably isn't: 'CERT-REQ-PENDING' on line 440 -- Looks like a reference, but probably isn't: 'CERT-ISSUED' on line 440 ** 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. '14') (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. -------------------------------------------------------------------------------- 1 Network Working Group P. Gutmann 2 Internet-Draft University of Auckland 3 Intended status: Standards Track M. Pritikin 4 Expires: September 16, 2016 Cisco 5 March 15, 2016 7 Simple Certificate Enrolment Protocol 8 draft-gutmann-scep-02.txt 10 Abstract 12 This document specifies the Simple Certificate Enrolment Protocol 13 (SCEP), a Public Key Infrastructure (PKI) communication protocol 14 which leverages existing technology by using CMS (formerly known as 15 PKCS #7) and PKCS #10 over HTTP. SCEP is the evolution of the 16 enrolment protocol sponsored by Cisco Systems, which now enjoys wide 17 support in both client and server implementations, as well as being 18 relied upon by numerous other industry standards that work with 19 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 September 16, 2016. 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1. Conventions Used in This Document . . . . . . . . . . . . 5 57 2. SCEP Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.1. SCEP Entities . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1.1. Requester . . . . . . . . . . . . . . . . . . . . . . 5 60 2.1.2. Certification Authority . . . . . . . . . . . . . . . 6 61 2.1.3. CA Certificate Distribution . . . . . . . . . . . . . 6 62 2.2. Requester authentication . . . . . . . . . . . . . . . . 7 63 2.3. Enrolment authorization . . . . . . . . . . . . . . . . . 8 64 2.4. Certificate Enrolment/Renewal/Update . . . . . . . . . . 9 65 2.4.1. Client State Transitions . . . . . . . . . . . . . . 10 66 2.5. Certificate Access . . . . . . . . . . . . . . . . . . . 11 67 2.6. CRL Access . . . . . . . . . . . . . . . . . . . . . . . 12 68 2.7. Certificate Revocation . . . . . . . . . . . . . . . . . 13 69 2.8. Mandatory-to-Implement Functionality . . . . . . . . . . 13 70 3. SCEP Secure Message Objects . . . . . . . . . . . . . . . . . 13 71 3.1. SCEP pkiMessage . . . . . . . . . . . . . . . . . . . . . 14 72 3.1.1. Signed Transaction Attributes . . . . . . . . . . . . 15 73 3.1.1.1. transactionID . . . . . . . . . . . . . . . . . . 17 74 3.1.1.2. messageType . . . . . . . . . . . . . . . . . . . 18 75 3.1.1.3. pkiStatus . . . . . . . . . . . . . . . . . . . . 18 76 3.1.1.4. failInfo . . . . . . . . . . . . . . . . . . . . 18 77 3.1.1.5. senderNonce and recipientNonce . . . . . . . . . 19 78 3.1.2. SCEP pkcsPKIEnvelope . . . . . . . . . . . . . . . . 19 79 3.2. SCEP pkiMessage types . . . . . . . . . . . . . . . . . . 20 80 3.2.1. PKCSReq/RenewalReq/UpdateReq . . . . . . . . . . . . 20 81 3.2.2. CertRep . . . . . . . . . . . . . . . . . . . . . . . 20 82 3.2.2.1. CertRep SUCCESS . . . . . . . . . . . . . . . . . 21 83 3.2.2.2. CertRep FAILURE . . . . . . . . . . . . . . . . . 22 84 3.2.2.3. CertRep PENDING . . . . . . . . . . . . . . . . . 22 85 3.2.3. CertPoll (GetCertInitial) . . . . . . . . . . . . . . 22 86 3.2.4. GetCert . . . . . . . . . . . . . . . . . . . . . . . 23 87 3.2.5. GetCRL . . . . . . . . . . . . . . . . . . . . . . . 23 88 3.3. Degenerate certificates-only CMS Signed-Data . . . . . . 24 89 3.4. CA Capabilities . . . . . . . . . . . . . . . . . . . . . 24 90 3.4.1. GetCACaps HTTP Message Format . . . . . . . . . . . . 24 91 3.4.2. CA Capabilities Response Format . . . . . . . . . . . 24 92 4. SCEP Transactions . . . . . . . . . . . . . . . . . . . . . . 26 93 4.1. Get CA Certificate . . . . . . . . . . . . . . . . . . . 26 94 4.1.1. Get CA Certificate Response Message Format . . . . . 27 95 4.1.1.1. CA Certificate Response Message Format . . . . . 27 96 4.1.1.2. CA Certificate Chain Response Message Format . . 27 97 4.2. Certificate Enrolment/Renewal/Update . . . . . . . . . . 27 98 4.2.1. Certificate Enrolment/Renewal/Update Response Message 27 99 4.3. Poll for Requester Initial Certificate . . . . . . . . . 28 100 4.3.1. Polling Response Message Format . . . . . . . . . . . 28 101 4.4. Certificate Access . . . . . . . . . . . . . . . . . . . 28 102 4.4.1. Certificate Access Response Message Format . . . . . 29 103 4.5. CRL Access . . . . . . . . . . . . . . . . . . . . . . . 29 104 4.5.1. CRL Access Response Message Format . . . . . . . . . 29 105 4.6. Get Next Certification Authority Certificate . . . . . . 29 106 4.6.1. Get Next CA Response Message Format . . . . . . . . . 30 107 5. SCEP Transport . . . . . . . . . . . . . . . . . . . . . . . 30 108 5.1. HTTP GET and POST Message Formats . . . . . . . . . . . . 30 109 5.1.1. Response Message Format . . . . . . . . . . . . . . . 31 110 5.2. SCEP HTTP Messages . . . . . . . . . . . . . . . . . . . 31 111 5.2.1. GetCACert . . . . . . . . . . . . . . . . . . . . . . 32 112 5.2.1.1. GetCACert Response . . . . . . . . . . . . . . . 32 113 5.2.1.1.1. CA Certificate Only Response . . . . . . . . 32 114 5.2.1.1.2. CA Certificate Chain Response . . . . . . . . 32 115 5.2.2. PKCSReq/RenewalReq/UpdateReq . . . . . . . . . . . . 32 116 5.2.2.1. PKCSReq/RenewalReq/UpdateReq Response . . . . . . 33 117 5.2.3. CertPoll . . . . . . . . . . . . . . . . . . . . . . 33 118 5.2.3.1. CertPoll Response . . . . . . . . . . . . . . . . 33 119 5.2.4. GetCert . . . . . . . . . . . . . . . . . . . . . . . 33 120 5.2.4.1. GetCert Response . . . . . . . . . . . . . . . . 34 121 5.2.5. GetCRL . . . . . . . . . . . . . . . . . . . . . . . 34 122 5.2.5.1. GetCRL Response . . . . . . . . . . . . . . . . . 34 123 5.2.6. GetNextCACert . . . . . . . . . . . . . . . . . . . . 34 124 5.2.6.1. GetNextCACert Response . . . . . . . . . . . . . 34 125 6. Contributors/Acknowledgements . . . . . . . . . . . . . . . . 34 126 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 127 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 128 8.1. General Security . . . . . . . . . . . . . . . . . . . . 35 129 8.2. Use of the CA keypair . . . . . . . . . . . . . . . . . . 36 130 8.3. Challenge Password . . . . . . . . . . . . . . . . . . . 36 131 8.4. Transaction ID . . . . . . . . . . . . . . . . . . . . . 36 132 8.5. Nonces and Replay . . . . . . . . . . . . . . . . . . . . 36 133 8.6. GetCACaps Issues . . . . . . . . . . . . . . . . . . . . 36 134 8.7. Unnecessary cryptography . . . . . . . . . . . . . . . . 37 135 8.8. GetNextCACert . . . . . . . . . . . . . . . . . . . . . . 37 136 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 137 9.1. Normative References . . . . . . . . . . . . . . . . . . 37 138 9.2. Informative References . . . . . . . . . . . . . . . . . 38 139 Appendix A. SCEP State Transitions . . . . . . . . . . . . . . . 38 140 Appendix B. Background Notes . . . . . . . . . . . . . . . . . . 41 141 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 143 1. Introduction 145 Public key technology is widely available and increasingly widely 146 deployed. X.509 certificates serve as the basis for several 147 standards-based security protocols in the IETF, such as TLS [14], S/ 148 MIME [13], and and IKE/IPsec [12]. When an X.509 certificate is 149 issued by other than the certificate subject (a self-issued 150 certificate), there typically is a need for a certificate management 151 protocol. Such a protocol enables a PKI client to request a 152 certificate, certificate renewal, or certificate update from a 153 Certification Authority (CA). 155 This specification defines a protocol, Simple Certificate Enrolment 156 Protocol (SCEP), for certificate management and certificate and CRL 157 queries in a closed environment. While widely deployed, this 158 protocol omits some certificate management features, e.g. certificate 159 revocation transactions, which can significantly enhance the security 160 achieved in a PKI. The IETF protocol suite currently includes two 161 further certificate management protocols with more comprehensive 162 functionality: Certificate Management Protocol (CMP) [10] and 163 Certificate Management over CMS (CMC) [9]. Environments that do not 164 require interoperability with SCEP implementations MAY consider using 165 the above-mentioned certificate management protocols, however anyone 166 considering this step should be aware that the high level of 167 complexity of these two protocols has resulted in serious 168 interoperability problems and corresponding lack of industry support. 169 SCEP's simplicity, while being a drawback in terms of its limited 170 functionality, also makes deployment relatively straightforward, so 171 that it enjoys widespread industry support and ready interoperability 172 across a wide range of platforms. While implementers are encouraged 173 to investigate one of the more comprehensive alternative certificate 174 management protocols in addition to the protocol defined in this 175 specification, anyone wishing to deploy them should proceed with 176 caution, and consider support and interoperability issues before 177 committing to their use. 179 The protocol supports the following general operations: 181 o CA public key distribution. 182 o Certificate enrolment. 183 o Certificate renewal/update. 184 o Certificate query. 185 o CRL query. 187 SCEP makes extensive use of CMS [3] and PKCS #10 [6]. 189 1.1. Conventions Used in This Document 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 193 document are to be interpreted as described in [1]. 195 2. SCEP Overview 197 This section provides a high level overview of the functionality of 198 SCEP. 200 2.1. SCEP Entities 202 The entity types defined in SCEP are 204 o The Requester, or client (Section 2.1.1). 205 o The Server, a Certification Authority (CA) (Section 2.1.2). 207 2.1.1. Requester 209 The requester is sometimes called a "client" in this document. It is 210 the client of the SCEP exchange. 212 Before a requester can start a PKI transaction, it MUST have at least 213 one appropriate key pair for use when signing the SCEP pkiMessage 214 (Section 3.1). 216 The message types, being based on CMS [3] and PKCS #10 [6], fully 217 support algorithm agility but the requester has to use a key type 218 that is supported by the server. Specifically, they must employ a 219 PKC algorithm capable of both encryption and signing. RSA is the 220 only widely-used algorithm that has these properties. 222 A requester MUST have the following information locally configured: 224 1. The Certification Authority IP address or fully qualified domain 225 name. 226 2. The Certification Authority HTTP CGI script path (this usually 227 has a default value, see Section 5.1). 228 3. The identifying information that is used for authentication of 229 the Certification Authority in Section 4.1.1, typically a 230 certificate fingerprint. This information MAY be obtained from 231 the user, or presented to the end user for manual authorization 232 during the protocol exchange (e.g. the user indicates acceptance 233 of a fingerprint via a user-interface element). 235 The requester MAY maintain multiple independent configurations 236 appropriate for multiple Certification Authorities. Doing so does 237 not effect the protocol operation and is not in scope of this 238 document. 240 2.1.2. Certification Authority 242 A SCEP Certification Authority (CA) is the entity that signs client 243 certificates. A certification authority MAY enforce any arbitrary 244 policies and apply them to certification requests. The certification 245 authority MAY reject any request. If the client has already been 246 issued a certificate for this keypair the server MAY return the 247 previously created certificate. The requester MUST NOT assume any of 248 the fields in the certification request, except for the public key, 249 will be the same in the certificate issued. 251 The certification authority MAY include a cRLDistributionPoint 252 extension in every certificate it issues, make CRLs available via 253 HTTP [11] or LDAP, or answer CRL queries itself. In the latter case 254 it SHOULD be online at all times. 256 Since the client is expected to perform encryption and signature 257 verification using the CA certificate, the keyUsage extension in the 258 CA certificate MUST indicate that it is valid for digitalSignature 259 and keyEncipherment use alongside the usual CA usages of keyCertSign 260 and/or cRLSign. 262 If a client times out from polling for a pending request it can 263 resynchronize by reissuing the original request with the original 264 subject name, key, and transactionID. The CA SHOULD return the 265 status of the original transaction, including the certificate if it 266 was granted. 268 2.1.3. CA Certificate Distribution 270 If the CA certificate(s) have not previously been acquired by the 271 requester in some other means, the requester MUST retrieve the CA 272 certificate(s) before any PKI operation (Section 3) can be started. 274 Since no public key has yet been exchanged between the requester and 275 the CA, the messages cannot be secured using CMS [3], and the data is 276 instead transferred in the clear. 278 If an intermediate CA is in use, a certificates-only CMS [3] Signed- 279 Data message with a certificate chain consisting of all CA 280 certificates is returned. Otherwise the CA certificate itself is 281 returned. The transport protocol (Section 5) MUST indicate which one 282 is returned. 284 The SCEP server CA certificate MAY be provided out-of-band to the 285 SCEP requester. Alternatively, the CA certificate fingerprint MAY be 286 used to authenticate a CA Certificate distributed by the GetCACert 287 response (Section 4.1) or via HTTP [11]. The fingerprint is created 288 by calculating a SHA-1, SHA-256, or SHA-512 hash over the whole CA 289 certificate. 291 After the requester gets the CA certificate, it SHOULD authenticate 292 the certificate by comparing its fingerprint with the locally 293 configured, out-of- band distributed, identifying information. 294 Intermediate CA certificates, if any, are signed by a higher-level CA 295 so there is no need to authenticate them against the out-of-band 296 data. Clients SHOULD verify intermediate-level CA certificate 297 signatures using the issuing CA's certificate before use during 298 protocol exchanges. 300 Because a long time can pass between queries from a requester to a CA 301 and because intermediate CA certificates can change over time, it is 302 recommended that a requester not store intermediate CA certificates. 303 Instead, the requester SHOULD retrieve the CA certificates before 304 each operation. 306 2.2. Requester authentication 308 As with every protocol that uses public-key cryptography, the 309 association between the public keys used in the protocol and the 310 identities with which they are associated must be authenticated in a 311 cryptographically secure manner. This requirement is needed to 312 prevent a man-in-the-middle (MITM) attack, in which an adversary can 313 manipulate the data as it travels between the protocol participants 314 and subvert the security of the protocol. 316 The communication between the requester and the certification 317 authority are secured using SCEP Secure Message Objects (Section 3) 318 which specifies how CMS [3] is used to encrypt and sign the data. In 319 order to perform the signing operation the client uses an appropriate 320 local certificate: 322 1. If the requester does not have an appropriate existing 323 certificate then a locally generated self-signed certificate MUST 324 be used. The self-signed certificate SHOULD use the same subject 325 name as in the PKCS #10 request. In this case the messageType is 326 PKCS10Req (see Section 3.1.1.2). 327 2. If the requesting system already has a certificate issued by the 328 SCEP server, and the server supports renewal (see Section 2.4), 329 that certificate SHOULD be used. In this case the messageType is 330 RenewalReq (see Section 3.1.1.2). 332 3. If the requesting system has no certificate issued by the new CA, 333 but has credentials from an alternate CA the certificate issued 334 by the alternate CA MAY be used. Policy settings on the new CA 335 will determine if the request can be accepted or not. This is 336 useful when enrolling with a new administrative domain using a 337 certificate from the old domain as credentials. In this case the 338 messageType is UpdateReq (see Section 3.1.1.2). 340 Note that although the above text describes three different types of 341 operations, in practice most implementations always apply the first 342 one even if an existing certificate already exists. For this reason 343 support for the first case is mandatory while support for the latter 344 two are optional (see Section 2.8). 346 During the certificate enrolment process, the requester MUST use the 347 selected certificate's key when signing the CMS [3] envelope (see 348 Section 3). The server's CertResp then uses the same certificate's 349 public key when encrypting the response (see Section 3.2.2). 351 [Question: This is another area where the semantics were never 352 defined, what happens during a renewal or update? For an 353 enrolment the signing cert contains the key that's also in the 354 request, but what about for a renewal or update where they're 355 quite probably different keys? Should the envelope be 356 encrypted to the key in the request or the signing key?]. 358 When the certification authority creates the CMS [3] envelope 359 containing the issued certificate, it SHOULD use the public key and 360 identifying information conveyed in the above included certificate. 361 This will inform the end entity of which private key is needed to 362 open the envelope. 364 2.3. Enrolment authorization 366 PKCS #10 [6] specifies a PKCS #9 [5] challengePassword attribute to 367 be sent as part of the enrolment request. When utilizing the 368 challengePassword, the server distributes a shared secret to the 369 requester which will uniquely associate the enrolment request with 370 the requester. 372 Inclusion of the challengePassword by the SCEP client is OPTIONAL and 373 allows for unauthenticated authorization of enrolment requests 374 (which, however, requires manual approval of each certificate issue, 375 see below), or for renewal or update requests which are authenticated 376 by being signed with an existing certificate. The CMS [3] envelope 377 protects the privacy of the challengePassword. 379 A client that is performing certificate renewal or update as per 380 Section 2.4 SHOULD omit the challengePassword but MAY send the 381 originally distributed password in the challengePassword attribute. 382 In the former case the SCEP CA MUST authenticate the request based on 383 the certificate used to sign the renewal or update request. In the 384 latter case the SCEP CA MAY use either the challengePassword or the 385 previously issued certificate (or both), depending on CA policy, to 386 authenticate the request. The SCEP server MUST NOT attempt to 387 authenticate a client based on a self-signed certificate unless it 388 has been verified through out-of-band means such as a certificate 389 fingerprint. 391 To perform the authorization in manual mode the requester's messages 392 are placed in the PENDING state until the CA operator authorizes or 393 rejects them. Manual authorization is used when the client has only 394 a self-signed certificate that hasn't been previously authenticated 395 by the CA and/or a challengePassword is not available. The SCEP 396 server MAY either reject unauthorized certification requests or mark 397 them for manual authorization according to CA policy. 399 2.4. Certificate Enrolment/Renewal/Update 401 A requester starts an enrolment (Section 3.2.1) transaction by 402 creating a certificate request using PKCS #10 [6] and sends it to the 403 CA enveloped using CMS [3] (Section 3). 405 If the CA supports certificate renewal or update then a new 406 certificate with new validity dates can be issued, even though the 407 old one is still valid, if the CA policy permits. The server MAY 408 automatically revoke the old client certificate. To renew or update 409 an existing certificate, the client uses the RenewalReq or UpdateReq 410 message (see Section 3.2) and signs it with the existing client 411 certificate. The client SHOULD use a new keypair when requesting a 412 new certificate, but MAY request a new certicate using the old 413 keypair. 415 If the CA returns a CertRep (Section 3.2.2) message with status set 416 to PENDING, the requester enters into polling mode by periodically 417 sending a CertPoll (Section 3.2.3) PKI message to the CA, until the 418 CA operator completes the manual authentication (approving or denying 419 the request). 421 In general, the requester will send a single PKCSReq/RenewalReq/ 422 UpdateReq (Section 3.2.1) message, followed by 0 or more CertPoll 423 (Section 3.2.3) messages, if polling mode is entered. 425 In general, the CA will send 0 or more CertRep (Section 3.2.2) 426 messages with status set to PENDING, followed by a single CertRep 427 (Section 3.2.2) with status set to either SUCCESS or FAILURE. 429 2.4.1. Client State Transitions 431 The requester state transitions during enrolment operation are 432 indicated in Figure 1. 434 CertPoll 435 +----<---+ 436 | | CertRep(PENDING), 437 | | CertPoll send-timeout, 438 | | new-poll timer 439 | | 440 [CERT-NONEXISTENT] -----+---> [CERT-REQ-PENDING] [CERT-ISSUED] 441 ^ PKCSReq | | ^ 442 | RenewalReq | | | 443 | UpdateReq | +---------------+ 444 | | CertRep(SUCCESS) 445 +--------------------------+ 446 CertRep(FAILURE), 447 PKCS/Update/RenewalReq send-timeout, 448 max-time/max-polls exceeded 450 Figure 1: State Transition Diagram 452 The certificate issue process starts at the state CERT-NONEXISTENT. 454 Sending a PKCSReq/RenewalReq/UpdateReq message changes the state to 455 CERT-REQ-PENDING. If there is no response, or sending is not 456 possible, the state reverts back to CERT-NONEXISTENT. 458 Receiving a CertRep message with pkiStatus set to SUCCESS changes the 459 state to CERT-ISSUED. 461 Receiving a CertRep message with pkiStatus set to FAILURE changes the 462 state to CERT-NONEXISTENT. 464 If the server sends back a CertRep message with pkiStatus set to 465 PENDING, the requester will keep polling by sending a CertPoll 466 message to the server, until either a CertRep message with status set 467 to SUCCESS or FAILURE is received, or the maximum number of polls has 468 been exceeded. 470 If the maximum number of polls has been exceeded or a CertRep message 471 with pkiStatus set to FAILURE is received while in the CERT-REQ- 472 PENDING state, the end entity will transition to the CERT-NONEXISTENT 473 state, and the SCEP client can eventually initiate another enrolment 474 request. It is important to note that, as long as the requester does 475 not change its subject name or keys, the same transactionID may be 476 used in the "new" transaction. This is important because based on 477 this transactionID, the certification authority can recognize this as 478 an existing transaction instead of a new one. 480 A successful transaction in automatic mode: 482 REQUESTER CA SERVER 484 PKCSReq: PKI cert. enrolment msg 485 --------------------------------> CertRep: pkiStatus = SUCCESS 486 certificate attached 487 <------------------------------ 488 Receive issued certificate. 490 A successful transaction in manual mode: 492 REQUESTER CA SERVER 494 PKCSReq: PKI cert. enrolment msg 495 --------------------------------> CertRep: pkiStatus = PENDING 496 <------------------------------ 497 CertPoll: polling msg 498 --------------------------------> CertRep: pkiStatus = PENDING 499 <------------------------------ 500 ................ ............... 502 CertPoll: polling msg 503 --------------------------------> CertRep: pkiStatus = SUCCESS 504 certificate attached 505 <------------------------------ 506 Receive issued certificate. 508 2.5. Certificate Access 510 A certificate query message is defined for clients to retrieve a copy 511 of their own certificate from the CA. It allows clients that do not 512 store their certificates locally to obtain a copy when needed. This 513 functionality is not intended to provide a general purpose 514 certificate store access service, which may be achieved via HTTP [11] 515 or LDAP. 517 To query a certificate from the certification authority, a requester 518 sends a request consisting of the certificate's issuer name and 519 serial number. This assumes that the requester has saved the issuer 520 name and the serial number of the issued certificate from the 521 previous enrolment transaction. The transaction to query a 522 certificate consists of one GetCert (Section 3.2.4) message and one 523 CertRep (Section 3.2.2) message, as shown below. 525 REQUESTER CA SERVER 527 GetCert: PKI certificate query msg 528 -------------------------------> CertRep: pkiStatus = SUCCESS 529 certificate attached 530 <----------------------------- 531 Receive the certificate. 533 2.6. CRL Access 535 SCEP clients MAY request a CRL via one of three methods: 537 1. If the CA supports CRL Distribution Points (CRLDPs) [7], then the 538 CRL MAY be retrieved via the mechanism specified in the CRDLP. 539 2. If the CA supports HTTP [11], then the CRL MAY be retrieved via 540 the AuthorityInfoAcces [7] location specified in the certificate. 541 3. Only if the CA does not support CRDLPs or HTTP access should a 542 CRL query be composed by creating a GetCRL message consisting of 543 the issuer name and serial number from the certificate whose 544 revocation status is being queried. 546 The server SHOULD NOT support the GetCRL method because: 548 o It does not scale well due to the unnecessary cryptography (see 549 Section 8). 550 o It requires the CA to be a high-availability service. 551 o Only limited information to determine the CRL scope is provided 552 (see [7]). 554 The message is sent to the SCEP server in the same way as the other 555 SCEP requests. The transaction to retrieve a CRL consists of one 556 GetCRL PKI message and one CertRep PKI message, which contains only 557 the CRL (no certificates) in a degenerate certificates-only CMS [3] 558 Signed-Data message (Section 3.3), as shown below. 560 REQUESTER CA SERVER 562 GetCRL: PKI CRL query msg 563 ----------------------------------> 564 CertRep: CRL attached 565 <----------------------------- 566 Receive the CRL 568 2.7. Certificate Revocation 570 SCEP does not specify a method to request certificate revocation. In 571 order to revoke a certificate, the requester must contact the CA 572 using a non-SCEP defined mechanism. 574 2.8. Mandatory-to-Implement Functionality 576 At a minimum, all SCEP implementations compliant with this 577 specification MUST support GetCACert (Section 4.1), PKCSReq 578 (Section 3.2.1) (and its associated response messages), communication 579 of binary data via HTTP POST (Section 5.1), and the AES and SHA-256 580 algorithms to secure pkiMessages (Section 3.1). 582 For historical reasons implementations MAY support communications of 583 binary data via HTTP GET (Section 5.1), and the triple DES and SHA-1 584 algorithms to secure pkiMessages (Section 3.1). 586 3. SCEP Secure Message Objects 588 CMS [3] is a general enveloping mechanism that enables both signed 589 and encrypted transmission of arbitrary data. SCEP messages that 590 require confidentiality use two layers of CMS [3], as shown in 591 Figure 2. By applying both enveloping and signing transformations, 592 the SCEP message is protected both for the integrity of its end-to- 593 end transaction information and the confidentiality of its 594 information portion. The advantage of this technique over the 595 conventional transaction message format is that the signed 596 transaction type information and the status of the transaction can be 597 determined prior to invoking security handling procedures specific to 598 the information portion being processed. 600 Some messages do not require enveloping, in which case the Enveloped- 601 Data in Figure 2 is omitted. 603 pkiMessage { 604 contentType = signedData 605 content { 606 pkcsPKIEnvelope { -- Optional 607 contentType = envelopedData 608 content { 609 recipientInfo 610 contentType = data 611 content { 612 messageData -- Typically PKCS #10 request 613 } 614 } 615 } 616 signerInfo { 617 signedAttrs { 618 transactionID 619 messageType 620 pkiStatus 621 failInfo 622 senderNonce 623 recipientNonce 624 } 625 signature 626 } 627 } 628 } 630 Figure 2: CMS Layering 632 When a particular SCEP message carries data, this data is carried in 633 the messageData. CertRep messages will lack any signed content and 634 consist only of a pkcsPKIEnvelope (Section 3.1.2). 636 Note: The remainder of this document will refer only to 637 'messageData', but it is understood to always be encapsulated in the 638 pkcsPKIEnvelope (Section 3.1.2). The format of the data in the 639 messageData is defined by the messageType attribute (see Section 3.1) 640 of the Signed-Data. If there is no messageData to be transmitted, 641 the entire pkcsPKIEnvelope MUST be omitted. 643 3.1. SCEP pkiMessage 645 The basic building block of all secured SCEP messages is the SCEP 646 pkiMessage. It consists of a CMS [3] Signed-Data content type. The 647 following restrictions apply: 649 o The contentType in contentInfo MUST be data ({pkcs-7 1}) as 650 defined in CMS [3]. 651 o The signed content, if present (e.g. FAILURE and PENDING CertRep 652 messages will lack any signed content), MUST be a pkcsPKIEnvelope 653 (Section 3.1.2), and MUST match the messageType attribute. 654 o The SignerInfo MUST contain a set of authenticatedAttributes (see 655 CMS [3] as well as Section 3.1.1 in this document). 657 At a minimum, all messages MUST contain the following 658 authenticatedAttributes: 660 o A transactionID attribute (see Section 3.1.1.1). 661 o A messageType attribute (see Section 3.1.1.2). 662 o A senderNonce attribute (see Section 3.1.1.5). 663 o Any attributes required by CMS [3]. 665 If the message is a response, it MUST also include the following 666 authenticatedAttributes: 668 o A pkiStatus attribute (see Section 3.1.1.3). 669 o A recipientNonce attribute (see Section 3.1.1.5). 671 3.1.1. Signed Transaction Attributes 673 The following transaction attributes are encoded as authenticated 674 attributes, and are carried, as specified in CMS [3], in the 675 SignerInfo for this Signed-Data. 677 +----------------+-----------------+--------------------------------+ 678 | Attribute | Encoding | Comment | 679 +----------------+-----------------+--------------------------------+ 680 | transactionID | PrintableString | Unique ID for this transaction | 681 | | | as a text string | 682 | | | | 683 | messageType | PrintableString | Decimal value as a numeric | 684 | | | text string | 685 | | | | 686 | pkiStatus | PrintableString | Decimal value as a numeric | 687 | | | text string | 688 | | | | 689 | failInfo | PrintableString | Decimal value as a numeric | 690 | | | text string | 691 | | | | 692 | senderNonce | OCTET STRING | Random nonce as a 16-byte | 693 | | | binary data string | 694 | | | | 695 | recipientNonce | OCTET STRING | Random nonce as a 16-byte | 696 | | | binary data string | 697 +----------------+-----------------+--------------------------------+ 698 The OIDs used for these attributes are as follows: 700 +-------------------+-----------------------------------------------+ 701 | Name | ASN.1 Definition | 702 +-------------------+-----------------------------------------------+ 703 | id-VeriSign | OBJECT_IDENTIFIER ::= {2 16 US(840) 1 | 704 | | VeriSign(113733)} | 705 | | | 706 | id-pki | OBJECT_IDENTIFIER ::= {id-VeriSign pki(1)} | 707 | | | 708 | id-attributes | OBJECT_IDENTIFIER ::= {id-pki attributes(9)} | 709 | | | 710 | id-transactionID | OBJECT_IDENTIFIER ::= {id-attributes | 711 | | transactionID(7)} | 712 | | | 713 | id-messageType | OBJECT_IDENTIFIER ::= {id-attributes | 714 | | messageType(2)} | 715 | | | 716 | id-pkiStatus | OBJECT_IDENTIFIER ::= {id-attributes | 717 | | pkiStatus(3)} | 718 | | | 719 | id-failInfo | OBJECT_IDENTIFIER ::= {id-attributes | 720 | | failInfo(4)} | 721 | | | 722 | id-senderNonce | OBJECT_IDENTIFIER ::= {id-attributes | 723 | | senderNonce(5)} | 724 | | | 725 | id-recipientNonce | OBJECT_IDENTIFIER ::= {id-attributes | 726 | | recipientNonce(6)} | 727 +-------------------+-----------------------------------------------+ 729 The attributes are detailed in the following sections. 731 3.1.1.1. transactionID 733 A PKI operation is a transaction consisting of the messages exchanged 734 between a requester and the server. The transactionID is a text 735 string generated by the client when starting a transaction. The 736 client MUST generate a unique string as the transaction identifier, 737 which MUST be used for all PKI messages exchanged for a given 738 enrolment, encoded as a PrintableString. 740 One means of generating the transactionID is as a SHA-1, SHA-256, or 741 SHA-512 hash of the public key value in the enrolment request when 742 encoded as an X.509 SubjectPublicKeyInfo [7] (in other words the 743 exact binary form in which it appears in both the request and the 744 resulting certificate) and then coverting it into a text string using 745 base64 encoding or ASCII hex digits. This allows the SCEP client to 746 automatically generate the same transactionID for any given public 747 key. The SCEP protocol requires that transactionIDs be unique, so 748 that subsequent polling queries can be matched with previous 749 transactions. 751 When using the certificate query and CRL query messages defined in 752 this protocol, the transactionID is required so that the requester 753 can match the response message with the outstanding request message. 754 For a non-enrolment message (for example GetCert and GetCRL), the 755 transactionID SHOULD be some value unique to the client. 757 3.1.1.2. messageType 759 The messageType attribute specifies the type of operation performed 760 by the transaction. This attribute MUST be included in all PKI 761 messages. The following message types are defined: 763 o CertRep ("3") -- Response to certificate or CRL request. 764 o RenewalReq ("17") -- PKCS #10 [6] certificate request for renewal 765 of an existing certificate. 766 o UpdateReq ("18") -- PKCS #10 [6] certificate request for update of 767 a certificate issued by a different CA. 768 o PKCSReq ("19") -- PKCS #10 [6] certificate request. 769 o CertPoll ("20") -- Certificate polling in manual enrolment. 770 o GetCert ("21") -- Retrieve a certificate. 771 o GetCRL ("22") -- Retrieve a CRL. 773 Undefined message types are treated as an error. 775 3.1.1.3. pkiStatus 777 All response messages MUST include transaction status information, 778 which is defined as pkiStatus attribute: 780 o SUCCESS ("0") -- request granted. 781 o FAILURE ("2") -- request rejected. When pkiStatus is FAILURE, the 782 failInfo attribute, as defined in Section 3.1.1.4, MUST also be 783 present. 784 o PENDING ("3") -- request pending for manual approval. 786 Undefined pkiStatus attributes are treated as an error. 788 3.1.1.4. failInfo 790 The failInfo attribute MUST contain one of the following failure 791 reasons: 793 o badAlg ("0") -- Unrecognized or unsupported algorithm identifier. 795 o badMessageCheck ("1") -- integrity check failed. 796 o badRequest ("2") -- transaction not permitted or supported. 797 o badTime ("3") -- The signingTime attribute from the CMS [3] 798 authenticatedAttributes was not sufficiently close to the system 799 time (see Section 3.1.1.6). 800 o badCertId ("4") -- No certificate could be identified matching the 801 provided criteria. 803 [Question: Is there any demand for a free-form UTF8String 804 attribute to explain what really went wrong? Trying to sort 805 out an error when all you ever get back is the near-universal 806 badRequest is almost impossible, adding a failInfoText 807 attribute to address this could be quite useful since it 808 would allow expressing information such as a failure to meet 809 CA policy, or indeed anything more complex than "no go away"]. 811 Undefined failInfo attributes are treated as an error. 813 3.1.1.5. senderNonce and recipientNonce 815 The attributes of senderNonce and recipientNonce are a 16 byte random 816 number generated for each transaction. These are intended to prevent 817 replay attacks. 819 When a sender sends a PKI message to a recipient, a senderNonce MUST 820 be included in the message. The recipient MUST copy the senderNonce 821 into the recipientNonce of the reply as a proof of liveliness. The 822 original sender MUST verify that the recipientNonce of the reply 823 matches the senderNonce it sent in the request. If the nonce does 824 not match, the message MUST be rejected. 826 [Question: What does this do for polling? Polling messages can 827 get lost so nonces will go out of sync, is there a need to 828 chain XXXReqs to polls via nonces? If not, why do we have two 829 nonces?]. 831 3.1.2. SCEP pkcsPKIEnvelope 833 The information portion of a SCEP message is carried inside an 834 Enveloped-Data content type, as defined in CMS [3], with the 835 following restrictions: 837 o contentType in encryptedContentInfo MUST be data ({pkcs-7 1}) as 838 defined in CMS [3]. 839 o encryptedContent MUST be the SCEP message being transported (see 840 Section 4), and must match the messageType authenticated Attribute 841 in the pkiMessage. 843 The CMS [3] content-encryption key is encrypted using the public key 844 of the recipient of the message, i.e. the CA public key (if sent from 845 the requester), or the requester public key (if sent as a reply to 846 the requester). 848 3.2. SCEP pkiMessage types 850 All of the messages in this section are pkiMessages (Section 3.1), 851 where the type of the message MUST be specified in the 'messageType' 852 authenticated Attribute. Each section defines a valid message type, 853 the corresponding messageData formats, and mandatory authenticated 854 attributes for that type. 856 3.2.1. PKCSReq/RenewalReq/UpdateReq 858 The messageData for this type consists of a PKCS #10 [6] 859 Certification Request. The certification request MUST contain at 860 least the following items: 862 o The subject Distinguished Name. 863 o The subject public key. 864 o For a PKCSReq and if authorisation based on a password is being 865 used, a challengePassword attribute. 867 In addition to the authenticatedAttributes required for a valid CMS 868 [3] message, the pkiMessage MUST include the following attributes: 870 o A transactionID (Section 3.1.1.1) attribute. 871 o A messageType (Section 3.1.1.2) attribute set to PKCSReq, 872 RenewalReq, or UpdateReq as appropriate. 873 o A senderNonce (Section 3.1.1.5) attribute. 875 The pkcsPKIEnvelope for this message type is protected using the 876 public key of the recipient as detailed in Section 3.1.2, e.g. either 877 the CA public key. 879 3.2.2. CertRep 881 The messageData for this type consists of a degenerate certificates- 882 only CMS [3] Signed-Data message (Section 3.3). The exact content 883 required for the reply depends on the type of request this message is 884 a reply to. They are detailed in Section 3.2.2.1 and in Section 4. 886 In addition to the authenticatedAttributes required for a valid CMS 887 [3], this pkiMessage MUST include the following attributes: 889 o The transactionID (Section 3.1.1.1) attribute copied from the 890 request we are responding to. 892 o A messageType (Section 3.1.1.2) attribute set to CertRep. 893 o A senderNonce (Section 3.1.1.5) attribute. 894 o A recipientNonce attribute (Section 3.1.1.5) copied from the 895 senderNonce from the request that this is a response to. 896 o A pkiStatus (Section 3.1.1.3) set to the status of the reply. 898 The pkcsPKIEnvelope for this message type is protected using the 899 public key of the recipient as detailed in Section 3.1.2. For 900 example if a self-signed certificate was used to send the original 901 request then this self-signed certificate's public key is used to 902 encrypt the content-encryption key of the SUCCESS response's 903 pkcsPKIEnvelope. 905 Note that although it may appear that the senderNonce serves no 906 purpose in this message, it is required if the CertRep contains a 907 PENDING status since the nonce will be used in subsequent polling 908 operations. 910 3.2.2.1. CertRep SUCCESS 912 When the pkiStatus attribute is set to SUCCESS, the messageData for 913 this message consists of a degenerate certificates-only CMS [3] 914 Signed-Data message (Section 3.3). The content of this degenerate 915 certificates-only Signed-Data depends on what the original request 916 was, as outlined below. 918 +--------------+----------------------------------------------------+ 919 | Request-type | Reply-contents | 920 +--------------+----------------------------------------------------+ 921 | PKCSReq | The reply MUST contain at least the issued | 922 | | certificate in the certificates field of the | 923 | | Signed-Data. The reply MAY contain additional | 924 | | certificates, but the issued certificate MUST be | 925 | | the leaf certificate. The reply MUST NOT contain | 926 | | a CRL. | 927 | | | 928 | RenewalReq | Same as PKCSReq | 929 | | | 930 | UpdateReq | Same as PKCSReq | 931 | | | 932 | CertPoll | Same as PKCSReq | 933 | | | 934 | GetCert | The reply MUST contain at least the requested | 935 | | certificate in the certificates field of the | 936 | | Signed-Data. The reply MAY contain additional | 937 | | certificates, but the requested certificate MUST | 938 | | be the leaf certificate. The reply MUST NOT | 939 | | contain a CRL. | 940 | | | 941 | GetCRL | The reply MUST contain the CRL in the crls field | 942 | | of the Signed-Data. The reply MUST NOT contain a | 943 | | certificate. | 944 +--------------+----------------------------------------------------+ 946 3.2.2.2. CertRep FAILURE 948 When the pkiStatus attribute is set to FAILURE, the reply MUST also 949 contain a failInfo (Section 3.1.1.4) attribute set to the appropriate 950 error condition describing the failure. The pkcsPKIEnvelope 951 (Section 3.1.2) MUST be omitted. 953 3.2.2.3. CertRep PENDING 955 When the pkiStatus attribute is set to PENDING, the pkcsPKIEnvelope 956 (Section 3.1.2) MUST be omitted. 958 3.2.3. CertPoll (GetCertInitial) 960 This message is used for certificate polling. For unknown reasons it 961 was referred to as "GetCertInitial" in earlier drafts. The 962 messageData for this type consists of an IssuerAndSubject: 964 issuerAndSubject ::= SEQUENCE { 965 issuer Name, 966 subject Name 967 } 969 The issuer is set to the subjectName of the CA (in other words the 970 intended issuerName of the certificate that's being requested). The 971 Subject is set to the subjectName used when requesting the 972 certificate. 974 In addition to the authenticatedAttributes required for a valid CMS 975 [3], this pkiMessage MUST include the following attributes: 977 o The same transactionID (Section 3.1.1.1) attribute from the 978 original PKCSReq/RenewalReq/UpdateReq message. 979 o A messageType (Section 3.1.1.2) attribute set to CertPoll. 980 o A senderNonce (Section 3.1.1.5) attribute. 981 o A recipientNonce attribute (Section 3.1.1.5) copied from the 982 senderNonce from the request that this is a response to. 984 3.2.4. GetCert 986 The messageData for this type consists of an IssuerAndSerialNumber as 987 defined in CMS [3] which uniquely identifies the certificate being 988 requested. 990 In addition to the authenticatedAttributes required for a valid CMS 991 [3], this pkiMessage MUST include the following attributes: 993 o A transactionID (Section 3.1.1.1) attribute. 994 o A messageType (Section 3.1.1.2) attribute set to GetCert. 995 o A senderNonce (Section 3.1.1.5) attribute. 997 A self-signed certificate MAY be used in the signed envelope. This 998 enables the requester to request their own certificate if they were 999 unable to store it previously. 1001 3.2.5. GetCRL 1003 The messageData for this type consists of a IssuerAndSerialNumber as 1004 defined in CMS [3] containing the issuer name and serial number of 1005 the certificate whose revocation status is being checked. 1007 In addition to the authenticatedAttributes required for a valid CMS 1008 [3], this pkiMessage MUST include the following attributes: 1010 o A transactionID (Section 3.1.1.1) attribute. 1012 o A messageType (Section 3.1.1.2) attribute set to GetCRL. 1013 o A senderNonce (Section 3.1.1.5) attribute. 1015 3.3. Degenerate certificates-only CMS Signed-Data 1017 CMS [3] includes a degenerate case of the CMS [3] Signed-Data content 1018 type, in which there are no signers. The use of such a degenerate 1019 case is to disseminate certificates and CRLs. For SCEP the content 1020 field of the ContentInfo value of a degenerate certificates-only 1021 Signed-Data MUST be omitted. 1023 When carrying certificates, the certificates are included in the 1024 'certificates' field of the Signed-Data. When carrying a CRL, the 1025 CRL will be included in the 'crls' field of the Signed-Data. 1027 3.4. CA Capabilities 1029 In order to provide support for future enhancements to the protocol, 1030 CAs SHOULD implement the GetCACaps message to allow clients to query 1031 which functionality is available from the CA. 1033 3.4.1. GetCACaps HTTP Message Format 1035 This message requests capabilities from a CA, with the format: 1037 "GET" CGI-PATH CGI-PROG "?operation=GetCACaps" 1039 with the message components as described in Section 5. The response 1040 is a list of text capabilities, as defined in Section 3.4.2. CA 1041 servers SHOULD support the GetCACaps message and MUST support it when 1042 they implement any extended functonality beyond the mandatory-to- 1043 implement basics Section 2.8. 1045 3.4.2. CA Capabilities Response Format 1046 The response for a GetCACaps message is a list of CA capabilities, in 1047 plain text, separated by characters, as follows (quotation marks 1048 are NOT sent): 1050 +--------------------+----------------------------------------------+ 1051 | Keyword | Description | 1052 +--------------------+----------------------------------------------+ 1053 | "AES" | CA Supports the AES encryption algorithm. | 1054 | | | 1055 | "DES3" | CA Supports the triple DES encryption | 1056 | | algorithm. | 1057 | | | 1058 | "GetNextCACert" | CA Supports the GetNextCACert message. | 1059 | | | 1060 | "POSTPKIOperation" | PKIOPeration messages may be sent via HTTP | 1061 | | POST. | 1062 | | | 1063 | "Renewal" | CA Supports the Renewal CA operation. | 1064 | | | 1065 | "SHA-1" | CA Supports the SHA-1 hashing algorithm. | 1066 | | | 1067 | "SHA-256" | CA Supports the SHA-256 hashing algorithm. | 1068 | | | 1069 | "SHA-512" | CA Supports the SHA-512 hashing algorithm. | 1070 | | | 1071 | "Update" | CA Supports the Update CA operation. | 1072 +--------------------+----------------------------------------------+ 1074 The client SHOULD use SHA-256 or SHA-512 in preference to SHA-1 1075 hashing, and AES in preference to triple DES if they are supported by 1076 the CA. 1078 Announcing some of these capabilities is redundant since they're 1079 required as mandatory-to-implement functionality (see Section 2.8), 1080 but it may be useful to announce them in order to deal with old 1081 implementations that would otherwise default to obsolete, insecure 1082 algorithms and mechanisms. 1084 The server MUST use the texual case specified here, but clients 1085 SHOULD ignore the textual case when processing this message. A 1086 client MUST be able to accept and ignore any unknown keywords that 1087 might be sent back by a CA. 1089 If the CA supports none of the above capabilities the SCEP server 1090 SHOULD return an empty message. A server MAY simply return an HTTP 1091 error. A client that receives an empty message or an HTTP error 1092 SHOULD interpret the response as if none of the requested 1093 capabilities are supported by the CA. 1095 (Note that at least one widely-deployed server implementation 1096 supports several of the above operations but doesn't support the 1097 GetCACaps message to indicate that it supports them. This means that 1098 the equivalent of GetCACaps must be performed through server 1099 fingerprinting, which can be done using the ID string "Microsoft- 1100 IIS"). 1102 The Content-type of the reply SHOULD be "text/plain". Clients SHOULD 1103 ignore the Content-type, as older server implementations of SCEP may 1104 send various Content-types. 1106 Example: 1108 GET /cgi-bin/pkiclient.exe?operation=GetCACaps 1110 might return: 1112 AES 1113 SHA-256 1114 GetNextCACert 1115 POSTPKIOperation 1117 This means that the CA supports modern crypto algorithms, the 1118 GetNextCACert message, and allows PKIOperation messages 1119 (PKCSReq/RenewalReq/UpdateReq, GetCert, CertPoll, ...) to be sent 1120 using HTTP POST. 1122 4. SCEP Transactions 1124 This section describes the SCEP Transactions, without explaining the 1125 transport. The transport of each message is discussed in Section 5. 1126 Some of the transaction-requests have no data to send, i.e. the only 1127 data is the message-type itself (e.g. a GetCACert message has no 1128 additional data). 1130 In this section, each SCEP transaction is specified in terms of the 1131 complete messages exchanged during the transaction. 1133 4.1. Get CA Certificate 1135 To get the CA certificate(s), the requester sends a GetCACert message 1136 to the server. There is no request data associated with this message 1137 (see Section 5.2.1). 1139 4.1.1. Get CA Certificate Response Message Format 1141 The server MUST indicate which response it is sending via the 1142 transport protocol used (see Section 5.2.1). If the requester does 1143 not have a certificate path to a trust anchor certificate, the SHA-1, 1144 SHA-256, or SHA-512 fingerprint of the returned CA certificate 1145 (communicated via out- of- band means) may be used to verify it. 1147 All returned certificates MUST conform to PKIX [7]. 1149 4.1.1.1. CA Certificate Response Message Format 1151 If the server does not have any intermediate CA certificates, the 1152 response consists of a single X.509 CA certificate. 1154 4.1.1.2. CA Certificate Chain Response Message Format 1156 If the server has intermediate CA certificates, the response consists 1157 of a degenerate certificates-only CMS [3] Signed-Data (Section 3.3) 1158 containing the certificates, with the intermediate CA certificate(s) 1159 as the leaf certificate(s). 1161 4.2. Certificate Enrolment/Renewal/Update 1163 A PKCSReq/RenewalReq/UpdateReq (Section 3.2.1) message is used to 1164 perform a certificate enrolment, renewal, or update transaction. 1166 The reply MUST be a CertRep (Section 3.2.2) message sent back from 1167 the server, indicating SUCCESS, FAILURE, or PENDING. 1169 Precondition: Both the requester and the certification authority have 1170 completed their initialization process. The requester has already 1171 been configured with the CA certificate. 1173 Postcondition: The requester receives the certificate, the request is 1174 rejected, or the request is pending. A pending response might 1175 indicate that manual authentication is necessary. 1177 4.2.1. Certificate Enrolment/Renewal/Update Response Message 1179 If the request is granted, a CertRep (Section 3.2.2) message with 1180 pkiStatus set to SUCCESS is returned. The reply MUST also contain 1181 the certificate (and MAY contain any other certificates needed by the 1182 requester). The issued certificate MUST be the first in the list. 1184 If the request is rejected, a CertRep (Section 3.2.2) message with 1185 pkiStatus set to FAILURE is returned. The reply MUST also contain a 1186 failInfo attribute. 1188 If the the CA is configured to manually authenticate the requester, a 1189 CertRep (Section 3.2.2) message with pkiStatus set to PENDING MAY be 1190 returned. The CA MAY return a PENDING for other reasons. 1192 4.3. Poll for Requester Initial Certificate 1194 Triggered by a CertRep (Section 3.2.2) with pkiStatus set to PENDING, 1195 a requester will enter the polling state by periodically sending 1196 CertPoll messages (Section 3.2.3) to the server, until either the 1197 request is granted and the certificate is sent back, or the request 1198 is rejected, or some preconfigured time limit for polling or maximum 1199 number of polls is exceeded. 1201 CertPoll messages exchanged during the polling period MUST carry the 1202 same transactionID attribute as the previous PKCSReq/RenewalReq/ 1203 UpdateReq. A server receiving a CertPoll for which it does not have 1204 a matching PKCSReq/RenewalReq/UpdateReq MUST ignore this request. 1206 Since at this time the certificate has not been issued, the requester 1207 can only use its own subject name (which was contained in the 1208 original PKCS# 10 sent via PKCSReq/RenewalReq/UpdateReq) to identify 1209 the polled certificate request. In theory there can be multiple 1210 outstanding requests from one requester (for example, if different 1211 keys and different key-usages were used to request multiple 1212 certificates), so the transactionID must also be included to 1213 disambiguate between multiple requests. In practice however it's 1214 safer for the requester to not have multiple requests outstanding at 1215 any one time, since this tends to confuse some servers. 1217 PreCondition: The requester has received a CertRep with pkiStatus set 1218 to PENDING. 1220 PostCondition: The requester has either received a valid response, 1221 which could be either a valid certificate (pkiStatus = SUCCESS), or a 1222 FAILURE message, or the polling period times out. 1224 4.3.1. Polling Response Message Format 1226 The response messages for CertPoll are the same as in Section 4.2.1. 1228 4.4. Certificate Access 1230 A requester can query an issued certificate from the SCEP server, as 1231 long as the requester knows the issuer name and the issuer assigned 1232 certificate serial number. 1234 This transaction consists of one GetCert (Section 3.2.4) message sent 1235 to the server by a requester, and one CertRep (Section 3.2.2) message 1236 sent back from the server. 1238 PreCondition: The certification authority has issued the queried 1239 certificate and the issuer assigned serial number is known. 1241 PostCondition: Either the certificate is sent back or the request is 1242 rejected. 1244 4.4.1. Certificate Access Response Message Format 1246 In this case, the CertRep from the server is same as in 1247 Section Section 4.2.1, except that the server will only either grant 1248 the request (SUCCESS) or reject the request (FAILURE). 1250 4.5. CRL Access 1252 Clients can request a CRL from the SCEP server as described in 1253 Section 2.6. 1255 PreCondition: The certification authority certificate has been 1256 downloaded to the end entity. 1258 PostCondition: CRL sent back to the requester. 1260 4.5.1. CRL Access Response Message Format 1262 The CRL is sent back to the requester in a CertRep (Section 3.2.2) 1263 message. The information portion of this message is a degenerate 1264 certificates-only Signed-Data (Section 3.3) that contains only the 1265 most recent CRL in the crls field of the Signed-Data. 1267 4.6. Get Next Certification Authority Certificate 1269 When the CA certificate expires all certificates that have been 1270 signed by it are no longer valid. CA key rollover provides a 1271 mechanism by which the server MAY distribute a new CA certificate 1272 which is valid in the future; when the current certificate has 1273 expired. When a CA certificate is about to expire, clients need to 1274 retrieve the CA's next CA certificate (i.e. the rollover 1275 certificate). This is done via the GetNextCACert message. There is 1276 no request data associated with this message (see Section 5.2.6). 1278 Clients MUST store the not-yet-valid CA certificate, and any not-yet- 1279 valid client certificates obtained, until such time that they are 1280 valid, at which point clients switch over to using the newly valid 1281 certificates. 1283 4.6.1. Get Next CA Response Message Format 1285 The response consists of a Signed-Data CMS [3], signed by the current 1286 CA signing key. Clients MUST validate the signature on the the 1287 Signed-Data CMS [3] before accepting any of its contents. 1289 The content of the Signed-Data CMS [3] message is a degenerate 1290 certificates-only Signed-Data (Section 3.3) message containing the 1291 new CA certificate(s) as defined in Section 5.2.1.1.2, to be used 1292 when the current CA certificate expires. 1294 If the CA does not have the rollover certificate(s) it MUST reject 1295 the request. It SHOULD also remove the GetNextCACert setting from 1296 the capabilities until it does have rollover certificates. 1298 If there are any intermediate CA certificates in this response, 1299 clients MUST check that these certificates are signed by the CA, and 1300 MUST check authorization of these intermediate CA certificates (see 1301 Section 2.1.2). 1303 5. SCEP Transport 1305 HTTP [4] is used as the transport protocol for SCEP Message Objects. 1307 5.1. HTTP GET and POST Message Formats 1309 SCEP uses the HTTP "GET" and "POST" messages to exchange information 1310 with the CA. The following defines the syntax of a HTTP GET and POST 1311 messages sent from a requester to a certification authority server: 1313 "GET" CGI-PATH CGI-PROG "?operation=" OPERATION "&message=" MESSAGE 1314 "POST" CGI-PATH CGI-PROG "?operation=" OPERATION 1316 where: 1318 o CGI-PATH defines the actual CGI path to invoke the CGI program 1319 that parses the request. 1320 o CGI-PROG is set to be the string "pkiclient.exe". This is 1321 intended to be the program that the CA will use to handle the SCEP 1322 transactions, though the CA may ignore CGI-PROG and use only the 1323 CGI-PATH, or ignore both if it's not issuing certificates via a 1324 web server. Typically, setting CGI-PATH/CGI-PROG to "/cgi-bin/ 1325 pkiclient.exe" will satisfy most servers. 1326 o OPERATION depends on the SCEP transaction and is defined in the 1327 following sections. 1329 o MESSAGE depends on the SCEP transaction and is defined in the 1330 following sections. 1332 Early SCEP drafts performed all communications via "GET" messages, 1333 including non-idempotent ones that should have been sent via "POST" 1334 messages. This has caused problems because of the way that the 1335 (supposedly) idempotent GET interacts with caches and proxies, and 1336 because the extremely large GET requests created by encoding CMS 1337 messages may be truncated in transit. These issues are typically not 1338 visible when testing on a LAN, but crop up during deployment over 1339 WANs. If the remote CA supports it, any of the CMS [3]-encoded SCEP 1340 messages SHOULD be sent via HTTP POST instead of HTTP GET. This is 1341 allowed for any SCEP message except GetCACert, GetNextCACert, or 1342 GetCACaps, and avoids the need for base64- and URL-encoding that's 1343 required for GET messaging. The client can verify that the CA 1344 supports SCEP messages via POST by looking for the "POSTPKIOperation" 1345 capability (See Section 3.4.2). 1347 If your client or server uses HTTP GET and encounters HTTP-related 1348 problems such as messages being truncated, seeing errors such as HTTP 1349 414 ("Request URI too long"), or simply having the message not sent/ 1350 received at all, when standard requests to the server (for example 1351 via a web browser) work, then this is a symptom of the problematic 1352 use of HTTP GET. The solution to this problem is typically to move 1353 to HTTP POST instead. In addition when using GET it's recommended to 1354 test your implementation over the public internet from as many 1355 locations as possible to determine whether the use of GET will cause 1356 problems with communications. 1358 When using GET messages to communicate binary data, base64 encoding 1359 as specified in [2] MUST be used. The base64 encoded data is 1360 distinct from "base64url" and may contain URI reserved characters, 1361 thus it MUST be escaped as specified in [8] in addition to being 1362 bas64 encoded. 1364 5.1.1. Response Message Format 1366 For each GET or POST operation, the CA server MUST return a Content- 1367 Type and appropriate response data, if any. 1369 5.2. SCEP HTTP Messages 1371 This section describes the OPERATION and MESSAGE values for SCEP 1372 exchanges. 1374 5.2.1. GetCACert 1376 The OPERATION MUST be set to "GetCACert". 1378 5.2.1.1. GetCACert Response 1380 The response for GetCACert is different between the case where the CA 1381 directly communicates with the requester during the enrolment, and 1382 the case where an intermediate CA exists and the requester 1383 communicates with this CA during the enrolment. 1385 5.2.1.1.1. CA Certificate Only Response 1387 The response will have a Content-Type of "application/x-x509-ca- 1388 cert". 1390 The body of this response consists of an X.509 CA certificate, as 1391 defined in Section 4.1.1.1: 1393 "Content-Type:application/x-x509-ca-cert" 1395 1397 5.2.1.1.2. CA Certificate Chain Response 1399 The response will have a Content-Type of "application/x-x509-ca-ra- 1400 cert". Note that this designation is used for historical reasons due 1401 to its use in older SCEP drafts, no special meaning should be 1402 attached to the label itself. 1404 The body of this response consists of a degenerate certificates-only 1405 CMS [3] Signed-Data (Section 3.3) message containing both CA and 1406 intermediate CA certificates, as defined in Section 4.1.1.2: 1408 "Content-Type:application/x-x509-ca-ra-cert" 1410 1412 5.2.2. PKCSReq/RenewalReq/UpdateReq 1414 The OPERATION MAY be set to "PKIOperation". When used with HTTP 1415 POST, the only OPERATION possible is "PKIOperation", so many servers 1416 don't check this values or even notice its absence. 1418 The MESSAGE consists of a PKCSReq, RenewalReq, or UpdateReq SCEP 1419 message. When implemented using HTTP POST this might look as 1420 follows: 1422 POST /cgi-bin/pkiclient.exe?operation=PKIOperation HTTP/1.1 1423 Content-Length: 1425 1427 When implemented using HTTP GET this might look as follows: 1429 GET /cgi-bin/pkiclient.exe?operation=PKIOperation& \ 1430 message=MIAGCSqGSIb3DQEHA6CAMIACAQAxgDCBzAIBADB2MG \ 1431 IxETAPBgNVBAcTCE......AAAAAA== HTTP/1.1 1433 5.2.2.1. PKCSReq/RenewalReq/UpdateReq Response 1435 The response will have a Content-Type of "application/x-pki-message". 1437 The body of this response consists of a CertRep SCEP message defined 1438 in Section 4.2.1. The following is an example of the response: 1440 "Content-Type:application/x-pki-message" 1442 1444 5.2.3. CertPoll 1446 The OPERATION MUST be set to "PKIOperation". The MESSAGE consists of 1447 a CertPoll SCEP message. 1449 5.2.3.1. CertPoll Response 1451 The body of this response consists of a CertRep SCEP message defined 1452 in Section 4.3.1. 1454 5.2.4. GetCert 1456 The OPERATION MUST be set to "PKIOperation". The MESSAGE consists of 1457 a GetCert SCEP message. 1459 5.2.4.1. GetCert Response 1461 The body of this response consists of a CertRep SCEP message defined 1462 in Section 4.4.1. 1464 5.2.5. GetCRL 1466 The OPERATION MUST be set to "PKIOperation". The MESSAGE consists of 1467 a GetCRL SCEP message. 1469 5.2.5.1. GetCRL Response 1471 The body of this response consists of a CertRep SCEP message defined 1472 in Section 4.5.1. 1474 5.2.6. GetNextCACert 1476 The OPERATION MUST be set to "GetNextCACert". 1478 5.2.6.1. GetNextCACert Response 1480 The response will have a Content-Type of "application/x-x509-next-ca- 1481 cert". 1483 The body of this response consists of a Signed-Data CMS [3], as 1484 defined in Section 4.6.1. (This is similar to the GetCert response 1485 but does not include any of the attributes defined in Section 3.1.1). 1487 "Content-Type:application/x-x509-next-ca-cert" 1489 1491 6. Contributors/Acknowledgements 1493 The editor would like to thank all the previous editors, authors and 1494 contributors: Cheryl Madson, Xiaoyi Liu, David McGrew, David Cooper, 1495 Andy Nourse, Max Pritikin, Jan Vilhuber, etc for their work 1496 maintaining the draft over the years. Numerous other people have 1497 contributed during the long life cycle of the draft and all deserve 1498 thanks. 1500 The earlier authors would like to thank Peter William of ValiCert, 1501 Inc. (formerly of VeriSign, Inc.) and Alex Deacon of VeriSign, Inc. 1502 and Christopher Welles of IRE, Inc. for their contributions to early 1503 versions of this protocol and this document. 1505 7. IANA Considerations 1507 This memo includes no request to IANA. 1509 8. Security Considerations 1511 The security goals of SCEP are that no adversary can: 1513 o Subvert the public key/identity binding from that intended. 1514 o Discover the identity information in the enrolment requests and 1515 issued certificates. 1517 Here an adversary is any entity other than the requester and the CA 1518 participating in the protocol. The adversary is computationally 1519 limited, but that can manipulate data during transmission (that is, 1520 can act as a MITM). The precise meaning of 'computationally limited' 1521 depends on the implementer's choice of one-way hash functions and 1522 cryptographic algorithms. 1524 The first and second goals are met through the use of CMS [3] and 1525 PKCS #10 [6] encryption and digital signatures using authenticated 1526 public keys. The CA's public key is authenticated via out-of-band 1527 means such as the checking of the CA fingerprint, as specified in 1528 Section 2.1.2, and the SCEP client's public key is authenticated 1529 through manual or pre-shared secret authentication, as specified in 1530 Section 2.2. 1532 The motivation of the first security goal is straightforward. The 1533 motivation for the second security goal is to protect the identity 1534 information in the enrolment requests and issued certificates. 1535 Subsequent protocols can use the certificate in ways that either 1536 expose the identity information, or protect it, depending on the 1537 security requirements of those protocols. The motivation for the 1538 third security goal is to protect the SCEP clients from denial of 1539 service attacks. 1541 8.1. General Security 1543 Common key-management considerations such as keeping private keys 1544 truly private and using adequate lengths for symmetric and asymmetric 1545 keys must be followed in order to maintain the security of this 1546 protocol. This is especially true for CA keys, which, when 1547 compromised, compromise the security of all relying parties. 1549 8.2. Use of the CA keypair 1551 A CA key pair is generally meant for (and is usually flagged as) 1552 certificate (and CRL) signing exclusively, rather than data signing 1553 or encryption. The SCEP protocol, however, uses the CA private key 1554 to both encrypt and sign CMS [3] transport messages. This is 1555 generally considered undesirable, as it widens the possibility of an 1556 implementation weakness, and provides: 1558 o Another place that the private key must be used (and hence is 1559 slightly more vulnerable to exposure). 1560 o Another place where a side channel attack (say, timing or power 1561 analysis) might be used. 1562 o Another place that the attacker might somehow insert their own 1563 data and get it signed by the CA's private key (note that this 1564 issue is purely theoretical, since the CMS data signed by the CA 1565 is nothing remotely like a certificate and couldn't be passed off 1566 as such). 1568 8.3. Challenge Password 1570 The challengePassword sent in the PKCS #10 enrolment request is 1571 signed and encrypted by way of being encapsulated in a pkiMessage. 1572 When saved by the CA, care should be taken to protect this password. 1574 If the challengePassword is used to automatically authenticate an 1575 enrolment request, it is recommended that some form of one-time 1576 password be used to minimize damage in the event the data is 1577 compromised. 1579 8.4. Transaction ID 1581 CAs SHOULD NOT rely on the transactionID to be correct or as 1582 specified in this document. Requesters with buggy software might add 1583 additional undetected duplicate requests to the CA's queue. A well- 1584 written CA should never assume the data from a requester is well- 1585 formed. 1587 8.5. Nonces and Replay 1589 In order to detect replay attacks, both sides need to maintain state 1590 information sufficient to detect an unexpected nonce value. 1592 8.6. GetCACaps Issues 1594 The GetCACaps response is not signed. This allows an attacker to 1595 perform downgrade attacks on the cryptographic capabilities of the 1596 client/CA exchange. 1598 8.7. Unnecessary cryptography 1600 Some of the SCEP exchanges use signing and encryption operations that 1601 are not necessary. In particular the GetCert and GetCRL exchanges 1602 are encrypted and signed in both directions. The information 1603 requested is public and thus signing the requests is of questionable 1604 value but also CRLs and Certificates, i.e. the respective responses, 1605 are already signed by the CA and can be verified by the recipient 1606 without requiring additional signing and encryption. 1608 This may affect performance and scalability of the CA and could be 1609 used as an attack vector on the CA (though not an anonymous one). 1610 The use of CRLDPs as well as other ways of retrieving certificates 1611 such as HTTP access and LDAP are recommended for CRL access. 1613 8.8. GetNextCACert 1615 GetNextCACert depends on a 'flag moment' at which every client in the 1616 PKI infrastructure switches from the current CA certificate (and 1617 client certificate) to the new CA certificate and client 1618 certificates. Proper monitoring of the network infrastructure can 1619 ensure that this will proceed as expected but any errors in 1620 processing or implementation can result in a failure of the PKI 1621 infrastructure. 1623 9. References 1625 9.1. Normative References 1627 [1] Bradner, S., "Key words for use in RFCs to Indicate 1628 Requirement Levels", BCP 14, RFC 2119, March 1997. 1630 [2] Josefsson, S., "The Base16, Base32, and Base64 Data 1631 Encodings", RFC 4648, October 2006. 1633 [3] Housley, R., "Cryptographic Message Syntax (CMS)", 1634 RFC 5652, September 2009. 1636 [4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1637 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1638 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1640 [5] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 1641 Classes and Attribute Types Version 2.0", RFC 2985, 1642 November 2000. 1644 [6] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1645 Request Syntax Specification Version 1.7", RFC 2986, 1646 November 2000. 1648 [7] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1649 Housley, R., and W. Polk, "PKCS #10: Certification Request 1650 Syntax Specification Version 1.7", RFC 5280, May 2008. 1652 [8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1653 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1654 August 1998. 1656 9.2. Informative References 1658 [9] Schaad, J. and M. Myers, "Certificate Management over CMS 1659 (CMC)", RFC 5272, June 2008. 1661 [10] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1662 "Internet X.509 Public Key Infrastructure Certificate 1663 Management Protocol (CMP)", RFC 4210, September 2005. 1665 [11] Gutmann, P., "Internet X.509 Public Key Infrastructure 1666 Operational Protocols: Certificate Store Access via HTTP", 1667 RFC 4387, February 2006. 1669 [12] Alighieri, D., "Internet Key Exchange (IKEv2) Protocol", 1670 RFC 4306, March 1300. 1672 [13] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1673 Mail Extensions (S/MIME) Version 3.2 Message 1674 Specification", RFC 5751, January 2010. 1676 [14] Dierks, T. and E. Rescorla, "The Transport Layer Security 1677 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1679 Appendix A. SCEP State Transitions 1681 SCEP state transitions are indexed by the transactionID attribute. 1682 The design goal is to ensure the synchronization between the CA and 1683 the requester under various error situations. 1685 Each enrolment transaction is uniquely associated with a 1686 transactionID (carried in the transactionID signed attribute (see 1687 Section 3.1.1.1). Because the enrolment transaction could be 1688 interrupted by various errors, including network connection errors or 1689 client reboot, the SCEP client generates a fixed transaction 1690 identifier as specified in Section 3.1.1.1 which is included in the 1691 PKCSReq/RenewalReq/UpdateReq. If the CA returns a response of 1692 PENDING, the requester will poll by periodically sending a CertPoll 1693 with the same transaction identifier until either a response other 1694 than PENDING is obtained or the configured maximum time has elapsed. 1695 This mechanism retains the same transaction identifier throughout the 1696 enrolment transaction. 1698 If the client times out or reboots, the client administrator will 1699 start another transaction with the same key pair. The second 1700 enrolment will have the same transactionID. At the server side, 1701 instead of accepting the PKCSReq/RenewalReq/UpdateReq as a new 1702 request, it can respond as if another CertPoll message had been sent 1703 with that transaction ID. The second PKCSReq/RenewalReq/UpdateReq 1704 should be taken as a resynchronization message to allow the process 1705 to resume as the same transaction. 1707 The following gives several examples of client to CA transactions. 1709 Client actions are indicated in the left column, CA actions are 1710 indicated in the right column. A blank action signifies that no 1711 message was received. 1713 The first transaction, for example, would read like this: 1715 "Client Sends PKCSReq message with transactionID 1 to the CA. The CA 1716 signs the certificate and constructs a CertRep Message containing the 1717 signed certificate with a transaction ID 1. The client receives the 1718 message and installs the certificate locally." 1720 Successful Enrolment Case: no manual authentication 1722 PKCSReq (1) ----------> CA Signs Cert 1723 Client Installs Cert <---------- CertRep (1) SIGNED CERT 1724 Successful Enrolment Case: manual authentication required 1726 PKCSReq (10) ----------> Cert Request goes into Queue 1727 Client Polls <---------- CertRep (10) PENDING 1728 CertPoll (10) ----------> Still pending 1729 Client Polls <---------- CertRep (10) PENDING 1730 CertPoll (10) ----------> Still pending 1731 Client Polls <---------- CertRep (10) PENDING 1732 CertPoll (10) ----------> Still pending 1733 Client Polls <---------- CertRep (10) PENDING 1734 CertPoll (10) ----------> Cert has been signed 1735 <---------- CertRep (10) SIGNED CERT 1736 Client Installs Cert 1738 Resync Case 1 - CA Receives PKCSReq, sends PENDING, eventually grants 1739 the certificate and returns SUCCESS, with the certificate. The 1740 SUCCESS gets lost: 1742 PKCSReq (3) ----------> Cert Request goes into queue 1743 <---------- CertRep (3) PENDING 1744 CertPoll (3) ----------> Still pending 1745 <---------- CertRep (3) PENDING 1746 CertPoll (3) ----------> Cert has been signed 1747 X-------- CertRep(3) SIGNED CERT 1748 (Time Out) 1749 PKCSReq (3) ----------> Cert already granted 1750 <---------- CertRep (3) SIGNED CERT 1751 Client Installs Cert 1753 Resync Case 2 - CA Receives PKCSReq, sends PENDING, PENDING reply 1754 gets lost: 1756 PKCSReq (3) ----------> Cert Request goes into queue 1757 X-------- CertRep (3) PENDING 1758 (Time Out) 1759 PKCSReq (3) ----------> 1760 <---------- CertRep (3) PENDING 1761 etc... 1763 Case when the Certificate is lost, the CA arbitrarily refuses to sign 1764 a replacement (enforcing name-uniqueness) until the original 1765 certificate has been revoked (there is no change of name 1766 information): 1768 PKCSReq (4) ----------> CA Signs Cert 1769 <---------- CertRep (4) SIGNED CERT 1770 Client Installs Cert 1771 (Client looses Cert) 1772 PKCSReq (5) ----------> There is already a valid cert with 1773 this DN. 1774 <---------- CertRep (5) BAD REQUEST 1775 Admin Revokes 1776 PKCSReq (5) ----------> CA Signs Cert 1777 <---------- CertRep (5) SIGNED CERT 1778 Client Installs Cert 1780 CA certificate rollover case: 1782 GetNextCACert ----------> 1783 <---------- New CA certificate 1785 PKCSReq* ----------> CA Signs certificate with NEW 1786 key 1787 Client Stores Cert <---------- CertRep - Certificate issued 1788 for installation when from NEW CA certificate and key 1789 existing cert expires. pair 1791 *enveloped for new CA cert and key pair. The CA will use the 1792 envelope to determine which key and certificate to use to issue the 1793 client certificate. 1795 Appendix B. Background Notes 1797 This specification has spent more than fifteen years in the draft 1798 stage. Its original goal, provisioning IPsec routers with RSA 1799 certificates, has long since changed to general device/embedded 1800 system/IoT use. To fit this role, extra features were bolted on in a 1801 haphazard manner through the addition of a growing list of appendices 1802 and by inserting additional, often conflicting, paragraphs in various 1803 locations in the body text. Since existing features were never 1804 updated as newer ones were added, the specification accumulated large 1805 amounts of historical baggage over time. If OpenPGP was described as 1806 "a museum of 1990s crypto" then the SCEP draft was its graveyard. 1808 About five years ago the specification, which even at that point had 1809 seen only sporadic re-posts of the existing document, was more or 1810 less abandoned by its original sponsors. Due to its widespread use 1811 in large segments of the industry, the specification was rebooted in 1812 2015, cleaning up fifteen years of accumulated cruft, fixing errors, 1813 clarifying ambiguities, and bringing the algorithms and standards 1814 used into the current century (prior to the update, the de-facto 1815 lowest-common denominator algorithms used for interoperability were 1816 the forty-year-old single DES and broken MD5 hash algorithms). 1818 Other changes include: 1820 o Resolved contradictions in the text, for example a requirement 1821 given as a MUST in one paragraph and a SHOULD in the next, a MUST 1822 NOT in one paragraph and a MAY a few paragraphs later, a SHOULD 1823 NOT contradicted later by a MAY, and so on. 1824 o Merged several later fragmentary addenda placed in appendices (for 1825 example the handling of certificate renewal and update) with the 1826 body of the text. 1827 o Updated the algorithms to ones dating from at least this century. 1828 o Did the same for normative references to other standards. 1829 o Corrected incorrect references to other standards, e.g. 1830 IssuerAndSerial -> IssuerAndSerialNumber. 1831 o Corrected errors such as a statement that when both signature and 1832 encryption certificates existed, the signature certificate was 1833 used for encryption. 1834 o Condensed redundant discussions of the same topic spread across 1835 multiple sections into a single location. For example the 1836 description of intermediate CA handling previously existed in 1837 three different locations, with slightly different reqirements in 1838 each one. 1839 o Relaxed some requirements that didn't serve any obvious purpose 1840 and that major implementations didn't seem to be enforcing. For 1841 example the requirement that the self-signed certificate used with 1842 a request MUST contain a subject name that matched the one in the 1843 PKCS #10 request was relaxed to a SHOULD because a number of 1844 implementations either ignored the issue entirely or at worst 1845 performed some minor action like creating a log entry after which 1846 they continued anyway. 1847 o Clarified sections that were unclear or even made no sense, for 1848 example the requirement for a "hash on the public key [sic]" 1849 encoded as a PrintableString. 1850 o Renamed "RA certificates" to "intermediate CA certificates". The 1851 original document at some point added mention of RA certificates 1852 without specifying how the client was determine that an RA was in 1853 use, how the RA operations were identified in the protocol, or how 1854 it was used. It's unclear whether what was meant was a true RA or 1855 merely an intermediate CA, as opposed to the default practice of 1856 having certificates issued directly from a single root CA 1857 certificate. This update uses the term "intermediate CA 1858 certificates", since this seems to have been the original intent 1859 of the text. 1860 o Clarified certificate renewal and update. These represent a 1861 capability that was bolted onto the original protocol with (at 1862 best) vaguely-defined semantics, including a requirement by the 1863 server to guess whether a particular request was a renewal or not 1864 (updates were even more vaguely defined). In response to 1865 developer feedback that they either avoided renewal/update 1866 entirely because of this uncertainty or hardcoded in particular 1867 behaviour on a per-server basis, this specification explicitly 1868 identifies renewal and update requests as such, and provides 1869 proper semantics for both. Note that this is still a work in 1870 progress due to the lack of clarity of the original spec in this 1871 area, see some of the questions inline with the text. 1872 o Removed the discussion in the security considerations of 1873 revocation issues, since SCEP doesn't support revocation. 1875 Authors' Addresses 1877 Peter Gutmann 1878 University of Auckland 1879 Department of Computer Science 1880 Auckland 1881 New Zealand 1883 Email: pgut001@cs.auckland.ac.nz 1885 Max Pritikin 1886 Cisco Systems, Inc