idnits 2.17.1 draft-ietf-pkix-est-07.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 10, 2013) is 3972 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Downref: Normative reference to an Informational RFC: RFC 2986 ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 5077 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX M. Pritikin, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track P. Yee, Ed. 5 Expires: December 12, 2013 AKAYLA, Inc. 6 D. Harkins, Ed. 7 Aruba Networks 8 June 10, 2013 10 Enrollment over Secure Transport 11 draft-ietf-pkix-est-07 13 Abstract 15 This document profiles certificate enrollment for clients using 16 Certificate Management over CMS (CMC) messages over a secure 17 transport. This profile, called Enrollment over Secure Transport 18 (EST), describes a simple yet functional certificate management 19 protocol targeting Public Key Infrastructure (PKI) clients that need 20 to acquire client certificates and associated Certification Authority 21 (CA) certificate(s). It also supports client-generated public/ 22 private key pairs as well as key pairs generated by the CA. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 12, 2013. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Operational Scenario Overviews . . . . . . . . . . . . . . . 5 61 2.1. Obtaining CA Certificates . . . . . . . . . . . . . . . . 6 62 2.2. Initial Enrollment . . . . . . . . . . . . . . . . . . . 7 63 2.2.1. Certificate TLS authentication . . . . . . . . . . . 7 64 2.2.2. Certificate-less TLS authentication . . . . . . . . . 8 65 2.2.3. HTTP-based client authentication . . . . . . . . . . 8 66 2.3. Client Certificate Re-issuance . . . . . . . . . . . . . 8 67 2.4. Server Key Generation . . . . . . . . . . . . . . . . . . 8 68 2.5. Full PKI Request messages . . . . . . . . . . . . . . . . 9 69 2.6. Certificate Signing Request (CSR) Attributes Request . . 9 70 3. Protocol Design and Layering . . . . . . . . . . . . . . . . 9 71 3.1. Application Layer . . . . . . . . . . . . . . . . . . . . 12 72 3.2. HTTP Layer . . . . . . . . . . . . . . . . . . . . . . . 13 73 3.2.1. HTTP headers for control . . . . . . . . . . . . . . 13 74 3.2.2. HTTP URIs for control . . . . . . . . . . . . . . . . 14 75 3.2.3. HTTP-Based Client Authentication . . . . . . . . . . 15 76 3.2.4. Message types . . . . . . . . . . . . . . . . . . . . 16 77 3.3. TLS Layer . . . . . . . . . . . . . . . . . . . . . . . . 17 78 3.3.1. TLS-Based Server Authentication . . . . . . . . . . . 17 79 3.3.2. TLS-Based Client Authentication . . . . . . . . . . . 18 80 3.3.3. Certificate-less TLS Mutual Authentication . . . . . 19 81 3.4. Proof-of-Possession . . . . . . . . . . . . . . . . . . . 19 82 3.5. Linking Identity and PoP information . . . . . . . . . . 19 83 3.6. Server Authorization . . . . . . . . . . . . . . . . . . 21 84 3.6.1. Client use of Explicit TA Database . . . . . . . . . 21 85 3.6.2. Client use of Implicit TA Database . . . . . . . . . 21 86 3.7. Client Authorization . . . . . . . . . . . . . . . . . . 21 87 4. Protocol Exchange Details . . . . . . . . . . . . . . . . . . 22 88 4.1. Distribution of CA certificates . . . . . . . . . . . . . 22 89 4.1.1. Bootstrap Distribution of CA certificates . . . . . . 22 90 4.1.2. CA certificates request . . . . . . . . . . . . . . . 23 91 4.1.3. CA certificates response . . . . . . . . . . . . . . 23 92 4.2. Client Certificate Request Functions . . . . . . . . . . 24 93 4.2.1. Simple Enrollment of Clients . . . . . . . . . . . . 25 94 4.2.2. Simple Re-Enrollment of Clients . . . . . . . . . . . 26 95 4.2.3. Simple Enroll and Re-Enroll Response . . . . . . . . 26 96 4.3. Full CMC . . . . . . . . . . . . . . . . . . . . . . . . 27 97 4.3.1. Full CMC Request . . . . . . . . . . . . . . . . . . 27 98 4.3.2. Full CMC Response . . . . . . . . . . . . . . . . . . 27 99 4.4. Server-side Key Generation . . . . . . . . . . . . . . . 28 100 4.4.1. Server-side Key Generation Request . . . . . . . . . 28 101 4.4.1.1. Requests for Symmetric Key Encryption of the 102 Private Key . . . . . . . . . . . . . . . . . . . 29 103 4.4.1.2. Requests for Asymmetric Encryption of the Private 104 Key . . . . . . . . . . . . . . . . . . . . . . . 29 105 4.4.2. Server-side Key Generation Response . . . . . . . . . 30 106 4.5. CSR Attributes . . . . . . . . . . . . . . . . . . . . . 31 107 4.5.1. CSR Attributes Request . . . . . . . . . . . . . . . 32 108 4.5.2. CSR Attributes Response . . . . . . . . . . . . . . . 32 109 5. Contributors/Acknowledgements . . . . . . . . . . . . . . . . 33 110 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 111 7. Security Considerations . . . . . . . . . . . . . . . . . . . 36 112 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 113 8.1. Normative References . . . . . . . . . . . . . . . . . . 38 114 8.2. Informative References . . . . . . . . . . . . . . . . . 40 115 Appendix A. Operational Scenario Example Messages . . . . . . . 41 116 A.1. Obtaining CA Certificates . . . . . . . . . . . . . . . . 41 117 A.2. CSR Attributes . . . . . . . . . . . . . . . . . . . . . 43 118 A.3. Enroll/ReEnroll . . . . . . . . . . . . . . . . . . . . . 44 119 A.4. Server Key Generation . . . . . . . . . . . . . . . . . . 46 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 122 1. Introduction 124 This document profiles certificate enrollment for clients using 125 Certificate Management over CMS (CMC) [RFC5272] messages over a 126 secure transport. Enrollment over Secure Transport (EST) describes 127 the use of Transport Layer Security (TLS) 1.1 [RFC4346] (or a later 128 version) and Hypertext Transfer Protocol (HTTP) 1.1 [RFC2616] (or a 129 later version) to provide an authenticated and authorized channel for 130 Simple PKI (Public Key Infrastructure) Requests and Responses 131 [RFC5272]. 133 Architecturally, the EST service is located between a Certification 134 Authority (CA) and a client. It performs several functions 135 traditionally allocated to the RA (Registration Authority) role in a 136 PKI. The nature of communication between an EST server and a CA is 137 not described in this document. 139 EST adopts the Certificate Management Protocol (CMP) [RFC4210] model 140 for CA certificate rollover, but does not use the CMP message syntax 141 or protocol. EST servers are extensible in that new functions may be 142 defined to provide additional capabilities not specified in CMC 143 [RFC5272], and this document defines two such extensions, one for 144 requesting Certificate Signing Request attributes, and another for 145 requesting server-generated keys. 147 EST specifies how to transfer messages securely via HTTP over TLS 148 (HTTPS) [RFC2818], where the HTTP headers and media types are used in 149 conjunction with TLS. HTTPS operates over TCP; this document does 150 not specify EST over Datagram Transport Layer Security/User Datagram 151 Protocol (DTLS/UDP). Figure 1 shows how the layers build upon each 152 other. 154 EST Layering: 156 Protocols: 157 +--------------------------------------------+ 158 | | 159 | EST request/response messages | 160 | | 161 +--------------------------------------------+ 162 | | 163 | HTTP for message transfer and signaling | 164 | | 165 +--------------------------------------------+ 166 | | 167 | TLS for transport security | 168 | | 169 +--------------------------------------------+ 170 | | 171 | TCP for transport | 172 | | 173 +--------------------------------------------+ 175 Figure 1 177 1.1. Terminology 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 181 "OPTIONAL" in this document are to be interpreted as described in 182 [RFC2119]. 184 It is assumed that the reader is familiar with the terms and concepts 185 described in Public Key Cryptography Standard (PKCS) #10 [RFC2986], 186 HTTPS [RFC2818], CMP [RFC4210], CMC [RFC5272][RFC5273][RFC5274], and 187 TLS [RFC4346]. 189 In addition to the terms defined in the terminology section of CMC 190 [RFC5272] the following terms are defined for clarity: 192 EST CA: For certificate issuing services, the EST CA is reached 193 through the EST Server; the CA could be logically "behind" the EST 194 Server or embedded within it. 196 Third-Party Trust Anchor (TA): Any Trust Anchor that is not 197 authoritative for the PKI hierarchy the EST server is providing 198 services for. 200 Explicit Trust Anchor: Any Trust Anchor that is explicitly 201 configured on the client or server for use during EST TLS 202 authentication. For example a TA that is manually configured on 203 the EST client or bootstrapped as described in Section 4.1.1. 204 (See more details in Section 3.6 and Section 7). 206 Implicit Trust Anchor: Any third-party Trust Anchor that is 207 available on the client or server for use during TLS 208 authentication but is not specifically indicated for use during 209 EST TLS authentication. For example TAs commonly used by web 210 browsers to authenticate web servers, or TAs used by server's to 211 authenticate manufacturing installed client credentials. The 212 authorization model for these TAs is different from the 213 authorization model for Explicit Trust Anchors. (See more details 214 in Section 3.6.1, Section 3.6.2, and Section 7). 216 Certificate-less TLS: Use of a TLS cipher suite in which neither the 217 client nor server use a certificate to authenticate. The 218 credential used for authentication is a word, phrase, code or key 219 that is shared between the client and server. The credential must 220 be uniquely shared between the client and server in order to 221 provide authentication of an individual client. 223 2. Operational Scenario Overviews 225 This section provides an informative overview of the operational 226 scenarios to better introduce the reader to the protocol discussion. 227 This section does not include RFC 2119 key words. 229 Both the EST clients and server are configured with information that 230 provides the basis for bidirectional authentication and for 231 authorization. The specific initialization data depends on the 232 methods available in the client and server, but can include shared 233 secrets, network service names and locations (e.g., a Uniform 234 Resource Identifier (URI) [RFC3986]), trust anchor information (e.g., 235 a CA certificate or a hash of a TA's certificate), and enrollment 236 keys and certificates. Depending on an enterprise's acquisition and 237 network management practices, some initialization may be performed by 238 the vendor prior to delivery of client hardware and software. In 239 that case, the client vendor may provide data, such as trust anchors, 240 to the enterprise via a secure procedure. The distribution of this 241 initial information is out of scope. 243 Distribution of trust anchors and other certificates can be effected 244 via the EST server. However, nothing can be inferred about the 245 authenticity of this data until an out-of-band mechanism is used to 246 verify them. 248 Sections 2.1-2.3 very closely mirror the text of the Scenarios 249 Appendix of [RFC6403] with such modifications as are appropriate for 250 this profile. Sections 2.1-2.6, below, enumerate the set of EST 251 functions (see Figure 5) and provide an informative overview of EST's 252 capabilities. 254 The general client/server interaction proceeds as follows: The client 255 initiates a TLS-secured HTTP session with an EST server. A specific 256 EST service is requested based on a portion of the URI used for the 257 session. The client and server authenticate each other. The client 258 verifies that the server is authorized to serve this client. The 259 server verifies that the client is authorized to make use of this 260 server and the request that the client has made. The server acts 261 upon the client request. 263 2.1. Obtaining CA Certificates 265 The EST client can request a copy of the current EST CA 266 certificate(s) from the EST server. The EST client is assumed to 267 perform this operation before performing other operations. 269 Throughout this document we assume the EST CA has a certificate that 270 is used by the client to verify signed objects issued by the CA, 271 e.g., certificates and certificate revocation lists (CRLs), and that 272 a separate end-entity (EE) certificate is used when EST protocol 273 communication requires additional encryption. 275 The EST client authenticates and verifies the authorization scope of 276 the EST server when requesting the current CA certificate(s). As 277 detailed in Section 3.3.1 and Section 3.3.3, available options 278 include: 280 o Verifying the EST server's HTTPS URI against the EST server's 281 certificate using Implicit TAs (similar to a common HTTPS 282 exchange). This allows the EST server and client to leverage 283 existing TAs that might be known to the EST client. 285 o The client can leverage a previously distributed trust anchor 286 specific to the EST server. This allows the EST client to use an 287 existing, potentially older, CA certificate to request a current 288 CA certificate. 290 o For bootstrapping, the EST client can rely upon manual 291 authentication performed by the end user as detailed in 292 Section 4.1.1. 294 Client authentication is not required for this exchange, so it is 295 trivially supported by the EST server. 297 2.2. Initial Enrollment 299 After authenticating an EST server and verifying that it is 300 authorized to provide services to the client, an EST client can 301 acquire a certificate for itself by submitting an enrollment request 302 to that server. 304 The EST server authenticates and authorizes the EST client as 305 specified in Section 3.3.2, Section 3.3.3 and Section 3.7. The 306 methods described in the normative text that are discussed in this 307 overview include: 309 o TLS with a previously issued client certificate (e.g., an existing 310 certificate issued by the EST CA); 312 o TLS with a previously installed certificate (e.g., manufacturer 313 installed certificate or a certificate issued by some other 314 party); 316 o Certificate-less TLS (e.g., with a shared credential distributed 317 out-of-band); 319 o HTTP-based with a username/password distributed out-of-band. 321 2.2.1. Certificate TLS authentication 323 If the EST client has a previously installed certificate issued by a 324 third party CA, this certificate can be used to authenticate the 325 client's request for a certificate from the EST server (if that CA is 326 recognized by the EST server). An EST client responds to the EST 327 server's TLS certificate request message with the existing 328 certificate already held by the client. The EST server will verify 329 the client's existing certificate and authorize the client's request 330 as described in Section 3.3.2. 332 2.2.2. Certificate-less TLS authentication 334 The EST client and EST server can be mutually authenticated using a 335 certificate-less TLS cipher suite (see Section 3.3.3). 337 2.2.3. HTTP-based client authentication 339 The EST server can optionally also request that the EST client submit 340 a username/password using the HTTP Basic or Digest Authentication 341 methods (see Section 3.2.3). This approach is desirable if the EST 342 client cannot be authenticated during the TLS handshake (see 343 Section 3.3.2) or the EST server policy requires additional 344 authentication information. See Section 3.2.3. 346 2.3. Client Certificate Re-issuance 348 An EST client can renew/rekey its existing client certificate by 349 submitting a re-enrollment request to an EST server. 351 When the current EST client certificate can be used for TLS client 352 authentication (Section 3.3.2) the client presents this certificate 353 to the EST server for client authentication. When the to be re- 354 issued EST client certificate cannot be used for TLS client 355 authentication, any of the authentication methods used for initial 356 enrollment can be used. 358 For example if the client has an alternative certificate issued by 359 the EST CA that can be used for TLS client authentication, then it 360 can be used. 362 The certificate request message includes the same Subject and 363 SubjectAltName as the current certificate. Name changes are 364 requested as specified in Section 4.2.2. 366 2.4. Server Key Generation 368 The EST client can request a server-generated certificate and key 369 pair (see Section 4.4). 371 2.5. Full PKI Request messages 373 Full PKI Request [RFC5272] messages can be transported via EST using 374 the Full CMC Request function. This affords access to functions not 375 provided by the Simple Enrollment functions. Full PKI Request 376 messages are defined in Sections 3.2 and 4.2 of [RFC5272]. See 377 Section 4.3 for a discussion of how EST provides a transport for 378 these messages. 380 2.6. Certificate Signing Request (CSR) Attributes Request 382 Prior to sending an enrollment request to an EST server, an EST 383 client can query the EST server for a set of additional attribute(s) 384 that the client is requested to use in a subsequent enrollment 385 request. 387 These attributes can provide additional descriptive information that 388 the EST server cannot access itself, such as the Media Access Control 389 (MAC) address of an interface. Alternatively, these attributes can 390 indicate the kind of enrollment request, such as a specific elliptic 391 curve or a specific hash function that the client is expected to use 392 when generating the CSR. 394 3. Protocol Design and Layering 396 Figure 2 provides an expansion of Figure 1 describing how the layers 397 are used. Each aspect is described in more detail in the sections 398 that follow. 400 EST Layering: 402 Protocols and uses: 403 +---------------------------------------------------+ 404 | | 405 | Message types: | 406 | - "Simple PKI" messages | 407 | (incorporates proof-of-possession) | 408 | - CA certificate retrieval | 409 | - "Full PKI" messages (OPTIONAL) | 410 | (incorporates proof-of-possession) | 411 | - CSR attribute request (OPTIONAL) | 412 | - Server-generated key request (OPTIONAL) | 413 | | 414 +---------------------------------------------------+ 415 | | 416 | HTTP: | 417 | - HTTP headers and URIs for control | 418 | - Content-Type headers specify message type | 419 | - Headers for control/error messages | 420 | - URIs for selecting functions | 421 | - Basic or Digest authentication (OPTIONAL) | 422 | | 423 +---------------------------------------------------+ 424 | | 425 | TLS for transport security | 426 | - Authentication of the EST server | 427 | - Authentication of the EST client (OPTIONAL) | 428 | - Provides communications integrity | 429 | and confidentiality | 430 | - Channel Binding [RFC5929] to link | 431 | proof-of-identity with message-based | 432 | proof-of-possession. (OPTIONAL) | 433 | | 434 +---------------------------------------------------+ 436 Figure 2 438 Specifying HTTPS as the secure transport for enrollment messages 439 introduces two 'layers' to communicate authentication and control 440 messages: TLS and HTTP. 442 The TLS layer provides integrity and confidentiality during 443 transport. The proof-of-identity is supplied by TLS handshake 444 authentication and optionally also by the HTTP layer headers. The 445 message type and control/error messages are included in the HTTP 446 headers. 448 CMC [RFC5272] Section 3.1 notes that "the Simple PKI Request MUST NOT 449 be used if a proof-of-identity needs to be included". Since the TLS 450 and HTTP layers can provide proof-of-identity for EST clients and 451 servers the Simple PKI message types are used. 453 The TLS layer certificate exchange provides a method for authorizing 454 client enrollment requests using existing certificates. Such 455 certificates may have been issued by the CA (from which the client is 456 requesting a certificate) or they may have been issued under a 457 distinct PKI (e.g., an IEEE 802.1AR IDevID [IDevID] credential). 459 Proof-of-possession (PoP) is a distinct issue from proof-of-identity 460 and is included in the Simple PKI message type as described in 461 Section 3.4. A method of linking proof-of-identity and proof-of- 462 possession is described in Section 3.5. 464 This document also defines transport for CMC [RFC5272] that complies 465 with CMC Transport Protocols [RFC5273]. CMC's PoP and proof-of- 466 identity mechanisms are defined in CMC, but the mechanisms here can 467 also be used in conjunction with those mechanisms in "Full PKI" 468 messages. 470 During protocol exchanges different certificates can be used. The 471 following table provides an informative overview. End-entities can 472 have one or more certificates of each type listed in Figure 3 and use 473 one or more Trust Anchor databases of each type listed in Figure 4. 475 Certificates and their corresponding uses: 476 +--------------+--------------------+-------------------------------+ 477 | Certificate | Issuer | Use and section references | 478 +==============+====================+===============================+ 479 | EST server | The CA served by | Presented by the EST server | 480 | certificate | the EST server | during the TLS handshake | 481 | | | | 482 | | | Section 3.3.1 | 483 +--------------+--------------------+-------------------------------+ 484 | EST server | A CA | Presented by the EST server | 485 | certificate | authenticatable by | during the TLS handshake | 486 | | a third-party TA | | 487 | | e.g., a web server | Section 3.3.1, and | 488 | | CA | Security Considerations | 489 +--------------+--------------------+-------------------------------+ 490 | Third-Party | A CA | Presented by the EST client | 491 | EST client | authenticatable by | to the EST server by clients | 492 | certificate | a third-party TA | that have not yet enrolled | 493 | | e.g., a device | | 494 | | manufacturer | Section 3.3.2 | 495 +--------------+--------------------+-------------------------------+ 496 | EST client | The CA served by | Presented to the EST server | 497 | certificate | the EST server | during future EST operations. | 498 | | | | 499 | | | Section 3.3.2 | 500 +--------------+--------------------+-------------------------------+ 501 | End-Entity | The CA served by | Clients can obtain certs | 502 | certificate | the EST server | that are intended for | 503 | | | non-EST uses. This includes | 504 | | | certs that can not be used | 505 | | | for EST operations. | 506 | | | | 507 | | | Section 4.2.3 | 508 +--------------+--------------------+-------------------------------+ 510 Figure 3 512 Trust Anchor databases and their corresponding uses: 513 +--------------+----------------------------------------------------+ 514 | TA database | Use and section references | 515 +==============+====================================================+ 516 | EST server | EST servers use this TA database to authenticate | 517 | Explicit | certificates issued by the EST CA, including EST | 518 | TA database | client certificates during enroll/re-enroll | 519 | | operations | 520 | | | 521 | | Section 3.3.2 | 522 +--------------+----------------------------------------------------+ 523 | EST server | EST servers use this TA database to authenticate | 524 | Implicit | certificates issued by third-party TAs. | 525 | TA database | e.g., EST client certificates issued by a device | 526 | | manufacturer | 527 | | An Implicit TA database can be disabled. | 528 | | | 529 | | Section 3.3.2 | 530 +--------------+----------------------------------------------------+ 531 | EST client | EST clients use this TA database to authenticate | 532 | Explicit | certificates issued by the EST CA, including EST | 533 | TA database | server certificates. | 534 | | | 535 | | Section 3.1, Section 3.3.1, Section 3.6.1 and | 536 | | Section 4.1.1 | 537 +--------------+----------------------------------------------------+ 538 | EST client | EST clients use this trust anchor database to | 539 | Implicit | authenticate an EST server that uses an externally | 540 | TA database | issued certificate. | 541 | | An Implicit TA database can be disabled. | 542 | | | 543 | | Section 3.1, Section 3.3.1, Section 3.6.2 | 544 | | and Security Considerations | 545 +--------------+----------------------------------------------------+ 547 Figure 4 549 3.1. Application Layer 551 The EST client MUST be capable of generating and parsing Simple PKI 552 messages (see Section 4.2). Generating and parsing Full PKI messages 553 is OPTIONAL (see Section 4.3). The client MUST also be able to 554 request CA certificates from the EST server and parse the returned 555 "bag" of certificates (see Section 4.1). Requesting CSR attributes 556 and parsing the returned list of attributes is OPTIONAL (see 557 Section 4.5). 559 Details of the EST client application configuration are out of scope 560 of the protocol discussion but are necessary for understanding the 561 prerequisites of initiating protocol operations. The EST client is 562 RECOMMENDED to be configured with TA databases for Section 3.3.1 or 563 with a secret key for Section 3.3.3. Implementations conforming to 564 this standard MUST provide the ability to designate Explicit TAs. 565 For human usability reasons a "fingerprint" of an Explicit TA 566 database entry can be configured for bootstrapping as discussed in 567 Section 4.1.1. Configuration of an Implicit TA database, perhaps by 568 its inclusion within the EST client distribution or available from 569 the operating system, provides flexibility along with the caveats 570 detailed in Section 7. Implementations conforming to this standard 571 MUST provide the ability to disable use of any Implicit TA database. 573 The EST client is configured with sufficient information to form the 574 EST server URI. This can be the full operation path segment (e.g. 575 https://www.example.com/.well-known/est/ or https://www.example.com/ 576 .well-known/est/arbitraryLabel1) or the EST client can be configured 577 with a tuple composed of the authority portion of the URI along with 578 the OPTIONAL label (e.g. "www.example.com:80", "arbitraryLabel1") or 579 just the authority portion of the URI. 581 3.2. HTTP Layer 583 HTTP is used to transfer EST messages. URIs are defined for handling 584 each media type (i.e., message type) as described in Section 3.2.2. 585 HTTP is also used for client authentication services when TLS client 586 authentication is not available, due to lack of a client certificate 587 suitable for use by TLS (see Section Section 3.2.3). HTTP 588 authentication can also be used in addition to TLS client 589 authentication if the EST server wishes additional authentication 590 information, as noted in Section 2.2.3. Registered media types are 591 used to convey EST messages as specified in Figure 6. 593 HTTP 1.1 [RFC2616] and above support persistent connections. As 594 described in Section 8.1 of that RFC, persistent connections may be 595 used to reduce network and processing load associated with multiple 596 HTTP requests. EST does not require or preclude persistent HTTP 597 connections and their use is out of scope of this specification. 599 3.2.1. HTTP headers for control 601 This document profiles the HTTP content-type header (as defined in 602 [RFC2046], but see Figure 6 for specific values) to indicate the 603 media type for EST messages and to specify control messages for EST. 604 The HTTP Status value is used to communicate success or failure of an 605 EST function. HTTP authentication is used by a client when requested 606 by the server. 608 The media types indicated in the HTTP content-type header indicates 609 which EST message is being transferred. Media types used by EST are 610 specified in Section 3.2.4. 612 3.2.2. HTTP URIs for control 614 The EST server MUST use the [RFC5785] defined path-prefix of "/.well- 615 known/" and the registered name of "est". Thus a valid EST server 616 URI path begins with "https://www.example.com/.well-known/est". Each 617 EST operation is indicated by a path-suffix that indicates the 618 intended operation: 620 Operations and their corresponding URIs: 621 +------------------------+-----------------+-------------------+ 622 | Operation |Operation Path | Details | 623 +========================+=================+===================+ 624 | Distribution of CA | /cacerts | Section 4.1 | 625 | certificates (MUST) | | | 626 +------------------------+-----------------+-------------------+ 627 | Enrollment of new | /simpleenroll | Section 4.2. | 628 | clients (MUST) | | | 629 +------------------------+-----------------+-------------------+ 630 | Re-Enrollment of | /simplereenroll | Section 4.2.2 | 631 | existing clients (MUST)| | | 632 +------------------------+-----------------+-------------------+ 633 | Full CMC (OPTIONAL) | /fullcmc | Section 4.3 | 634 +------------------------+-----------------+-------------------+ 635 | Server-side Key | /serverkeygen | Section 4.4 | 636 | Generation (OPTIONAL) | | | 637 +------------------------+-----------------+-------------------+ 638 | Request CSR attributes | /csrattrs | Section 4.5 | 639 | (OPTIONAL) | | | 640 +------------------------+-----------------+-------------------+ 642 Figure 5 644 The operation path (Figure 5) is appended to the path-prefix to form 645 the URI used with HTTP GET or POST to perform the desired EST 646 operation. An example valid URI absolute path for the "/cacerts" 647 operation is "/.well-known/est/cacerts". To retrieve the CA's 648 certificates, the EST client would use the following HTTP request: 650 GET /.well-known/est/cacerts HTTP/1.1 652 Likewise, to request a new certificate in this example scheme, the 653 EST client would use the following request: 655 POST /.well-known/est/simpleenroll HTTP/1.1 657 The use of distinct operation paths simplifies implementation for 658 servers that do not perform client authentication when distributing / 659 cacerts responses. 661 An EST server MAY provide service for multiple CAs as indicated by an 662 OPTIONAL additional path segment between the registered application 663 name and the operation path. To avoid conflict the CA label MUST NOT 664 be the same as any defined operation path segment. The EST server 665 MUST provide services regardless of whether the additional path 666 segment is present. The following are three example valid URIs: 668 1. https://www.example.com/.well-known/est/cacerts 670 2. https://www.example.com/.well-known/est/arbitraryLabel1/cacerts 672 3. https://www.example.com/.well-known/est/arbitraryLabel2/cacerts 674 In this specification the distinction between enroll and renew/rekey 675 is explicitly indicated by the HTTP URI. When requesting /fullcmc 676 operations CMC [RFC5272] uses the same messages for certificate 677 renewal and certificate rekey. 679 An EST server can provide additional services using other URIs. 681 3.2.3. HTTP-Based Client Authentication 683 The EST server MAY request HTTP-based client authentication. This 684 request can be in addition to successful TLS client authentication 685 (Section 3.3.2) if EST server policy requires additional 686 authentication. (For example the EST server may require that an EST 687 client "knows" a password in addition to "having" an existing client 688 certificate). Or HTTP-based client authentication can be an EST 689 server policy specified fallback in situations where the EST client 690 did not successfully complete the TLS client authentication. (This 691 might arise if the EST client is enrolling for the first time or if 692 the certificates available to an EST client cannot be used for TLS 693 client authentication). 695 HTTP Basic and Digest authentication MUST only be performed over TLS 696 1.1 [RFC4346] or later versions. NULL and anon cipher suites MUST 697 NOT be used because they do not provide confidentiality or support 698 mutual Certificate-based or Certificate-less authentication, 699 respectively. As specified in CMC: Transport Protocols [RFC5273] the 700 server "MUST NOT assume client support for any type of HTTP 701 authentication such as cookies, Basic authentication, or Digest 702 authentication". Clients SHOULD support the Basic and Digest 703 authentication mechanism. 705 Servers that wish to use Basic and Digest authentication reject the 706 HTTP request using the HTTP defined WWW-Authenticate response-header 707 ([RFC2616], Section 14.47). The client is expected to retry the 708 request, including the appropriate Authorization Request Header 709 ([RFC2617], Section 3.2.2), if the client is capable of using the 710 Basic or Digest authentication. If the client is not capable of 711 retrying the request or it is not capable of Basic or Digest 712 authentication, then the client MUST terminate the connection. 714 A client MAY set the username to the empty string ("") if it is 715 presenting a password that is not associated with a username. 717 Support for HTTP-based client authentication has security 718 ramifications as discussed in Section 7. The client MUST NOT respond 719 to the server's HTTP authentication request unless the client has 720 authorized the EST server (as per Section 3.6). 722 3.2.4. Message types 724 This document uses existing media types for the messages as specified 725 by [RFC2585], [RFC5967], and CMC [RFC5272]. To support distribution 726 of multiple certificates for a CA certificate path, the [RFC2046] 727 multipart/mixed media type is used. 729 For consistency with [RFC5273], each distinct EST message type uses 730 an HTTP Content-Type header with a specific media type. 732 The EST messages and their corresponding media types are (parameters 733 if any are discussed in the sections noted in the table): 735 +--------------------+--------------------------+-------------------+ 736 | Message type |Request media type | Request section(s)| 737 | |Response media type(s) | Response section | 738 | |Source(s) of types | | 739 +====================+==========================+===================+ 740 | CA certificate | N/A | Section 4.1 | 741 | request | application/pkcs7-mime | Section 4.1.1 | 742 | | [RFC5751] | | 743 +--------------------+--------------------------+-------------------+ 744 | Cert enroll/renew/ | application/pkcs10 | Section 4.2/4.2.1 | 745 | rekey | application/pkcs7-mime | Section 4.2.2 | 746 | | [RFC5967] [RFC5751] | | 747 +--------------------+--------------------------+-------------------+ 748 | Full CMC | application/pkcs7-mime | Section 4.3.1 | 749 | | application/pkcs7-mime | Section 4.3.2 | 750 | | [RFC5751] | | 751 +--------------------+--------------------------+-------------------+ 752 | Server-side Key | application/pkcs10 | Section 4.4.1 | 753 | Generation | multipart/mixed | Section 4.4.2 | 754 | | (application/pkcs7-mime &| | 755 | | application/pkcs8) | | 756 | | [RFC5967] [RFC5751] & | | 757 | | [RFC5958] | | 758 +--------------------+--------------------------+-------------------+ 759 | Request CSR | N/A | Section 4.5.1 | 760 | attributes | application/csrattrs | Section 4.5.2 | 761 | | This RFC | | 762 +--------------------+--------------------------+-------------------+ 764 Figure 6 766 3.3. TLS Layer 768 TLS provides authentication, which in turn enables authorization 769 decisions. The EST server and EST client are responsible for 770 ensuring that an acceptable cipher suite is negotiated and that 771 bidirectional authentication has been performed. TLS authentication 772 is most commonly enabled with the use of certificates [RFC5280]. 773 Alternately, certificate-less TLS authentication, where neither the 774 client nor server present a certificate, is also an acceptable method 775 for EST mutual authentication (Section 3.3.3. The EST server MUST be 776 authenticated during the TLS handshake unless the client is 777 requesting Bootstrap Distribution of CA certificates (Section 4.1.1) 778 or Full CMC (Section 4.3). 780 HTTPS [RFC2818] specifies how HTTP messages are carried over TLS. 781 HTTPS MUST be used. TLS 1.1 [RFC4346] (or a later version) MUST be 782 used. TLS session resumption [RFC5077] SHOULD be supported. 784 TLS channel binding information can be inserted into a certificate 785 request as detailed in Section 3.5 in order to provide the EST server 786 with assurance that the authenticated TLS client has access to the 787 private key for the certificate being requested. 789 3.3.1. TLS-Based Server Authentication 791 TLS server authentication with certificates MUST be supported. 793 The EST client authenticates the EST server as defined for the cipher 794 suite negotiated. The following text provides details assuming a 795 certificate-based cipher suite, such as the TLS 1.1 [RFC4346] 796 mandatory cipher suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA). 798 Certificate validation MUST be performed as per [RFC5280]. The EST 799 server certificate MUST conform to the [RFC5280] certificate profile. 801 The client validates the TLS server certificate using the EST client 802 Explicit and, if enabled, Implicit TA database(s). The client MUST 803 maintain a distinction between the use of Explicit and Implicit TA 804 databases during authentication in order to support proper 805 authorization. The EST client MUST perform authorization checks as 806 specified in Section 3.6. 808 If certificate validation fails, the client MAY follow the procedure 809 outlined in Section 4.1.1 for bootstrap distribution of CA 810 certificates. 812 3.3.2. TLS-Based Client Authentication 814 TLS client authentication is the RECOMMENDED method for identifying 815 EST clients. HTTP-Based Client Authentication (Section 3.2.3) MAY be 816 used. 818 The EST server authenticates the EST client as defined for the cipher 819 suite negotiated. The following text provides details assuming a 820 certificate-based cipher suite such as the TLS 1.1 [RFC4346] 821 mandatory cipher suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA). The EST 822 server MUST support certificate-based client authentication. 824 Generally, the client will use an existing certificate for renew or 825 rekey operations. If the certificate to be renewed or rekeyed is 826 appropriate for the negotiated cipher suite, then the client MUST use 827 it for the TLS handshake, otherwise the client SHOULD use an 828 alternate certificate that is suitable for the cipher suite and 829 contains the same subject identity information. When requesting an 830 enroll operation the client MAY use a third-party issued client 831 certificate to authenticate itself. 833 Certificate validation MUST be performed as per [RFC5280]. The EST 834 client certificate MUST conform to the [RFC5280] certificate profile. 836 The server validates the TLS server certificate using the EST server 837 Explicit and, if enabled, Implicit TA database(s). The server MUST 838 maintain a distinction between the use of Explicit and Implicit TA 839 databases during authentication in order to support proper 840 authorization. 842 The EST server MUST perform authorization checks as specified in 843 Section 3.7. 845 If a client does not support TLS client authentication, then it MUST 846 support HTTP-based client authentication (Section 3.2.3) or 847 certificate-less TLS authentication (Section 3.3.3). 849 3.3.3. Certificate-less TLS Mutual Authentication 851 Certificate-less TLS cipher suites provide a way to perform mutual 852 authentication in situations where neither the client nor server have 853 certificates, do not desire to use certificates, or do not have the 854 trust anchors necessary to verify a certificate. The client and 855 server MAY negotiate a certificate-less cipher suite for mutual 856 authentication. 858 When using certificate-less mutual authentication in TLS for 859 enrollment, the cipher suite MUST be based on a protocol that is 860 resistant to dictionary attack and MUST be based on a zero knowledge 861 protocol. TLS-SRP ciphersuites, i.e., those with _SRP_ in the name, 862 listed in section 2.7 of [RFC5054] are suitable for this purpose. 863 Section 7 lists the characteristics of a ciphersuite that are 864 suitable for use in certificate-less mutual authentication for 865 enrollment. 867 Successful authentication using a certificate-less cipher suite 868 proves knowledge of a pre-shared secret which implicitly authorizes a 869 peer in the exchange. 871 3.4. Proof-of-Possession 873 As defined in Section 2.1 of CMC [RFC5272], Proof-of-possession (POP) 874 "refers to a value that can be used to prove that the private key 875 corresponding to the public key is in the possession and can be used 876 by an end-entity." 878 The signed enrollment request provides a signature-based proof-of- 879 possession. The mechanism described in Section 3.5 strengthens this 880 by optionally including "Direct"-based proof-of-possession [RFC5272] 881 by including TLS session-specific information within the data covered 882 by the enrollment request signature (thus linking the enrollment 883 request to the authenticated end-point of the TLS connection). 885 3.5. Linking Identity and PoP information 887 Server policy will determine whether clients are required to support 888 the mechanism specified in this section. This specification provides 889 an OPTIONAL method of linking identity and proof-of-possession by 890 including information specific to the current authenticated TLS 891 session within the signed certification request. The client can 892 determine if the server requires the linking of identity and PoP by 893 examining the CSR Attributes Response (see Section 4.5.2). 894 Regardless of the CSR Attributes Response, clients are RECOMMENDED to 895 link identity and PoP by embedding tls-unique information in the 896 certification request. If tls-unique information is included by the 897 client, the server MUST verify it. The EST server MAY reject 898 requests without tls-unique information as indicated by server 899 policy. 901 Linking identity and proof-of-possession proves to the server that 902 the authenticated TLS client has possession of the private key 903 associated with the certification request and that the client was 904 able to sign the certification request after the TLS session was 905 established. This is an alternative to the [RFC5272] 906 Section 6.3-defined "Linking Identity and POP information" method 907 available if Full PKI messages are used. 909 The client generating the request obtains the tls-unique value as 910 defined in Channel Bindings for TLS [RFC5929] from the TLS subsystem. 911 The tls-unique specification includes a synchronization problem as 912 described in Channel Bindings for TLS [RFC5929] section 3.1. To 913 avoid this problem, EST implementations that support this feature 914 MUST use the tls-unique value from the first TLS handshake. EST 915 clients and servers use their tls-unique implementation specific 916 synchronization methods to obtain this first tls-unique value. TLS 917 "secure_renegotiation" [RFC5746] MUST be used. This maintains the 918 binding from the first tls-unique value across renegotiations to the 919 most recently negotiated connection. 921 The tls-unique value is base 64-encoded as specified in Section 4 of 922 [RFC4648] and the resulting string is placed in the certification 923 request challenge-password field ([RFC2985], Section 5.4.1). The 924 challenge-password field is limited to 255 bytes. If the TLS cipher 925 suite in use produces a longer verify_data than that, then an 926 associated hash algorithm will have to be selected to reduce the 927 verify_data to fit within the challenge password length limit. 928 (Section 7.4.9 of [RFC5246] indicates that no existing cipher suite 929 pose such an issue.) If tls-unique information is not embedded 930 within the certification request the challenge-password field MUST be 931 empty to indicate that the client did not include the optional 932 channel-binding information (any value submitted is verified by the 933 server as tls-unique information). 935 If the EST server makes use of a back-end infrastructure for 936 processing, it is RECOMMENDED that the results of this verification 937 be communicated. (For example this communication might use the CMC 938 [RFC5272] "RA POP Witness Control" in a CMC Full PKI Request message. 939 Or an EST server might TLS authenticate an EST client as being a 940 trusted infrastructure element that does not forward invalid 941 requests. A detailed discussion of back-end processing is out of 942 scope). 944 When rejecting requests, the EST server response is as described for 945 all enroll responses (Section 4.2.3). If a Full PKI Response is 946 included, the CMCFailInfo MUST be set to popFailed. If a human 947 readable reject message is included it SHOULD include an informative 948 text message indicating that linking of identity and POP information 949 is required. 951 3.6. Server Authorization 953 The client MUST check EST server authorization before accepting any 954 server responses or responding to HTTP authentication requests. 956 The EST client authorization method depends on which method was used 957 to authenticate the server. When the Explicit TA database is used to 958 authenticate the EST server then Section 3.6.1 applies. When the 959 Implicit TA database is used to authenticate the EST server then 960 Section 3.6.2 applies. Successful authentication using a 961 certificate-less cipher suite implies authorization of the server. 963 The client MAY perform bootstrapping as specified in Section 4.1.1 964 even if these checks fail. 966 3.6.1. Client use of Explicit TA Database 968 When the EST client Explicit TA database is used to validate the EST 969 server certificate the client MUST check either the configured URI 970 against the server's identity, or the EST server certificate MUST 971 contain the id-kp-cmcRA [RFC6402] extended key usage extension. 973 3.6.2. Client use of Implicit TA Database 975 When the EST client Implicit TA database is used to validate the EST 976 server certificate, the client MUST check the URI "against the 977 server's identity as presented in the server's Certificate message" 978 (HTTP Over TLS Section 3.1 "Server Identity" [RFC2818] and 979 [RFC6125]). The provisioned URI provides the basis for 980 authorization, and the server's authenticated identity confirms it is 981 the authorized server. 983 3.7. Client Authorization 985 The decision to issue a certificate to a client is always controlled 986 by local CA policy. The EST server configuration reflects this CA 987 policy. This document does not specify any constraints on such 988 policy. EST provides the EST server access to each client's 989 authenticated identity -- e.g., the TLS client's certificate in 990 addition to any HTTP user authentication credentials -- to help in 991 implementing such policy. 993 If the client's certificate was issued by the EST CA, and it includes 994 the id-kp-cmcRA [RFC6402] extended key usage extension, then the 995 client is a Registration Authority (RA) as described in [RFC5272] and 996 [RFC6402]. In this case the EST server SHOULD apply authorization 997 policy consistent with an RA client. For example when handling / 998 simpleenroll requests the EST server could be configured to accept 999 PoP linking information that does not match the current TLS session 1000 because the authenticated EST client RA has verified this information 1001 when acting as an EST server (as specified in Section 3.5). More 1002 specific RA mechanisms are available if the EST client uses /fullcmc 1003 methods. 1005 4. Protocol Exchange Details 1007 Before processing a request, an EST server determines if the client 1008 is authorized to receive the requested services. Likewise, the 1009 client determines if it will make requests to the EST server. These 1010 authorization decisions are described in the next two sections. 1011 Assuming that both sides of the exchange are authorized, then the 1012 actual operations are as described in subsequent sections. 1014 4.1. Distribution of CA certificates 1016 The EST client can request a copy of the current CA certificates. 1017 This function is generally performed before other EST functions. 1019 4.1.1. Bootstrap Distribution of CA certificates 1021 It is possible that the client was not configured with the TA 1022 database(s) necessary to validate the EST server certificate. This 1023 section describes a method by which minimally configured EST clients 1024 can populate their Explicit TA database. 1026 If the EST client application does not specify either an Explicit TA 1027 database or a Implicit TA database then the initial TLS server 1028 authentication and authorization will fail. The client MAY 1029 provisionally continue the TLS handshake to completion for the 1030 purposes of accessing the /cacerts or /fullcmc method. If the EST 1031 client continues with an unauthenticated connection, the client MUST 1032 extract the HTTP content data from the response (Section 4.1.3 or 1033 Section 4.3.2) and engage a human user to authorize the CA 1034 certificate using out-of-band data such as a CA certificate 1035 "fingerprint" (e.g., a SHA-256 or SHA-512 [SHS] hash on the whole CA 1036 certificate). In a /fullcmc response it is the Publish Trust Anchors 1037 control within the Full PKI Response that must be accepted manually. 1038 It is incumbent on the user to properly verify the TA information, or 1039 to provide the "fingerprint" data during configuration that is 1040 necessary to verify the TA information. 1042 HTTP authentication requests MUST NOT be responded to if the server 1043 has not been authenticated as specified in Section 3.3.1 or 1044 Section 3.3.3 if the optional Certificate-less authentication is 1045 used. 1047 The EST client uses the /cacerts response to establish an Explicit 1048 Trust Anchor database for subsequent TLS authentication of the EST 1049 server. EST clients MUST NOT engage in any other protocol exchange 1050 until after the /cacerts response has been accepted and a new TLS 1051 session has been established (using TLS certificate-based 1052 authentication). 1054 4.1.2. CA certificates request 1056 EST clients request the EST CA TA database information of the CA (in 1057 the form of certificates) with an HTTPS GET message using an 1058 operation path of "/cacerts". EST clients and servers MUST support 1059 the /cacerts function. Clients SHOULD request an up-to-date response 1060 before stored information has expired in order to ensure the EST CA 1061 TA database is up to date. 1063 The EST server SHOULD NOT require client authentication or 1064 authorization to reply to this request. 1066 The client MUST authenticate the EST server as specified in 1067 Section 3.3.1 if certificate-based authentication is used or 1068 Section 3.3.3 if the optional certificate-less authentication is used 1069 and check the server's authorization as given in Section 3.6 or 1070 follow the procedure outlined in Section 4.1.1. 1072 4.1.3. CA certificates response 1074 If successful, the server response MUST have an HTTP 200 response 1075 code. Any other response code indicates an error and the client MUST 1076 abort the protocol. 1078 A successful response MUST be a certs-only CMC Simple PKI Response, 1079 as defined in [RFC5272], containing the certificates described in the 1080 following paragraph. The HTTP content-type of "application/ 1081 pkcs7-mime" is used. The Simple PKI response is sent with a Content- 1082 Transfer-Encoding of "base64" [RFC2045]. 1084 The EST server MUST include the current root CA certificate in the 1085 response. The EST server MUST include any additional certificates 1086 the client would need to build a chain from an EST CA issued 1087 certificate to the current EST CA TA. For example if the EST CA is a 1088 subordinate CA then all the appropriate subordinate CA certificates 1089 necessary to build a chain to the root EST CA are included in the 1090 response. 1092 The EST server SHOULD include the three "Root CA Key Update" 1093 certificates OldWithOld, OldWithNew, and NewWithOld in the response 1094 chain. These are defined in Section 4.4 of CMP [RFC4210]. The EST 1095 client MUST be able to handle these certificates in the response. 1096 The EST CA's most recent self-signed certificate (e.g. NewWithNew 1097 certificate) is self-signed and has the latest NotAfter date. If the 1098 EST server does not include these in the response then after the 1099 current EST CA certificate expires the EST clients will need to be 1100 reinitialized with the PKI using the Bootstrap Distribution of CA 1101 certificates (Section 4.1.1) method, which involves user interaction. 1103 After out-of-band validation occurs, all the other certificates MUST 1104 be validated using normal [RFC5280] certificate path validation 1105 (using the most recent CA certificate as the TA) before they can be 1106 used to build certificate paths during certificate validation. 1108 The EST client MUST store the extracted EST CA certificate as an 1109 Explicit TA database entry for subsequent EST server authentication. 1110 The EST client SHOULD disable use of Implicit TA database entries for 1111 this EST server, now that an Explicit TA database entry is available. 1112 If the client disables the Implicit TA database, and if the EST 1113 server certificate was verified using an Implicit TA database entry, 1114 then the client MUST include the "Trusted CA Indication" extension in 1115 future TLS sessions [RFC6066]. This indicates to the server that 1116 only an EST Server certificate authenticatable by the Explicit TA 1117 database entry is now acceptable (otherwise the EST server might 1118 continue to use a server certificate that is only verifiable by a now 1119 disabled Implicit TA). 1121 The EST client SHOULD also make the CA Certificate response 1122 information available to the end-entity software for use when 1123 validating peer certificates. 1125 4.2. Client Certificate Request Functions 1127 EST clients request a certificate from the EST server with an HTTPS 1128 POST using the operation path value of "/simpleenroll". EST clients 1129 request a renew/rekey of existing certificates with an HTTP POST 1130 using the operation path value of "/simplereenroll". EST servers 1131 MUST support the /simpleenroll and /simplereenroll functions. 1133 It is RECOMMENDED that a client obtain the current CA certificates, 1134 as described in Section 4.1, before performing certificate request 1135 functions. This ensures that the client will be able to validate the 1136 EST server certificate. The client MUST authenticate the EST server 1137 as specified in Section 3.3.1 if certificate-based authentication is 1138 used or Section 3.3.3 if the optional certificate-less authentication 1139 is used. The client MUST verify the authorization the EST server as 1140 specified in Section 3.6. 1142 The server MUST authenticate the client as specified in Section 3.3.2 1143 if certificate-based authentication is used or Section 3.3.3 if the 1144 optional certificate-less authentication is used. The server MUST 1145 verify client authorization as specified in Section 3.7. The EST 1146 server MUST check the tls-unique value as described in Section 3.5 if 1147 one is submitted by the client. 1149 The server MAY accept a certificate request for manual authorization 1150 checking by an administrator. (Section 4.2.3 describes the use of an 1151 HTTP 202 response to the EST client if this occurs). 1153 4.2.1. Simple Enrollment of Clients 1155 When HTTPS POSTing to /simpleenroll the client MUST include a Simple 1156 PKI Request as specified in CMC [RFC5272] Section 3.1 (i.e., a 1157 PKCS#10 Certification Request [RFC2986]). 1159 The Certification Signing Request (CSR) signature provides proof-of- 1160 possession of the private key to the EST server. If the CSR KeyUsage 1161 extension indicates the private key can be used to generate digital 1162 signatures then the CSR signature MUST be generated using the private 1163 key. If the key can be used to generate digital signatures but the 1164 requested CSR KeyUsage extension prohibits generation of digital 1165 signatures then the CSR signature MUST still be generated using the 1166 private key but the key MUST NOT be used to for any other signature 1167 operations (this is consistent with the recommendations concerning 1168 submission of proof-of-possession to an RA or CA as described in 1169 [SP-800-57-Part-1]). The use of /fullcmc operations provides access 1170 to more advanced proof-of-possession methods that MUST be used when 1171 the key pair can not be used for digital signature generation (see 1172 Section 4.3). 1174 The HTTP content-type of "application/pkcs10" is used here. The 1175 format of the message is as specified in [RFC5967] with a Content- 1176 Transfer-Encoding of "base64" [RFC2045]. 1178 The EST client MAY request additional certificates even when using an 1179 existing certificate in the TLS client authentication. For example 1180 the client can use an existing certificate for TLS client 1181 authentication when requesting a certificate that cannot be used for 1182 TLS client authentication. 1184 4.2.2. Simple Re-Enrollment of Clients 1186 EST clients renew/rekey certificates with an HTTPS POST using the 1187 operation path value of "/simplereenroll". 1189 A certificate request employs the same format as the "simpleenroll" 1190 request, using the same HTTP content-type. The request Subject field 1191 and SubjectAltName extension MUST be identical to the corresponding 1192 fields in the certificate being renewed/rekeyed. The 1193 ChangeSubjectName attribute, as defined in [RFC6402], MAY be included 1194 in the CSR to request that these fields be changed in the new 1195 certificate. 1197 If the Subject Public Key Info in the certification request is the 1198 same as the current client certificate then the EST server renews the 1199 client certificate. If the public key information in the 1200 certification request is different than the current client 1201 certificate then the EST server rekeys the client certificate. 1203 4.2.3. Simple Enroll and Re-Enroll Response 1205 If the enrollment is successful, the server response MUST contain an 1206 HTTP 200 response code with a content-type of "application/ 1207 pkcs7-mime". 1209 A successful response MUST be a certs-only CMC Simple PKI Response, 1210 as defined in [RFC5272], containing only the certificate that was 1211 issued. The HTTP content-type of "application/pkcs7-mime" with an 1212 smime-type parameter "certs-only" is used, as specified in [RFC5273]. 1214 When rejecting a request the server MUST specify either an HTTP 1215 [RFC2616] 4xx error, or an HTTP 5xx error. A Simple PKI Response 1216 with an HTTP content-type of "application/pkcs7-mime" (see 1217 Section 4.3.2) MAY be included in the response data to convey an 1218 error response. If the content-type is not set the response data 1219 MUST be a plain text human-readable error message containing 1220 informative information describing why the request was rejected (for 1221 example indicating that CSR attributes are incomplete). 1223 If the server responds with an HTTP [RFC2616] 202, this indicates 1224 that the request has been accepted for processing but that a response 1225 is not yet available. The server MUST include a Retry-After header 1226 as defined for HTTP 503 responses. The server also MAY include 1227 informative human-readable content. The client MUST wait at least 1228 the specified 'retry-after' time before repeating the same request. 1230 The client repeats the initial enrollment request after the 1231 appropriate 'retry-after' interval has expired. The client SHOULD 1232 log or inform the end user of this event. The server is responsible 1233 for maintaining all state necessary to recognize and handle retry 1234 operations as the client is stateless in this regard; it simply sends 1235 the same request repeatedly until it receives a different response 1236 code. 1238 All other return codes are handled as specified in HTTP [RFC2616]. 1240 The EST client MAY also make the certificate response, and associated 1241 private key, available to end-entity software for use as an end- 1242 entity certificate. 1244 4.3. Full CMC 1246 An EST client can request a certificate from an EST server with an 1247 HTTPS POST using the operation path value of "/fullcmc". Support for 1248 the /fullcmc function is OPTIONAL for both clients and servers. 1250 4.3.1. Full CMC Request 1252 If the HTTP POST to /fullcmc is not a valid Full PKI Request, the 1253 server MUST reject the message. The HTTP content-type used is 1254 "application/pkcs7-mime" with an smime-type parameter "CMC-request", 1255 as specified in [RFC5273]. The body of the message is the binary 1256 value of the encoding of the PKI Request with a Content-Transfer- 1257 Encoding of "base64" [RFC2045]. 1259 4.3.2. Full CMC Response 1261 If the enrollment is successful, the server response MUST include an 1262 HTTP 200 response code with a content-type of "application/ 1263 pkcs7-mime" as specified in [RFC5273]. The response data includes 1264 either the Simple PKI Response with an smime-type parameter of 1265 "certs-only" or the Full PKI Response with an smime-type parameter 1266 "CMC-response", as specified in Section 3.2.1 of [RFC5751]. The body 1267 of the message is the binary value of the encoding of the PKI 1268 Response with a Content-Transfer-Encoding of "base64" [RFC2045]. 1270 When rejecting a request, the server MUST specify either an HTTP 4xx 1271 error or an HTTP 5xx error. A CMC response with content-type of 1272 "application/pkcs7-mime" SHOULD be included in the response data for 1273 any CMC error response. If the content-type is not set the response 1274 data MUST be a plain text human-readable error message containing 1275 informative information describing why the request was rejected (for 1276 example indicating that CSR attributes are incomplete). 1278 All other return codes are handled as specified in Section 4.2.3 or 1279 HTTP [RFC2616]. For example, a client interprets an HTTP 404 or 501 1280 response to indicate that this service is not implemented. 1282 4.4. Server-side Key Generation 1284 An EST client may request a private key and associated certificate 1285 from an EST server using an HTTPS POST with an operation path value 1286 of "/serverkeygen". Support for the /serverkeygen function is 1287 OPTIONAL. 1289 A client MUST authenticate an EST server as specified in 1290 Section 3.3.1 if certificate-based authentication is used or 1291 Section 3.3.3 if the optional certificate-less authentication is used 1292 and check the server's authorization as given in Section 3.6. 1294 The EST server MUST authenticate the client as specified in 1295 Section 3.3.2 if certificate-based authenticated is used or 1296 Section 3.3.3 if the optional certificate-less authentication is used 1297 and check the client's authorization as given in Section 3.7. The 1298 EST server applies whatever authorization or logic it chooses to 1299 determine if the private key and certificate should be provided. 1301 Cipher suites which have a NULL confidentiality algorithm MUST NOT be 1302 used as they will disclose the contents of an unprotected private 1303 key. 1305 Proper random number and key generation [RFC4086] is a server 1306 implementation responsibility and server archiving of generated keys 1307 is determined by CA policy. The key pair and certificate are 1308 transferred over the TLS session. The cipher suite used to return 1309 the private key and certificate MUST offer confidentiality 1310 commensurate with the private key being delivered to the client. 1312 The EST client MAY request additional certificates even when using an 1313 existing certificate in the TLS client authentication. For example 1314 the client can use an existing certificate for TLS client 1315 authentication when requesting a certificate that cannot be used for 1316 TLS client authentication. 1318 4.4.1. Server-side Key Generation Request 1320 The certificate request is HTTPS POSTed and is the same format as for 1321 the "/simpleenroll" and "/simplereenroll" path extensions with the 1322 same content-type and transfer encoding. 1324 In all respects the server SHOULD treat the CSR as it would any 1325 enroll or re-enroll CSR; the only distinction here is that the server 1326 MUST ignore the public key values and signature in the CSR. These 1327 are included in the request only to allow re-use of existing 1328 codebases for generating and parsing such requests. 1330 If the client desires to receive the private key with encryption that 1331 exists outside of and in addition to that of the TLS transport used 1332 by EST or if server policy requires that the key be delivered in such 1333 a form, the client MUST include an attribute in the CSR indicating 1334 the encryption key to be used. Both symmetric and asymmetric 1335 encryption are supported as described in the following subsections. 1336 The server needs to know a priori about the algorithms supported by 1337 the client. 1339 It is strongly RECOMMENDED that the clients request that the returned 1340 private key be afforded the additional security of the CMS 1341 EnvelopedData in addition to the TLS-provided security to protect 1342 against unauthorized disclosure. 1344 4.4.1.1. Requests for Symmetric Key Encryption of the Private Key 1346 To specify a symmetric encryption key to be used to encrypt the 1347 server-generated private key, the client MUST include a 1348 DecryptKeyIdentifier attribute (as defined in Section 2.2.5, 1349 [RFC4108]) specifying the identifier of the secret key to be used by 1350 the server to encrypt the private key. While that attribute was 1351 originally designated for specifying a firmware encryption key, it 1352 exactly mirrors the requirements for specifying a secret key to 1353 encrypt a private key. If the server does not have a secret key 1354 matching the identifier specified by the client, the request MUST be 1355 terminated and an error returned to the client. Distribution of the 1356 key specified by the DecryptKeyIdentifer to the key generator and the 1357 client is outside the scope of this document. 1359 4.4.1.2. Requests for Asymmetric Encryption of the Private Key 1361 To specify an asymmetric encryption key to be used to encrypt the 1362 server-generated private key, the client MUST include an 1363 AsymmetricDecryptKeyIdentifier attribute. The 1364 AsymmetricDecryptKeyIdentifier attribute is defined as: 1366 id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= { 1367 id-pkix TBD } 1369 The asymmetric-decrypt-key-identifier attribute values have ASN.1 1370 type AsymmetricDecryptKeyIdentifier: 1372 AsymmetricDecryptKeyIdentifier ::= OCTET STRING 1374 If the server does not have a public key matching the identifier 1375 specified by the client, the request MUST be terminated and an error 1376 returned to the client. Distribution of the key specified by the 1377 AysmmetricDecryptKeyIdentifer to the key generator and the client is 1378 outside the scope of this document. If the key identified is bound 1379 to an X.509 certificate, then the key MUST either explicitly support 1380 keyTransport or keyAgreement or its use MUST be unrestricted. 1382 4.4.2. Server-side Key Generation Response 1384 If the request is successful, the server response MUST have an HTTP 1385 200 response code with a content-type of "multipart/mixed" consisting 1386 of two parts. One part is the private key data and the other part is 1387 the certificate data. 1389 The format in which the private key data part is returned is 1390 dependent on whether the private key is being returned with 1391 additional encryption on top of that provided by TLS. 1393 If additional encryption is not being employed, the private key data 1394 MUST be placed in an "application/pkcs8". An "application/pkcs8" 1395 part consists of the base 64-encoded DER-encoded PrivateKeyInfo with 1396 a Content-Transfer-Encoding of "base64" [RFC2045]. 1398 If additional encryption is being employed, the private key is placed 1399 inside of a CMS SignedData. The SignedData is signed by the party 1400 that generated the private key, which may or may not be the EST 1401 server or the EST CA. The SignedData is further protected by placing 1402 it inside of a CMS EnvelopedData, as described in Section 4 of 1403 [RFC5958]. The following list shows how the EncryptedData is used, 1404 depending on the type of protection key specified by the client. 1406 o If the client specified a symmetric encryption key to protect the 1407 server-generated private key, the EnvelopedData content is 1408 encrypted using the secret key identified in the request. The 1409 EnvelopedData RecipientInfo field MUST indicate the kekri (Key 1410 Encryption Key Recipient Info) key management technique. The 1411 values are: version is set to 4, kekid is set to the value of the 1412 DecryptKeyIdentifier from Section 4.4.1.1, keyEncryptionAlgorithm 1413 is set to one of the key wrap algorithms that the client included 1414 in the SMIME Capabilities accompanying the request, and 1415 encryptedKey is the encrypted key. 1417 o If the client specified an asymmetric encryption key suitable for 1418 key transport operations to protect the server-generated private 1419 key, the EnvelopedData content is encrypted using a randomly- 1420 generated symmetric encryption key. The cryptographic strength of 1421 the symmetric encryption key SHOULD be equivalent to the client- 1422 specified asymmetric key. The EnvelopedData RecipientInfo field 1423 MUST indicate the ktri (KeyTransRecipientInfo) key management 1424 technique. In KeyTransRecipientInfo, rid is either the 1425 subjectKeyIdentifier copied from the attribute defined in 1426 Section 4.4.1.2 or the server determines an associated 1427 issuerAndSerialNumber from the attribute. version is derived from 1428 the choice of rid [RFC5652], keyEncryptionAlgorithm is set to one 1429 of the key wrap algorithms that the client included in the SMIME 1430 Capabilities accompanying the request, and encryptedKey is the 1431 encrypted key. 1433 o If the client specified an asymmetric encryption key suitable for 1434 key agreement operations to protect the server-generated private 1435 key, the EnvelopedData content is encrypted using a randomly- 1436 generated symmetric encryption key. The cryptographic strength of 1437 the symmetric encryption key SHOULD be equivalent to the client- 1438 specified asymmetric key. The EnvelopedData RecipientInfo field 1439 MUST indicate the kari (KeyAgreeRecipientInfo) key management 1440 technique. In the KeyAgreeRecipientInfo type, version, 1441 originator, and ukm are as in [RFC5652] and keyEncryptionAlgorithm 1442 is set to one of the key wrap algorithms that the client included 1443 in the SMIME Capabilities accompanying the request. The 1444 recipient's key identifier is either copied from the attribute 1445 defined in Section 4.4.1.2 to subjectKeyIdentifier or the server 1446 determines an IssuerAndSerialNumber that corresponds to the value 1447 provided in the attribute. 1449 In all three additional encryption cases, the EnvelopedData is 1450 returned in the response as an "application/pkcs7-mime" part, with an 1451 smime-type parameter of "server-generated-key", and with a Content- 1452 Transfer-Encoding of "base64". 1454 The certificate data part is an "application/pkcs7-mime" and exactly 1455 matches the certificate response to /simpleenroll. 1457 When rejecting a request, the server MUST specify either an HTTP 4xx 1458 error, or an HTTP 5xx error. If the content-type is not set, the 1459 response data MUST be a plain text human-readable error message. 1461 4.5. CSR Attributes 1463 CA policy may allow inclusion of client-provided attributes in 1464 certificates that it issues, and some of these attributes may 1465 describe information that is not available to the CA. In addition, a 1466 CA may desire to certify a certain type of public key and a client 1467 may not have a priori knowledge of that fact. Therefore, clients 1468 SHOULD request a list of expected attributes that are required, or 1469 desired, by the CA in an enrollment request, or if dictated by local 1470 policy. 1472 Requesting CSR Attributes is optional but clients are advised that 1473 CA's may refuse enrollment requests that are not encoded according to 1474 the CA's policy. 1476 4.5.1. CSR Attributes Request 1478 The EST client requests a list of CA-desired CSR attributes from the 1479 CA by sending an HTTPS GET message to the EST server with an 1480 operations path of "/csrattrs". 1482 4.5.2. CSR Attributes Response 1484 If locally configured policy for an authenticated EST client 1485 indicates a CSR Attributes Response is to be provided, the server 1486 response MUST include an HTTP 200 response code. An HTTP response 1487 code of 204 or 404 indicates that a CSR Attributes Response is not 1488 available. Regardless of the response code, the EST server and CA 1489 MAY reject any subsequent enrollment requests for any reason, e.g., 1490 incomplete CSR attributes in the request. 1492 If the CA requires a particular crypto system (e.g., certification of 1493 a public key based on a certain elliptic curve) it MUST provide that 1494 information in the CSR Attributes response. If an EST server 1495 requires the linking of identity and PoP information (see 1496 Section 3.5) it MUST include the challengePassword OID in the CSR 1497 Attributes response. 1499 Responses to attribute request messages MUST be encoded as content- 1500 type of "application/csrattrs" with a Content-Transfer-Encoding of 1501 "base64" [RFC2045]. The syntax for application/csrattrs body is as 1502 follows: 1504 id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= { 1505 id-pkix TBD } 1506 Csrattrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID 1508 AttrOrOID ::= CHOICE (oid OBJECT IDENTIFIER, attribute Attribute } 1510 Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE { 1511 type ATTRIBUTE.&id({IOSet}), 1512 values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) } 1514 An EST server includes zero or more OIDs that it requests the client 1515 to use in the certification request. The server MAY include zero or 1516 more Attributes [RFC2986] providing additional information to the 1517 client. The client MUST ignore any OID or Attribute it does not 1518 recognize. When the server encodes Csrattrs as an empty SEQUENCE it 1519 means that the server has no specific additional information it 1520 desires in a client certification request (this is functionally 1521 equivalent to an HTTP response code of 204 or 404). The sequence is 1522 Distinguished Encoding Rules (DER) encoded and then base 64 encoded 1523 (section 4 of [RFC4648]). The resulting text forms the application/ 1524 csrattr body, without headers. 1526 For example, if a CA requests a client to submit a certification 1527 request containing the Media Access Control (MAC) address [RFC2397] 1528 of a device, the challengePassword (indicating that Linking of 1529 Identity and POP information is requested, see Section 3.5), to use 1530 the the secp384r1 elliptic curve, and to use the SH384 hash function 1531 then it sends the following object identifiers: 1533 o macAddress: 1.3.6.1.1.1.1.22 1535 o challengePassword: 1.2.840.113549.1.9.7 1537 o the secp384r1 elliptic curve: 1.3.132.0.34 1539 o the SHA384 hash function: 2.16.840.1.101.3.4.2.2 1541 and encodes them into an ASN.1 SEQUENCE to produce: 1543 30 26 06 07 2B 06 01 01 01 01 16 06 09 2A 86 48 86 F7 0D 01 09 07 1544 06 05 2B 81 04 00 22 06 09 60 86 48 01 65 03 04 02 02 1546 and then base 64 encodes the resulting ASN.1 SEQUENCE to produce: 1548 MCYGBysGAQEBARYGCSqGSIb3DQEJBwYFK4EEACIGCWCGSAFlAwQCAg== 1550 The EST client parses the OID's in the response and handles each OID 1551 independently. When an OID indicates a known descriptive CSR 1552 attribute type, or a common PKIX OID, the client SHOULD include the 1553 requested information or use the indicated algorithm in the 1554 subsequent CSR that it submits, either in the CSR attributes or in 1555 any other appropriate CSR field. When an OID indicates a particular 1556 way to generate the CSR, the client SHOULD generate its CSR according 1557 to the parsed OID. The Attributes in the response contain additional 1558 information for the client as defined by the Attribute type. 1560 5. Contributors/Acknowledgements 1561 The editors would like to thank Stephen Kent, Vinod Arjun, Jan 1562 Vilhuber, Sean Turner, Russ Housley, and others for their feedback 1563 and prototypes of early drafts. Our thanks also go the authors of 1564 [RFC6403] around whose document we structured part of this 1565 specification. 1567 6. IANA Considerations 1569 There is one OID in Section 4.4.1.2 that needs to be registered in 1570 the PKIX Arc. 1572 IANA is requested to register the following: 1574 IANA SHALL update the well-known URI registry with the following 1575 filled-in template from [RFC5785]. 1577 URI suffix: est 1579 Change controller: IETF 1581 IANA SHALL update the Application Media Types registry with the 1582 following filled-in templates from [RFC6838]. 1584 The media subtype for CSR Attributes in a CSR Attributes response is 1585 application/csrattrs. 1587 Type name: application 1589 Subtype name: csrattrs 1591 Required parameters: None 1593 Optional parameters: None 1595 Encoding considerations: binary; 1597 Security Considerations: 1599 Clients request a list of attributes that servers wish to be in 1600 certification requests. The request/response SHOULD be done in a 1601 TLS-protected tunnel. 1603 Interoperability considerations: None 1605 Published specification: This memo. 1607 Applications which use this media type: Enrollment over Secure 1608 Transport (EST) 1609 Additional information: 1611 Magic number(s): None 1613 File extension: None 1615 Macintosh File Type Code(s): 1617 Person & email address to contact for further information: 1619 Dan Harkins 1621 Restrictions on usage: None 1623 Author: Dan Harkins 1625 Intended usage: COMMON 1627 Change controller: The IESG 1629 The application/pkcs7-mime content type defines the optional "smime- 1630 type" parameter [RFC5751]. The smime-type parameter for Server-side 1631 Key Generation Response is server-generated-key. 1633 smime-type name: server-generated-key 1635 Required parameters: None 1637 Optional parameters: None 1639 Encoding considerations: binary; 1641 Security Considerations: 1643 Clients request a server provided key. The request/response 1644 SHOULD be done in a TLS-protected tunnel. 1646 Interoperability considerations: None 1648 Published specification: This memo. 1650 Applications which use this media type: Enrollment over Secure 1651 Transport (EST) 1653 Additional information: 1655 Magic number(s): None 1656 File extension: None 1658 Macintosh File Type Code(s): 1660 Person & email address to contact for further information: 1662 Max Pritikin 1664 Restrictions on usage: None 1666 Author: Max Pritikin 1668 Intended usage: COMMON 1670 Change controller: The IESG 1672 7. Security Considerations 1674 Support for Basic authentication as specified in HTTP [RFC2617] 1675 allows the server access to a client's cleartext password. This 1676 provides support for legacy username/password databases but requires 1677 exposing the plaintext password to the EST server. Use of a PIN or 1678 one-time-password can help mitigate such exposure, but it is 1679 RECOMMENDED that EST clients use such credentials only once to obtain 1680 a client certificate (that will be used during future interactions 1681 with the EST server). 1683 When a client uses the Implicit TA database for certificate 1684 validation (see Section 3) then authorization proceeds as specified 1685 in Section 3.6.2. In this situation, the client has validated the 1686 server as being a certified-by-a-third-party responder for the URI 1687 configured, but cannot verify that the responder is authorized to act 1688 as an RA for the PKI in which the client is trying to enroll. 1689 Clients using an implicit trust anchor database are RECOMMENDED to 1690 only use TLS-based client authentication (to prevent exposing HTTP- 1691 based Client Authentication information). It is RECOMMENDED that 1692 such clients include "Linking Identity and POP information" 1693 (Section 3.5) in requests (to prevent such requests from being 1694 forwarded to a real EST server by a MITM). It is RECOMMENDED that 1695 the implicit trust anchor database used for EST server authentication 1696 be carefully managed, to reduce the chance of a third-party CA with 1697 poor certification practices from being trusted. Disabling the 1698 implicit trust anchor database after succesfully recieving the 1699 Distribution of CA Certificates response (Section 4.1.3) limits any 1700 vulnerability to the first TLS enchange. 1702 Certificate-less TLS ciphersuites that maintain security and perform 1703 the mutual authentiation necessary for enrollment have the following 1704 properties: 1706 o the only information leaked by an active attack is whether a 1707 single guess of the secret is correct or not. 1709 o any advantage an adversary gains is through interaction and not 1710 compuation. 1712 o it is possible to perform countermeasures, such as exponential 1713 backoff after a certain number of failed attempts, to frustrate 1714 repeated active attacks. 1716 Using a certificate-less ciphersuite that does not have the 1717 properties listed above would render the results of enrollment void 1718 and potentially result in certificates being issued to 1719 unauthenticated and/or unauthorized entities. 1721 When using a certificate-less TLS cipher suite, the shared secret 1722 used for authentication and authorization cannot be shared with an 1723 entity that is not a party to the exchange: someone other than the 1724 client and the server. Any additional sharing of secrets voids the 1725 security afforded by a certificate-less cipher suite. Exposure of a 1726 shared secret used by a certificate-less cipher suite to a third- 1727 party enables client impersonation that can results in corruption of 1728 a client's trust anchor database. 1730 TLS cipher suites that include "_EXPORT_" and "_DES_" in their names 1731 MUST NOT be used. These ciphers do not offer a sufficient level of 1732 protection; 40-bit crypto in 2013 doesn't offer acceptable protection 1733 and the use of DES is deprecated. 1735 As described in CMC Section 6.7 [RFC5272], "For keys that can be used 1736 as signature keys, signing the certification request with the private 1737 key serves as a POP on that key pair". The inclusion of tls-unique 1738 within the certification request links the proof-of-possession to the 1739 TLS proof-of-identity by enforcing that the POP operation occurred 1740 while the TLS session was active. This implies to the server that 1741 the authenticated client currently has access to the private key. If 1742 the authenticated client is known to have specific capabilities, such 1743 as hardware protection for authentication credentials and key 1744 storage, this implication is strengthened but not proven. 1746 The server-side key generation method allows keys to be transported 1747 over the TLS connection to the client without any application layer 1748 protection. The distribution of private key material is inherently 1749 risky. Private key distribution uses the encryption mode of the 1750 negotiated TLS cipher suite. Keys are not protected by preferred key 1751 wrapping methods such as AES Key Wrap [RFC3394] or as specified in 1752 [RFC5958] as encryption of the private key beyond that provided by 1753 TLS is optional. It is RECOMMEND that EST servers not support this 1754 operation by default. It is RECOMMENDED that clients not request 1755 this service unless there is a compelling operational benefit. Use 1756 of an implicit trust anchor database is NOT RECOMMENDED when server- 1757 side key generation is employed. The use of an encrypted CMS Server- 1758 side Key Generation Response is RECOMMENDED. 1760 Regarding the CSR attributes that the CA may list for inclusion in an 1761 enrollment request, there are no real inherent security issues with 1762 the content being conveyed but an adversary who is able to interpose 1763 herself into the conversation could exclude attributes that a server 1764 may want, include attributes that a server may not want, and render 1765 meaningless other attributes that a server may want. 1767 8. References 1769 8.1. Normative References 1771 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1772 Extensions (MIME) Part One: Format of Internet Message 1773 Bodies", RFC 2045, November 1996. 1775 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1776 Extensions (MIME) Part Two: Media Types", RFC 2046, 1777 November 1996. 1779 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1780 Requirement Levels", BCP 14, RFC 2119, March 1997. 1782 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 1783 Infrastructure Operational Protocols: FTP and HTTP", RFC 1784 2585, May 1999. 1786 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1787 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1788 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1790 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1791 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1792 Authentication: Basic and Digest Access Authentication", 1793 RFC 2617, June 1999. 1795 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1796 Request Syntax Specification Version 1.7", RFC 2986, 1797 November 2000. 1799 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1800 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1801 3986, January 2005. 1803 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1804 Requirements for Security", BCP 106, RFC 4086, June 2005. 1806 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 1807 Protect Firmware Packages", RFC 4108, August 2005. 1809 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1810 "Internet X.509 Public Key Infrastructure Certificate 1811 Management Protocol (CMP)", RFC 4210, September 2005. 1813 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1814 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1816 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1817 Encodings", RFC 4648, October 2006. 1819 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1820 "Transport Layer Security (TLS) Session Resumption without 1821 Server-Side State", RFC 5077, January 2008. 1823 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1824 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1826 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 1827 (CMC)", RFC 5272, June 2008. 1829 [RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS 1830 (CMC): Transport Protocols", RFC 5273, June 2008. 1832 [RFC5274] Schaad, J. and M. Myers, "Certificate Management Messages 1833 over CMS (CMC): Compliance Requirements", RFC 5274, June 1834 2008. 1836 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1837 Housley, R., and W. Polk, "Internet X.509 Public Key 1838 Infrastructure Certificate and Certificate Revocation List 1839 (CRL) Profile", RFC 5280, May 2008. 1841 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1842 RFC 5652, September 2009. 1844 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 1845 "Transport Layer Security (TLS) Renegotiation Indication 1846 Extension", RFC 5746, February 2010. 1848 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1849 Mail Extensions (S/MIME) Version 3.2 Message 1850 Specification", RFC 5751, January 2010. 1852 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 1853 Uniform Resource Identifiers (URIs)", RFC 5785, April 1854 2010. 1856 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 1857 for TLS", RFC 5929, July 2010. 1859 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 1860 2010. 1862 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 1863 Extension Definitions", RFC 6066, January 2011. 1865 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1866 Verification of Domain-Based Application Service Identity 1867 within Internet Public Key Infrastructure Using X.509 1868 (PKIX) Certificates in the Context of Transport Layer 1869 Security (TLS)", RFC 6125, March 2011. 1871 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 1872 Updates", RFC 6402, November 2011. 1874 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1875 Specifications and Registration Procedures", BCP 13, RFC 1876 6838, January 2013. 1878 [X.680] ITU-T Recommendation, ., "ITU-T Recommendation X.680 1879 Abstract Syntax Notation One (ASN.1): Specification of 1880 basic notation", November 2008, 1881 . 1883 [X.690] ITU-T Recommendation, ., "ITU-T Recommendation X.690 ASN.1 1884 encoding rules: Specification of Basic Encoding Rules 1885 (BER), Canonical Encoding Rules (CER) and Distinguished 1886 Encoding Rules (DER)", November 2008, 1887 . 1889 8.2. Informative References 1891 [IDevID] IEEE Std, ., "IEEE 802.1AR Secure Device Identifier", 1892 December 2009, . 1895 [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, August 1896 1998. 1898 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1900 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 1901 Classes and Attribute Types Version 2.0", RFC 2985, 1902 November 2000. 1904 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 1905 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 1907 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 1908 "Using the Secure Remote Password (SRP) Protocol for TLS 1909 Authentication", RFC 5054, November 2007. 1911 [RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, 1912 August 2010. 1914 [RFC6403] Zieglar, L., Turner, S., and M. Peck, "Suite B Profile of 1915 Certificate Management over CMS", RFC 6403, November 2011. 1917 [SHS] National Institute of Standards and Technology, ., 1918 "Federal Information Processing Standard Publication 1919 180-4: Secure Hash Standard (SHS)", March 2012, . 1922 [SP-800-57-Part-1] 1923 National Institute of Standards and Technology, ., 1924 "Recommendation for Key Management - Part 1: General 1925 (Revision 3)", July 2012, . 1929 [X.520] ITU-T Recommendation, ., "ITU-T Recommendation X.520 The 1930 Directory: Selected attribute types", November 2008, 1931 . 1933 Appendix A. Operational Scenario Example Messages 1935 (informative) 1937 This section expands on the Operational Scenario Overviews by 1938 providing detailed examples of the messages at each TLS layer. 1940 A.1. Obtaining CA Certificates 1942 The following is an example of a valid /CACerts exchange. 1944 During the initial TLS handshake the client can ignore the optional 1945 server generated "certificate request" and can instead proceed with 1946 the HTTP GET request: 1948 GET /.well-known/est/cacerts HTTP/1.1 1949 User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenS 1950 SL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 1951 Host: 192.0.2.1:8085 1952 Accept: */* 1954 In response the server provides the current CA certificates: 1956 HTTP/1.1 200 OK 1957 Status: 200 OK 1958 Content-Type: application/pkcs7-mime 1959 Content-Transfer-Encoding: base64 1960 Content-Length: 4246 1962 MIIMOQYJKoZIhvcNAQcCoIIMKjCCDCYCAQExADALBgkqhkiG9w0BBwGgggwMMIIC 1963 +zCCAeOgAwIBAgIJAJpY3nUZO3qcMA0GCSqGSIb3DQEBBQUAMBsxGTAXBgNVBAMT 1964 EGVzdEV4YW1wbGVDQSBPd08wHhcNMTMwNTA5MDM1MzMxWhcNMTQwNTA5MDM1MzMx 1965 WjAbMRkwFwYDVQQDExBlc3RFeGFtcGxlQ0EgT3dPMIIBIjANBgkqhkiG9w0BAQEF 1966 AAOCAQ8AMIIBCgKCAQEAwDqpiHopaICubpRqbpEN7LqTIqWELFIA9qDDheHIKuyO 1967 HW/ZAP7Rl4S5ZU6gaLW/ksseBUxdmox3KNyvtyjehIofTu28eZWhgy6/LCEGWR3P 1968 K+fgPBA0l0JfJR/8oeXZa70oLVQc3hI4kCeqjFMs+biYH0vp/RluhftyZ5kzQyH1 1969 EGsRkw1/qUKkTZ8PCF8VFlYfqmUoqsaRTyZbjII4J+Y6/jEG+p7QreW9zcz4sPe8 1970 3c/uhwMLOWQkZtKsQtgo5CpfYMjuAmk4Q2joQq2vcxlc+WNKHf+wbrDb11ORZril 1971 9ISlI94oumcRz3uBG1Yg7z83hdDfasmdfbp8gOSNFQIDAQABo0IwQDAPBgNVHRMB 1972 Af8EBTADAQH/MB0GA1UdDgQWBBQITTKxMqATXrfc4ffpCIbt6Gsz0jAOBgNVHQ8B 1973 Af8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBACPnQPu5WReUGuCMS0nBOGa2tXh6 1974 uZP4mS3J1qEfDePam/IiU9ssyYdcDwhVvKMoP4gI/yu4XFqhdpIoy/PyD4T15MT7 1975 KADCxXkh5rM1IqMui7FvBKLWYGdy9sjEf90wAkBjHBe/TMO1NNw3uELyONSkHIvo 1976 X0pu6aPmm/moIMyGi46niFse1iWlXXldGLkOQsh0e7U+wpBX07QpOr2KB2+Yf+uA 1977 KY1SWzEG23bUxXlvcbUMgANDGj5r6z+niKL0VlApip/iCuVEEOcZ91UlmJjVLQWA 1978 x6ie+v84oM+pIojiGM0C4XWcVlKKEgcMOsN3S4lvm8Ptpq0GLoIJY8NTD20wggMD 1979 MIIB66ADAgECAgEBMA0GCSqGSIb3DQEBBQUAMBsxGTAXBgNVBAMTEGVzdEV4YW1w 1980 bGVDQSBPd08wHhcNMTMwNTA5MDM1MzMyWhcNMTQwNTA5MDM1MzMyWjAbMRkwFwYD 1981 VQQDExBlc3RFeGFtcGxlQ0EgTndPMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB 1982 CgKCAQEAnn3rZ3rMJHwf7MD9K4mubxHAvtdnrsQf5OfgtMhRIL4aePNhAdgPyj8C 1983 loxOgD3UTV+dQ1ViOzVxPN7acikoOnkIdRpjpOpkyMo+KkvHMQXGnQTbsMAv1qWt 1984 9S12DMpo0GOA1e4Ge3ud5YPOTR/q6PvjN51IEwYKksG7CglwZwB+5JbwhYr2D/0u 1985 btGltriRVixPWrvt+wz/ITp5rcjh/8RS3LE8tQy3kTNhJF3Y/esR2sSgOiPNgIto 1986 CATysbaINEPr4MemqML4tDpR/aG9y+8Qe7s1LyMFvDletp2mmBykAC/7nOat/pwU 1987 lB0sN524D1XAgz8ZKvWrkh+ZaOr3hwIDAQABo1IwUDAOBgNVHQ8BAf8EBAMCBLAw 1988 HQYDVR0OBBYEFLHEaeZbowSn2Jejizu/uWqyMkI8MB8GA1UdIwQYMBaAFAhNMrEy 1989 oBNet9zh9+kIhu3oazPSMA0GCSqGSIb3DQEBBQUAA4IBAQCLDkL7aLNV6hSOkIqH 1990 q+shV9YLO56/tj00vY/jV5skgDHk5d0B+OGortKVuGa57+v0avTrlJns3bNW8Ntv 1991 zkDEhmd00Ak02aPsi4wRHLFgttUf9HdEHAuTkAESPTU43DiptjkfHhtBMfsFrCkd 1992 sxWzCz+prDOMHYfUEkhRVV++1zyGEX6ov1Ap2IU2p3E+ASihL/amxTEQAsbwjUTI 1993 R52zoL6nMPzpbKeZi2M0eEBVF8sDueA9Hjo6woLjgJqV0/yc5vC2HAxUOhx0cWTY 1994 GcRBgL/yOyQLKiY5TKBH951OjQ4vhF2HmcoO7DkcNLYJOge16ssx4ogBHul20VgF 1995 XJJjMIIDAzCCAeugAwIBAgIBAjANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBl 1996 c3RFeGFtcGxlQ0EgTndOMB4XDTEzMDUwOTAzNTMzMloXDTE0MDUwOTAzNTMzMlow 1997 GzEZMBcGA1UEAxMQZXN0RXhhbXBsZUNBIE93TjCCASIwDQYJKoZIhvcNAQEBBQAD 1998 ggEPADCCAQoCggEBAMA6qYh6KWiArm6Uam6RDey6kyKlhCxSAPagw4XhyCrsjh1v 1999 2QD+0ZeEuWVOoGi1v5LLHgVMXZqMdyjcr7co3oSKH07tvHmVoYMuvywhBlkdzyvn 2000 4DwQNJdCXyUf/KHl2Wu9KC1UHN4SOJAnqoxTLPm4mB9L6f0ZboX7cmeZM0Mh9RBr 2001 EZMNf6lCpE2fDwhfFRZWH6plKKrGkU8mW4yCOCfmOv4xBvqe0K3lvc3M+LD3vN3P 2002 7ocDCzlkJGbSrELYKOQqX2DI7gJpOENo6EKtr3MZXPljSh3/sG6w29dTkWa4pfSE 2003 pSPeKLpnEc97gRtWIO8/N4XQ32rJnX26fIDkjRUCAwEAAaNSMFAwDgYDVR0PAQH/ 2004 BAQDAgSwMB0GA1UdDgQWBBQITTKxMqATXrfc4ffpCIbt6Gsz0jAfBgNVHSMEGDAW 2005 gBSxxGnmW6MEp9iXo4s7v7lqsjJCPDANBgkqhkiG9w0BAQUFAAOCAQEALhDaE6Mp 2006 BINBsJozdbXlijrWxL1CSv8f4GwpUFk3CgZjibt/qW9UoaNR4E58yRopuEhjwFZK 2007 2w8YtRqx8IZoFhcoLkpBDfgLLwhoztzbYvOVKQMidjBlkBEVNR5MWdrs7F/AxWuy 2008 iZ2+8AnR8GwqEIbCD0A7xIghmWEMh/BVI9C7GLqd6PxKrTAjuDfEpfdWhU/uYKmK 2009 cL3XDbSwr30j2EQyaTV/3W0Tn2UfuxdwDQ4ZJs9G+Mw50s7AG6CpISyOIFmX6/bU 2010 DpJXGLiLwfJ9C/aum9nylYuGCJ68BuTrCs9567KGfXEXI0mdFFCL7TaVR43kjsg3 2011 c43kZ7369MeEZzCCAvswggHjoAMCAQICCQDprp3DmjOyETANBgkqhkiG9w0BAQUF 2012 ADAbMRkwFwYDVQQDExBlc3RFeGFtcGxlQ0EgTndOMB4XDTEzMDUwOTAzNTMzMloX 2013 DTE0MDUwOTAzNTMzMlowGzEZMBcGA1UEAxMQZXN0RXhhbXBsZUNBIE53TjCCASIw 2014 DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ5962d6zCR8H+zA/SuJrm8RwL7X 2015 Z67EH+Tn4LTIUSC+GnjzYQHYD8o/ApaMToA91E1fnUNVYjs1cTze2nIpKDp5CHUa 2016 Y6TqZMjKPipLxzEFxp0E27DAL9alrfUtdgzKaNBjgNXuBnt7neWDzk0f6uj74zed 2017 SBMGCpLBuwoJcGcAfuSW8IWK9g/9Lm7Rpba4kVYsT1q77fsM/yE6ea3I4f/EUtyx 2018 PLUMt5EzYSRd2P3rEdrEoDojzYCLaAgE8rG2iDRD6+DHpqjC+LQ6Uf2hvcvvEHu7 2019 NS8jBbw5XradppgcpAAv+5zmrf6cFJQdLDeduA9VwIM/GSr1q5IfmWjq94cCAwEA 2020 AaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUscRp5lujBKfYl6OLO7+5 2021 arIyQjwwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQBCz/CWdYvn 2022 GM/SdCdEiom5A1VxaW8nKgCWg/EyWtAIiaHQuViB+jTUAE9lona2MbJoFHW8U5e8 2023 9dCP0rJpA9UYXXhWvFQzd5ZWpms4wUYt1j3gqqd36KorJIAuPigVng13yKytxM7c 2024 VmxQnh0aux3aEnEyRGAhGalHp0RaKdgPRzUaGtipJTNBkSV5S4kD4yDCPHMNbBu+ 2025 OcluerwEpbz6GvE7CpXl2jrTBZSqBsFelq0iz4kk9++9CnwZwrVgdzklhRfJ1Z4j 2026 NkLruwbQ+o4NvBZsXiKxNfn3K2o3SK8AuaEyDWkq18+5rjcfprRO8x4YTW+6mXPq 2027 jM0MAGNDEW+1oQAxAA== 2029 A.2. CSR Attributes 2031 The following is an example of a valid /csrattrs exchange. During 2032 this exchange the EST client authenticates itself using an existing 2033 certificate issued by the CA the EST server provides services for. 2035 The initial TLS handshake is identical to the enrollment example 2036 handshake. The HTTP GET request: 2038 GET /.well-known/est/csrattrs HTTP/1.1 2039 User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenS 2040 SL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 2041 Host: 192.0.2.1:8085 2042 Accept: */* 2044 In response the server provides suggested attributes that are 2045 appropriate for the authenticated client. In this example the EST 2046 server also includes two example Attributes which the client would 2047 ignore unless the attribute type is known to the client: 2049 HTTP/1.1 200 OK 2050 Status: 200 OK 2051 Content-Type: application/csrattrs 2052 Content-Transfer-Encoding: base64 2053 Content-Length: 171 2055 MHwGBysGAQEBARYwIgYDiDcBMRsTGVBhcnNlIFNFVCBhcyAyLjk5OS4xIGRhdGEG 2056 CSqGSIb3DQEJBzAsBgOINwIxJQYDiDcDBgOINwQTGVBhcnNlIFNFVCBhcyAyLjk5 2057 OS4yIGRhdGEGCSskAwMCCAEBCwYJYIZIAWUDBAIC 2059 A.3. Enroll/ReEnroll 2061 The following is an example of a valid /simpleEnroll exchange. The 2062 data messages for /simpleReEnroll are similar. 2064 During this exchange the EST client uses an out-of-band distributed 2065 username/password to authenticate itself to the EST server. This is 2066 the normal HTTP WWW-Authenticate behavior and is included here for 2067 informative purposes. When an existing TLS client certificate is 2068 used the server might skip requesting the HTTP WWW-Authenticate 2069 header, such as during a /simpleReEnroll operation. 2071 During the initial TLS handshake the client can ignore the optional 2072 server generated "certificate request" and can instead proceed with 2073 the HTTP POST request. In response to the initial HTTP POST attempt 2074 the server requests WWW-Authenticate from the client (this might 2075 occur even if the client used a client certificate, as detailed in 2076 the normative text above): 2078 HTTP/1.1 401 Unauthorized 2079 Content-Length: 0 2080 WWW-Authenticate: Digest qop="auth", realm="estrealm", 2081 nonce="1368141352" 2082 In the subsequent HTTP POST the username/password is included, along 2083 with the complete application/pkcs10 content: 2085 POST /.well-known/est/simplereenroll HTTP/1.1 2086 Authorization: Digest username="estuser", realm="estrealm", nonc 2087 e="1368141352", uri="/.well-known/est/simpleReEnroll", cnonce="M 2088 TYwMzg3", nc=00000001, qop="auth", response="144cc27f96046f1d70e 2089 b16db20f75f22" 2090 Host: 192.0.2.1:8085 2091 Accept: */* 2092 Content-Type: application/pkcs10 2093 Content-Transfer-Encoding: base64 2094 Content-Length: 882 2096 MIIChTCCAW0CAQAwHzEdMBsGA1UEAxMUZGVtb3N0ZXA0IDEzNjgxNDEzNTIwggEi 2097 MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQClNp+kdz+Nj8XpEp9kaumWxDZ3 2098 eFYJpQKz9ddD5e5OzUeCm103ZIXQIxc0eVtMCatnRr3dnZRCAxGjwbqoB3eKt29/ 2099 XSQffVv+odbyw0WdkQOIbntCQry8YdcBZ+8LjI/N7M2krmjmoSLmLwU2V4aNKf0Y 2100 MLR5Krmah3Ik31jmYCSvwTnv6mx6pr2pTJ82JavhTEIIt/fAYq1RYhkM1CXoBL+y 2101 hEoDanN7TzC94skfS3VV+f53J9SkUxTYcy1Rw0k3VXfxWwy+cSKEPREl7I6k0YeK 2102 tDEVAgBIEYM/L1S69RXTLujirwnqSRjOquzkAkD31BE961KZCxeYGrhxaR4PAgMB 2103 AAGgITAfBgkqhkiG9w0BCQcxEhMQK3JyQ2lyLzcrRVl1NTBUNDANBgkqhkiG9w0B 2104 AQUFAAOCAQEARBv0AJeXaHpl1MFIdzWqoi1dOCf6U+qaYWcBzpLADvJrPK1qx5pq 2105 wXM830A1O+7RvrFv+nyd6VF2rl/MrNp+IsKuA9LYWIBjVe/LXoBO8dB/KxrYl16c 2106 VUS+Yydi1m/a+DaftYSRGolMLtWeiqbc2SDBr2kHXW1TR130hIcpwmr29kC2Kzur 2107 5thsuj276FGL1vPu0dRfGQfx4WWa9uAHBgz6tW37CepZsrUKe/0pfVhr2oHxApYh 2108 cHGBQDQHVTFVjHccdUjAXicrtbsVhU5o1lPv7f4lEApv3SBQmJcaq5O832BzHw7n 2109 PyMFcM15E9gtUVee5C62bVwuk/tbnGsbwQ== 2111 The ESTserver uses the username/password to perform authentication/ 2112 authorization and responds with the issued certificate: 2114 HTTP/1.1 200 OK 2115 Status: 200 OK 2116 Content-Type: application/pkcs7-mime; smime-type=certs-only 2117 Content-Transfer-Encoding: base64 2118 Content-Length: 1122 2120 MIIDOAYJKoZIhvcNAQcCoIIDKTCCAyUCAQExADALBgkqhkiG9w0BBwGgggMLMIID 2121 BzCCAe+gAwIBAgIBFTANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBlc3RFeGFt 2122 cGxlQ0EgTndOMB4XDTEzMDUwOTIzMTU1M1oXDTE0MDUwOTIzMTU1M1owHzEdMBsG 2123 A1UEAxMUZGVtb3N0ZXA0IDEzNjgxNDEzNTIwggEiMA0GCSqGSIb3DQEBAQUAA4IB 2124 DwAwggEKAoIBAQClNp+kdz+Nj8XpEp9kaumWxDZ3eFYJpQKz9ddD5e5OzUeCm103 2125 ZIXQIxc0eVtMCatnRr3dnZRCAxGjwbqoB3eKt29/XSQffVv+odbyw0WdkQOIbntC 2126 Qry8YdcBZ+8LjI/N7M2krmjmoSLmLwU2V4aNKf0YMLR5Krmah3Ik31jmYCSvwTnv 2127 6mx6pr2pTJ82JavhTEIIt/fAYq1RYhkM1CXoBL+yhEoDanN7TzC94skfS3VV+f53 2128 J9SkUxTYcy1Rw0k3VXfxWwy+cSKEPREl7I6k0YeKtDEVAgBIEYM/L1S69RXTLuji 2129 rwnqSRjOquzkAkD31BE961KZCxeYGrhxaR4PAgMBAAGjUjBQMA4GA1UdDwEB/wQE 2130 AwIEsDAdBgNVHQ4EFgQU/qDdB6ii6icQ8wGMXvy1jfE4xtUwHwYDVR0jBBgwFoAU 2131 scRp5lujBKfYl6OLO7+5arIyQjwwDQYJKoZIhvcNAQEFBQADggEBACmxg1hvL6+7 2132 a+lFTARoxainBx5gxdZ9omSb0L+qL+4PDvg/+KHzKsDnMCrcU6M4YP5n0EDKmGa6 2133 4lY8fbET4tt7juJg6ixb95/760Th0vuctwkGr6+D6ETTfqyHnrbhX3lAhnB+0Ja7 2134 o1gv4CWxh1I8aRaTXdpOHORvN0SMXdcrlCys2vrtOl+LjR2a3kajJO6eQ5leOdzF 2135 QlZfOPhaLWen0e2BLNJI0vsC2Fa+2LMCnfC38XfGALa5A8e7fNHXWZBjXZLBCza3 2136 rEs9Mlh2CjA/ocSC/WxmMvd+Eqnt/FpggRy+F8IZSRvBaRUCtGE1lgDmu6AFUxce 2137 R4POrT2xz8ChADEA 2139 A.4. Server Key Generation 2141 The following is an example of a valid /serverKeyGen exchange. 2142 During this exchange the EST client authenticates itself using an 2143 existing certificate issued by the CA the EST server provides 2144 services for. 2146 The initial TLS handshake is identical to the enrollment example 2147 handshake. An example HTTP POSTed message is: 2149 POST /.well-known/est/serverkeygen HTTP/1.1 2150 Host: 192.0.2.1:8085 2151 Accept: */* 2152 Expect: 100-continue 2153 Content-Type: application/pkcs10 2154 Content-Transfer-Encoding: base64 2155 Content-Length: 963 2157 MIICwTCCAakCAQAwWzE+MDwGA1UEAxM1c2VydmVyS2V5R2VuIHJlcSBieSBjbGll 2158 bnQgaW4gZGVtbyBzdGVwIDEyIDEzNjgxNDE5NTUxGTAXBgNVBAUTEFBJRDpXaWRn 2159 ZXQgU046MTAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvE1/6m4A/ 2160 3/L32Suyzbf28LM9y8CQfp0aepa7o20BSfluvm8HXR44mlV+wpieM8H5n3Ub3RIo 2161 RUun/FllIzK9uV7UrkqJ3Yzmq2NOoTd4C+OPsV/RPTu873dhFrssDk3P4NIphlSS 2162 sSIkt5rhz7wYbCqCFR5Aphe/30Jx7D+xBI5Rs8e6vRS8IpuImh71BHiLfhq9AFhz 2163 4ZJsOUSVpUmqUogFsM7SOQ6XI4dl+djhpjT+YTJ6hQ2PXrqdch3KsTQ8c6aKs+e2 2164 5QJxh7O8JHVlPHo4YIxXtAYSutcbbTN5TXWFCWSrWDJ+zuMmk2yU+dio1oW7YR7V 2165 ftAvazJ3laQbAgMBAAGgITAfBgkqhkiG9w0BCQcxEhMQZEZzQVhtSm5qb2tCdER2 2166 cjANBgkqhkiG9w0BAQUFAAOCAQEAR+I0EQB+hSjrLCAjnVH6bZdHUNGszIdwx1iu 2167 L4n+0XK3SfEzeOMkC4T74yFGKj3redS1Ht9atYUPb0D1Qi9Jf9Co8eLblo1l19A6 2168 GaS798ofxIF0Pl0Dr6/GqjheqJEIbcDTAJq+kvDihyQ4GQnhosygIZHvKppQlebA 2169 gvp2RJSnMroPCe6RgTU9E2fmI9rin/9PyXeWFF1namp+lYbTGwjv1aE1ikhjCLlH 2170 veHhCdgOExPw+fqhKhHjp+0ZKBlo2bC3pqRWvDTiZuwt9UpFFfGtuxvpTp44oS/j 2171 M/965hWIw/5dshY/wQjIfYs07bbq2ERbpJiw9bAQY34gyoVmEQ== 2172 Because the DecryptKeyIdentifier attribute is not included in this 2173 request the response does not include additional encryption beyond 2174 the TLS session. The EST server response is: 2176 HTTP/1.1 200 OK 2177 Status: 200 OK 2178 Content-Type: multipart/mixed ; boundary=estServerExampleBoundary 2179 Content-Length: 3219 2181 This is the preamble. It is to be ignored, though it 2182 is a handy place for estServer to include an explanatory note 2183 including contact or support information. 2184 --estServerExampleBoundary 2185 Content-Type: application/pkcs8 2186 Content-Transfer-Encoding: base64 2188 MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDPwKtwJ7TjMgA+ 2189 Poj64V909ryql0foP1hU4Yq5y8/bOP5ZTe6ArgVhUye099Ac+dfdwpyP/DESiujU 2190 F/dS62Vck3UWNbnw+4O38FUp0enLbbjSTud48KpEW6+FzkeuAanPGZMA1wKyrYy9 2191 rD5tQOOJU/CBVhUrITyYLZNYUe4agbpcR0wMtrRr2E58Mu8wQ80ryk6nkL7COk5Z 2192 IQdNRxldk7DFvpA85Yn1stumoGRtVLW51iXeTS1LtXwhuUb/j6Lds3vvAiJ2SiZ0 2193 Y3rxPlnJVyFmR8Mf2TBOjzuFqva/VLD2ayQjgaGEjq2ZWHXelQAOZ6N3lrChojEK 2194 FGq93yOhAgMBAAECggEBALQ5az/nYjd5x9Y3f7NMUffwl+jRRfMHCMTRx/u4AEAo 2195 KBYm0hFVZZtxfM+z7xlD8G0Th6gs2hFA6gwcIlUPmiX+UaOLxht0xWaLGgYmcNAm 2196 BiCDjLBQ7xRQCWtlcK9WCA5+HBWtcEy6244rXxh+IyWd6NT6bXC165AEcX87y/e3 2197 JFJ7XFNeDP656s2DmxSCci+iDte6SaEm7sJvYGu16qevJeMThcQcC9/rJjXkvpGL 2198 IKK2px5idad4Pb6+QHpqj3d4oM8djO6wYUvrH8XQLqAaF8Hd5lFWVU57nSYY+H79 2199 GaNDTfRTUL6AXr7kmMsKVFOJ0JjZExUCVMZtGiqhB6UCgYEA639OtdWLZCzyZFMe 2200 p7VlRddoz0VAtrU2dxnEb4cWD8Gerg8uNvp8OG84gH+6MbPwz4ZYWKCgDFqyrAlw 2201 SF02n9Sovh93eoJ5latSbfeYUkLtB8L/HVk5/CBGEsV9MUkdMF0+B43YlhyEDyKW 2202 fX2+0UeHLFgRrfpSzP2cXduEieMCgYEA4db/SIrwN2+g1Gjo3oE09kd89VGjVRer 2203 srbcqc7DcPXP6Lw42sx96h4jVWWqHVo3DfwFBdUb1LH2cnVXQjgDUHdNdpl01cf/ 2204 BFYCFINi2qKMqiJYswkhYxZ1BLz/zuQTDbPFL2PgLniKFG2aFLrTS3S/tgeB5QwI 2205 RPigH3kfI6sCgYAPqsCJyFMlrvfRRNZdQewi4VnPsEPF4/hjpAs1gD8vfSoZWlkw 2206 vylUd9HCerzgYaA7rixieQ0sxTvtxhL6PXlM2NEBFQbV16hPFL6/IiG4F0u9oHNo 2207 eG8rHtqKlSjnBn4yoYFm70Dhe7QtbZelcaAoPCH6CUHj2St5B8ZHWDtREQKBgHNp 2208 wER+XIy4C2UByCANv9csaXulIOdXlXNbaCGPfOm5dWrm5ddLMf33MO9vaSRe+ku3 2209 Q4nbgsGLwPp1ZQZ+QZNZpMi7W6306yp4GdAJ5Pb+oww/ST0VqW5OB7dILyK4A9S4 2210 zkiNrf+Rsl8GM/vsDhc9rsuDwqofIAq/VHVBHNzJAoGBAOHQof5L6iGHOHcxLazx 2211 4MGvRTpmzU/PX6Q3QxqpetEGFEDZAaL58L67SSS3fFBnKrVAidF6llC1bAH1aoRa 2212 fYHUDi45xBoroy0hBwrnTKRxppua4UK75FUH5PPJfR6cCvw5stRkzIevTZHhozkX 2213 pM7PYH/x4BiBmgQ3bhOqTp4H 2214 --estServerExampleBoundary 2215 Content-Type: application/pkcs7-mime; smime-type=certs-only 2216 Content-Transfer-Encoding: base64 2218 MIIDRQYJKoZIhvcNAQcCoIIDNjCCAzICAQExADALBgkqhkiG9w0BBwGgggMYMIID 2219 FDCCAfygAwIBAgIBFjANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBlc3RFeGFt 2220 cGxlQ0EgTndOMB4XDTEzMDUwOTIzMjU1NloXDTE0MDUwOTIzMjU1NlowLDEqMCgG 2221 A1UEAxMhc2VydmVyc2lkZSBrZXkgZ2VuZXJhdGVkIHJlc3BvbnNlMIIBIjANBgkq 2222 hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz8CrcCe04zIAPj6I+uFfdPa8qpdH6D9Y 2223 VOGKucvP2zj+WU3ugK4FYVMntPfQHPnX3cKcj/wxEoro1Bf3UutlXJN1FjW58PuD 2224 t/BVKdHpy2240k7nePCqRFuvhc5HrgGpzxmTANcCsq2Mvaw+bUDjiVPwgVYVKyE8 2225 mC2TWFHuGoG6XEdMDLa0a9hOfDLvMEPNK8pOp5C+wjpOWSEHTUcZXZOwxb6QPOWJ 2226 9bLbpqBkbVS1udYl3k0tS7V8IblG/4+i3bN77wIidkomdGN68T5ZyVchZkfDH9kw 2227 To87har2v1Sw9mskI4GhhI6tmVh13pUADmejd5awoaIxChRqvd8joQIDAQABo1Iw 2228 UDAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0OBBYEFKeZixu9F+appDX2SS5HaxmV6Jr4 2229 MB8GA1UdIwQYMBaAFLHEaeZbowSn2Jejizu/uWqyMkI8MA0GCSqGSIb3DQEBBQUA 2230 A4IBAQBHhLmRAKrnTapqqBObDM9IQDQPuwW+fW1gYwZKlSm/IWIwHEZL1igXhpjj 2231 rf4xqpIkiJMmkaOeoXA8PFniX0/lZM9FQSM/j89CUf5dMoAqWj8s17xuXu9L/hVe 2232 XjjXHsL40WuDG6tMPN9vcT8tE3ruor608MKSHFX/NEM6+AaNVSUPTmB33BgYB1Wa 2233 E7pn3JMN6pjIxsHnF4pKi8qvoTSVVjaCEwUe8Q/fw1yvjoHoYJtyMn4v5Kb3Rt+m 2234 s8Yie1tcfVQrjQutqr34/IJsKdPziZwi92KZa+1958A6M9O/p5OI0up9ZXKg2DEC 2235 1O9qT0GyYJ6sxAyKiGTOxk6jMddDoQAxAA== 2236 --estServerExampleBoundary-- 2237 This is the epilogue. It is also to be ignored. 2239 Authors' Addresses 2241 Max Pritikin (editor) 2242 Cisco Systems, Inc. 2243 510 McCarthy Drive 2244 Milpitas, CA 95035 2245 USA 2247 Email: pritikin@cisco.com 2249 Peter E. Yee (editor) 2250 AKAYLA, Inc. 2251 7150 Moorland Drive 2252 Clarksville, MD 21029 2253 USA 2255 Email: peter@akayla.com 2257 Dan Harkins (editor) 2258 Aruba Networks 2259 1322 Crossman Avenue 2260 Sunnyvale, CA 94089-1113 2261 USA 2263 Email: dharkins@arubanetworks.com