idnits 2.17.1 draft-gutmann-scep-00.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 23, 2015) is 3322 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 478 -- Looks like a reference, but probably isn't: 'CERT-REQ-PENDING' on line 478 -- Looks like a reference, but probably isn't: 'CERT-ISSUED' on line 478 ** 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 24, 2015 A. Nourse 5 J. Vilhuber 6 Cisco 7 March 23, 2015 9 Simple Certificate Enrolment Protocol 10 draft-gutmann-scep-00.txt 12 Abstract 14 This document specifies the Simple Certificate Enrolment Protocol 15 (SCEP), a Public Key Infrastructure (PKI) communication protocol 16 which leverages existing technology by using CMS (formerly known as 17 PKCS #7) and PKCS #10 over HTTP. SCEP is the evolution of the 18 enrolment protocol sponsored by Cisco Systems, which now enjoys wide 19 support in both client and server implementations, as well as being 20 relied upon by numerous other industry standards that work with 21 certificates. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 24, 2015. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Conventions Used in This Document . . . . . . . . . . . . 5 59 2. SCEP Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.1. SCEP Entities . . . . . . . . . . . . . . . . . . . . . . 5 61 2.1.1. Requester . . . . . . . . . . . . . . . . . . . . . . 5 62 2.1.2. Certification Authority . . . . . . . . . . . . . . . 6 63 2.1.3. Registration Authority . . . . . . . . . . . . . . . 6 64 2.1.4. CA/RA Certificate Distribution . . . . . . . . . . . 7 65 2.2. Requester authentication . . . . . . . . . . . . . . . . 8 66 2.3. Enrolment authorization . . . . . . . . . . . . . . . . . 9 67 2.4. Certificate Enrolment/Renewal/Update . . . . . . . . . . 10 68 2.4.1. Client State Transitions . . . . . . . . . . . . . . 10 69 2.5. Certificate Access . . . . . . . . . . . . . . . . . . . 12 70 2.6. CRL Access . . . . . . . . . . . . . . . . . . . . . . . 13 71 2.7. Certificate Revocation . . . . . . . . . . . . . . . . . 14 72 2.8. Mandatory-to-Implement Functionality . . . . . . . . . . 14 73 3. SCEP Secure Message Objects . . . . . . . . . . . . . . . . . 14 74 3.1. SCEP pkiMessage . . . . . . . . . . . . . . . . . . . . . 15 75 3.1.1. Signed Transaction Attributes . . . . . . . . . . . . 16 76 3.1.1.1. transactionID . . . . . . . . . . . . . . . . . . 18 77 3.1.1.2. messageType . . . . . . . . . . . . . . . . . . . 19 78 3.1.1.3. pkiStatus . . . . . . . . . . . . . . . . . . . . 19 79 3.1.1.4. failInfo . . . . . . . . . . . . . . . . . . . . 20 80 3.1.1.5. senderNonce and recipientNonce . . . . . . . . . 20 81 3.1.2. SCEP pkcsPKIEnvelope . . . . . . . . . . . . . . . . 20 82 3.2. SCEP pkiMessage types . . . . . . . . . . . . . . . . . . 21 83 3.2.1. PKCSReq/RenewalReq/UpdateReq . . . . . . . . . . . . 21 84 3.2.2. CertRep . . . . . . . . . . . . . . . . . . . . . . . 21 85 3.2.2.1. CertRep SUCCESS . . . . . . . . . . . . . . . . . 22 86 3.2.2.2. CertRep FAILURE . . . . . . . . . . . . . . . . . 23 87 3.2.2.3. CertRep PENDING . . . . . . . . . . . . . . . . . 23 88 3.2.3. CertPoll (GetCertInitial) . . . . . . . . . . . . . . 23 89 3.2.4. GetCert . . . . . . . . . . . . . . . . . . . . . . . 24 90 3.2.5. GetCRL . . . . . . . . . . . . . . . . . . . . . . . 24 91 3.3. Degenerate certificates-only CMS Signed-Data . . . . . . 25 92 3.4. CA Capabilities . . . . . . . . . . . . . . . . . . . . . 25 93 3.4.1. GetCACaps HTTP Message Format . . . . . . . . . . . . 25 94 3.4.2. CA Capabilities Response Format . . . . . . . . . . . 25 95 4. SCEP Transactions . . . . . . . . . . . . . . . . . . . . . . 27 96 4.1. Get CA Certificate . . . . . . . . . . . . . . . . . . . 27 97 4.1.1. Get CA Certificate Response Message Format . . . . . 28 98 4.1.1.1. CA Certificate Response Message Format . . . . . 28 99 4.1.1.2. CA/RA Certificate Response Message Format . . . . 28 100 4.2. Certificate Enrolment/Renewal/Update . . . . . . . . . . 28 101 4.2.1. Certificate Enrolment/Renewal/Update Response Message 28 102 4.3. Poll for Requester Initial Certificate . . . . . . . . . 29 103 4.3.1. Polling Response Message Format . . . . . . . . . . . 29 104 4.4. Certificate Access . . . . . . . . . . . . . . . . . . . 30 105 4.4.1. Certificate Access Response Message Format . . . . . 30 106 4.5. CRL Access . . . . . . . . . . . . . . . . . . . . . . . 30 107 4.5.1. CRL Access Response Message Format . . . . . . . . . 30 108 4.6. Get Next Certification Authority Certificate . . . . . . 30 109 4.6.1. Get Next CA Response Message Format . . . . . . . . . 31 110 5. SCEP Transport . . . . . . . . . . . . . . . . . . . . . . . 31 111 5.1. HTTP GET and POST Message Formats . . . . . . . . . . . . 31 112 5.1.1. Response Message Format . . . . . . . . . . . . . . . 32 113 5.2. SCEP HTTP Messages . . . . . . . . . . . . . . . . . . . 32 114 5.2.1. GetCACert . . . . . . . . . . . . . . . . . . . . . . 32 115 5.2.1.1. GetCACert Response . . . . . . . . . . . . . . . 33 116 5.2.1.1.1. CA Certificate Only Response . . . . . . . . 33 117 5.2.1.1.2. CA and RA Certificates Response . . . . . . . 33 118 5.2.2. PKCSReq/RenewalReq/UpdateReq . . . . . . . . . . . . 33 119 5.2.2.1. PKCSReq/RenewalReq/UpdateReq Response . . . . . . 34 120 5.2.3. CertPoll . . . . . . . . . . . . . . . . . . . . . . 34 121 5.2.3.1. CertPoll Response . . . . . . . . . . . . . . . . 34 122 5.2.4. GetCert . . . . . . . . . . . . . . . . . . . . . . . 34 123 5.2.4.1. GetCert Response . . . . . . . . . . . . . . . . 34 124 5.2.5. GetCRL . . . . . . . . . . . . . . . . . . . . . . . 35 125 5.2.5.1. GetCRL Response . . . . . . . . . . . . . . . . . 35 126 5.2.6. GetNextCACert . . . . . . . . . . . . . . . . . . . . 35 127 5.2.6.1. GetNextCACert Response . . . . . . . . . . . . . 35 128 6. Contributors/Acknowledgements . . . . . . . . . . . . . . . . 35 129 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 130 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 131 8.1. General Security . . . . . . . . . . . . . . . . . . . . 37 132 8.2. Use of the CA keypair . . . . . . . . . . . . . . . . . . 37 133 8.3. Challenge Password . . . . . . . . . . . . . . . . . . . 37 134 8.4. Transaction ID . . . . . . . . . . . . . . . . . . . . . 38 135 8.5. Nonces and Replay . . . . . . . . . . . . . . . . . . . . 38 136 8.6. GetCACaps Issues . . . . . . . . . . . . . . . . . . . . 38 137 8.7. Unnecessary cryptography . . . . . . . . . . . . . . . . 38 138 8.8. GetNextCACert . . . . . . . . . . . . . . . . . . . . . . 38 139 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 140 9.1. Normative References . . . . . . . . . . . . . . . . . . 39 141 9.2. Informative References . . . . . . . . . . . . . . . . . 39 142 Appendix A. SCEP State Transitions . . . . . . . . . . . . . . . 40 143 Appendix B. Background Notes . . . . . . . . . . . . . . . . . . 43 144 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 146 1. Introduction 148 Public key technology is widely available and increasingly widely 149 deployed. X.509 certificates serve as the basis for several 150 standards-based security protocols in the IETF, such as TLS [14], S/ 151 MIME [13], and and IKE/IPsec [12]. When an X.509 certificate is 152 issued by other than the certificate subject (a self-issued 153 certificate), there typically is a need for a certificate management 154 protocol. Such a protocol enables a PKI client to request a 155 certificate, certificate renewal, certificate update, or certificate 156 revocation from a Certification Authority (CA). 158 This specification defines a protocol, Simple Certificate Enrolment 159 Protocol (SCEP), for certificate management and certificate and CRL 160 queries in a closed environment. While widely deployed, this 161 protocol omits some certificate management features, e.g. certificate 162 revocation transactions, which can significantly enhance the security 163 achieved in a PKI. The IETF protocol suite currently includes two 164 further certificate management protocols with more comprehensive 165 functionality: Certificate Management Protocol (CMP) [10] and 166 Certificate Management over CMS (CMC) [9]. Environments that do not 167 require interoperability with SCEP implementations MAY consider using 168 the above-mentioned certificate management protocols, however anyone 169 considering this step should be aware that the high level of 170 complexity of these two protocols has resulted in serious 171 interoperability problems and corresponding lack of industry support. 172 SCEP's simplicity, while being a drawback in terms of its limited 173 functionality, also makes deployment relatively straightforward, so 174 that it enjoys widespread industry support and ready interoperability 175 across a wide range of platforms. While implementers are encouraged 176 to investigate one of the more comprehensive alternative certificate 177 management protocols in addition to the protocol defined in this 178 specification, anyone wishing to deploy them should proceed with 179 caution, and consider support and interoperability issues before 180 committing to their use. 182 The protocol supports the following general operations: 184 o CA and Registration Authority (RA) public key distribution. 185 o Certificate enrolment. 186 o Certificate renewal/update. 187 o Certificate query. 188 o CRL query. 190 SCEP makes extensive use of CMS [3] and PKCS #10 [6]. 192 1.1. Conventions Used in This Document 194 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 195 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 196 document are to be interpreted as described in [1]. 198 2. SCEP Overview 200 This section provides a high level overview of the functionality of 201 SCEP. 203 2.1. SCEP Entities 205 The entity types defined in SCEP are 207 o The Requester, or client (Section 2.1.1). 208 o The Server, which may be either a Certification Authority (CA) 209 (Section 2.1.2) or a Registration Authority (RA) (Section 2.1.3). 211 2.1.1. Requester 213 The requester is sometimes called a "client" in this document. It is 214 the client of the SCEP exchange. 216 The requester MAY submit SCEP messages for itself or it MAY submit 217 SCEP messages on behalf of peers as described in Registration 218 Authority (Section 2.1.3). This section focuses on the requester 219 that is obtaining certificates for its own use. 221 Before a requester can start a PKI transaction, it MUST have at least 222 one appropriate key pair for use when signing the SCEP pkiMessage 223 (Section 3.1). 225 The message types, being based on CMS [3] and PKCS #10 [6], fully 226 support algorithm agility but the requester has to use a key type 227 that is supported by the server. Specifically, they must employ a 228 PKC algorithm capable of both encryption and signing. RSA is the 229 only widely-used algorithm that has these properties. 231 A requester MUST have the following information locally configured: 233 1. The Certification Authority IP address or fully qualified domain 234 name. 235 2. The Certification Authority HTTP CGI script path (this usually 236 has a default value, see Section 5.1). 237 3. The identifying information that is used for authentication of 238 the Certification Authority in Section 4.1.1, typically a 239 certificate fingerprint. This information MAY be obtained from 240 the user, or presented to the end user for manual authorization 241 during the protocol exchange (e.g. the user indicates acceptance 242 of a fingerprint via a user-interface element). 244 The requester MAY maintain multiple independent configurations 245 appropriate for multiple Certification Authorities. Doing so does 246 not effect the protocol operation and is not in scope of this 247 document. 249 2.1.2. Certification Authority 251 A SCEP Certification Authority (CA) is the entity that signs client 252 certificates. A certification authority MAY enforce any arbitrary 253 policies and apply them to certification requests. The certification 254 authority MAY reject any request. If the client has already been 255 issued a certificate for this keypair the server MAY return the 256 previously created certificate. The requester MUST NOT assume any of 257 the fields in the certification request, except for the public key, 258 will be the same in the certificate issued. 260 The certification authority MAY include a cRLDistributionPoint 261 extension in every certificate it issues, make CRLs available via 262 HTTP [11] or LDAP, or answer CRL queries itself. In the latter case 263 it SHOULD be online at all times. 265 Since the client is expected to perform encryption and signature 266 verification using the CA certificate, the keyUsage extension in the 267 CA certificate MUST indicate that it is valid for digitalSignature 268 and keyEncipherment use alongside the usual CA usages of keyCertSign 269 and/or cRLSign. 271 If a client times out from polling for a pending request it can 272 resynchronize by reissuing the original request with the original 273 subject name, key, and transactionID. The CA SHOULD return the 274 status of the original transaction, including the certificate if it 275 was granted. 277 2.1.3. Registration Authority 279 A SCEP Registration Authority (RA) is a SCEP server that performs 280 validation and authorization checks of the SCEP requester but 281 forwards the certification requests to the CA. The RA's name does 282 not appear in the issuer field of resulting certificates. 284 Distribution of RA certificates is covered in Section 2.1.4. In 285 order to securely communicate with an RA using SCEP Secure Message 286 Objects (Section 3) the client specifies the RA as the recipient of 287 subsequent SCEP pkiMessages (see Section 3.1.2). 289 In order to service certification requests the RA must pass the 290 requests to the CA server for signing. The RA MAY use SCEP to 291 communicate with the CA, in which case the RA acts as both a SCEP 292 server (between the client and the RA) and a SCEP requester (between 293 the RA and the CA). The RA MAY respond to client certificate 294 requests with a PENDING response while communicating with the CA; for 295 example if the CA must manually authorize a certification request and 296 thus returns PENDING to the RA the RA may respond with PENDING to the 297 client while polling the CA. 299 2.1.4. CA/RA Certificate Distribution 301 If the CA and/or RA certificates have not previously been acquired by 302 the requester in some other means, the requester MUST retrieve the 303 CA/RA certificates before any PKI operation (Section 3) can be 304 started. 306 Since no public key has yet been exchanged between the requester and 307 the CA/RA, the messages cannot be secured using CMS [3], and the data 308 is instead transferred in the clear. 310 If an RA is in use, a certificates-only CMS [3] Signed-Data message 311 with a certificate chain consisting of both RA and CA certificates is 312 returned. Otherwise the CA certificate itself is returned. The 313 transport protocol (Section 5) MUST indicate which one is returned. 315 The SCEP server CA certificate MAY be provided out-of-band to the 316 SCEP requester. Alternatively, the CA certificate fingerprint MAY be 317 used to authenticate a CA Certificate distributed by the GetCACert 318 response (Section 4.1) or via HTTP [11]. The fingerprint is created 319 by calculating a SHA-1, SHA-256, or SHA-512 hash over the whole CA 320 certificate. 322 After the requester gets the CA certificate, it SHOULD authenticate 323 the CA certificate by comparing the CA certificate fingerprint with 324 the locally configured, out-of-band distributed, identifying 325 information. RA certificates, if any, are signed by the CA so there 326 is no need to authenticate them against the out-of-band data. 327 Clients SHOULD verify the RA certificate signatures before use during 328 protocol exchanges. 330 Because a long time can pass between queries from a requester to a 331 CA/RA and because RA certificates can change at any time, it is 332 recommended that a requester not store RA certificates. Instead, the 333 requester SHOULD retrieve the CA/RA certificates before each 334 operation. 336 2.2. Requester authentication 338 As with every protocol that uses public-key cryptography, the 339 association between the public keys used in the protocol and the 340 identities with which they are associated must be authenticated in a 341 cryptographically secure manner. This requirement is needed to 342 prevent a man-in-the-middle (MITM) attack, in which an adversary can 343 manipulate the data as it travels between the protocol participants 344 and subvert the security of the protocol. 346 The communication between the requester and the certification 347 authority are secured using SCEP Secure Message Objects (Section 3) 348 which specifies how CMS [3] is used to encrypt and sign the data. In 349 order to perform the signing operation the client uses an appropriate 350 local certificate: 352 1. If the requester does not have an appropriate existing 353 certificate then a locally generated self-signed certificate MUST 354 be used. The self-signed certificate MUST use the same subject 355 name as in the PKCS #10 request. In this case the messageType is 356 PKCS10Req (see Section 3.1.1.2). 357 2. If the requesting system already has a certificate issued by the 358 SCEP server, and the server supports renewal (see Section 2.4), 359 that certificate SHOULD be used. In this case the messageType is 360 RenewalReq (see Section 3.1.1.2). 361 3. If the requesting system has no certificate issued by the new CA, 362 but has credentials from an alternate CA the certificate issued 363 by the alternate CA MAY be used. Policy settings on the new CA 364 will determine if the request can be accepted or not. This is 365 useful when enrolling with a new administrative domain using a 366 certificate from the old domain as credentials. In this case the 367 messageType is UpdateReq (see Section 3.1.1.2). 369 Note that although the above text describes three different types of 370 operations, in practice most implementations always apply the first 371 one even if an existing certificate already exists. For this reason 372 support for the first case is mandatory while support for the latter 373 two are optional (see Section 2.8). 375 During the certificate enrolment process, the requester MUST use the 376 selected certificate's key when signing the CMS [3] envelope (see 377 Section 3). The server's CertResp then uses the same certificate's 378 public key when encrypting the response (see Section 3.2.2). 380 [Question: This is another area where the semantics were never 381 defined, what happens during a renewal or update? For an 382 enrolment the signing cert contains the key that's also in the 383 request, but what about for a renewal or update where they're 384 quite probably different keys? Should the envelope be 385 encrypted to the key in the request or the signing key?]. 387 When the certification authority creates the CMS [3] envelope 388 containing the issued certificate, it SHOULD use the public key and 389 identifying information conveyed in the above included certificate. 390 This will inform the end entity of which private key is needed to 391 open the envelope. Note that when a client enrolls for separate 392 encryption and signature certificates, it MAY use the signature 393 certificate to sign both requests, and then expect its encryption 394 certificate to be used to encrypt both responses. In any case, the 395 RecipientInfo on the envelope MUST reflect the key used to encrypt 396 the request. 398 [Question: Another undefined area, how is this dual-cert 399 operation supposed to work? Does the CA look up a previously- 400 issued encryption cert? Does anyone even care about this?]. 402 2.3. Enrolment authorization 404 PKCS #10 [6] specifies a PKCS #9 [5] challengePassword attribute to 405 be sent as part of the enrolment request. When utilizing the 406 challengePassword, the server distributes a shared secret to the 407 requester which will uniquely associate the enrolment request with 408 the requester. 410 Inclusion of the challengePassword by the SCEP client is OPTIONAL and 411 allows for unauthenticated authorization of enrolment requests 412 (which, however, requires manual approval of each certificate issue, 413 see below), or for renewal or update requests which are authenticated 414 by being signed with an existing certificate. The CMS [3] envelope 415 protects the privacy of the challengePassword. 417 A client that is performing certificate renewal or update as per 418 Section 2.4 SHOULD omit the challengePassword but MAY send the 419 originally distributed password in the challengePassword attribute. 420 In the former case the SCEP CA MUST authenticate the request based on 421 the certificate used to sign the renewal or update request. In the 422 latter case the SCEP CA MAY use either the challengePassword or the 423 previously issued certificate (or both), depending on CA policy, to 424 authenticate the request. The SCEP server MUST NOT attempt to 425 authenticate a client based on a self-signed certificate unless it 426 has been verified through out-of-band means such as a certificate 427 fingerprint. 429 To perform the authorization in manual mode the requester's messages 430 are placed in the PENDING state until the CA operator authorizes or 431 rejects them. Manual authorization is used when the client has only 432 a self-signed certificate that hasn't been previously authenticated 433 by the CA and/or a challengePassword is not available. The SCEP 434 server MAY either reject unauthorized certification requests or mark 435 them for manual authorization according to CA policy. 437 2.4. Certificate Enrolment/Renewal/Update 439 A requester starts an enrolment (Section 3.2.1) transaction by 440 creating a certificate request using PKCS #10 [6] and sends it to the 441 CA/RA enveloped using CMS [3] (Section 3). 443 If the CA supports certificate renewal or update then a new 444 certificate with new validity dates can be issued, even though the 445 old one is still valid, if the CA policy permits. The server MAY 446 automatically revoke the old client certificate. To renew or update 447 an existing certificate, the client uses the RenewalReq or UpdateReq 448 message (see Section 3.2) and signs it with the existing client 449 certificate. The client SHOULD use a new keypair when requesting a 450 new certificate, but MAY request a new certicate using the old 451 keypair. 453 If the CA/RA returns a CertRep (Section 3.2.2) message with status 454 set to PENDING, the requester enters into polling mode by 455 periodically sending a CertPoll (Section 3.2.3) PKI message to the 456 CA/RA, until the CA/RA operator completes the manual authentication 457 (approving or denying the request). 459 In general, the requester will send a single PKCSReq/RenewalReq/ 460 UpdateReq (Section 3.2.1) message, followed by 0 or more CertPoll 461 (Section 3.2.3) messages, if polling mode is entered. 463 In general, the CA/RA will send 0 or more CertRep (Section 3.2.2) 464 messages with status set to PENDING, followed by a single CertRep 465 (Section 3.2.2) with status set to either SUCCESS or FAILURE. 467 2.4.1. Client State Transitions 469 The requester state transitions during enrolment operation are 470 indicated in Figure 1. 472 CertPoll 473 +----<---+ 474 | | CertRep(PENDING), 475 | | CertPoll send-timeout, 476 | | new-poll timer 477 | | 478 [CERT-NONEXISTENT] -----+---> [CERT-REQ-PENDING] [CERT-ISSUED] 479 ^ PKCSReq | | ^ 480 | RenewalReq | | | 481 | UpdateReq | +---------------+ 482 | | CertRep(SUCCESS) 483 +--------------------------+ 484 CertRep(FAILURE), 485 PKCS/Update/RenewalReq send-timeout, 486 max-time/max-polls exceeded 488 Figure 1: State Transition Diagram 490 The certificate issue process starts at the state CERT-NONEXISTENT. 492 Sending a PKCSReq/RenewalReq/UpdateReq message changes the state to 493 CERT-REQ-PENDING. If there is no response, or sending is not 494 possible, the state reverts back to CERT-NONEXISTENT. 496 Receiving a CertRep message with pkiStatus set to SUCCESS changes the 497 state to CERT-ISSUED. 499 Receiving a CertRep message with pkiStatus set to FAILURE changes the 500 state to CERT-NONEXISTENT. 502 If the server sends back a CertRep message with pkiStatus set to 503 PENDING, the requester will keep polling by sending a CertPoll 504 message to the server, until either a CertRep message with status set 505 to SUCCESS or FAILURE is received, or the maximum number of polls has 506 been exceeded. 508 If the maximum number of polls has been exceeded or a CertRep message 509 with pkiStatus set to FAILURE is received while in the CERT-REQ- 510 PENDING state, the end entity will transition to the CERT-NONEXISTENT 511 state, and the SCEP client can eventually initiate another enrolment 512 request. It is important to note that, as long as the requester does 513 not change its subject name or keys, the same transactionID may be 514 used in the "new" transaction. This is important because based on 515 this transactionID, the certification authority can recognize this as 516 an existing transaction instead of a new one. 518 A successful transaction in automatic mode: 520 REQUESTER CA SERVER 522 PKCSReq: PKI cert. enrolment msg 523 --------------------------------> CertRep: pkiStatus = SUCCESS 524 certificate attached 525 <------------------------------ 526 Receive issued certificate. 528 A successful transaction in manual mode: 530 REQUESTER CA SERVER 532 PKCSReq: PKI cert. enrolment msg 533 --------------------------------> CertRep: pkiStatus = PENDING 534 <------------------------------ 535 CertPoll: polling msg 536 --------------------------------> CertRep: pkiStatus = PENDING 537 <------------------------------ 538 ................ ............... 540 CertPoll: polling msg 541 --------------------------------> CertRep: pkiStatus = SUCCESS 542 certificate attached 543 <------------------------------ 544 Receive issued certificate. 546 2.5. Certificate Access 548 A certificate query message is defined for clients to retrieve a copy 549 of their own certificate from the CA. It allows clients that do not 550 store their certificates locally to obtain a copy when needed. This 551 functionality is not intended to provide a general purpose 552 certificate store access service, which may be achieved via HTTP [11] 553 or LDAP. 555 To query a certificate from the certification authority, a requester 556 sends a request consisting of the certificate's issuer name and 557 serial number. This assumes that the requester has saved the issuer 558 name and the serial number of the issued certificate from the 559 previous enrolment transaction. The transaction to query a 560 certificate consists of one GetCert (Section 3.2.4) message and one 561 CertRep (Section 3.2.2) message, as shown below. 563 REQUESTER CA SERVER 565 GetCert: PKI certificate query msg 566 -------------------------------> CertRep: pkiStatus = SUCCESS 567 certificate attached 568 <----------------------------- 569 Receive the certificate. 571 2.6. CRL Access 573 SCEP clients MAY request a CRL via one of three methods: 575 1. If the CA supports CRL Distribution Points (CRLDPs) [7], then the 576 CRL MAY be retrieved via the mechanism specified in the CRDLP. 577 2. If the CA supports HTTP [11], then the CRL MAY be retrieved via 578 the AuthorityInfoAcces [7] location specified in the certificate. 579 3. Only if the CA does not support CRDLPs or HTTP access should a 580 CRL query be composed by creating a GetCRL message consisting of 581 the issuer name and serial number from the certificate whose 582 revocation status is being queried. 584 The server SHOULD NOT support the GetCRL method because: 586 o It does not scale well due to the unnecessary cryptography (see 587 Section 8). 588 o It requires the CA to be a high-availability service. 589 o Only limited information to determine the CRL scope is provided 590 (see [7]). 592 The message is sent to the SCEP server in the same way as the other 593 SCEP requests. The transaction to retrieve a CRL consists of one 594 GetCRL PKI message and one CertRep PKI message, which contains only 595 the CRL (no certificates) in a degenerate certificates-only CMS [3] 596 Signed-Data message (Section 3.3), as shown below. 598 REQUESTER CA SERVER 600 GetCRL: PKI CRL query msg 601 ----------------------------------> 602 CertRep: CRL attached 603 <----------------------------- 604 Receive the CRL 606 2.7. Certificate Revocation 608 SCEP does not specify a method to request certificate revocation. In 609 order to revoke a certificate, the requester must contact the CA 610 using a non-SCEP defined mechanism. 612 2.8. Mandatory-to-Implement Functionality 614 At a minimum, all SCEP implementations compliant with this 615 specification MUST support GetCACert (Section 4.1), PKCSReq 616 (Section 3.2.1) (and its associated response messages), communication 617 of binary data via HTTP POST (Section 5.1), and the AES and SHA-256 618 algorithms to secure pkiMessages (Section 3.1). 620 For historical reasons implementations MAY support communications of 621 binary data via HTTP GET (Section 5.1), and the triple DES and SHA-1 622 algorithms to secure pkiMessages (Section 3.1). 624 3. SCEP Secure Message Objects 626 CMS [3] is a general enveloping mechanism that enables both signed 627 and encrypted transmission of arbitrary data. SCEP messages that 628 require confidentiality use two layers of CMS [3], as shown in 629 Figure 2. By applying both enveloping and signing transformations, 630 the SCEP message is protected both for the integrity of its end-to- 631 end transaction information and the confidentiality of its 632 information portion. The advantage of this technique over the 633 conventional transaction message format is that the signed 634 transaction type information and the status of the transaction can be 635 determined prior to invoking security handling procedures specific to 636 the information portion being processed. 638 Some messages do not require enveloping, in which case the Enveloped- 639 Data in Figure 2 is omitted. 641 pkiMessage { 642 contentType = signedData 643 content { 644 pkcsPKIEnvelope { -- Optional 645 contentType = envelopedData 646 content { 647 recipientInfo 648 contentType = data 649 content { 650 messageData -- Typically PKCS #10 request 651 } 652 } 653 } 654 signerInfo { 655 signedAttrs { 656 transactionID 657 messageType 658 pkiStatus 659 failInfo 660 senderNonce 661 recipientNonce 662 } 663 signature 664 } 665 } 666 } 668 Figure 2: CMS Layering 670 When a particular SCEP message carries data, this data is carried in 671 the messageData. CertRep messages will lack any signed content and 672 consist only of a pkcsPKIEnvelope (Section 3.1.2). 674 Note: The remainder of this document will refer only to 675 'messageData', but it is understood to always be encapsulated in the 676 pkcsPKIEnvelope (Section 3.1.2). The format of the data in the 677 messageData is defined by the messageType attribute (see Section 3.1) 678 of the Signed-Data. If there is no messageData to be transmitted, 679 the entire pkcsPKIEnvelope MUST be omitted. 681 3.1. SCEP pkiMessage 683 The basic building block of all secured SCEP messages is the SCEP 684 pkiMessage. It consists of a CMS [3] Signed-Data content type. The 685 following restrictions apply: 687 o The contentType in contentInfo MUST be data ({pkcs-7 1}) as 688 defined in CMS [3]. 689 o The signed content, if present (e.g. FAILURE and PENDING CertRep 690 messages will lack any signed content), MUST be a pkcsPKIEnvelope 691 (Section 3.1.2), and MUST match the messageType attribute. 692 o The SignerInfo MUST contain a set of authenticatedAttributes (see 693 CMS [3] as well as Section 3.1 in this document). 695 At a minimum, all messages MUST contain the following 696 authenticatedAttributes: 698 o A transactionID attribute (see Section 3.1.1.1). 699 o A messageType attribute (see Section 3.1.1.2). 700 o A senderNonce attribute (see Section 3.1.1.5). 701 o Any attributes required by CMS [3]. 703 If the message is a response, it MUST also include the following 704 authenticatedAttributes: 706 o A pkiStatus attribute (see Section 3.1.1.3). 707 o A recipientNonce attribute (see Section 3.1.1.5). 709 3.1.1. Signed Transaction Attributes 711 The following transaction attributes are encoded as authenticated 712 attributes, and are carried, as specified in CMS [3], in the 713 SignerInfo for this Signed-Data. 715 +----------------+-----------------+--------------------------------+ 716 | Attribute | Encoding | Comment | 717 +----------------+-----------------+--------------------------------+ 718 | transactionID | PrintableString | Unique ID for this transaction | 719 | | | as a text string | 720 | | | | 721 | messageType | PrintableString | Decimal value as a numeric | 722 | | | text string | 723 | | | | 724 | pkiStatus | PrintableString | Decimal value as a numeric | 725 | | | text string | 726 | | | | 727 | failInfo | PrintableString | Decimal value as a numeric | 728 | | | text string | 729 | | | | 730 | senderNonce | OCTET STRING | Random nonce as a 16-byte | 731 | | | binary data string | 732 | | | | 733 | recipientNonce | OCTET STRING | Random nonce as 16-byte binary | 734 | | | data string | 735 +----------------+-----------------+--------------------------------+ 736 The OIDs used for these attributes are as follows: 738 +-------------------+-----------------------------------------------+ 739 | Name | ASN.1 Definition | 740 +-------------------+-----------------------------------------------+ 741 | id-VeriSign | OBJECT_IDENTIFIER ::= {2 16 US(840) 1 | 742 | | VeriSign(113733)} | 743 | | | 744 | id-pki | OBJECT_IDENTIFIER ::= {id-VeriSign pki(1)} | 745 | | | 746 | id-attributes | OBJECT_IDENTIFIER ::= {id-pki attributes(9)} | 747 | | | 748 | id-transactionID | OBJECT_IDENTIFIER ::= {id-attributes | 749 | | transactionID(7)} | 750 | | | 751 | id-messageType | OBJECT_IDENTIFIER ::= {id-attributes | 752 | | messageType(2)} | 753 | | | 754 | id-pkiStatus | OBJECT_IDENTIFIER ::= {id-attributes | 755 | | pkiStatus(3)} | 756 | | | 757 | id-failInfo | OBJECT_IDENTIFIER ::= {id-attributes | 758 | | failInfo(4)} | 759 | | | 760 | id-senderNonce | OBJECT_IDENTIFIER ::= {id-attributes | 761 | | senderNonce(5)} | 762 | | | 763 | id-recipientNonce | OBJECT_IDENTIFIER ::= {id-attributes | 764 | | recipientNonce(6)} | 765 +-------------------+-----------------------------------------------+ 767 The attributes are detailed in the following sections. 769 3.1.1.1. transactionID 771 A PKI operation is a transaction consisting of the messages exchanged 772 between a requester and the server. The transactionID is a text 773 string generated by the client when starting a transaction. The 774 client MUST generate a unique string as the transaction identifier, 775 which MUST be used for all PKI messages exchanged for a given 776 enrolment, encoded as a PrintableString. 778 One means of generating the transactionID is as a SHA-1, SHA-256, or 779 SHA-512 hash of the public key value in the enrolment request when 780 encoded as an X.509 SubjectPublicKeyInfo [7] (in other words the 781 exact binary form in which it appears in both the request and the 782 resulting certificate) and then coverting it into a text string using 783 base64 encoding or ASCII hex digits. This allows the SCEP client to 784 automatically generate the same transactionID for any given public 785 key. The SCEP protocol requires that transactionIDs be unique, so 786 that subsequent polling queries can be matched with previous 787 transactions. When separate signing and encryption certificates are 788 requested by the client, using distinct keypairs ensures that 789 distinct transactionIDs are also used when the transactionID is 790 created by hashing the X.509 SubjectPublicKeyInfo. 792 [Question: Again with the separate-certificate stuff...]. 794 When using the certificate query and CRL query messages defined in 795 this protocol, the transactionID is required so that the requester 796 can match the response message with the outstanding request message. 797 For a non-enrolment message (for example GetCert and GetCRL), the 798 transactionID SHOULD be some value unique to the client. 800 3.1.1.2. messageType 802 The messageType attribute specifies the type of operation performed 803 by the transaction. This attribute MUST be included in all PKI 804 messages. The following message types are defined: 806 o CertRep ("3") -- Response to certificate or CRL request. 807 o RenewalReq ("17") -- PKCS #10 [6] certificate request for renewal 808 of an existing certificate. 809 o UpdateReq ("18") -- PKCS #10 [6] certificate request for update of 810 a certificate issued by a different CA. 811 o PKCSReq ("19") -- PKCS #10 [6] certificate request. 812 o CertPoll ("20") -- Certificate polling in manual enrolment. 813 o GetCert ("21") -- Retrieve a certificate. 814 o GetCRL ("22") -- Retrieve a CRL. 816 Undefined message types are treated as an error. 818 3.1.1.3. pkiStatus 820 All response messages MUST include transaction status information, 821 which is defined as pkiStatus attribute: 823 o SUCCESS ("0") -- request granted. 824 o FAILURE ("2") -- request rejected. When pkiStatus is FAILURE, the 825 failInfo attribute, as defined in Section 3.1.1.4, MUST also be 826 present. 827 o PENDING ("3") -- request pending for manual approval. 829 Undefined pkiStatus attributes are treated as an error. 831 3.1.1.4. failInfo 833 The failInfo attribute MUST contain one of the following failure 834 reasons: 836 o badAlg ("0") -- Unrecognized or unsupported algorithm identifier. 837 o badMessageCheck ("1") -- integrity check failed. 838 o badRequest ("2") -- transaction not permitted or supported. 839 o badTime ("3") -- The signingTime attribute from the CMS [3] 840 authenticatedAttributes was not sufficiently close to the system 841 time (see Section 3.1.1.6). 842 o badCertId ("4") -- No certificate could be identified matching the 843 provided criteria. 845 [Question: Is there any demand for a free-form UTF8String 846 attribute to explain what really went wrong? Trying to sort 847 out an error when all you ever get back is the near-universal 848 badRequest is almost impossible, adding a failInfoText 849 attribute to address this could be quite useful since it 850 would allow expressing information such as a failure to meet 851 CA policy, or indeed anything more complex than "no go away"]. 853 Undefined failInfo attributes are treated as an error. 855 3.1.1.5. senderNonce and recipientNonce 857 The attributes of senderNonce and recipientNonce are a 16 byte random 858 number generated for each transaction. These are intended to prevent 859 replay attacks. 861 When a sender sends a PKI message to a recipient, a senderNonce MUST 862 be included in the message. The recipient MUST copy the senderNonce 863 into the recipientNonce of the reply as a proof of liveliness. The 864 original sender MUST verify that the recipientNonce of the reply 865 matches the senderNonce it sent in the request. If the nonce does 866 not match, the message MUST be rejected. 868 [Question: What does this do for polling? Polling messages can 869 get lost so nonces will go out of sync, is there a need to 870 chain XXXReqs to polls via nonces? If not, why do we have two 871 nonces?]. 873 3.1.2. SCEP pkcsPKIEnvelope 875 The information portion of a SCEP message is carried inside an 876 Enveloped-Data content type, as defined in CMS [3], with the 877 following restrictions: 879 o contentType in encryptedContentInfo MUST be data ({pkcs-7 1}) as 880 defined in CMS [3]. 881 o encryptedContent MUST be the SCEP message being transported (see 882 Section 4), and must match the messageType authenticated Attribute 883 in the pkiMessage. 885 The CMS [3] content-encryption key is encrypted using the public key 886 of the recipient of the message, i.e. the RA or the CA public key (if 887 sent from the requester), or the requester public key (if sent as a 888 reply to the requester). 890 3.2. SCEP pkiMessage types 892 All of the messages in this section are pkiMessages (Section 3.1), 893 where the type of the message MUST be specified in the 'messageType' 894 authenticated Attribute. Each section defines a valid message type, 895 the corresponding messageData formats, and mandatory authenticated 896 attributes for that type. 898 3.2.1. PKCSReq/RenewalReq/UpdateReq 900 The messageData for this type consists of a PKCS #10 [6] 901 Certification Request. The certification request MUST contain at 902 least the following items: 904 o The subject Distinguished Name. 905 o The subject public key. 906 o For a PKCSReq and if authorisation based on a password is being 907 used, a challengePassword attribute. 909 In addition to the authenticatedAttributes required for a valid CMS 910 [3] message, the pkiMessage MUST include the following attributes: 912 o A transactionID (Section 3.1.1.1) attribute. 913 o A messageType (Section 3.1.1.2) attribute set to PKCSReq, 914 RenewalReq, or UpdateReq as appropriate. 915 o A senderNonce (Section 3.1.1.5) attribute. 917 The pkcsPKIEnvelope for this message type is protected using the 918 public key of the recipient as detailed in Section 3.1.2, e.g. either 919 the CA or RA public key. 921 3.2.2. CertRep 923 The messageData for this type consists of a degenerate certificates- 924 only CMS [3] Signed-Data message (Section 3.3). The exact content 925 required for the reply depends on the type of request this message is 926 a reply to. They are detailed in Section 3.2.2.1 and in Section 4. 928 In addition to the authenticatedAttributes required for a valid CMS 929 [3], this pkiMessage MUST include the following attributes: 931 o The transactionID (Section 3.1.1.1) attribute copied from the 932 request we are responding to. 933 o A messageType (Section 3.1.1.2) attribute set to CertRep. 934 o A senderNonce (Section 3.1.1.5) attribute. 935 o A recipientNonce attribute (Section 3.1.1.5) copied from the 936 senderNonce from the request that this is a response to. 937 o A pkiStatus (Section 3.1.1.3) set to the status of the reply. 939 The pkcsPKIEnvelope for this message type is protected using the 940 public key of the recipient as detailed in Section 3.1.2. For 941 example if a self-signed certificate was used to send the original 942 request then this self-signed certificate's public key is used to 943 encrypt the content-encryption key of the SUCCESS response's 944 pkcsPKIEnvelope. 946 Note that although it may appear that the senderNonce serves no 947 purpose in this message, it is required if the CertRep contains a 948 PENDING status since the nonce will be used in subsequent polling 949 operations. 951 3.2.2.1. CertRep SUCCESS 953 When the pkiStatus attribute is set to SUCCESS, the messageData for 954 this message consists of a degenerate certificates-only CMS [3] 955 Signed-Data message (Section 3.3). The content of this degenerate 956 certificates-only Signed-Data depends on what the original request 957 was, as outlined below. 959 +--------------+----------------------------------------------------+ 960 | Request-type | Reply-contents | 961 +--------------+----------------------------------------------------+ 962 | PKCSReq | The reply MUST contain at least the issued | 963 | | certificate in the certificates field of the | 964 | | Signed-Data. The reply MAY contain additional | 965 | | certificates, but the issued certificate MUST be | 966 | | the leaf certificate. The reply MUST NOT contain | 967 | | a CRL. | 968 | | | 969 | RenewalReq | Same as PKCSReq | 970 | | | 971 | UpdateReq | Same as PKCSReq | 972 | | | 973 | CertPoll | Same as PKCSReq | 974 | | | 975 | GetCert | The reply MUST contain at least the requested | 976 | | certificate in the certificates field of the | 977 | | Signed-Data. The reply MAY contain additional | 978 | | certificates, but the requested certificate MUST | 979 | | be the leaf certificate. The reply MUST NOT | 980 | | contain a CRL. | 981 | | | 982 | GetCRL | The reply MUST contain the CRL in the crls field | 983 | | of the Signed-Data. The reply MUST NOT contain a | 984 | | certificate. | 985 +--------------+----------------------------------------------------+ 987 3.2.2.2. CertRep FAILURE 989 When the pkiStatus attribute is set to FAILURE, the reply MUST also 990 contain a failInfo (Section 3.1.1.4) attribute set to the appropriate 991 error condition describing the failure. The pkcsPKIEnvelope 992 (Section 3.1.2) MUST be omitted. 994 3.2.2.3. CertRep PENDING 996 When the pkiStatus attribute is set to PENDING, the pkcsPKIEnvelope 997 (Section 3.1.2) MUST be omitted. 999 3.2.3. CertPoll (GetCertInitial) 1001 This message is used for certificate polling. For unknown reasons it 1002 was referred to as "GetCertInitial" in earlier drafts. The 1003 messageData for this type consists of an IssuerAndSubject: 1005 issuerAndSubject ::= SEQUENCE { 1006 issuer Name, 1007 subject Name 1008 } 1010 The issuer is set to the subjectName of the CA (in other words the 1011 intended issuerName of the certificate that's being requested). The 1012 Subject is set to the subjectName used when requesting the 1013 certificate. 1015 In addition to the authenticatedAttributes required for a valid CMS 1016 [3], this pkiMessage MUST include the following attributes: 1018 o The same transactionID (Section 3.1.1.1) attribute from the 1019 original PKCSReq/RenewalReq/UpdateReq message. 1020 o A messageType (Section 3.1.1.2) attribute set to CertPoll. 1021 o A senderNonce (Section 3.1.1.5) attribute. 1022 o A recipientNonce attribute (Section 3.1.1.5) copied from the 1023 senderNonce from the request that this is a response to. 1025 3.2.4. GetCert 1027 The messageData for this type consists of an IssuerAndSerialNumber as 1028 defined in CMS [3] which uniquely identifies the certificate being 1029 requested. 1031 In addition to the authenticatedAttributes required for a valid CMS 1032 [3], this pkiMessage MUST include the following attributes: 1034 o A transactionID (Section 3.1.1.1) attribute. 1035 o A messageType (Section 3.1.1.2) attribute set to GetCert. 1036 o A senderNonce (Section 3.1.1.5) attribute. 1038 A self-signed certificate MAY be used in the signed envelope. This 1039 enables the requester to request their own certificate if they were 1040 unable to store it previously. 1042 3.2.5. GetCRL 1044 The messageData for this type consists of a IssuerAndSerialNumber as 1045 defined in CMS [3] containing the issuer name and serial number of 1046 the certificate whose revocation status is being checked. 1048 In addition to the authenticatedAttributes required for a valid CMS 1049 [3], this pkiMessage MUST include the following attributes: 1051 o A transactionID (Section 3.1.1.1) attribute. 1053 o A messageType (Section 3.1.1.2) attribute set to GetCRL. 1054 o A senderNonce (Section 3.1.1.5) attribute. 1056 3.3. Degenerate certificates-only CMS Signed-Data 1058 CMS [3] includes a degenerate case of the CMS [3] Signed-Data content 1059 type, in which there are no signers. The use of such a degenerate 1060 case is to disseminate certificates and CRLs. For SCEP the content 1061 field of the ContentInfo value of a degenerate certificates-only 1062 Signed-Data MUST be omitted. 1064 When carrying certificates, the certificates are included in the 1065 'certificates' field of the Signed-Data. When carrying a CRL, the 1066 CRL will be included in the 'crls' field of the Signed-Data. 1068 3.4. CA Capabilities 1070 In order to provide support for future enhancements to the protocol, 1071 CAs SHOULD implement the GetCACaps message to allow clients to query 1072 which functionality is available from the CA. 1074 3.4.1. GetCACaps HTTP Message Format 1076 This message requests capabilities from a CA, with the format: 1078 "GET" CGI-PATH CGI-PROG "?operation=GetCACaps" \ 1079 [ "&message=" CA-IDENT ] 1081 with the message components as described in Section 5 (note that the 1082 message component is optional and is only required if multiple CAs 1083 are being operated through the same server). The response is a list 1084 of text capabilities, as defined in Section 3.4.2. CA servers SHOULD 1085 support the GetCACaps message and MUST support it when they implement 1086 any extended functonality beyond the mandatory-to-implement basics 1087 Section 2.8. 1089 3.4.2. CA Capabilities Response Format 1090 The response for a GetCACaps message is a list of CA capabilities, in 1091 plain text, separated by characters, as follows (quotation marks 1092 are NOT sent): 1094 +--------------------+----------------------------------------------+ 1095 | Keyword | Description | 1096 +--------------------+----------------------------------------------+ 1097 | "AES" | CA Supports the AES encryption algorithm. | 1098 | | | 1099 | "DES3" | CA Supports the triple DES encryption | 1100 | | algorithm. | 1101 | | | 1102 | "GetNextCACert" | CA Supports the GetNextCACert message. | 1103 | | | 1104 | "POSTPKIOperation" | PKIOPeration messages may be sent via HTTP | 1105 | | POST. | 1106 | | | 1107 | "Renewal" | CA Supports the Renewal CA operation. | 1108 | | | 1109 | "SHA-1" | CA Supports the SHA-1 hashing algorithm. | 1110 | | | 1111 | "SHA-256" | CA Supports the SHA-256 hashing algorithm. | 1112 | | | 1113 | "SHA-512" | CA Supports the SHA-512 hashing algorithm. | 1114 | | | 1115 | "Update" | CA Supports the Update CA operation. | 1116 +--------------------+----------------------------------------------+ 1118 The client SHOULD use SHA-256 or SHA-512 in preference to SHA-1 1119 hashing, and AES in preference to triple DES if they are supported by 1120 the CA. 1122 Announcing some of these capabilities is redundant since they're 1123 required as mandatory-to-implement functionality (see Section 2.8), 1124 but it may be useful to announce them in order to deal with old 1125 implementations that would otherwise default to obsolete, insecure 1126 algorithms and mechanisms. 1128 The server MUST use the texual case specified here, but clients 1129 SHOULD ignore the textual case when processing this message. A 1130 client MUST be able to accept and ignore any unknown keywords that 1131 might be sent back by a CA. 1133 If the CA supports none of the above capabilities the SCEP server 1134 SHOULD return an empty message. A server MAY simply return an HTTP 1135 error. A client that receives an empty message or an HTTP error 1136 SHOULD interpret the response as if none of the requested 1137 capabilities are supported by the CA. 1139 (Note that at least one widely-deployed server implementation 1140 supports several of the above operations but doesn't support the 1141 GetCACaps message to indicate that it supports them. This means that 1142 the equivalent of GetCACaps must be performed through server 1143 fingerprinting, which can be done using the ID string "Microsoft- 1144 IIS"). 1146 The Content-type of the reply SHOULD be "text/plain". Clients SHOULD 1147 ignore the Content-type, as older server implementations of SCEP may 1148 send various Content-types. 1150 Example: 1152 GET /cgi-bin/pkiclient.exe?operation=GetCACaps&message=myca 1154 might return: 1156 AES 1157 SHA-256 1158 GetNextCACert 1159 POSTPKIOperation 1161 This means that the CA supports modern crypto algorithms, the 1162 GetNextCACert message, and allows PKIOperation messages 1163 (PKCSReq/RenewalReq/UpdateReq, GetCert, CertPoll, ...) to be sent 1164 using HTTP POST. 1166 4. SCEP Transactions 1168 This section describes the SCEP Transactions, without explaining the 1169 transport. The transport of each message is discussed in Section 5. 1170 Some of the transaction-requests have no data to send, i.e. the only 1171 data is the message-type itself (e.g. a GetCACert message has no 1172 additional data). 1174 In this section, each SCEP transaction is specified in terms of the 1175 complete messages exchanged during the transaction. 1177 4.1. Get CA Certificate 1179 To get the CA certificate(s), the requester sends a GetCACert message 1180 to the server. There is no request data associated with this message 1181 (see Section 5.2.1). 1183 4.1.1. Get CA Certificate Response Message Format 1185 The response depends on whether the responding server has RA 1186 certificates or only a single CA certificate. The server MUST 1187 indicate which response it is sending via the transport protocol used 1188 (see Section 5.2.1). 1190 All returned certificates MUST conform to PKIX [7]. 1192 If the requester does not have a certificate path to a trust anchor 1193 certificate, the SHA-1, SHA-256, or SHA-512 fingerprint of the 1194 returned CA certificate (communicated via out-of-band means) may be 1195 used to verify it. 1197 4.1.1.1. CA Certificate Response Message Format 1199 If the server does not have any RA Certificates, the response 1200 consists of a single X.509 CA certificate. 1202 4.1.1.2. CA/RA Certificate Response Message Format 1204 If the server has RA Certificates, the response consists of a 1205 degenerate certificates-only CMS [3] Signed-Data (Section 3.3) 1206 containing the CA and RA certificates, with the RA certificate(s) as 1207 the leaf certificate(s). 1209 4.2. Certificate Enrolment/Renewal/Update 1211 A PKCSReq/RenewalReq/UpdateReq (Section 3.2.1) message is used to 1212 perform a certificate enrolment, renewal, or update transaction. 1214 The reply MUST be a CertRep (Section 3.2.2) message sent back from 1215 the server, indicating SUCCESS, FAILURE, or PENDING. 1217 Precondition: Both the requester and the certification authority have 1218 completed their initialization process. The requester has already 1219 been configured with the CA/RA certificate. 1221 Postcondition: The requester receives the certificate, the request is 1222 rejected, or the request is pending. A pending response might 1223 indicate that manual authentication is necessary. 1225 4.2.1. Certificate Enrolment/Renewal/Update Response Message 1227 If the request is granted, a CertRep (Section 3.2.2) message with 1228 pkiStatus set to SUCCESS is returned. The reply MUST also contain 1229 the certificate (and MAY contain any other certificates needed by the 1230 requester). The issued certificate MUST be the first in the list. 1232 If the request is rejected, a CertRep (Section 3.2.2) message with 1233 pkiStatus set to FAILURE is returned. The reply MUST also contain a 1234 failInfo attribute. 1236 If the the CA is configured to manually authenticate the requester, a 1237 CertRep (Section 3.2.2) message with pkiStatus set to PENDING MAY be 1238 returned. The CA MAY return a PENDING for other reasons. 1240 4.3. Poll for Requester Initial Certificate 1242 Triggered by a CertRep (Section 3.2.2) with pkiStatus set to PENDING, 1243 a requester will enter the polling state by periodically sending 1244 CertPoll messages (Section 3.2.3) to the server, until either the 1245 request is granted and the certificate is sent back, or the request 1246 is rejected, or some preconfigured time limit for polling or maximum 1247 number of polls is exceeded. 1249 CertPoll messages exchanged during the polling period MUST carry the 1250 same transactionID attribute as the previous PKCSReq/RenewalReq/ 1251 UpdateReq. A server receiving a CertPoll for which it does not have 1252 a matching PKCSReq/RenewalReq/UpdateReq MUST ignore this request. 1254 Since at this time the certificate has not been issued, the requester 1255 can only use its own subject name (which was contained in the 1256 original PKCS# 10 sent via PKCSReq/RenewalReq/UpdateReq) to identify 1257 the polled certificate request. In theory there can be multiple 1258 outstanding requests from one requester (for example, if different 1259 keys and different key-usages were used to request multiple 1260 certificates), so the transactionID must also be included to 1261 disambiguate between multiple requests. In practice however it's 1262 safer for the requester to not have multiple requests outstanding at 1263 any one time, since this tends to confuse some servers. 1265 PreCondition: The requester has received a CertRep with pkiStatus set 1266 to PENDING. 1268 PostCondition: The requester has either received a valid response, 1269 which could be either a valid certificate (pkiStatus = SUCCESS), or a 1270 FAILURE message, or the polling period times out. 1272 4.3.1. Polling Response Message Format 1274 The response messages for CertPoll are the same as in Section 4.2.1. 1276 4.4. Certificate Access 1278 A requester can query an issued certificate from the SCEP server, as 1279 long as the requester knows the issuer name and the issuer assigned 1280 certificate serial number. 1282 This transaction consists of one GetCert (Section 3.2.4) message sent 1283 to the server by a requester, and one CertRep (Section 3.2.2) message 1284 sent back from the server. 1286 PreCondition: The certification authority has issued the queried 1287 certificate and the issuer assigned serial number is known. 1289 PostCondition: Either the certificate is sent back or the request is 1290 rejected. 1292 4.4.1. Certificate Access Response Message Format 1294 In this case, the CertRep from the server is same as in 1295 Section Section 4.2.1, except that the server will only either grant 1296 the request (SUCCESS) or reject the request (FAILURE). 1298 4.5. CRL Access 1300 Clients can request a CRL from the SCEP server as described in 1301 Section 2.6. 1303 PreCondition: The certification authority certificate has been 1304 downloaded to the end entity. 1306 PostCondition: CRL sent back to the requester. 1308 4.5.1. CRL Access Response Message Format 1310 The CRL is sent back to the requester in a CertRep (Section 3.2.2) 1311 message. The information portion of this message is a degenerate 1312 certificates-only Signed-Data (Section 3.3) that contains only the 1313 most recent CRL in the crls field of the Signed-Data. 1315 4.6. Get Next Certification Authority Certificate 1317 When the CA certificate expires all certificates that have been 1318 signed by it are no longer valid. CA key rollover provides a 1319 mechanism by which the server MAY distribute a new CA certificate 1320 which is valid in the future; when the current certificate has 1321 expired. When a CA certificate is about to expire, clients need to 1322 retrieve the CA's next CA certificate (i.e. the rollover 1323 certificate). This is done via the GetNextCACert message. There is 1324 no request data associated with this message (see Section 5.2.6). 1326 Clients MUST store the not-yet-valid CA certificate, and any not-yet- 1327 valid client certificates obtained, until such time that they are 1328 valid, at which point clients switch over to using the newly valid 1329 certificates. 1331 4.6.1. Get Next CA Response Message Format 1333 The response consists of a Signed-Data CMS [3], signed by the current 1334 CA (or RA) signing key. Clients MUST validate the signature on the 1335 the Signed-Data CMS [3] before accepting any of its contents. 1337 The content of the Signed-Data CMS [3] message is a degenerate 1338 certificates-only Signed-Data (Section 3.3) message containing the 1339 new CA certificate and any new RA certificates, as defined in 1340 Section 5.2.1.1.2, to be used when the current CA certificate 1341 expires. 1343 If the CA (or RA) does not have the rollover certificate(s) it MUST 1344 reject the request. It SHOULD also remove the GetNextCACert setting 1345 from the capabilities until it does have rollover certificates. 1347 If there are any RA certificates in this response, clients MUST check 1348 that these RA certificates are signed by the CA, and MUST check 1349 authorization of these RA certificates (see Section 2.1.3). 1351 5. SCEP Transport 1353 HTTP [4] is used as the transport protocol for SCEP Message Objects. 1355 5.1. HTTP GET and POST Message Formats 1357 SCEP uses the HTTP "GET" and "POST" messages to exchange information 1358 with the CA. The following defines the syntax of a HTTP GET and POST 1359 messages sent from a requester to a certification authority server: 1361 "GET" CGI-PATH CGI-PROG "?operation=" OPERATION "&message=" MESSAGE 1362 "POST" CGI-PATH CGI-PROG "?operation=" OPERATION "&message=" MESSAGE 1364 where: 1366 o CGI-PATH defines the actual CGI path to invoke the CGI program 1367 that parses the request. 1369 o CGI-PROG is set to be the string "pkiclient.exe". This is 1370 intended to be the program that the CA will use to handle the SCEP 1371 transactions, though the CA may ignore CGI-PROG and use only the 1372 CGI-PATH, or ignore both if it's not issuing certificates via a 1373 web server. Typically, setting CGI-PATH/CGI-PROG to "/cgi-bin/ 1374 pkiclient.exe" will satisfy most servers. 1375 o OPERATION depends on the SCEP transaction and is defined in the 1376 following sections. 1377 o MESSAGE depends on the SCEP transaction and is defined in the 1378 following sections. 1380 Early SCEP drafts performed all communications via "GET" messages, 1381 including non-idempotent ones that should have been sent via "POST" 1382 messages. This has caused problems because of the way that the 1383 (supposedly) idempotent GET interacts with caches and proxies, and 1384 because the extremely large GET requests created by encoding CMS 1385 messages may be truncated in transit. These issues are typically not 1386 visible when testing on a LAN, but crop up during deployment over 1387 WANs. If the remote CA supports it, any of the CMS [3]-encoded SCEP 1388 messages SHOULD be sent via HTTP POST instead of HTTP GET. This is 1389 allowed for any SCEP message except GetCACert, GetNextCACert, or 1390 GetCACaps, and avoids the need for base64- and URL-encoding that's 1391 required for GET messaging. The client can verify that the CA 1392 supports SCEP messages via POST by looking for the "POSTPKIOperation" 1393 capability (See Section 3.4.2). 1395 When using GET messages to communicate binary data, base64 encoding 1396 as specified in [2] MUST be used. The base64 encoded data is 1397 distinct from "base64url" and may contain URI reserved characters, 1398 thus it MUST be escaped as specified in [8] in addition to being 1399 bas64 encoded. 1401 5.1.1. Response Message Format 1403 For each GET or POST operation, the CA/RA server MUST return a 1404 Content-Type and appropriate response data, if any. 1406 5.2. SCEP HTTP Messages 1408 This section describes the OPERATION and MESSAGE values for SCEP 1409 exchanges. 1411 5.2.1. GetCACert 1413 The OPERATION MUST be set to "GetCACert". 1415 The MESSAGE MAY be omitted, or it MAY be a string that represents the 1416 certification authority issuer identifier, allowing for multiple CAs 1417 supported by one SCEP server. 1419 5.2.1.1. GetCACert Response 1421 The response for GetCACert is different between the case where the CA 1422 directly communicates with the requester during the enrolment, and 1423 the case where a RA exists and the requester communicates with the RA 1424 during the enrolment. 1426 5.2.1.1.1. CA Certificate Only Response 1428 The response will have a Content-Type of "application/x-x509-ca- 1429 cert". 1431 The body of this response consists of an X.509 CA certificate, as 1432 defined in Section 4.1.1.1: 1434 "Content-Type:application/x-x509-ca-cert" 1436 1438 5.2.1.1.2. CA and RA Certificates Response 1440 The response will have a Content-Type of "application/x-x509-ca-ra- 1441 cert". 1443 The body of this response consists of a degenerate certificates-only 1444 CMS [3] Signed-Data (Section 3.3) message containing both CA and RA 1445 certificates, as defined in Section 4.1.1.2: 1447 "Content-Type:application/x-x509-ca-ra-cert" 1449 1451 5.2.2. PKCSReq/RenewalReq/UpdateReq 1453 The OPERATION MUST be set to "PKIOperation". 1455 The MESSAGE consists of a PKCSReq, RenewalReq, or UpdateReq SCEP 1456 message. When implemented using HTTP POST this might look as 1457 follows: 1459 POST /cgi-bin/pkiclient.exe?operation=PKIOperation HTTP/1.1 1460 Content-Length: 1462 1464 When implemented using HTTP GET this might look as follows: 1466 GET /cgi-bin/pkiclient.exe?operation=PKIOperation& \ 1467 message=MIAGCSqGSIb3DQEHA6CAMIACAQAxgDCBzAIBADB2MG \ 1468 IxETAPBgNVBAcTCE......AAAAAA== HTTP/1.1 1470 5.2.2.1. PKCSReq/RenewalReq/UpdateReq Response 1472 The response will have a Content-Type of "application/x-pki-message". 1474 The body of this response consists of a CertRep SCEP message defined 1475 in Section 4.2.1. The following is an example of the response: 1477 "Content-Type:application/x-pki-message" 1479 1481 5.2.3. CertPoll 1483 The OPERATION MUST be set to "PKIOperation". The MESSAGE consists of 1484 a CertPoll SCEP message. 1486 5.2.3.1. CertPoll Response 1488 The body of this response consists of a CertRep SCEP message defined 1489 in Section 4.3.1. 1491 5.2.4. GetCert 1493 The OPERATION MUST be set to "PKIOperation". The MESSAGE consists of 1494 a GetCert SCEP message. 1496 5.2.4.1. GetCert Response 1498 The body of this response consists of a CertRep SCEP message defined 1499 in Section 4.4.1. 1501 5.2.5. GetCRL 1503 The OPERATION MUST be set to "PKIOperation". The MESSAGE consists of 1504 a GetCRL SCEP message. 1506 5.2.5.1. GetCRL Response 1508 The body of this response consists of a CertRep SCEP message defined 1509 in Section 4.5.1. 1511 5.2.6. GetNextCACert 1513 The OPERATION MUST be set to "GetNextCACert". 1515 The MESSAGE MAY be ommitted, or it MAY be a string that represents 1516 the certification authority issuer identifier, if such has been set 1517 by the CA Administrator. 1519 5.2.6.1. GetNextCACert Response 1521 The response will have a Content-Type of "application/x-x509-next-ca- 1522 cert". 1524 The body of this response consists of a Signed-Data CMS [3], as 1525 defined in Section 4.6.1. (This is similar to the GetCert response 1526 but does not include any of the attributes defined in Section 3.1.1). 1528 "Content-Type:application/x-x509-next-ca-cert" 1530 1532 6. Contributors/Acknowledgements 1534 The editor would like to thank all the previous editors, authors and 1535 contributors: Cheryl Madson, Xiaoyi Liu, David McGrew, David Cooper, 1536 Andy Nourse, Max Pritikin, Jan Vilhuber, etc for their work 1537 maintaining the draft over the years. Numerous other people have 1538 contributed during the long life cycle of the draft and all deserve 1539 thanks. 1541 The earlier authors would like to thank Peter William of ValiCert, 1542 Inc. (formerly of VeriSign, Inc.) and Alex Deacon of VeriSign, Inc. 1543 and Christopher Welles of IRE, Inc. for their contributions to early 1544 versions of this protocol and this document. 1546 7. IANA Considerations 1548 This memo includes no request to IANA. 1550 8. Security Considerations 1552 The security goals of SCEP are that no adversary can: 1554 o Subvert the public key/identity binding from that intended. 1555 o Discover the identity information in the enrolment requests and 1556 issued certificates. 1557 o Cause the revocation of certificates with any non-negligible 1558 probability. 1560 Here an adversary is any entity other than the requester and the CA 1561 (and optionally the RA) participating in the protocol. The adversary 1562 is computationally limited, but that can manipulate data during 1563 transmission (that is, can act as a MITM). The precise meaning of 1564 'computationally limited' depends on the implementer's choice of one- 1565 way hash functions and cryptographic algorithms. 1567 The first and second goals are met through the use of CMS [3] and 1568 PKCS #10 [6] encryption and digital signatures using authenticated 1569 public keys. The CA's public key is authenticated via out-of-band 1570 means such as the checking of the CA fingerprint, as specified in 1571 Section 2.1.2, and the SCEP client's public key is authenticated 1572 through manual or pre-shared secret authentication, as specified in 1573 Section 2.2. The third goal is met through the use of a 1574 challengePassword for revocation, which is chosen by the SCEP client 1575 and communicated to the CA protected by the CMS [3] Enveloped-Data, 1576 as specified in Section 2.7. 1578 [Question: Uhh, the protocol doesn't support revocation 1579 requests, should this be removed to match what it actually 1580 does or should be spec be updated to match the description 1581 here?]. 1583 The motivation of the first security goal is straightforward. The 1584 motivation for the second security goal is to protect the identity 1585 information in the enrolment requests and issued certificates. 1586 Subsequent protocols can use the certificate in ways that either 1587 expose the identity information, or protect it, depending on the 1588 security requirements of those protocols. The motivation for the 1589 third security goal is to protect the SCEP clients from denial of 1590 service attacks. 1592 8.1. General Security 1594 Common key-management considerations such as keeping private keys 1595 truly private and using adequate lengths for symmetric and asymmetric 1596 keys must be followed in order to maintain the security of this 1597 protocol. This is especially true for CA keys, which, when 1598 compromised, compromise the security of all relying parties. 1600 8.2. Use of the CA keypair 1602 A CA key pair is generally meant for (and is usually flagged as) 1603 certificate (and CRL) signing exclusively, rather than data signing 1604 or encryption. The SCEP protocol, however, uses the CA private key 1605 to both encrypt and sign CMS [3] transport messages. This is 1606 generally considered undesirable, as it widens the possibility of an 1607 implementation weakness, and provides: 1609 o Another place that the private key must be used (and hence is 1610 slightly more vulnerable to exposure). 1611 o Another place where a side channel attack (say, timing or power 1612 analysis) might be used. 1613 o Another place that the attacker might somehow insert their own 1614 data and get it signed by the CA's private key (note that this 1615 issue is purely theoretical, since the CMS data signed by the CA 1616 is nothing remotely like a certificate and couldn't be passed off 1617 as such). 1619 One solution to this problem is to use RA keys to secure the SCEP 1620 transport (i.e. message signing and encrypting), which allows the CA 1621 keys to be used only for their intended purpose of certificate 1622 signing. An RA can be implemented in two ways, physically separate 1623 or implicit. In the implicit case, the CA simply creates an extra 1624 key pair. A physically separate RA allows the CA to be inside the 1625 secure network, not accessible to hackers at all. 1627 The corresponding downside of using an RA is that it makes the client 1628 side considerably more complex, as the key used by the CA to issue 1629 certificates is no longer the same one used by the client to 1630 communicate with the CA. This requires that the client keep track of 1631 multiple keys rather than a single CA key. 1633 8.3. Challenge Password 1635 The challengePassword sent in the PKCS #10 enrolment request is 1636 signed and encrypted by way of being encapsulated in a pkiMessage. 1637 When saved by the CA, care should be taken to protect this password. 1639 If the challengePassword is used to automatically authenticate an 1640 enrolment request, it is recommended that some form of one-time 1641 password be used to minimize damage in the event the data is 1642 compromised. 1644 8.4. Transaction ID 1646 CAs/RAs SHOULD NOT rely on the transactionID to be correct or as 1647 specified in this document. Requesters with buggy software might add 1648 additional undetected duplicate requests to the CA's queue. A well- 1649 written CA/RA should never assume the data from a requester is well- 1650 formed. 1652 8.5. Nonces and Replay 1654 In order to detect replay attacks, both sides need to maintain state 1655 information sufficient to detect an unexpected nonce value. 1657 8.6. GetCACaps Issues 1659 The GetCACaps response is not signed. This allows an attacker to 1660 perform downgrade attacks on the cryptographic capabilities of the 1661 client/CA exchange. 1663 8.7. Unnecessary cryptography 1665 Some of the SCEP exchanges use signing and encryption operations that 1666 are not necessary. In particular the GetCert and GetCRL exchanges 1667 are encrypted and signed in both directions. The information 1668 requested is public and thus signing the requests is of questionable 1669 value but also CRLs and Certificates, i.e. the respective responses, 1670 are already signed by the CA and can be verified by the recipient 1671 without requiring additional signing and encryption. 1673 This may affect performance and scalability of the CA and could be 1674 used as an attack vector on the CA (though not an anonymous one). 1675 The use of CRLDPs as well as other ways of retrieving certificates 1676 such as HTTP access and LDAP are recommended for CRL access. 1678 8.8. GetNextCACert 1680 GetNextCACert depends on a 'flag moment' at which every client in the 1681 PKI infrastructure switches from the current CA certificate (and 1682 client certificate) to the new CA certificate and client 1683 certificates. Proper monitoring of the network infrastructure can 1684 ensure that this will proceed as expected but any errors in 1685 processing or implementation can result in a failure of the PKI 1686 infrastructure. 1688 9. References 1690 9.1. Normative References 1692 [1] Bradner, S., "Key words for use in RFCs to Indicate 1693 Requirement Levels", BCP 14, RFC 2119, March 1997. 1695 [2] Josefsson, S., "The Base16, Base32, and Base64 Data 1696 Encodings", RFC 4648, October 2006. 1698 [3] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 1699 5652, September 2009. 1701 [4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1702 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1703 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1705 [5] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 1706 Classes and Attribute Types Version 2.0", RFC 2985, 1707 November 2000. 1709 [6] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1710 Request Syntax Specification Version 1.7", RFC 2986, 1711 November 2000. 1713 [7] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1714 Housley, R., and W. Polk, "PKCS #10: Certification Request 1715 Syntax Specification Version 1.7", RFC 5280, May 2008. 1717 [8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1718 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1719 August 1998. 1721 9.2. Informative References 1723 [9] Schaad, J. and M. Myers, "Certificate Management over CMS 1724 (CMC)", RFC 5272, June 2008. 1726 [10] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1727 "Internet X.509 Public Key Infrastructure Certificate 1728 Management Protocol (CMP)", RFC 4210, September 2005. 1730 [11] Gutmann, P., "Internet X.509 Public Key Infrastructure 1731 Operational Protocols: Certificate Store Access via HTTP", 1732 RFC 4387, February 2006. 1734 [12] Kaufman, C., "The Internet Key Exchange (IKEv2)", RFC 1735 4306, December 2005. 1737 [13] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1738 Mail Extensions (S/MIME) Version 3.2 Message 1739 Specification", RFC 5751, January 2010. 1741 [14] Dierks, T. and E. Rescorla, "The Transport Layer Security 1742 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1744 Appendix A. SCEP State Transitions 1746 SCEP state transitions are indexed by the transactionID attribute. 1747 The design goal is to ensure the synchronization between the CA and 1748 the requester under various error situations. 1750 Each enrolment transaction is uniquely associated with a 1751 transactionID (carried in the transactionID signed attribute (see 1752 Section 3.1.1.1). Because the enrolment transaction could be 1753 interrupted by various errors, including network connection errors or 1754 client reboot, the SCEP client generates a fixed transaction 1755 identifier as specified in Section 3.1.1.1 which is included in the 1756 PKCSReq/RenewalReq/UpdateReq. If the CA returns a response of 1757 PENDING, the requester will poll by periodically sending a CertPoll 1758 with the same transaction identifier until either a response other 1759 than PENDING is obtained or the configured maximum time has elapsed. 1760 This mechanism retains the same transaction identifier throughout the 1761 enrolment transaction. 1763 If the client times out or reboots, the client administrator will 1764 start another transaction with the same key pair. The second 1765 enrolment will have the same transactionID. At the server side, 1766 instead of accepting the PKCSReq/RenewalReq/UpdateReq as a new 1767 request, it can respond as if another CertPoll message had been sent 1768 with that transaction ID. The second PKCSReq/RenewalReq/UpdateReq 1769 should be taken as a resynchronization message to allow the process 1770 to resume as the same transaction. 1772 The following gives several examples of client to CA transactions. 1774 Client actions are indicated in the left column, CA actions are 1775 indicated in the right column. A blank action signifies that no 1776 message was received. 1778 The first transaction, for example, would read like this: 1780 "Client Sends PKCSReq message with transactionID 1 to the CA. The CA 1781 signs the certificate and constructs a CertRep Message containing the 1782 signed certificate with a transaction ID 1. The client receives the 1783 message and installs the certificate locally." 1784 Successful Enrolment Case: no manual authentication 1786 PKCSReq (1) ----------> CA Signs Cert 1787 Client Installs Cert <---------- CertRep (1) SIGNED CERT 1789 Successful Enrolment Case: manual authentication required 1791 PKCSReq (10) ----------> Cert Request goes into Queue 1792 Client Polls <---------- CertRep (10) PENDING 1793 CertPoll (10) ----------> Still pending 1794 Client Polls <---------- CertRep (10) PENDING 1795 CertPoll (10) ----------> Still pending 1796 Client Polls <---------- CertRep (10) PENDING 1797 CertPoll (10) ----------> Still pending 1798 Client Polls <---------- CertRep (10) PENDING 1799 CertPoll (10) ----------> Cert has been signed 1800 <---------- CertRep (10) SIGNED CERT 1801 Client Installs Cert 1803 Resync Case 1 - CA Receives PKCSReq, sends PENDING, eventually grants 1804 the certificate and returns SUCCESS, with the certificate. The 1805 SUCCESS gets lost: 1807 PKCSReq (3) ----------> Cert Request goes into queue 1808 <---------- CertRep (3) PENDING 1809 CertPoll (3) ----------> Still pending 1810 <---------- CertRep (3) PENDING 1811 CertPoll (3) ----------> Cert has been signed 1812 X-------- CertRep(3) SIGNED CERT 1813 (Time Out) 1814 PKCSReq (3) ----------> Cert already granted 1815 <---------- CertRep (3) SIGNED CERT 1816 Client Installs Cert 1817 Resync Case 2 - CA Receives PKCSReq, sends PENDING, PENDING reply 1818 gets lost: 1820 PKCSReq (3) ----------> Cert Request goes into queue 1821 X-------- CertRep (3) PENDING 1822 (Time Out) 1823 PKCSReq (3) ----------> 1824 <---------- CertRep (3) PENDING 1825 etc... 1827 Case when the Certificate is lost, the CA arbitrarily refuses to sign 1828 a replacement (enforcing name-uniqueness) until the original 1829 certificate has been revoked (there is no change of name 1830 information): 1832 PKCSReq (4) ----------> CA Signs Cert 1833 <---------- CertRep (4) SIGNED CERT 1834 Client Installs Cert 1835 (Client looses Cert) 1836 PKCSReq (5) ----------> There is already a valid cert with 1837 this DN. 1838 <---------- CertRep (5) BAD REQUEST 1839 Admin Revokes 1840 PKCSReq (5) ----------> CA Signs Cert 1841 <---------- CertRep (5) SIGNED CERT 1842 Client Installs Cert 1844 CA certificate rollover case: 1846 GetNextCACert ----------> 1847 <---------- New CA certificate 1849 PKCSReq* ----------> CA Signs certificate with NEW 1850 key 1851 Client Stores Cert <---------- CertRep - Certificate issued 1852 for installation when from NEW CA certificate and key 1853 existing cert expires. pair 1855 *enveloped for new CA or RA cert and key pair. The CA will use the 1856 envelope to determine which key and certificate to use to issue the 1857 client certificate. 1859 Appendix B. Background Notes 1861 This specification has spent more than fifteen years in the draft 1862 stage. Its original goal, provisioning IPsec routers with RSA 1863 certificates, has long since changed to general device/embedded 1864 system/IoT use. To fit this role, extra features were bolted on in a 1865 haphazard manner through the addition of a growing list of appendices 1866 and by inserting additional, often conflicting, paragraphs in various 1867 locations in the body text. Since existing features were never 1868 updated as newer ones were added, the specification accumulated large 1869 amounts of historical baggage over time. If OpenPGP was described as 1870 "a museum of 1990s crypto" then the SCEP draft was its graveyard. 1872 About five years ago the specification, which even at that point had 1873 seen only sporadic re-posts of the existing document, was more or 1874 less abandoned by its original sponsors. Due to its widespread use 1875 in large segments of the industry, the specification was rebooted in 1876 2015, cleaning up fifteen years of accumulated cruft, fixing errors, 1877 clarifying ambiguities, and bringing the algorithms and standards 1878 used into the current century (prior to the update, the de-facto 1879 lowest-common denominator algorithms used for interoperability were 1880 the forty-year-old single DES and broken MD5 hash algorithms). 1882 Other changes include: 1884 o Resolved contradictions in the text, for example a requirement 1885 given as a MUST in one paragraph and a SHOULD in the next, a MUST 1886 NOT in one paragraph and a MAY a few paragraphs later, a SHOULD 1887 NOT contradicted later by a MAY, and so on. 1888 o Merged several later fragmentary addenda placed in appendices (for 1889 example the handling of certificate renewal and update) with the 1890 body of the text. 1891 o Updated the algorithms to ones dating from at least this century. 1892 o Did the same for normative references to other standards. 1893 o Corrected incorrect references to other standards, e.g. 1894 IssuerAndSerial -> IssuerAndSerialNumber. 1895 o Corrected errors such as a statement that when both signature and 1896 encryption certificates existed, the signature certificate was 1897 used for encryption. 1898 o Condensed redundant discussions of the same topic spread across 1899 multiple sections into a single location. For example the 1900 description of RA certificate handling previously existed in three 1901 different locations, with slightly different reqirements in each 1902 one. 1903 o Clarified sections that were unclear or even made no sense, for 1904 example the requirement for a "hash on the public key [sic]" 1905 encoded as a PrintableString. 1907 o Clarified certificate renewal and update. These represent a 1908 capability that was bolted onto the original protocol with (at 1909 best) vaguely-defined semantics, including a requirement by the 1910 server to guess whether a particular request was a renewal or not 1911 (updates were even more vaguely defined). In response to 1912 developer feedback that they either avoided renewal/update 1913 entirely because of this uncertainty or hardcoded in particular 1914 behaviour on a per-server basis, this specification explicitly 1915 identifies renewal and update requests as such, and provides 1916 proper semantics for both. Note that this is still a work in 1917 progress due to the lack of clarity of the original spec in this 1918 area, see some of the questions inline with the text. 1920 Authors' Addresses 1922 Peter Gutmann 1923 University of Auckland 1924 Department of Computer Science 1925 Auckland 1926 New Zealand 1928 Email: pgut001@cs.auckland.ac.nz 1930 Max Pritikin 1931 Cisco Systems, Inc 1933 Email: pritikin@cisco.com 1935 Andrew Nourse 1936 Cisco Systems, Inc 1938 Email: nourse@cisco.com 1940 Jan Vilhuber 1941 Cisco Systems, Inc 1943 Email: vilhuber@cisco.com