idnits 2.17.1 draft-ietf-pkix-est-06.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 : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (March 29, 2013) is 4018 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) == Unused Reference: 'RFC1321' is defined on line 1673, but no explicit reference was found in the text == Unused Reference: 'RFC2986' is defined on line 1709, but no explicit reference was found in the text == Unused Reference: 'RFC5652' is defined on line 1763, but no explicit reference was found in the text == Unused Reference: 'RFC2712' is defined on line 1821, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 2314 (Obsoleted by RFC 2986) ** 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) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Downref: Normative reference to an Informational RFC: RFC 2985 ** Downref: Normative reference to an Informational RFC: RFC 2986 ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) ** Downref: Normative reference to an Informational RFC: RFC 5054 ** Obsolete normative reference: RFC 5077 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Downref: Normative reference to an Informational RFC: RFC 5967 ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' Summary: 16 errors (**), 0 flaws (~~), 7 warnings (==), 3 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: September 30, 2013 AKAYLA, Inc. 6 D. Harkins, Ed. 7 Aruba Networks 8 March 29, 2013 10 Enrollment over Secure Transport 11 draft-ietf-pkix-est-06 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 September 30, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 60 2. Operational Scenario Overviews . . . . . . . . . . . . . . . . 6 61 2.1. Obtaining CA Certificates . . . . . . . . . . . . . . . . 7 62 2.2. Initial Enrollment . . . . . . . . . . . . . . . . . . . . 8 63 2.2.1. Certificate TLS authentication . . . . . . . . . . . . 8 64 2.2.2. Certificate-less TLS authentication . . . . . . . . . 8 65 2.2.3. HTTP-based client authentication . . . . . . . . . . . 9 66 2.3. Client Certificate Re-issuance . . . . . . . . . . . . . . 9 67 2.4. Server Key Generation . . . . . . . . . . . . . . . . . . 9 68 2.5. Full PKI Request messages . . . . . . . . . . . . . . . . 9 69 2.6. Certificate Signing Request (CSR) Attributes Request . . . 9 70 3. Protocol Design and Layering . . . . . . . . . . . . . . . . . 10 71 3.1. Application Layer . . . . . . . . . . . . . . . . . . . . 14 72 3.2. HTTP Layer . . . . . . . . . . . . . . . . . . . . . . . . 15 73 3.2.1. HTTP headers for control . . . . . . . . . . . . . . . 15 74 3.2.2. HTTP URIs for control . . . . . . . . . . . . . . . . 16 75 3.2.3. HTTP-Based Client Authentication . . . . . . . . . . . 17 76 3.2.4. Message types . . . . . . . . . . . . . . . . . . . . 18 77 3.3. TLS Layer . . . . . . . . . . . . . . . . . . . . . . . . 19 78 3.3.1. TLS-Based Server Authentication . . . . . . . . . . . 20 79 3.3.2. TLS-Based Client Authentication . . . . . . . . . . . 20 80 3.3.3. Certificate-less TLS Mutual Authentication . . . . . . 21 81 3.4. Proof-of-Possession . . . . . . . . . . . . . . . . . . . 21 82 3.5. Linking Identity and PoP information . . . . . . . . . . . 22 83 3.6. Server Authorization . . . . . . . . . . . . . . . . . . . 23 84 3.6.1. Client use of Explicit TA Database . . . . . . . . . . 23 85 3.6.2. Client use of Implicit TA Database . . . . . . . . . . 23 86 3.7. Client Authorization . . . . . . . . . . . . . . . . . . . 24 87 4. Protocol Exchange Details . . . . . . . . . . . . . . . . . . 24 88 4.1. Distribution of CA certificates . . . . . . . . . . . . . 24 89 4.1.1. Bootstrap Distribution of CA certificates . . . . . . 24 90 4.1.2. CA certificates request . . . . . . . . . . . . . . . 25 91 4.1.3. CA certificates response . . . . . . . . . . . . . . . 25 92 4.2. Client Certificate Request Functions . . . . . . . . . . . 27 93 4.2.1. Simple Enrollment of Clients . . . . . . . . . . . . . 27 94 4.2.2. Simple Re-Enrollment of Clients . . . . . . . . . . . 28 95 4.2.3. Simple Enroll and Re-Enroll Response . . . . . . . . . 28 97 4.3. Full CMC . . . . . . . . . . . . . . . . . . . . . . . . . 29 98 4.3.1. Full CMC Request . . . . . . . . . . . . . . . . . . . 29 99 4.3.2. Full CMC Response . . . . . . . . . . . . . . . . . . 29 100 4.4. Server-side Key Generation . . . . . . . . . . . . . . . . 30 101 4.4.1. Server-side Key Generation Request . . . . . . . . . . 30 102 4.4.1.1. Requests for Symmetric Key Encryption of the 103 Private Key . . . . . . . . . . . . . . . . . . . 31 104 4.4.1.2. Requests for Asymmetric Encryption of the 105 Private Key . . . . . . . . . . . . . . . . . . . 31 106 4.4.2. Server-side Key Generation Response . . . . . . . . . 31 107 4.5. CSR Attributes . . . . . . . . . . . . . . . . . . . . . . 33 108 4.5.1. CSR Attributes Request . . . . . . . . . . . . . . . . 33 109 4.5.2. CSR Attributes Response . . . . . . . . . . . . . . . 33 110 5. Contributors/Acknowledgements . . . . . . . . . . . . . . . . 35 111 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 112 7. Security Considerations . . . . . . . . . . . . . . . . . . . 36 113 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 114 8.1. Normative References . . . . . . . . . . . . . . . . . . . 38 115 8.2. Informative References . . . . . . . . . . . . . . . . . . 41 116 Appendix A. Operational Scenario Example Messages . . . . . . . . 42 117 A.1. Obtaining CA Certificates . . . . . . . . . . . . . . . . 42 118 A.2. Enroll/ReEnroll . . . . . . . . . . . . . . . . . . . . . 44 119 A.3. Server Key Generation . . . . . . . . . . . . . . . . . . 46 120 A.4. CSR Attributes . . . . . . . . . . . . . . . . . . . . . . 48 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 123 1. Introduction 125 This document profiles certificate enrollment for clients using 126 Certificate Management over CMS (CMC) [RFC5272] messages over a 127 secure transport. Enrollment over Secure Transport (EST) describes 128 the use of Transport Layer Security (TLS) 1.1 [RFC4346] (or a later 129 version) and Hypertext Transfer Protocol (HTTP) 1.1 [RFC2616] (or a 130 later version) to provide an authenticated and authorized channel for 131 Simple PKI (Public Key Infrastructure) Requests and Responses 132 [RFC5272]. 134 Architecturally, the EST service is located between a CA and a client 135 device. It performs several functions traditionally allocated to the 136 RA (Registration Authority) role in a PKI. The nature of 137 communication between an EST server and a CA is not described in this 138 document. 140 EST adopts the Certificate Management Protocol (CMP) [RFC4210] model 141 for CA certificate rollover, but does not use the CMP message syntax 142 or protocol. EST servers are extensible in that new functions may be 143 defined to provide additional capabilities not specified in CMC 144 [RFC5272], and this document defines two such extensions, one for 145 requesting Certificate Signing Request attributes, and another for 146 requesting server-generated keys. 148 EST specifies how to transfer messages securely via HTTP over TLS 149 (HTTPS) [RFC2818], where the HTTP headers and content types are used 150 in conjunction with TLS. HTTPS operates over TCP; this document does 151 not specify EST over Datagram Transport Layer Security/User Datagram 152 Protocol (DTLS/UDP). Figure 1 shows how the layers build upon each 153 other. 155 EST Layering: 157 Protocols: 158 +--------------------------------------------+ 159 | | 160 | EST request/response messages | 161 | | 162 +--------------------------------------------+ 163 | | 164 | HTTP for message transfer and signaling | 165 | | 166 +--------------------------------------------+ 167 | | 168 | TLS for transport security | 169 | | 170 +--------------------------------------------+ 171 | | 172 | TCP for transport | 173 | | 174 +--------------------------------------------+ 176 Figure 1 178 [[EDNOTE: Comments such as this one, included within double brackets 179 and initiated with an 'EDNOTE', are for editorial use and shall be 180 removed as the document is polished.]] 182 1.1. Terminology 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in [RFC2119]. 188 It is assumed that the reader is familiar with the terms and concepts 189 described in Public Key Cryptography Standard (PKCS) #10 [RFC2314], 190 HTTPS [RFC2818], CMP [RFC4210], CMC [RFC5272][RFC5273][RFC5274], and 191 TLS [RFC4346]. 193 In addition to the terms defined in the terminology section of CMC 194 [RFC5272] the following terms are defined for clarity: 196 EST CA: For certificate issuing services, the EST CA is reached 197 through the EST Server; the CA could be logically "behind" the EST 198 Server or embedded within it. 200 Third-Party Trust Anchor (TA): Any Trust Anchor that is not 201 authoritative for the PKI hierarchy the EST server is providing 202 services for. 204 Explicit Trust Anchor: Any Trust Anchor that is explicitly 205 configured on the client or server for use during EST TLS 206 authentication. For example a TA that is manually configured on 207 the EST client or bootstrapped as described in Section 4.1.1. 208 (See more details in Section 3.6 and Section 7). 210 Implicit Trust Anchor: Any third-party Trust Anchor that is 211 available on the client or server for use during TLS 212 authentication but is not specifically indicated for use during 213 EST TLS authentication. For example TAs commonly used by web 214 browsers to authenticate web servers, or TAs used by server's to 215 authenticate manufacturing installed client credentials. The 216 authorization model for these TAs is different from the 217 authorization model for Explicit Trust Anchors. (See more details 218 in Section 3.6.1, Section 3.6.2, and Section 7). 220 Certificate-less TLS: Use of a TLS cipher suite in which neither the 221 client nor server use a certificate to authenticate. The 222 credential used for authentication is a word, phrase, code or key 223 that is shared between the client and server. The credential must 224 be uniquely shared between the client and server in order to 225 provide authentication of an individual client. 227 2. Operational Scenario Overviews 229 This section provides an informative overview of the operational 230 scenarios to better introduce the reader to the protocol discussion. 231 This section does not include RFC 2119 key words. 233 Both the EST clients and server are configured with information that 234 provides the basis for bidirectional authentication and for 235 authorization. The specific initialization data depends on the 236 methods available in the client device and server, but can include 237 shared secrets, network service names and locations (e.g., a Uniform 238 Resource Identifier (URI) [RFC3986]), trust anchor information (e.g., 239 a CA certificate or a hash of a TA's certificate), and enrollment 240 keys and certificates. Depending on an enterprise's acquisition and 241 network management practices, some initialization may be performed by 242 the vendor prior to delivery of client hardware and software. In 243 that case, the client device vendor may provide data, such as trust 244 anchors, to the enterprise via a secure procedure. The distribution 245 of this initial information is out of scope. 247 Distribution of trust anchors and other certificates can be effected 248 via the EST server. However, nothing can be inferred about the 249 authenticity of this data until an out-of-band mechanism is used to 250 verify them. 252 Sections 2.1-2.3 very closely mirror the text of the Scenarios 253 Appendix of [RFC6403] with such modifications as are appropriate for 254 this profile. Sections 2.1-2.6, below, enumerate the set of EST 255 functions (see Figure 5) and provide an informative overview of EST's 256 capabilities. 258 The general client/server interaction proceeds as follows: The client 259 device initiates a TLS-secured HTTP session with an EST server. A 260 specific EST service is requested based on a portion of the URI used 261 for the session. The client device and server authenticate each 262 other. The client verifies that the server is authorized to serve 263 this client. The server verifies that the client is authorized to 264 make use of this server and the request that the client has made. 265 The server acts upon the client request. 267 2.1. Obtaining CA Certificates 269 The EST client can request a copy of the current EST CA certificates 270 from the EST server. The EST client is assumed to perform this 271 operation before performing other operations. 273 Throughout this document we assume the EST CA has a certificate that 274 is used by the client to verify signed objects issued by the CA, 275 e.g., certificates and certificate revocation lists (CRLs), and that 276 a separate end-entity (EE) certificate is used when EST protocol 277 communication requires additional encryption. This operation is used 278 to obtain the EST CA certificate(s). 280 The EST client authenticates and verifies the authorization scope of 281 the EST server when requesting the current CA certificate(s). As 282 detailed in Section 3.3.1 and Section 3.3.3, available options 283 include: 285 o Verifying the EST server's HTTPS URI against the EST server's 286 certificate using Implicit TAs (similar to a common HTTPS 287 exchange). This allows the EST server and client to leverage 288 existing TAs that might be known to the EST client. 290 o The client can leverage a previously distributed trust anchor 291 specific to the EST server. This allows the EST client to use an 292 existing, potentially older, CA certificate to request a current 293 CA certificate. 295 o For bootstrapping, the EST client can rely upon manual 296 authentication performed by the end user as detailed in 297 Section 4.1.1. 299 Client authentication is not required for this exchange, so it is 300 trivially supported by the EST server. 302 2.2. Initial Enrollment 304 After authenticating an EST server and verifying that it is 305 authorized to provide services to the client, an EST client can 306 acquire a certificate for itself by submitting an enrollment request 307 to that server. 309 The EST server authenticates and authorizes the EST client as 310 specified in Section 3.3.2, Section 3.3.3 and Section 3.7. The 311 methods described in the normative text that are discussed in this 312 overview include: 314 o TLS with a previously issued client certificate (e.g., an existing 315 certificate issued by the EST CA); 317 o TLS with a previously installed certificate (e.g., manufacturer 318 installed certificate or a certificate issued by some other 319 party); 321 o Certificate-less TLS (e.g., with a shared credential distributed 322 out-of-band); 324 o HTTP-based with a username/password distributed out-of-band. 326 2.2.1. Certificate TLS authentication 328 If the EST client has a previously installed certificate issued by a 329 third party CA, this certificate can be used to authenticate the 330 client's request for a certificate from the EST server (if that CA is 331 recognized by the EST server). An EST client responds to the EST 332 server's TLS certificate request message with the existing 333 certificate already held by the client. The EST server will verify 334 the client's existing certificate and authorize the client's request 335 as described in Section 3.3.2. 337 2.2.2. Certificate-less TLS authentication 339 The EST client and EST server can be mutually authenticated using a 340 certificate-less TLS cipher suite (see Section 3.3.3). 342 2.2.3. HTTP-based client authentication 344 The EST server can optionally also request that the EST client submit 345 a username/password using the HTTP Basic or Digest Authentication 346 methods (see Section 3.2.3). This approach is desirable if the EST 347 client cannot be authenticated during the TLS handshake (see Section 348 3.3.2) or the EST server policy requires additional authentication 349 information. See Section 3.2.3. 351 2.3. Client Certificate Re-issuance 353 An EST client can renew/rekey its existing client certificate by 354 submitting a re-enrollment request to an EST server. 356 When the current EST client certificate can be used for TLS client 357 authentication (Section 3.3.2) the client presents this certificate 358 to the EST server for client authentication. When the to be re- 359 issued EST client certificate cannot be used for TLS client 360 authentication, any of the authentication methods used for initial 361 enrollment can be used. 363 For example if the client has an alternative certificate issued by 364 the EST CA that can be used for TLS client authentication, then it 365 can be used. 367 The certificate request message includes the same Subject and 368 SubjectAltName as the current certificate. Name changes are 369 requested as specified in Section 4.2.2. 371 2.4. Server Key Generation 373 The EST client can request a server-generated certificate and key 374 pair (see Section 4.4). 376 2.5. Full PKI Request messages 378 Full PKI Request [RFC5272] messages can be transported via EST using 379 the Full CMC Request function. This affords access to functions not 380 provided by the Simple Enrollment functions. Full PKI Request 381 messages are defined in Sections 3.2 and 4.2 of [RFC5272]. See 382 Section 4.3 for a discussion of how EST provides a transport for 383 these messages. 385 2.6. Certificate Signing Request (CSR) Attributes Request 387 Prior to sending an enrollment request to an EST server, an EST 388 client can query the EST server for a set of additional attribute(s) 389 that the client is requested to use in a subsequent enrollment 390 request. 392 These attributes can provide additional descriptive information that 393 the EST server cannot access itself, such as the MAC address of an 394 interface. Alternatively, these attributes can indicate the kind of 395 enrollment request, such as a specific elliptic curve or a specific 396 hash function that the client is expected to use when generating the 397 CSR. 399 3. Protocol Design and Layering 401 Figure 2 provides an expansion of Figure 1 describing how the layers 402 are used. Each aspect is described in more detail in the sections 403 that follow. 405 EST Layering: 407 Protocols and uses: 408 +---------------------------------------------------+ 409 | | 410 | Message types: | 411 | - "Simple PKI" messages | 412 | (incorporating proof-of-possession) | 413 | - CA certificate retrieval | 414 | - "Full PKI" messages (OPTIONAL) | 415 | - CSR attribute request (OPTIONAL) | 416 | - Server-generated key request (OPTIONAL) | 417 | | 418 +---------------------------------------------------+ 419 | | 420 | HTTP: | 421 | - HTTP headers and URIs for control | 422 | - Content-Type headers specify message type | 423 | - Headers for control/error messages | 424 | - URIs for selecting functions | 425 | - Basic or Digest authentication (OPTIONAL) | 426 | | 427 +---------------------------------------------------+ 428 | | 429 | TLS for transport security | 430 | - Authentication of the EST server | 431 | - Authentication of the EST client (OPTIONAL) | 432 | - Provides communications integrity | 433 | and confidentiality | 434 | - Channel Binding [RFC5929] to link | 435 | proof-of-identity with message-based | 436 | proof-of-possession. (OPTIONAL) | 437 | | 438 +---------------------------------------------------+ 440 Figure 2 442 Specifying HTTPS as the secure transport for enrollment messages 443 introduces two 'layers' to communicate authentication and control 444 messages: TLS and HTTP. 446 The TLS layer provides integrity and confidentiality during 447 transport. The proof-of-identity is supplied by TLS handshake 448 authentication and optionally also by the HTTP layer headers. The 449 message type and control/error messages are included in the HTTP 450 headers. 452 CMC [RFC5272] Section 3.1 notes that "the Simple PKI Request MUST NOT 453 be used if a proof-of-identity needs to be included". Since the TLS 454 and HTTP layers provide proof-of-identity for EST clients and servers 455 the Simple PKI message types are used. 457 The TLS layer certificate exchange provides a method for authorizing 458 client enrollment requests using existing certificates. Such 459 certificates may have been issued by the CA (from which the client is 460 requesting a certificate) or they may have been issued under a 461 distinct PKI (e.g., an IEEE 802.1AR IDevID [IDevID] credential). 463 Proof-of-possession (PoP) is a distinct issue from proof-of-identity 464 and is included in the Simple PKI message type as described in 465 Section 3.4. A method of linking proof-of-identity and proof-of- 466 possession is described in Section 3.5. 468 This document also defines transport for CMC [RFC5272] that complies 469 with CMC Transport Protocols [RFC5273]. 471 During protocol exchanges different certificates can be used. The 472 following table provides an informative overview. End-entities MAY 473 have one or more certificates of each type listed in Figure 3 and use 474 one or more Trust Anchor databases of each type listed in Figure 4. 476 Certificates and their corresponding uses: 477 +--------------+--------------------+-------------------------------+ 478 | Certificate | Issuer | Use and section references | 479 +==============+====================+===============================+ 480 | EST server | The CA served by | Presented by the EST server | 481 | certificate | the EST server | during the TLS handshake | 482 | | | | 483 | | | Section 3.3.1 | 484 +--------------+--------------------+-------------------------------+ 485 | EST server | A CA | Presented by the EST server | 486 | certificate | authenticatable by | during the TLS handshake | 487 | | a third-party TA | | 488 | | e.g., a web server | Section 3.3.1, and | 489 | | CA | Security Considerations | 490 +--------------+--------------------+-------------------------------+ 491 | Third-Party | A CA | Presented by the EST client | 492 | EST client | authenticatable by | to the EST server by clients | 493 | certificate | a third-party TA | that have not yet enrolled | 494 | | e.g., a device | | 495 | | manufacturer | Section 3.3.2 | 496 +--------------+--------------------+-------------------------------+ 497 | EST client | The CA served by | Presented to the EST server | 498 | certificate | the EST server | during future EST operations. | 499 | | | | 500 | | | Section 3.3.2 | 501 +--------------+--------------------+-------------------------------+ 502 | End-Entity | The CA served by | Clients can obtain certs | 503 | certificate | the EST server | that are intended for | 504 | | | non-EST uses. This includes | 505 | | | certs that can not be used | 506 | | | for EST operations. | 507 | | | | 508 | | | Section 4.2.3 | 509 +--------------+--------------------+-------------------------------+ 511 Figure 3 513 Trust Anchor databases and their corresponding uses: 514 +--------------+----------------------------------------------------+ 515 | TA database | Use and section references | 516 +==============+====================================================+ 517 | EST server | EST servers use this TA database to authenticate | 518 | Explicit | certificates issued by the EST CA, including EST | 519 | TA database | client certificates during enroll/re-enroll | 520 | | operations | 521 | | | 522 | | Section 3.3.2 | 523 +--------------+----------------------------------------------------+ 524 | EST server | EST servers use this TA database to authenticate | 525 | Implicit | certificates issued by third-party TAs. | 526 | TA database | e.g., EST client certificates issued by a device | 527 | | manufacturer | 528 | | An Implicit TA database can be disabled. | 529 | | | 530 | | Section 3.3.2 | 531 +--------------+----------------------------------------------------+ 532 | EST client | EST clients use this TA database to authenticate | 533 | Explicit | certificates issued by the EST CA, including EST | 534 | TA database | server certificates. | 535 | | | 536 | | Section 3.1, Section 3.3.1, Section 3.6.1 and | 537 | | Section 4.1.1 | 538 +--------------+----------------------------------------------------+ 539 | EST client | EST clients use this trust anchor database to | 540 | Implicit | authenticate an EST server that uses an externally | 541 | TA database | issued certificate. | 542 | | An Implicit TA database can be disabled. | 543 | | | 544 | | Section 3.1, Section 3.3.1, Section 3.6.2 | 545 | | and Security Considerations | 546 +--------------+----------------------------------------------------+ 548 Figure 4 550 3.1. Application Layer 552 The EST client MUST be capable of generating and parsing Simple PKI 553 messages (see Section 4.2). Generating and parsing Full PKI messages 554 is OPTIONAL (see Section 4.3). The client MUST also be able to 555 request CA certificates from the EST server and parse the returned 556 "bag" of certificates (see Section 4.1). Requesting CSR attributes 557 and parsing the returned list of attributes is OPTIONAL (see 558 Section 4.5). 560 Details of the EST client application configuration are out of scope 561 of the protocol discussion but are necessary for understanding the 562 prerequisites of initiating protocol operations. The EST client is 563 RECOMMENDED to be configured with TA databases for Section 3.3.1 or 564 with a secret key for Section 3.3.3. Implementations conforming to 565 this standard MUST provide the ability to designate Explicit TAs. 566 For human usability reasons a "fingerprint" of an Explicit TA 567 database entry can be configured for bootstrapping as discussed in 568 Section 4.1.1. Configuration of an Implicit TA database, perhaps by 569 its inclusion within the EST client distribution or available from 570 the operating system, provides flexibility along with the caveats 571 detailed in Section 7. Implementations conforming to this standard 572 MUST provide the ability to disable use of any Implicit TA database. 574 The EST client is configured with sufficient information to form the 575 EST server URI. This can be the full operation path segment (e.g. 576 https://www.example.com/.well-known/est/ or 577 https://www.example.com/.well-known/est/arbitraryLabel1) or the EST 578 client can be configured with a tuple composed of the authority 579 portion of the URI along with the OPTIONAL label (e.g. 580 "www.example.com:80", "arbitraryLabel1") or just the authority 581 portion of the URI. 583 3.2. HTTP Layer 585 HTTP is used to transfer EST messages. URIs are defined for handling 586 each media type (i.e., message type) as described in Section 3.2.2. 587 HTTP is also used for client authentication services when TLS client 588 authentication is not available, due to lack of a client certificate 589 suitable for use by TLS (see Section Section 3.2.3). HTTP 590 authentication can also be used in addition to TLS client 591 authentication if the EST server wishes additional authentication 592 information, as noted in Section 2.2.3. Registered media types are 593 used to convey EST messages as specified in Figure 6. 595 HTTP 1.1 [RFC2616] and above support persistent connections. As 596 described in Section 8.1 of that RFC, persistent connections may be 597 used to reduce network and processing load associated with multiple 598 HTTP requests. EST does not require or preclude persistent HTTP 599 connections and their use is out of scope of this specification. 601 3.2.1. HTTP headers for control 603 This document profiles the HTTP content-type header (as defined in 604 [RFC2046], but see Figure 6 for specific values) to indicate the 605 media type for EST messages and to specify control messages for EST. 606 The HTTP Status value is used to communicate success or failure of an 607 EST function. HTTP authentication is used by a client when requested 608 by the server. 610 The media types indicated in the HTTP content-type header indicates 611 which EST message is being transferred. Media types used by EST are 612 specified in Section 3.2.4. 614 3.2.2. HTTP URIs for control 616 The EST server MUST use the [RFC5785] defined path-prefix of "/.well- 617 known/" and the registered name of "est". Thus a valid EST server 618 URI path begins with "https://www.example.com/.well-known/est". Each 619 EST operation is indicated by a path-suffix that indicates the 620 intended operation: 622 Operations and their corresponding URIs: 623 +------------------------+-----------------+-------------------+ 624 | Operation |Operation Path | Details | 625 +========================+=================+===================+ 626 | Distribution of CA | /CACerts | Section 4.1 | 627 | certificates (MUST) | | | 628 +------------------------+-----------------+-------------------+ 629 | Enrollment of new | /simpleEnroll | Section 4.2. | 630 | clients (MUST) | | | 631 +------------------------+-----------------+-------------------+ 632 | Re-Enrollment of | /simpleReEnroll | Section 4.2.2 | 633 | existing clients (MUST)| | | 634 +------------------------+-----------------+-------------------+ 635 | Full CMC (OPTIONAL) | /fullCMC | Section 4.3 | 636 +------------------------+-----------------+-------------------+ 637 | Server-side Key | /serverKeyGen | Section 4.4 | 638 | Generation (OPTIONAL) | | | 639 +------------------------+-----------------+-------------------+ 640 | Request CSR attributes | /CSRAttrs | Section 4.5 | 641 | (OPTIONAL) | | | 642 +------------------------+-----------------+-------------------+ 644 Figure 5 646 The operation path (Figure 5) is appended to the path-prefix to form 647 the URI used with HTTP GET or POST to perform the desired EST 648 operation. An example valid URI absolute path for the "/CACerts" 649 operation is "/.well-known/est/CACerts". To retrieve the CA's 650 certificates, the EST client would use the following HTTP request: 652 GET /.well-known/est/CACerts HTTP/1.1 654 Likewise, to request a new certificate in this example scheme, the 655 EST client would use the following request: 657 POST /.well-known/est/simpleEnroll HTTP/1.1 659 The use of distinct operation paths simplifies implementation for 660 servers that do not perform client authentication when distributing 661 /CACerts responses. 663 An EST server MAY provide service for multiple CAs as indicated by an 664 OPTIONAL additional path segment between the registered application 665 name and the operation path. To avoid conflict the CA label MUST NOT 666 be the same as any defined operation path segment. The EST server 667 MUST provide services when the additional path segment is not 668 included. The following are three example valid URIs: 670 1. https://www.example.com/.well-known/est/CACerts 672 2. https://www.example.com/.well-known/est/arbitraryLabel1/CACerts 674 3. https://www.example.com/.well-known/est/arbitraryLabel2/CACerts 676 In this specification the distinction between enroll and renew/rekey 677 is explicitly indicated by the HTTP URI. When requesting /fullCMC 678 operations CMC uses the same messages for certificate renewal and 679 certificate rekey. 681 An EST server MAY provide additional services using other URIs. 683 3.2.3. HTTP-Based Client Authentication 685 The EST server MAY request HTTP-based client authentication. This 686 request can be in addition to successful TLS client authentication 687 (Section 3.3.2) if EST server policy requires additional 688 authentication. (For example the EST server may require that an EST 689 client "knows" a password in addition to "having" an existing client 690 certificate). Or HTTP-based client authentication can be an EST 691 server policy specified fallback in situations where the EST client 692 did not successfully complete the TLS client authentication. (This 693 might arise if the EST client is enrolling for the first time or if 694 the certificates available to an EST client cannot be used for TLS 695 client authentication). 697 HTTP Basic and Digest authentication MUST only be performed over TLS 698 1.1 [RFC4346] or later versions. As specified in CMC: Transport 699 Protocols [RFC5273] the server "MUST NOT assume client support for 700 any type of HTTP authentication such as cookies, Basic 701 authentication, or Digest authentication". Clients SHOULD support 702 the Basic and Digest authentication mechanism. 704 Servers that wish to use Basic and Digest authentication reject the 705 HTTP request using the HTTP defined WWW-Authenticate response-header 706 ([RFC2616], Section 14.47). The client is expected to retry the 707 request, including the appropriate Authorization Request Header 708 ([RFC2617], Section 3.2.2), if the client is capable of using the 709 Basic or Digest authentication. If the client is not capable of 710 retrying the request or it is not capable of Basic or Digest 711 authentication, then the client MUST terminate the connection. 713 A client MAY set the username to the empty string ("") if it is 714 presenting a password that is not associated with a username. 716 Support for HTTP-based client authentication has security 717 ramifications as discussed in Section 7. The client MUST NOT respond 718 to the server's HTTP authentication request unless the client has 719 authenticated the EST server (as per Section 3.6). 721 3.2.4. Message types 723 This document uses existing media types for the messages as specified 724 by [RFC2585], [RFC5967], and CMC [RFC5272]. To support distribution 725 of multiple certificates for a CA certificate path, the [RFC2046] 726 multipart/mixed media type is used. 728 For consistency with [RFC5273], each distinct EST message type uses 729 an HTTP Content-Type header with a specific media type. 731 The EST messages and their corresponding media types are: 733 +--------------------+--------------------------+-------------------+ 734 | Message type |Request media type | Request section(s)| 735 | |Response media type(s) | Response section | 736 | |Source(s) of types | | 737 +====================+==========================+===================+ 738 | CA certificate | N/A | Section 4.1 | 739 | request | application/pkcs7-mime | Section 4.1.1 | 740 | | [RFC5751] | | 741 +--------------------+--------------------------+-------------------+ 742 | Cert enroll/renew/ | application/pkcs10 | Section 4.2/4.2.1 | 743 | rekey | application/pkcs7-mime | Section 4.2.2 | 744 | | [RFC5967] [RFC5751] | | 745 +--------------------+--------------------------+-------------------+ 746 | Full CMC | application/pkcs7-mime | Section 4.3.1 | 747 | | application/pkcs7-mime | Section 4.3.2 | 748 | | [RFC5751] | | 749 +--------------------+--------------------------+-------------------+ 750 | Server-side Key | application/pkcs10 | Section 4.4.1 | 751 | Generation | multipart/mixed | Section 4.4.2 | 752 | | (application/pkcs7-mime &| | 753 | | application/pkcs8) | | 754 | | [RFC5967] [RFC5751] & | | 755 | | [RFC5958] | | 756 +--------------------+--------------------------+-------------------+ 757 | Request CSR | N/A | Section 4.5.1 | 758 | attributes | application/csrattrs | Section 4.5.2 | 759 | | This RFC | | 760 +--------------------+--------------------------+-------------------+ 762 Figure 6 764 3.3. TLS Layer 766 TLS provides authentication, which in turn enables authorization 767 decisions. The EST server and EST client are responsible for 768 ensuring that an acceptable cipher suite is negotiated and that 769 bidirectional authentication has been performed. Alternately, 770 certificate-less TLS authentication, where neither the client nor 771 server present a certificate, is also an acceptable method for EST 772 mutual authentication. 774 HTTPS [RFC2818] specifies how HTTP messages are carried over TLS. 775 HTTPS MUST be used. TLS 1.1 [RFC4346] (or a later version) MUST be 776 used TLS session resumption [RFC5077] SHOULD be supported. 778 TLS channel binding information MAY be inserted into a certificate 779 request as detailed in Section 3.5 in order to provide the EST server 780 with assurance that the authenticated TLS client has access to the 781 private key for the certificate being requested. 783 3.3.1. TLS-Based Server Authentication 785 The EST server MUST be authenticated during the TLS handshake unless 786 the client is requesting Bootstrap Distribution of CA certificates 787 (Section 4.1.1) or Full CMC (Section 4.3). 789 The EST client authenticates the EST server as defined for the cipher 790 suite negotiated. The following text provides details assuming a 791 certificate-based cipher suite, such as the TLS 1.1 [RFC4346] 792 mandatory cipher suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA). As an 793 alternative to authentication using a certificate, an EST client MAY 794 support certificate-less TLS authentication (Section 3.3.3). 796 Certificate validation MUST be performed as per [RFC5280]. The EST 797 server certificate MUST conform to the [RFC5280] certificate profile. 799 The client validates the TLS server certificate using the EST client 800 Explicit and, if enabled, Implicit TA database(s). The client MUST 801 maintain a distinction between the use of Explicit and Implicit TA 802 databases during authentication in order to support proper 803 authorization. The EST client MUST perform authorization checks as 804 specified in Section 3.6. 806 If certificate validation fails, the client MAY follow the procedure 807 outlined in Section 4.1.1 for bootstrap distribution of CA 808 certificates. 810 3.3.2. TLS-Based Client Authentication 812 TLS client authentication is the RECOMMENDED method for identifying 813 EST clients. HTTP-Based Client Authentication (Section 3.2.3) MAY be 814 used. 816 The EST server authenticates the EST client as defined for the cipher 817 suite negotiated. The following text provides details assuming a 818 certificate-based cipher suite such as the TLS 1.1 [RFC4346] 819 mandatory cipher suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA). The EST 820 server MUST support certificate based client authentication. As an 821 alternative or as an addition to authentication using a certificate, 822 an EST server MAY support certificate-less TLS authentication 823 (Section 3.3.3). 825 Generally, the client will use an existing certificate for renew or 826 rekey operations. If the certificate to be renewed or rekeyed is 827 appropriate for the negotiated cipher suite, then the client MUST use 828 it for the TLS handshake, otherwise the client SHOULD use an 829 alternate certificate that is suitable for the cipher suite and 830 contains the same subject identity information. When requesting an 831 enroll operation the client MAY use a third-party issued client 832 certificate to authenticate itself. 834 Certificate validation MUST be performed as per [RFC5280]. The EST 835 client certificate MUST conform to the [RFC5280] certificate profile. 837 The server validates the TLS server certificate using the EST server 838 Explicit and, if enabled, Implicit TA database(s). The server MUST 839 maintain a distinction between the use of Explicit and Implicit TA 840 databases during authentication in order to support proper 841 authorization. 843 The EST server MUST perform authorization checks as specified in 844 Section 3.7. 846 If a client does not support TLS client authentication, then it MUST 847 support HTTP-based client authentication (Section 3.2.3) or 848 certificate-less TLS authentication (Section 3.3.3). 850 3.3.3. Certificate-less TLS Mutual Authentication 852 Certificate-less TLS cipher suites provide a way to perform mutual 853 authentication in situations where neither the client nor server have 854 certificates, do not desire to use certificates, or do not have the 855 trust anchors necessary to verify a certificate. The client and 856 server MAY negotiate a certificate-less cipher suite for mutual 857 authentication. 859 When using certificate-less mutual authentication in TLS for 860 enrollment, the cipher suite MUST be based on a protocol that is 861 resistant to dictionary attack and MUST be based on a zero knowledge 862 protocol. TLS-SRP ciphersuites listed in section 2.7 of [RFC5054] 863 are suitable for this purpose. Section 7 lists the characteristics 864 of a ciphersuite that are suitable for use in certificate-less mutual 865 authentication for 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 the server requires the 888 mechanism specified in this section be used by the client. This 889 specification provides an OPTIONAL method of linking identity and 890 proof-of-possession by including information specific to the current 891 authenticated TLS session within the signed certification request. 892 The client can determine if the server requires the linking of 893 identity and PoP by examining the CSR Attributes Response (see 894 Section 4.5.2). Regardless of the CSR Attributes Response, clients 895 are RECOMMENDED to link identity and PoP by embedding tls-unique 896 information in the certification request. If tls-unique information 897 is included by the client, the server MUST verify it. The EST server 898 MAY reject requests without tls-unique information as indicated by 899 server 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] Section 6.3- 906 defined "Linking Identity and POP information" method available if 907 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). If tls- 924 unique information is not embedded within the certification request 925 the challenge-password field MUST be empty to indicate that the 926 client did not include the optional channel-binding information (any 927 value submitted is verified by the server as tls-unique information). 929 If the EST server makes use of a back-end infrastructure for 930 processing, it is RECOMMENDED that the results of this verification 931 be communicated. (For example this communication might use the CMC 932 "RA POP Witness Control" in a CMC Full PKI Request message. Or an 933 EST server might TLS authenticate an EST client as being a trusted 934 infrastructure element that does not forward invalid requests. A 935 detailed discussion of back-end processing is out of scope). 937 When rejecting requests, the EST server response is as described for 938 all enroll responses (Section 4.2.3). If a Full PKI Response is 939 included, the CMCFailInfo MUST be set to popFailed. If a human 940 readable reject message is included it SHOULD include an informative 941 text message indicating that linking of identity and POP information 942 is required. 944 3.6. Server Authorization 946 The client MUST check EST server authorization before accepting any 947 server responses or responding to HTTP authentication requests. 949 The EST client authorization method depends on which method was used 950 to authenticate the server. When the Explicit TA database is used to 951 authenticate the EST server then Section 3.6.1 applies. When the 952 Implicit TA database is used to authenticate the EST server then 953 Section 3.6.2 applies. Successful authentication using a 954 certificate-less cipher suite implies authorization of the server. 956 The client MAY perform bootstrapping as specified in Section 4.1.1 957 even if these checks fail. 959 3.6.1. Client use of Explicit TA Database 961 When the EST client Explicit TA database is used to validate the EST 962 server certificate the client MUST check either the configured URI 963 against the server's identity, or the EST server certificate MUST 964 contain the id-kp-cmcRA [RFC6402] extended key usage extension. 966 3.6.2. Client use of Implicit TA Database 968 When the EST client Implicit TA database is used to validate the EST 969 server certificate, the client MUST check the URI "against the 970 server's identity as presented in the server's Certificate message" 971 (HTTP Over TLS Section 3.1 "Server Identity" [RFC2818] and 973 [RFC6125]). The provisioned URI provides the basis for 974 authorization, and the server's authenticated identity confirms it is 975 the authorized server. 977 3.7. Client Authorization 979 The decision to issue a certificate to a client is always controlled 980 by local CA policy. The EST server configuration reflects this CA 981 policy. This document does not specify any constraints on such 982 policy. EST provides the EST server access to each client's 983 authenticated identity -- e.g., the TLS client's certificate in 984 addition to any HTTP user authentication credentials -- to help in 985 implementing such policy. 987 If the client's certificate was issued by the EST CA, and it includes 988 the id-kp-cmcRA [RFC6402] extended key usage extension, then the 989 client is a Registration Authority (RA) as described in [RFC5272] and 990 [RFC6402]. In this case the EST server SHOULD apply authorization 991 policy consistent with an RA client. For example when handling 992 /simpleEnroll requests the EST server could be configured to accept 993 PoP linking information that does not match the current TLS session 994 because the authenticated EST client RA has verified this information 995 when acting as an EST server (as specified in Section 3.5). More 996 specific RA mechanisms are available if the EST client uses /fullCMC 997 methods. 999 4. Protocol Exchange Details 1001 Before processing a request, an EST server determines if the client 1002 is authorized to receive the requested services. Likewise, the 1003 client determines if it will make requests to the EST server. These 1004 authorization decisions are described in the next two sections. 1005 Assuming that both sides of the exchange are authorized, then the 1006 actual operations are as described in subsequent sections. 1008 4.1. Distribution of CA certificates 1010 The EST client can request a copy of the current CA certificates. 1011 This function is generally performed before other EST functions. 1013 4.1.1. Bootstrap Distribution of CA certificates 1015 It is possible that the client was not configured with the TA 1016 database(s) necessary to validate the EST server certificate. This 1017 section describes a method by which minimally configured EST clients 1018 can populate their Explicit TA database. 1020 If the EST client application does not specify either an Explicit TA 1021 database or a Implicit TA database then the initial TLS server 1022 authentication and authorization will fail. The client MAY 1023 provisionally continue the TLS handshake to completion for the 1024 purposes of accessing the /CACerts or /fullCMC method. If the EST 1025 client continues with an unauthenticated connection, the client MUST 1026 extract the HTTP content data from the response (Section 4.1.3 or 1027 Section 4.3.2) and engage a human user to authorize the CA 1028 certificate using out-of-band data such as a CA certificate 1029 "fingerprint" (e.g., a SHA-256 or SHA-512 [SHS] hash on the whole CA 1030 certificate). In a /fullCMC response it is the Publish Trust Anchors 1031 control within the Full PKI Response that must be accepted manually. 1032 It is incumbent on the user to properly verify the TA information, or 1033 to provide the "fingerprint" data during configuration that is 1034 necessary to verify the TA information. 1036 HTTP authentication requests MUST NOT be responded to if the server 1037 has not been authenticated. 1039 The EST client uses the /CACerts response to establish an Explicit 1040 Trust Anchor database for subsequent TLS authentication of the EST 1041 server. EST clients MUST NOT engage in any other protocol exchange 1042 until after the /CACerts response has been accepted and a new TLS 1043 session has been established (using TLS certificate-based 1044 authentication). 1046 4.1.2. CA certificates request 1048 EST clients request the EST CA TA database information of the CA (in 1049 the form of certificates) with an HTTPS GET message using an 1050 operation path of "/CACerts". EST clients and servers MUST support 1051 the /CACerts function. Clients SHOULD request an up-to-date response 1052 before stored information has expired in order to ensure the EST CA 1053 TA database is up to date. 1055 The EST server MUST NOT require client authentication or 1056 authorization to reply to this request. 1058 The client MUST authenticate the EST server as specified in 1059 Section 3.3.1 and Section 3.3.3 and check the server's authorization 1060 as given in Section 3.6 or follow the procedure outlined in 1061 Section 4.1.1. 1063 4.1.3. CA certificates response 1065 If successful, the server response MUST have an HTTP 200 response 1066 code. Any other response code indicates an error and the client MUST 1067 abort the protocol. 1069 A successful response MUST be a certs-only CMC Simple PKI Response, 1070 as defined in [RFC5272], containing the certificates described in the 1071 following paragraph. The HTTP content-type of "application/ 1072 pkcs7-mime" is used. The Simple PKI response is sent with a Content- 1073 Transfer-Encoding of "base64" [RFC2045]. 1075 The EST server MUST include the current root CA certificate in the 1076 response. The EST server MUST include any additional certificates 1077 the client would need to build a chain from an EST CA issued 1078 certificate to the current EST CA TA. For example if the EST CA is a 1079 subordinate CA then all the appropriate subordinate CA certificates 1080 necessary to build a chain to the root EST CA are included in the 1081 response. 1083 The EST server SHOULD include the three "Root CA Key Update" 1084 certificates OldWithOld, OldWithNew, and NewWithOld in the response 1085 chain. These are defined in Section 4.4 of CMP [RFC4210]. The EST 1086 client MUST be able to handle these certificates in the response. 1087 The EST CA's most recent self-signed certificate (e.g. NewWithNew 1088 certificate) is self-signed and has the latest NotAfter date. If the 1089 EST server does not include these in the response then after the 1090 current EST CA certificate expires the EST clients will need to be 1091 reinitialized with the PKI using the Bootstrap Distribution of CA 1092 certificates (Section 4.1.1) method, which involves user interaction. 1094 After out-of-band validation occurs, all the other certificates MUST 1095 be validated using normal [RFC5280] certificate path validation 1096 (using the most recent CA certificate as the TA) before they can be 1097 used to build certificate paths during certificate validation. 1099 The EST client MUST store the extracted EST CA certificate as an 1100 Explicit TA database entry for subsequent EST server authentication. 1101 The EST client SHOULD disable use of Implicit TA database entries for 1102 this EST server, now that an Explicit TA database entry is available. 1103 If the client disables the Implicit TA database, and if the EST 1104 server certificate was verified using an Implicit TA database entry, 1105 then the client MUST include the "Trusted CA Indication" extension in 1106 future TLS sessions [RFC4366]. This indicates to the server that 1107 only an EST Server certificate authenticatable by the Explicit TA 1108 database entry is now acceptable (otherwise the EST server might 1109 continue to use a server certificate that is only verifiable by a now 1110 disabled Implicit TA). 1112 The EST client SHOULD also make the CA Certificate response 1113 information available to the end-entity software for use when 1114 validating peer certificates. 1116 4.2. Client Certificate Request Functions 1118 EST clients request a certificate from the EST server with an HTTPS 1119 POST using the operation path value of "/simpleEnroll". EST clients 1120 request a renew/rekey of existing certificates with an HTTP POST 1121 using the operation path value of "/simpleReEnroll". EST servers 1122 MUST support the /simpleEnroll and /simpleReEnroll functions. 1124 It is RECOMMENDED that a client obtain the current CA certificates, 1125 as described in Section 4.1, before performing certificate request 1126 functions. This ensures that the client will be able to validate the 1127 EST server certificate. The client MUST authenticate the EST server 1128 as specified in Section 3.3.1 and Section 3.3.3. The client MUST 1129 verify the authorization the EST server as specified in Section 3.6. 1131 The server MUST authenticate the client as specified in Section 3.3.2 1132 and Section 3.3.3. The server MUST verify client authorization as 1133 specified in Section 3.7. The EST server MUST check the tls-unique 1134 value as described in Section 3.5 if one is submitted by the client. 1136 The server MAY accept a certificate request for manual authorization 1137 checking by an administrator. (Section 4.2.3 describes the use of an 1138 HTTP 202 response to the EST client if this occurs). 1140 4.2.1. Simple Enrollment of Clients 1142 When HTTPS POSTing to /simpleEnroll the client MUST include a Simple 1143 PKI Request as specified in CMC Section 3.1 (i.e., a PKCS#10 1144 Certification Request). 1146 The Certification Signing Request (CSR) signature provides proof-of- 1147 possession of the private key to the EST server. If the CSR KeyUsage 1148 extension indicates the private key can be used to generate digital 1149 signatures then the CSR signature MUST be generated using the private 1150 key. If the key can be used to generate digital signatures but the 1151 requested CSR KeyUsage extension prohibits generation of digital 1152 signatures then the CSR signature MUST still be generated using the 1153 private key but the key MUST NOT be used to for any other signature 1154 operations (this is consistent with the recommendations concerning 1155 submission of proof-of-possession to an RA or CA as described in 1156 [SP-800-57-Part-1]). The use of /fullCMC operations provides access 1157 to more advanced proof-of-possession methods that MUST be used when 1158 the key pair can not be used for digital signature generation (see 1159 Section 4.3). 1161 The HTTP content-type of "application/pkcs10" is used here. The 1162 format of the message is as specified in [RFC5967] with a Content- 1163 Transfer-Encoding of "base64" [RFC2045]. 1165 The EST client MAY request additional certificates even when using an 1166 existing certificate in the TLS client authentication. For example 1167 the client can use an existing certificate for TLS client 1168 authentication when requesting a certificate that cannot be used for 1169 TLS client authentication. 1171 4.2.2. Simple Re-Enrollment of Clients 1173 EST clients renew/rekey certificates with an HTTPS POST using the 1174 operation path value of "/simpleReEnroll". 1176 A certificate request employs the same format as the "simpleEnroll" 1177 request, using the same HTTP content-type. The request Subject field 1178 and SubjectAltName extension MUST be identical to the corresponding 1179 fields in the certificate being renewed/rekeyed. The 1180 ChangeSubjectName attribute, as defined in [RFC6402], MAY be included 1181 in the CSR to request that these fields be changed in the new 1182 certificate. 1184 If the Subject Public Key Info in the certification request is the 1185 same as the current client certificate, the EST server performs a 1186 renew operation. If the public key information is different than the 1187 currently issued certificate then the EST server performs a rekey 1188 operation. 1190 4.2.3. Simple Enroll and Re-Enroll Response 1192 If the enrollment is successful, the server response MUST contain an 1193 HTTP 200 response code with a content-type of "application/ 1194 pkcs7-mime". 1196 A successful response MUST be a certs-only CMC Simple PKI Response, 1197 as defined in [RFC5272], containing only the certificate that was 1198 issued. The HTTP content-type of "application/pkcs7-mime" is used. 1199 The Simple PKI response is sent with a Content-Transfer-Encoding of 1200 "base64" [RFC2045]. 1202 When rejecting a request the server MUST specify either an HTTP 4xx 1203 error, or an HTTP 5xx error. A Simple PKI Response with an HTTP 1204 content-type of "application/pkcs7-mime" (see Section 4.3.2) MAY be 1205 included in the response data to convey an error response. If the 1206 content-type is not set the response data MUST be a plain text human- 1207 readable error message containing informative information describing 1208 why the request was rejected (for example indicating that CSR 1209 attributes are incomplete). 1211 If the server responds with an HTTP [RFC2616] 202, this indicates 1212 that the request has been accepted for processing but that a response 1213 is not yet available. The server MUST include a Retry-After header 1214 as defined for HTTP 503 responses. The server also MAY include 1215 informative human-readable content. The client MUST wait at least 1216 the specified 'retry-after' time before repeating the same request. 1217 The client repeats the initial enrollment request after the 1218 appropriate 'retry-after' interval has expired. The client SHOULD 1219 log or inform the end user of this event. The server is responsible 1220 for maintaining all state necessary to recognize and handle retry 1221 operations as the client is stateless in this regard; it simply sends 1222 the same request repeatedly until it receives a different response 1223 code. 1225 All other return codes are handled as specified in HTTP [RFC2616]. 1227 The EST client MAY also make the certificate response, and associated 1228 private key, available to end-entity software for use as an end- 1229 entity certificate. 1231 4.3. Full CMC 1233 An EST client can request a certificate from an EST server with an 1234 HTTPS POST using the operation path value of "/fullCMC". Support for 1235 the /fullCMC function is OPTIONAL for both clients and servers. 1237 4.3.1. Full CMC Request 1239 If the HTTP POST to /fullCMC is not a valid Full PKI Request, the 1240 server MUST reject the message. The HTTP content-type used is 1241 "application/pkcs7-mime", as specified in [RFC5273]. The body of the 1242 message is the binary value of the encoding of the PKI Request with a 1243 Content-Transfer-Encoding of "base64" [RFC2045]. 1245 4.3.2. Full CMC Response 1247 If the enrollment is successful, the server response MUST include an 1248 HTTP 200 response code with a content-type of "application/ 1249 pkcs7-mime" as specified in [RFC5273]. The response data includes 1250 either the Simple PKI Response or the Full PKI Response as specified 1251 in Section 3.2 of [RFC5272]. The body of the message is the binary 1252 value of the encoding of the PKI Response with a Content-Transfer- 1253 Encoding of "base64" [RFC2045]. 1255 When rejecting a request, the server MUST specify either an HTTP 4xx 1256 error or an HTTP 5xx error. A CMC response with content-type of 1257 "application/pkcs7-mime" SHOULD be included in the response data for 1258 any CMC error response. If the content-type is not set the response 1259 data MUST be a plain text human-readable error message containing 1260 informative information describing why the request was rejected (for 1261 example indicating that CSR attributes are incomplete). 1263 All other return codes are handled as specified in Section 4.2.3 or 1264 HTTP [RFC2616]. For example, a client interprets an HTTP 404 or 501 1265 response to indicate that this service is not implemented. 1267 4.4. Server-side Key Generation 1269 An EST client may request a private key and associated certificate 1270 from an EST server using an HTTPS POST with an operation path value 1271 of "/serverKeyGen". Support for the /serverKeyGen function is 1272 OPTIONAL. 1274 A client MUST authenticate and authorize an EST server as specified 1275 in Section 3.3.1, Section 3.6, and Section 3.3.3. 1277 The EST server MUST authenticate and authorize the client as 1278 specified in Section 3.3.2, Section 3.7, and Section 3.3.3. The EST 1279 server applies whatever authorization or logic it chooses to 1280 determine if the private key and certificate should be provided. 1282 Proper random number and key generation [RFC4086] is a server 1283 implementation responsibility and server storage of generated keys is 1284 a local option. The key pair and certificate are transferred over 1285 the TLS session. The cipher suite used to return the private key and 1286 certificate MUST offer confidentiality commensurate with the private 1287 key being delivered to the client. 1289 The EST client MAY request additional certificates even when using an 1290 existing certificate in the TLS client authentication. For example 1291 the client can use an existing certificate for TLS client 1292 authentication when requesting a certificate that cannot be used for 1293 TLS client authentication. 1295 4.4.1. Server-side Key Generation Request 1297 The certificate request is HTTPS POSTed and is the same format as for 1298 the "/simpleEnroll" and "/simpleReEnroll" path extensions with the 1299 same content-type and transfer encoding. 1301 In all respects the server SHOULD treat the CSR as it would any 1302 enroll or re-enroll CSR; the only distinction here is that the server 1303 MUST ignore the public key values and signature in the CSR. These 1304 are included in the request only to allow re-use of existing 1305 codebases for generating and parsing such requests. 1307 If the client desires to receive the private key with encryption that 1308 exists outside and in addition to that of the TLS transport used by 1309 EST or if server policy requires that the key be delivered in such a 1310 form, the client MUST include an attribute in the CSR indicating the 1311 encryption key to be used. Both symmetric and asymmetric encryption 1312 are supported as described in the following subsections. 1314 4.4.1.1. Requests for Symmetric Key Encryption of the Private Key 1316 To specify a symmetric encryption key to be used to encrypt the 1317 server-generated private key, the client MUST include a 1318 DecryptKeyIdentifier attribute (as defined in Section 2.2.5, 1319 [RFC4108]) specifying the identifier of the secret key to be used by 1320 the server to encrypt the private key. While that attribute was 1321 originally designated for specifying a firmware encryption key, it 1322 exactly mirrors the requirements for specifying a secret key to 1323 encrypt a private key. If the server does not have a secret key 1324 matching the identifier specified by the client, the request must be 1325 terminated and an error returned to the client. Distribution of the 1326 key specified by the DecryptKeyIdentifer to the key generator and the 1327 client is outside the scope of this document. 1329 4.4.1.2. Requests for Asymmetric Encryption of the Private Key 1331 To specify an asymmetric encryption key to be used to encrypt the 1332 server-generated private key, the client MUST include an 1333 AsymmetricDecryptKeyIdentifier attribute. The 1334 AsymmetricDecryptKeyIdentifier attribute is defined as: 1336 id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= { 1337 id-pkix TBD } 1339 The asymmetric-decrypt-key-identifier attribute values have ASN.1 1340 type AsymmetricDecryptKeyIdentifier: 1342 AsymmetricDecryptKeyIdentifier ::= OCTET STRING 1344 If the server does not have a public key matching the identifier 1345 specified by the client, the request must be terminated and an error 1346 returned to the client. Distribution of the key specified by the 1347 AysmmetricDecryptKeyIdentifer to the key generator and the client is 1348 outside the scope of this document. 1350 4.4.2. Server-side Key Generation Response 1352 If the request is successful, the server response MUST have an HTTP 1353 200 response code with a content-type of "multipart/mixed" consisting 1354 of two parts. One part is the private key data and the other part is 1355 the certificate data. 1357 The format in which the private key data part is returned is 1358 dependent on whether the private key is being returned with 1359 additional encryption on top of that provided by TLS. 1361 If additional encryption is not being employed, the private key data 1362 MUST be placed in an "application/pkcs8". An "application/pkcs8" 1363 part consists of the base 64-encoded DER-encoded PrivateKeyInfo with 1364 a Content-Transfer-Encoding of "base64" [RFC2045]. 1366 If additional encryption is being employed, the private key is placed 1367 inside of a CMS SignedData. The SignedData is signed by the party 1368 that generated the private key, which may or may not be the EST 1369 server or the EST CA. The SignedData is further protected inside of 1370 a CMS EnvelopedData, as described in Section 4 of [RFC5958]. The 1371 following list shows how the EncryptedData is used, depending on the 1372 type of protection key specified by the client. 1374 o If the client specified a symmetric encryption key to protect the 1375 server-generated private key, the EnvelopedData content is 1376 encrypted using the secret key identified in the request. The 1377 EnvelopedData RecipientInfo field MUST indicate the ori (Other 1378 Recipient Info) key management technique. The oriType will be 1379 set to TBD and the oriValue will be set to TBD. 1381 o If the client specified an asymmetric encryption key suitable for 1382 key transport operations to protect the server-generated private 1383 key, the EnvelopedData content is encrypted using a randomly- 1384 generated symmetric encryption key. The cryptographic strength 1385 of the symmetric encryption key SHOULD be equivalent to the 1386 client-specified asymmetric key. The EnvelopedData RecipientInfo 1387 field MUST indicate the ktri (KeyTransRecipientInfo) key 1388 management technique. The KeyTransRecipInfo carries the random 1389 symmetric encryption key wrapped in the asymmetric key. The rid 1390 (recipient identification) field in the KeyTransRecipInfo MUST be 1391 ignored by the client. 1393 o If the client specified an asymmetric encryption key suitable for 1394 key agreement operations to protect the server-generated private 1395 key, the EnvelopedData content is encrypted using a randomly- 1396 generated symmetric encryption key. The cryptographic strength 1397 of the symmetric encryption key SHOULD be equivalent to the 1398 client-specified asymmetric key. The EnvelopedData RecipientInfo 1399 field MUST indicate the kari (KeyAgreeRecipientInfo) key 1400 management technique. The RecipientEncryptedKey carries the 1401 random symmetric encryption key encrypted in the key derived from 1402 the key agreement process. The rid (recipient identification) 1403 field in the RecipientEncryptedKey field and the 1404 KeyAgreeRecipientIdentifier field MUST be ignored by the client. 1406 In all three additional encryption cases, the EnvelopedData is 1407 returned in the response as an "application/pkcs7-mime" part with a 1408 Content-Transfer-Encoding of "base64". 1410 The certificate data part is an "application/pkcs7-mime" and exactly 1411 matches the certificate response to /simpleEnroll. If both parts are 1412 "application/pkcs7-mime" the client checks each; one will be a certs- 1413 only Simple PKI response and the other will be the CMS message with 1414 the encrypted data. 1416 When rejecting a request, the server MUST specify either an HTTP 4xx 1417 error, or an HTTP 5xx error. If the content-type is not set, the 1418 response data MUST be a plain text human-readable error message. 1420 4.5. CSR Attributes 1422 CA policy may allow inclusion of client-provided attributes in 1423 certificates that it issues, and some of these attributes may 1424 describe information that is not available to the CA. In addition, a 1425 CA may desire to certify a certain type of public key and a client 1426 may not have a priori knowledge of that fact. Therefore, clients 1427 SHOULD request a list of expected attributes that are required, or 1428 desired, by the CA in an enrollment request, or if dictated by local 1429 policy. 1431 Requesting CSR Attributes is optional but clients are advised that 1432 CA's may refuse enrollment requests that are not encoded according to 1433 the CA's policy. 1435 4.5.1. CSR Attributes Request 1437 The EST client requests a list of CA-desired CSR attributes from the 1438 CA by sending an HTTPS GET message to the EST server with an 1439 operations path of "/CSRAttrs". 1441 4.5.2. CSR Attributes Response 1443 If locally configured policy for an authenticated EST client 1444 indicates a CSR Attributes Response is to be provided, the server 1445 response MUST include an HTTP 200 response code. An HTTP response 1446 code of 204 or 404 indicates that a CSR Attributes Response is not 1447 available. Regardless of the response code, the EST server and CA 1448 MAY reject any subsequent enrollment requests for any reason, e.g., 1449 incomplete CSR attributes in the request. 1451 If the CA requires a particular crypto system (e.g., certification of 1452 a public key based on a certain elliptic curve) it MUST provide that 1453 information in the CSR Attributes response. If an EST server 1454 requires the linking of identity and PoP information (see 1455 Section 3.5) it MUST include the challengePassword OID in the CSR 1456 Attributes response. 1458 Responses to attribute request messages MUST be encoded as content- 1459 type of "application/csrattrs" with a Content-Transfer-Encoding of 1460 "base64" [RFC2045]. The syntax for application/csrattrs body is as 1461 follows: 1463 Csrattrs ::= SEQUENCE SIZE (0..MAX) OF OBJECT IDENTIFIER { } 1465 An EST server includes zero or more object identifiers that it 1466 requests the client to include in a certification request. When the 1467 server encodes Csrattrs as an empty SEQUENCE it means that the server 1468 has no specific additional attributes it requests in a client 1469 certification request (this is functionally equivalent to an HTTP 1470 response code of 204 or 404.) The sequence is Distinguished Encoding 1471 Rules (DER) encoded and then base 64 encoded (section 4 of 1472 [RFC4648]). The resulting text forms the application/csrattr body, 1473 without headers. 1475 For example, if a CA requests a client to submit a certification 1476 request containing the Media Access Control (MAC) address [RFC2397] 1477 of a device, the challengePassword (indicating that Linking of 1478 Identity and POP information is requested, see Section 3.5), to use 1479 the the secp384r1 elliptic curve, and to use the SH384 hash function 1480 then it sends the following object identifiers: 1482 o macAddress: 1.3.6.1.1.1.1.22 1484 o challengePassword: 1.2.840.113549.1.9.7 1486 o the secp384r1 elliptic curve: 1.3.132.0.34 1488 o the SHA384 hash function: 2.16.840.1.101.3.4.2.2 1490 and encodes them into an ASN.1 SEQUENCE to produce: 1492 30 26 06 07 2B 06 01 01 01 01 16 06 09 2A 86 48 86 F7 0D 01 09 07 1493 06 05 2B 81 04 00 22 06 09 60 86 48 01 65 03 04 02 02 1495 and then base 64 encodes the resulting ASN.1 SEQUENCE to produce: 1497 MCYGBysGAQEBARYGCSqGSIb3DQEJBwYFK4EEACIGCWCGSAFlAwQCAg== 1499 The EST client parses the OID's in the response and handles each OID 1500 independently. When an OID indicates a known descriptive CSR 1501 attribute type, the client SHOULD include the requested information 1502 in the subsequent CSR that it submits, either in the CSR attributes 1503 or in any other appropriate CSR field. When an OID indicates a 1504 particular way to generate the CSR, the client SHOULD generate its 1505 CSR according to the parsed OID. When an OID is of an unknown type 1506 the OID MUST be ignored by the client. 1508 5. Contributors/Acknowledgements 1510 The editors would like to thank Stephen Kent, Vinod Arjun, Jan 1511 Vilhuber, Sean Turner, Russ Housley, and others for their feedback 1512 and prototypes of early drafts. Our thanks also go the authors of 1513 [RFC6403] around whose document we structured part of this 1514 specification. 1516 6. IANA Considerations 1518 There is one OID in Section 4.4.1.2 that needs to be registered in 1519 the PKIX Arc. 1521 IANA is requested to register the following: 1523 IANA SHALL update the well-known URI registry with the following 1524 filled-in template from [RFC5785]. 1526 URI suffix: est 1528 Change controller: IETF 1530 IANA SHALL update the Application Media Types registry with the 1531 following filled-in template from [RFC4288]. 1533 The media subtype for Attributes in a CertificationRequest is 1534 application/csrattrs. 1536 Type name: application 1538 Subtype name: csrattrs 1540 Required parameters: None 1542 Optional parameters: None 1544 Encoding considerations: binary; 1546 Security Considerations: 1548 Clients request a list of attributes that servers wish to be in 1549 certification requests. The request/response SHOULD be done in 1550 a TLS-protected tunnel. 1552 Interoperability considerations: None 1554 Published specification: This memo. 1556 Applications which use this media type: 1558 Enrollment over Secure Transport (EST) 1560 Additional information: 1562 Magic number(s): None 1564 File extension: None 1566 Macintosh File Type Code(s): 1568 Person & email address to contact for further information: 1570 Dan Harkins 1572 Restrictions on usage: None 1574 Author: Dan Harkins 1576 Intended usage: COMMON 1578 Change controller: The IESG 1580 7. Security Considerations 1582 Support for Basic authentication as specified in HTTP [RFC2617] 1583 allows the server access to a client's cleartext password. This 1584 provides support for legacy username/password databases but requires 1585 exposing the plaintext password to the EST server. Use of a PIN or 1586 one-time-password can help mitigate such exposure, but it is 1587 RECOMMENDED that EST clients use such credentials only once to obtain 1588 a client certificate (that will be used during future interactions 1589 with the EST server). 1591 When a client uses the Implicit TA database for certificate 1592 validation (see Section 3) then authorization proceeds as specified 1593 in Section 3.6.2. In this situation, the client has validated the 1594 server as being a certified-by-a-third-party responder for the URI 1595 configured, but cannot verify that the responder is authorized to act 1596 as an RA for the PKI in which the client is trying to enroll. 1597 Clients using an implicit trust anchor database are RECOMMENDED to 1598 only use TLS-based client authentication (to prevent exposing HTTP- 1599 based Client Authentication information). It is RECOMMENDED that 1600 such clients include "Linking Identity and POP information" 1601 (Section 3.5) in requests (to prevent such requests from being 1602 forwarded to a real EST server by a MITM). It is RECOMMENDED that 1603 the implicit trust anchor database used for EST server authentication 1604 be carefully managed, to reduce the chance of a third-party CA with 1605 poor certification practices from being trusted. Disabling the 1606 implicit trust anchor database after succesfully recieving the 1607 Distribution of CA Certificates response (Section 4.1.3) limits any 1608 vulnerability to the first TLS enchange. 1610 Certificate-less TLS ciphersuites that maintain security and perform 1611 the mutual authentiation necessary for enrollment have the following 1612 properties: 1614 o the only information leaked by an active attack is whether a 1615 single guess of the secret is correct or not. 1617 o any advantage an adversary gains is through interaction and not 1618 compuation. 1620 o it is possible to perform countermeasures, such as exponential 1621 backoff after a certain number of failed attempts, to frustrate 1622 repeated active attacks. 1624 Using a certificate-less ciphersuite that does not have the 1625 properties listed above would render the results of enrollment void 1626 and potentially result in certificates being issued to 1627 unauthenticated and/or unauthorized entities. 1629 When using a certificate-less TLS cipher suite, the shared secret 1630 used for authentication and authorization cannot be shared with an 1631 entity that is not a party to the exchange: someone other than the 1632 client and the server. Any additional sharing of secrets voids the 1633 security afforded by a certificate-less cipher suite. Exposure of a 1634 shared secret used by a certificate-less cipher suite to a third- 1635 party enables client impersonation that can results in corruption of 1636 a client's trust anchor database. 1638 As described in CMC Section 6.7, "For keys that can be used as 1639 signature keys, signing the certification request with the private 1640 key serves as a POP on that key pair". The inclusion of tls-unique 1641 within the certification request links the proof-of-possession to the 1642 TLS proof-of-identity by enforcing that the POP operation occurred 1643 while the TLS session was active. This implies to the server that 1644 the authenticated client currently has access to the private key. If 1645 the authenticated client is known to have specific capabilities, such 1646 as hardware protection for authentication credentials and key 1647 storage, this implication is strengthened but not proven. 1649 The server-side key generation method allows keys to be transported 1650 over the TLS connection to the client. The distribution of private 1651 key material is inherently risky. Private key distribution uses the 1652 encryption mode of the negotiated TLS cipher suite. Keys are not 1653 protected by preferred key wrapping methods such as AES Key Wrap 1654 [RFC3394] or as specified in [RFC5958] as encryption of the private 1655 key beyond that provided by TLS is optional. It is RECOMMEND that 1656 EST servers not support this operation by default. It is RECOMMENDED 1657 that clients not request this service unless there is a compelling 1658 operational benefit. Use of an implicit trust anchor database is NOT 1659 RECOMMENDED when server-side key generation is employed. The use of 1660 an encrypted CMS Server-side Key Generation Response is RECOMMENDED. 1662 Regarding the CSR attributes that the CA may list for inclusion in an 1663 enrollment request, there are no real inherent security issues with 1664 the content being conveyed but an adversary who is able to interpose 1665 herself into the conversation could exclude attributes that a server 1666 may want, include attributes that a server may not want, and render 1667 meaningless other attributes that a server may want. 1669 8. References 1671 8.1. Normative References 1673 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1674 April 1992. 1676 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1677 Extensions (MIME) Part One: Format of Internet Message 1678 Bodies", RFC 2045, November 1996. 1680 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1681 Extensions (MIME) Part Two: Media Types", RFC 2046, 1682 November 1996. 1684 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1685 Requirement Levels", BCP 14, RFC 2119, March 1997. 1687 [RFC2314] Kaliski, B., "PKCS #10: Certification Request Syntax 1688 Version 1.5", RFC 2314, March 1998. 1690 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 1691 Infrastructure Operational Protocols: FTP and HTTP", 1692 RFC 2585, May 1999. 1694 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1695 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1696 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1698 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1699 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1700 Authentication: Basic and Digest Access Authentication", 1701 RFC 2617, June 1999. 1703 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1705 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 1706 Classes and Attribute Types Version 2.0", RFC 2985, 1707 November 2000. 1709 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1710 Request Syntax Specification Version 1.7", RFC 2986, 1711 November 2000. 1713 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1714 Resource Identifier (URI): Generic Syntax", STD 66, 1715 RFC 3986, January 2005. 1717 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1718 Requirements for Security", BCP 106, RFC 4086, June 2005. 1720 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 1721 Protect Firmware Packages", RFC 4108, August 2005. 1723 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1724 "Internet X.509 Public Key Infrastructure Certificate 1725 Management Protocol (CMP)", RFC 4210, September 2005. 1727 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1728 Registration Procedures", RFC 4288, December 2005. 1730 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1731 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1733 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1734 and T. Wright, "Transport Layer Security (TLS) 1735 Extensions", RFC 4366, April 2006. 1737 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1738 Encodings", RFC 4648, October 2006. 1740 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 1741 "Using the Secure Remote Password (SRP) Protocol for TLS 1742 Authentication", RFC 5054, November 2007. 1744 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1745 "Transport Layer Security (TLS) Session Resumption without 1746 Server-Side State", RFC 5077, January 2008. 1748 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 1749 (CMC)", RFC 5272, June 2008. 1751 [RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS 1752 (CMC): Transport Protocols", RFC 5273, June 2008. 1754 [RFC5274] Schaad, J. and M. Myers, "Certificate Management Messages 1755 over CMS (CMC): Compliance Requirements", RFC 5274, 1756 June 2008. 1758 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1759 Housley, R., and W. Polk, "Internet X.509 Public Key 1760 Infrastructure Certificate and Certificate Revocation List 1761 (CRL) Profile", RFC 5280, May 2008. 1763 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1764 RFC 5652, September 2009. 1766 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 1767 "Transport Layer Security (TLS) Renegotiation Indication 1768 Extension", RFC 5746, February 2010. 1770 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1771 Mail Extensions (S/MIME) Version 3.2 Message 1772 Specification", RFC 5751, January 2010. 1774 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 1775 Uniform Resource Identifiers (URIs)", RFC 5785, 1776 April 2010. 1778 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 1779 for TLS", RFC 5929, July 2010. 1781 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 1782 August 2010. 1784 [RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, 1785 August 2010. 1787 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1788 Verification of Domain-Based Application Service Identity 1789 within Internet Public Key Infrastructure Using X.509 1790 (PKIX) Certificates in the Context of Transport Layer 1791 Security (TLS)", RFC 6125, March 2011. 1793 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 1794 Updates", RFC 6402, November 2011. 1796 [SHS] National Institute of Standards and Technology, "Federal 1797 Information Processing Standard Publication 180-4: Secure 1798 Hash Standard (SHS)", March 2012, . 1801 [X.680] ITU-T Recommendation, "ITU-T Recommendation X.680 Abstract 1802 Syntax Notation One (ASN.1): Specification of basic 1803 notation", November 2008, 1804 . 1806 [X.690] ITU-T Recommendation, "ITU-T Recommendation X.690 ASN.1 1807 encoding rules: Specification of Basic Encoding Rules 1808 (BER), Canonical Encoding Rules (CER) and Distinguished 1809 Encoding Rules (DER)", November 2008, 1810 . 1812 8.2. Informative References 1814 [IDevID] IEEE Std, "IEEE 802.1AR Secure Device Identifier", 1815 December 2009, . 1818 [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, 1819 August 1998. 1821 [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher 1822 Suites to Transport Layer Security (TLS)", RFC 2712, 1823 October 1999. 1825 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 1826 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 1828 [RFC6403] Zieglar, L., Turner, S., and M. Peck, "Suite B Profile of 1829 Certificate Management over CMS", RFC 6403, November 2011. 1831 [SP-800-57-Part-1] 1832 National Institute of Standards and Technology, 1833 "Recommendation for Key Management - Part 1: General 1834 (Revision 3)", July 2012, . 1838 [X.520] ITU-T Recommendation, "ITU-T Recommendation X.520 The 1839 Directory: Selected attribute types", November 2008, 1840 . 1842 Appendix A. Operational Scenario Example Messages 1844 (informative) 1846 This section expands on the Operational Scenario Overviews by 1847 providing detailed examples of the messages at each TLS layer. 1849 A.1. Obtaining CA Certificates 1851 The following is an example of a valid /CACerts exchange. 1853 During the initial TLS handshake the client can ignore the optional 1854 server generated "certificate request" and can instead proceed with 1855 the HTTP GET request: 1857 GET /CACerts HTTP/1.1 1858 User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 OpenS 1859 SL/0.9.8b zlib/1.2.3 libidn/0.6.5 1860 Host: 127.0.0.1:8085 1861 Accept: */* 1863 In response the server provides the current CA certificates: 1864 HTTP/1.1 200 OK 1865 Status: 200 OK 1866 Content-Type: application/pkcs7-mime 1867 Content-Transfer-Encoding: base64 1868 Content-Length: 4181 1870 MIIMCQYJKoZIhvcNAQcCoIIL+jCCC/YCAQExADALBgkqhkiG9w0BBwGgggvcMIIC 1871 6DCCAdCgAwIBAgIJAOp44LEB7buwMA0GCSqGSIb3DQEBBQUAMBsxGTAXBgNVBAMT 1872 EGVzdEV4YW1wbGVDQSBPd08wHhcNMTMwMzIwMjI1NTMwWhcNMTQwMzIwMjI1NTMw 1873 WjAbMRkwFwYDVQQDExBlc3RFeGFtcGxlQ0EgT3dPMIIBIjANBgkqhkiG9w0BAQEF 1874 AAOCAQ8AMIIBCgKCAQEA3fJbVP2x1kDpCqMGgMS5YIsP1CeINHM6yuaS/PLgtcxw 1875 Wr07XUZPypgo6HTwYKTksmYZ5q4NObmRtjUYTRBO0OimKweNkv+peDJ7K7ItxrW9 1876 nCFE4MapAJI3ZmOnBOVMglHL+5vRq7PD+m65zTz++8FSkEpVPfIxNkakw263EIl/ 1877 i3otp97J9z8fY6ep0kTLGpKaNC/gBeprX74IZEW2mynrkaVDFPIJr2iaPmc/H4pN 1878 wU82DVcES6PI13mxH+aMVCfrz/CZzqgwY6bNtVHV3mI6XEUTcnzABtAO4rqm5YTm 1879 xQrOH5fTCPHXDYFRHF+DOCIhWXgXSl4wv30iUT+/IwIDAQABoy8wLTAMBgNVHRME 1880 BTADAQH/MB0GA1UdDgQWBBSnQZgJxiXNt/pNMgOcDzZ7W1foODANBgkqhkiG9w0B 1881 AQUFAAOCAQEAA1N9Xsu86NZgkhfpOQi2iouXRrFeW7dsr4UkFxwjnCdFTV7RQ/XR 1882 MKvAmW6QyBf4kYd0iLt+iRY9EA9aS7cZutLVK0MezYqWO5yfr1MnWu9jcyMsnT5g 1883 KFJ11MKtgMmXfOHCZ6e5L8PzIJ0q40NVb6hrPasZK84ew12Gb23GN2FUeSucCFlc 1884 CuiOLpaMYtS60gwd8B3Nbg4Kptvbv113SeIKie3RsIMZxhbTD2htBQ6Y3TeDF1ea 1885 Hq9wLJIwggBlPy7Isp+gyp1uB++RU3J4xn1WI6BAdUM7FiZ+JaVnJOwK0SO1px7L 1886 qyzfzwL0D1cIQz7MeRK/9URKKTyjoSUm3jCCAv4wggHmoAMCAQICAQEwDQYJKoZI 1887 hvcNAQEFBQAwGzEZMBcGA1UEAxMQZXN0RXhhbXBsZUNBIE93TzAeFw0xMzAzMjAy 1888 MjU1MzFaFw0xNDAzMjAyMjU1MzFaMBsxGTAXBgNVBAMTEGVzdEV4YW1wbGVDQSBO 1889 d08wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4Qnq1DrvZea5fx/gG 1890 IAveDvI3GXb9uAMm443EAdSiIZSiWU3A7tT0uA+BC/Ddn9iWja8m3YDP9+zAcaEJ 1891 iZZFLa+s+7yOPS6UwrIxMvDzevHT/hEae4eDrs+dDysjcEr0YGk78EPL5jCISeLX 1892 8sGn+vt/CV03H8rx5iUAFMnK5gaTWBQJbYu3RAPXUptEOOM7Skcx/DObrmQNd8B0 1893 GJgW4bZcIjMt5VIBM7FKTTF70Re8hy05FPFSp6yzCmjXpuox6vKke1ISOzWE3zw2 1894 lAjKv7wtVu4THBAk+0jcrZFsCxnvlaQXFhHhMwYvEbfq9+KRT5xb3zjhtpd54wNp 1895 sw09AgMBAAGjTTBLMAkGA1UdEwQCMAAwHQYDVR0OBBYEFI5rJ3wKlAo28FkeRGZ0 1896 5C8QQmyhMB8GA1UdIwQYMBaAFKdBmAnGJc23+k0yA5wPNntbV+g4MA0GCSqGSIb3 1897 DQEBBQUAA4IBAQBd03qDjEYiOtaFA6i7U6PF+ZUEl2Z0+vvtT/jIlpbCOXO2M54v 1898 Do6FFYe7YzF+XkG5ZqquMIgzSGR53GNkUPjTJZ/DHzRn1garcVGnr8rsk/+PPDvZ 1899 vqLc5SGQBk9KfZMV0oMOqlvioFP3oxdWwyyhJ2cY2qbP1s9uGSXg5uPmBKbboX7G 1900 P13bEoApMRr49nfPNMtiIs6BU7tyurPG2/mCcN1BX4P365CxqMAB2krP9mAhxYaA 1901 e98XLBz3yQ8CaMoAjX+B6fXzf30e5s7F3Nd8S5G4vsC92Iugre+yPyp6afQsjcbU 1902 pqvP/16M1z22ZKfoXkfoCyLbggLPGbI6MSVEMIIC/jCCAeagAwIBAgIBAjANBgkq 1903 hkiG9w0BAQUFADAbMRkwFwYDVQQDExBlc3RFeGFtcGxlQ0EgTndOMB4XDTEzMDMy 1904 MDIyNTUzMVoXDTE0MDMyMDIyNTUzMVowGzEZMBcGA1UEAxMQZXN0RXhhbXBsZUNB 1905 IE93TjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN3yW1T9sdZA6Qqj 1906 BoDEuWCLD9QniDRzOsrmkvzy4LXMcFq9O11GT8qYKOh08GCk5LJmGeauDTm5kbY1 1907 GE0QTtDopisHjZL/qXgyeyuyLca1vZwhRODGqQCSN2ZjpwTlTIJRy/ub0auzw/pu 1908 uc08/vvBUpBKVT3yMTZGpMNutxCJf4t6Lafeyfc/H2OnqdJEyxqSmjQv4AXqa1++ 1909 CGRFtpsp65GlQxTyCa9omj5nPx+KTcFPNg1XBEujyNd5sR/mjFQn68/wmc6oMGOm 1910 zbVR1d5iOlxFE3J8wAbQDuK6puWE5sUKzh+X0wjx1w2BURxfgzgiIVl4F0peML99 1911 IlE/vyMCAwEAAaNNMEswCQYDVR0TBAIwADAdBgNVHQ4EFgQUp0GYCcYlzbf6TTID 1912 nA82e1tX6DgwHwYDVR0jBBgwFoAUjmsnfAqUCjbwWR5EZnTkLxBCbKEwDQYJKoZI 1913 hvcNAQEFBQADggEBAKriJh0+BtoHOhCMVshYt8Org80jCMIDY1KYuXJO9avg2P/l 1914 bQOQ2ED+qE8xmUf6T/h/yv2550ICUJ98KY3xCUsATHcX6b5vOENlC3N/STtUrVPG 1915 33sN+daU5NwsciUnMl3SoqeZRHSJDopNORsslFF2Av4+A7hkeaER9oNzP+Jj5sEC 1916 t5/1jOtKu7YxZnMOUOqXoYXa4R8cI50iMQxdd32z8d+eJRgxd66YS5+MzOL/Wc4o 1917 nP3rvkpk820kRTELAk61Dv/xjpa05cyxTJtRvQwNxQMdgHaFKYd9owStHFMZuBI3 1918 mBH3V0jq4IAYVTQzBfhDmaGh230/WabUcYOgtXIwggLoMIIB0KADAgECAgkAxzoD 1919 SD8/y/gwDQYJKoZIhvcNAQEFBQAwGzEZMBcGA1UEAxMQZXN0RXhhbXBsZUNBIE53 1920 TjAeFw0xMzAzMjAyMjU1MzFaFw0xNDAzMjAyMjU1MzFaMBsxGTAXBgNVBAMTEGVz 1921 dEV4YW1wbGVDQSBOd04wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4 1922 Qnq1DrvZea5fx/gGIAveDvI3GXb9uAMm443EAdSiIZSiWU3A7tT0uA+BC/Ddn9iW 1923 ja8m3YDP9+zAcaEJiZZFLa+s+7yOPS6UwrIxMvDzevHT/hEae4eDrs+dDysjcEr0 1924 YGk78EPL5jCISeLX8sGn+vt/CV03H8rx5iUAFMnK5gaTWBQJbYu3RAPXUptEOOM7 1925 Skcx/DObrmQNd8B0GJgW4bZcIjMt5VIBM7FKTTF70Re8hy05FPFSp6yzCmjXpuox 1926 6vKke1ISOzWE3zw2lAjKv7wtVu4THBAk+0jcrZFsCxnvlaQXFhHhMwYvEbfq9+KR 1927 T5xb3zjhtpd54wNpsw09AgMBAAGjLzAtMAwGA1UdEwQFMAMBAf8wHQYDVR0OBBYE 1928 FI5rJ3wKlAo28FkeRGZ05C8QQmyhMA0GCSqGSIb3DQEBBQUAA4IBAQAjhssE+fXi 1929 RW+c8+ORpHaYOYS/o+O9Ui60W1kkK0TSKDoeJD7z7BWdIoj1hNbahQZOO8AzSulY 1930 knNVdonCC3AtPuBYndnPulF0cQifKEQCZDx00IkPr6+0o60aX4kWRBRiavzaHdqJ 1931 /+xL0K/P1NlIdkbx93Xb8/XLQ01wOBCFSmPmQ22k/Of+EydB+nteGsYvIoCuxsBw 1932 ZBKUMX//tKi2BUTS31WA6IRAolTL8V5IgyYP8Ub0M4n/fr5/tqzCjw5aiJ1ga4ED 1933 yrpd9XSBO3Og5/AWtr3BCaWkY8fiRt9ZcSmTWRWL84nAELGZEuEKODA4WMdY76TF 1934 Rs8Se9pRkVgxoQAxAA== 1936 A.2. Enroll/ReEnroll 1938 The following is an example of a valid /simpleEnroll exchange. The 1939 data messages for /simpleReEnroll are similar. 1941 During this exchange the EST client uses an out-of-band distributed 1942 username/password to authenticate itself to the EST server. This is 1943 the normal HTTP WWW-Authenticate behavior and is included here for 1944 informative purposes. When an existing TLS client certificate is 1945 used the server might skip requesting the HTTP WWW-Authenticate 1946 header, such as during a /simpleReEnroll operation. 1948 During the initial TLS handshake the client can ignore the optional 1949 server generated "certificate request" and can instead proceed with 1950 the HTTP POST request. In response to the initial HTTP POST attempt 1951 the server requests WWW-Authenticate from the client (this might 1952 occur even if the client used a client certificate, as detailed in 1953 the normative text above): 1954 HTTP/1.1 401 Unauthorized 1955 Content-Length: 0 1956 WWW-Authenticate: Digest qop="auth", realm="estrealm", 1957 nonce="1363821319" 1959 In the subsequent HTTP POST the username/password is included, along 1960 with the complete application/pkcs10 content: 1962 POST /.well-known/est/simpleEnroll HTTP/1.1 1963 Authorization: Digest username="estuser", realm="estrealm", nonc 1964 e="1363821164", uri="/.well-known/est/simpleEnroll", cnonce="MDY 1965 2OTcz", nc=00000002, qop="auth", response="93731653b26bd4693de10 1966 2745c294769" 1967 User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenS 1968 SL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 1969 Host: 127.0.0.1:8085 1970 Accept: */* 1971 Content-Type: application/pkcs10 1972 Content-Transfer-Encoding: base64 1973 Content-Length: 882 1975 MIIChjCCAW4CAQAwQTElMCMGA1UEAxMccmVxIGJ5IGNsaWVudCBpbiBkZW1vIHN0 1976 ZXAgMjEYMBYGA1UEBRMPUElEOldpZGdldCBTTjoyMIIBIjANBgkqhkiG9w0BAQEF 1977 AAOCAQ8AMIIBCgKCAQEA4Pw1JvjhOFL87eMmhIA/bXDORRItgxRZwq6FEQ3cWQvO 1978 wiA52hiAfrh/vQZFxIO/d44msbSxwbnG61aOEohhQgijUUGn2VxDi5S2xKUZAxnF 1979 +UfIP7PpZFg5c6aGO94ZFg6gT8iI0nRtXvd/T272sTY7n8GTKHfWhzv1nUV11DOz 1980 hWG57UC5+rfSqjNhiqtRsHM94emXR7rtjtfqY6KFN08x/z5CFKq+EmI5+1GmyUmb 1981 zfiCiFejgSULvHqtuMtVuqyaUDWKil0VRbFu0QK3oy5GiIsC4qwoguDRHsW7yO4E 1982 5BOLgK9n5PldpJNdEjyEgS7+dl5MD0nI5j2/pfeFkQIDAQABoAAwDQYJKoZIhvcN 1983 AQEFBQADggEBAKyuduqjuFc9INrFzvXSz1ZXU68FZtrmlaMfYRbk0xKbVAbB9dwe 1984 /NmkPQCQWGpiVyXo4rKgclcenlOYuFRbFGOxzprO9x0b99NNMP2bZscIUf0f6Xhb 1985 FXoGb6mFpft2HU4U1/hLmjOzBPeOOrcYrYqPTlDd+iniIMPTMn2ytP7ph6YEhc9S 1986 6W4O2VrBQQVhefoPh36MU4PvUF4+pbiPWkDzLvjTg01FB5rz3ECVVyodDgzVSeIT 1987 f3JxhMaYnfxcQ0ELdhhgSxcQhnfFSqc/k7LiAWE0yzUFJj3qilPBRJ2Q+uqA74Ct 1988 WHSWUBnkq5W4ZKpmxaqFxeZKy/Eyapyqwuk= 1990 The ESTserver uses the username/password to perform authentication/ 1991 authorization and responds with the issued certificate: 1993 HTTP/1.1 200 OK 1994 Status: 200 OK 1995 Content-Type: application/pkcs7-mime 1996 Content-Transfer-Encoding: base64 1997 Content-Length: 1162 1999 MIIDVQYJKoZIhvcNAQcCoIIDRjCCA0ICAQExADALBgkqhkiG9w0BBwGgggMoMIID 2000 JDCCAgygAwIBAgIBGjANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBlc3RFeGFt 2001 cGxlQ0EgTndOMB4XDTEzMDMyMDIzMTUxOVoXDTE0MDMyMDIzMTUxOVowQTElMCMG 2002 A1UEAxMccmVxIGJ5IGNsaWVudCBpbiBkZW1vIHN0ZXAgMjEYMBYGA1UEBRMPUElE 2003 OldpZGdldCBTTjoyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4Pw1 2004 JvjhOFL87eMmhIA/bXDORRItgxRZwq6FEQ3cWQvOwiA52hiAfrh/vQZFxIO/d44m 2005 sbSxwbnG61aOEohhQgijUUGn2VxDi5S2xKUZAxnF+UfIP7PpZFg5c6aGO94ZFg6g 2006 T8iI0nRtXvd/T272sTY7n8GTKHfWhzv1nUV11DOzhWG57UC5+rfSqjNhiqtRsHM9 2007 4emXR7rtjtfqY6KFN08x/z5CFKq+EmI5+1GmyUmbzfiCiFejgSULvHqtuMtVuqya 2008 UDWKil0VRbFu0QK3oy5GiIsC4qwoguDRHsW7yO4E5BOLgK9n5PldpJNdEjyEgS7+ 2009 dl5MD0nI5j2/pfeFkQIDAQABo00wSzAJBgNVHRMEAjAAMB0GA1UdDgQWBBSxOOKP 2010 RyQb246sgl7MxX+t1fvpWzAfBgNVHSMEGDAWgBSOayd8CpQKNvBZHkRmdOQvEEJs 2011 oTANBgkqhkiG9w0BAQUFAAOCAQEAgTNqMhUL1p5TNHiH9McYZuhKF1gW3dLxYpnj 2012 QweZcnSq/cEr1/qRTmMoyb25OySPHzE7Puqh2M2KQb/LqsB/4G1wuQY7eeumOcd+ 2013 xwrC8ic+jZaxcNA0+PNXvMdP9JafHZqZVTgF9DoD8a0++7UzUnXG2zSgkN5bvgik 2014 kcAP/D4/4Y1PNFDnolCFg5qGRwCXkPxQU7k458OZI8KHWGXTf5p8Vdo91tVH3LwM 2015 e9qeUMS7U8vRtOLye9PsRQ0rsGX3XDATDD6cPvRaImQRDtD0Uludl5QGw3Dxa1FI 2016 5zziAdaLFFbfLx6D/HfHrRZe9OLtkPc+1X3LSITE94VEzHfsSqEAMQA= 2018 A.3. Server Key Generation 2020 The following is an example of a valid /serverKeyGen exchange. 2021 During this exchange the EST client authenticates itself using an 2022 existing certificate issued by the CA the EST server provides 2023 services for. 2025 The initial TLS handshake is identical to the enrollment example 2026 handshake. The HTTP POSTed message is: 2028 POST /.well-known/est/serverKeyGen HTTP/1.1 2029 User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenS 2030 SL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 2031 Host: 127.0.0.1:8085 2032 Accept: */* 2033 Content-Type: application/pkcs10 2034 Content-Transfer-Encoding: base64 2035 Content-Length: 898 2037 MIICkzCCAXsCAQAwTjEyMDAGA1UEAxMpc2VydmVyS2V5R2VuIHJlcSBieSBjbGll 2038 bnQgaW4gZGVtbyBzdGVwIDUxGDAWBgNVBAUTD1BJRDpXaWRnZXQgU046NTCCASIw 2039 DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL3VrdX1IaAcEhQepAtRoA3vhrl/ 2040 tVS7ANr8SfCEt6xLNG6YorHoF+jSSYc7bE4gPC1cPkVs8a/tpySnHglD3WdJiCi4 2041 o9ClCl8FZzvqpLS4YSpLEtcBQCBItDCaObJzJbyaxS7XnJUUbXd2vbjPla5P7m9R 2042 69LEx0pODY5v2m1ck/0zPUvQRbo61jiXKrzaD4ufYZlD90SZq8Z5Br3caP9GAK9m 2043 pf1MdoRpbz62r1+2IljfcVnGIktHy7pY3l8+UlengC3/UybmkKxuaiE8yFBYiImw 2044 iM9GrUSWQCWvrQrk11U9xodCRlLr6Ywe6G7Pb96Oyt2uHW1Qu2sdjR4Kqz8CAwEA 2045 AaAAMA0GCSqGSIb3DQEBBQUAA4IBAQAK6QaV4VgbeGm1tDPu1vX5H7Q6GzPwJZLK 2046 VwyvI3mLXA6vRAfcd20q0rJNddGL9A555L2dEuS4Qo3iqiPBh067M/TUvYU73dSl 2047 kLl0rmqw/Iocvs7LTv4DoCiElmQq2vMIK6IN3vUm96csvDB6WQbd3eqKyPeHlJQf 2048 HAKhpoAn2bls1OLssOmIcWwtZ00GbchIy9XDzJSXKI8EIxZOK1xQ3p5cRO0kNcx9 2049 /MbSg+/wjJ9Xk2DTUux2DOCskCbyc7sizZWF4+LPBtaJOihT5sZyVgEE03hCYAVv 2050 U8z1QKILkt7t7VpWj9GpSHqTWFAyIf4xtfsJwZQWhdsbyT3zZUxS 2052 Because the DecryptKeyIdentifier attribute is not included in the 2053 request the response does not include additional encryption beyond 2054 the TLS session. The EST server response is: 2055 HTTP/1.1 200 OK 2056 Status: 200 OK 2057 Content-Type: multipart/mixed ; boundary=estServerExampleBoundary 2058 Content-Length: 3211 2060 This is the preamble. It is to be ignored, though it 2061 is a handy place for estServer to include an explanatory note 2062 including contact or support information. 2063 --estServerExampleBoundary 2064 Content-Type: application/pkcs8 2065 Content-Transfer-Encoding: base64 2067 MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDUuonyyFBAQzHY 2068 QiHK7pLMc0jDR4LSKtTNQ+Ng9vNMy/PUoJscXKwJzy+D36oLteAKlwIlgAYWMjS6 2069 0VnNN5zLzA43xAIZy4n6yDiCjXNOKiC7S4zC4c5e1wZbOnkBhxVb0T2pZ+DqQHqN 2070 z0GoWv0KYm8g5gLsJs4yrUxMB5KuevXI4NE7hUoAciYncX7gkZsHANHVpx2nw0d4 2071 3fyLSs21t2vkFvUvDBSQYaXEhZczjf2Yx1riz/E0j9hKUVDVOgCOLYGUvt27MAwk 2072 XFiEtKSOHzuZq+cTjEHcRUXvFwJLjx1+tcssbLZKwbXHpGnCP5GY2eW5YwMToI23 2073 Gn6FYKoLAgMBAAECggEAHI0czrUL8FQUcI4PswjqMv6WGX+Tk1mkThh6gB0k8n29 2074 MCCOMPRPMtHX8r8mN4QlmcZCx32zU29RnHFUuDJqnP+6OMnZ7lRfJIWS8BLEEw2c 2075 bwbo0Y80/42kkMH8U7QprbUbrYz/pvEYgcf7a/kqVSZ4+9VjNwbOTgbsYpfxm/Eu 2076 HAJVqP6Xe6tJ3bamrWteyjGvCc7QmF54srok+sPBx8uWSwogUEaPAm/DQge0XMR4 2077 rEyuTsaxmk3LZcVRaS3A0GzIFpFlhP3v3tIS8vE/2d1XV//F6rgXS8x1AEAHl/lw 2078 dNvH6YJGyT1hP1GKaoK5Oa2E9GsAGvmLEx6PAz+AgQKBgQD5YrzfL5+GAqjYLBuy 2079 Sdrlwxom90C4TNoFbWil7LIEQ+M47cOa5n+lYeFcEC1i6NLZodWYHU9sJ7khf3kC 2080 zCzPs+tCVtgZdeEQ/gAYkZB5zWriFugrIS9cHOl1jUvA+VSfbBRRfUxw+XCJt411 2081 E+o1kv0Tj0s5fMHsmb2Akn/V+wKBgQDaXujfrBRRfPLv41aaS3LykjxQbYnVQVOh 2082 tEvJQ2vVkKO1gVCT1vV2fKcBW4yFp0IGfSIdPjJkqEW51PPNjiPVhMM4vczNoYa4 2083 MDL8oaTXqDjptj8Ud5n1HiEAF5tLzG+Q3Ym0ND4uZc0zJNja85FwJrqEkxoZviuj 2084 MN+qbO0PMQKBgBUfft3sm7dvHDwLKGFmjgruBpYMVUgHAmR5Suba8I0Z7vIQeYPy 2085 SBeK/dqdaCq7i7hxU7UprmN7zdt/f5F0F8uT8rZQwscNS/3zdbCfC7y1YHs783hL 2086 vEYyELgrOqJiu/8w2Vu5oDLlfdm8WVf0Ut8szxDMD1QUNBzFPN7aCcfnAoGALJDY 2087 F+Xnk6XbcqfD4eNqByVfF87zJUmaxtKj8ORImqJVNtK4XiOtnsvbzYQgjppO+EIL 2088 d0pdQHuzFzTluNq8Z3Qb33Wk2YaQlwCHN1XJ7ZVQYCoof4XVLthCReGLeRG05yy/ 2089 UL6kvhVapohrlWvGD8xnnmzjE8Pi5gAwdXibfNECgYEAviTObA3hGULCT4YZ33wQ 2090 BQjFV2ktUegkNofeTsdixYq+rBJp/KTb/YKSLsqTFfHxmFLDbEKl2hWLCmjQtqjb 2091 s8/XAffa5adeMV1uAcSM8M2ngJM9BNYPg7uD7odVfBgjT/CGUsq9/vYdN4xhqctp 2092 MRWeTA9hNk730g8tNnL92K4= 2093 --estServerExampleBoundary 2094 Content-Type: application/pkcs7-mime 2095 Content-Transfer-Encoding: base64 2097 MIIDQAYJKoZIhvcNAQcCoIIDMTCCAy0CAQExADALBgkqhkiG9w0BBwGgggMTMIID 2098 DzCCAfegAwIBAgIBGzANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBlc3RFeGFt 2099 cGxlQ0EgTndOMB4XDTEzMDMyMDIzMzkyOFoXDTE0MDMyMDIzMzkyOFowLDEqMCgG 2100 A1UEAxMhc2VydmVyc2lkZSBrZXkgZ2VuZXJhdGVkIHJlc3BvbnNlMIIBIjANBgkq 2101 hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1LqJ8shQQEMx2EIhyu6SzHNIw0eC0irU 2102 zUPjYPbzTMvz1KCbHFysCc8vg9+qC7XgCpcCJYAGFjI0utFZzTecy8wON8QCGcuJ 2103 +sg4go1zTiogu0uMwuHOXtcGWzp5AYcVW9E9qWfg6kB6jc9BqFr9CmJvIOYC7CbO 2104 Mq1MTAeSrnr1yODRO4VKAHImJ3F+4JGbBwDR1acdp8NHeN38i0rNtbdr5Bb1LwwU 2105 kGGlxIWXM439mMda4s/xNI/YSlFQ1ToAji2BlL7duzAMJFxYhLSkjh87mavnE4xB 2106 3EVF7xcCS48dfrXLLGy2SsG1x6Rpwj+RmNnluWMDE6CNtxp+hWCqCwIDAQABo00w 2107 SzAJBgNVHRMEAjAAMB0GA1UdDgQWBBRawN1+4APoSakGRwvD/6i2s+4pDDAfBgNV 2108 HSMEGDAWgBSOayd8CpQKNvBZHkRmdOQvEEJsoTANBgkqhkiG9w0BAQUFAAOCAQEA 2109 YtPAbK4t+sk2ec5svdiNgvK8nsXpyTaHUyX9shuMfTghL/sA6HoSL8y55Cq2pAC/ 2110 Ts+vLWvjeJoN8xH7F9lLjx74gFmq/oxkysYCXsc5VcD4Pw5ppQvAL0n52WgX6MZh 2111 GqbGIJykJGvg/FSjqrt4oGo/RQakPnB7dJY/fp9k27DV2nTTkISgPSUzDglM94yj 2112 AbktKu32LN1kv8mt8wBEl1cNUAA2ZpZmzp9fnMgaFNgZBqpbjg07SkgEu8NRcMA5 2113 ffE3BoMxMRCtGUznugNtlYnYzOVppaT7pkSSpdv8Lt4k3Zh5E/nRl1OERkHUxn7N 2114 f7pEl6EI99JfWRNHIXMXvKEAMQA= 2115 --estServerExampleBoundary-- 2116 This is the epilogue. It is also to be ignored. 2118 A.4. CSR Attributes 2120 The following is an example of a valid /CSRAttrs exchange. During 2121 this exchange the EST client authenticates itself using an existing 2122 certificate issued by the CA the EST server provides services for. 2124 The initial TLS handshake is identical to the enrollment example 2125 handshake. The HTTP GET request: 2126 GET /.well-known/est/CSRAttrs HTTP/1.1 2127 User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenS 2128 SL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 2129 Host: 127.0.0.1:8085 2130 Accept: */* 2132 In response the server provides suggested attributes that are 2133 appropriate for the authenticated client: 2134 HTTP/1.1 200 OK 2135 Status: 200 OK 2136 Content-Type: application/csrattrs 2137 Content-Transfer-Encoding: base64 2138 Content-Length: 57 2140 MCYGBysGAQEBARYGCSqGSIb3DQEJBwYFK4EEACIGCWCGSAFlAwQCAg== 2142 Authors' Addresses 2144 Max Pritikin (editor) 2145 Cisco Systems, Inc. 2146 510 McCarthy Drive 2147 Milpitas, CA 95035 2148 USA 2150 Email: pritikin@cisco.com 2152 Peter E. Yee (editor) 2153 AKAYLA, Inc. 2154 7150 Moorland Drive 2155 Clarksville, MD 21029 2156 USA 2158 Email: peter@akayla.com 2160 Dan Harkins (editor) 2161 Aruba Networks 2162 1322 Crossman Avenue 2163 Sunnyvale, CA 94089-1113 2164 USA 2166 Email: dharkins@arubanetworks.com