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