idnits 2.17.1 draft-ietf-pkix-est-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 12 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (October 22, 2012) is 4204 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) == Missing Reference: 'RFC5751' is mentioned on line 660, but not defined ** Obsolete undefined reference: RFC 5751 (Obsoleted by RFC 8551) == Missing Reference: 'CMC RFC6402' is mentioned on line 853, but not defined == Unused Reference: 'RFC2986' is defined on line 1470, but no explicit reference was found in the text == Unused Reference: 'RFC2925' is defined on line 1569, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 2314 (Obsoleted by RFC 2986) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Downref: Normative reference to an Informational RFC: RFC 2985 ** Downref: Normative reference to an Informational RFC: RFC 2986 ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 5077 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 5967 ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' -- Obsolete informational reference (is this intentional?): RFC 2925 (Obsoleted by RFC 4560) Summary: 14 errors (**), 0 flaws (~~), 7 warnings (==), 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: April 25, 2013 AKAYLA, Inc. 6 D. Harkins, Ed. 7 Aruba Networks 8 October 22, 2012 10 Enrollment over Secure Transport 11 draft-ietf-pkix-est-03 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 certificate(s) and associated Certification 21 Authority (CA) certificate(s). 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 25, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 59 2. Operational Scenario Overviews . . . . . . . . . . . . . . . . 5 60 2.1. Obtaining CA Certificates . . . . . . . . . . . . . . . . 6 61 2.2. Initial Enrollment . . . . . . . . . . . . . . . . . . . . 7 62 2.2.1. Previously Installed Client Certificate . . . . . . . 7 63 2.2.2. Username/Password Distributed Out-of-Band . . . . . . 7 64 2.3. Client Certificate Re-issuance . . . . . . . . . . . . . . 8 65 2.3.1. Re-issuance of Signature Certificates . . . . . . . . 8 66 2.3.2. Re-issuance of Key Exchange Certificates . . . . . . . 8 67 2.4. Server Key Generation . . . . . . . . . . . . . . . . . . 8 68 2.5. Full PKI Request messages . . . . . . . . . . . . . . . . 8 69 2.6. CSR (Certificate Signing Request) Attributes Request . . . 8 70 3. Protocol Design and Layering . . . . . . . . . . . . . . . . . 9 71 3.1. Application Layer Design . . . . . . . . . . . . . . . . . 12 72 3.2. HTTP Layer Design . . . . . . . . . . . . . . . . . . . . 12 73 3.2.1. HTTP headers for control . . . . . . . . . . . . . . . 12 74 3.2.2. HTTP URIs for control . . . . . . . . . . . . . . . . 13 75 3.2.3. HTTP-Based Client Authentication . . . . . . . . . . . 14 76 3.2.4. Message types . . . . . . . . . . . . . . . . . . . . 15 77 3.3. TLS Layer Design . . . . . . . . . . . . . . . . . . . . . 16 78 3.3.1. TLS for transport security . . . . . . . . . . . . . . 17 79 3.3.1.1. TLS-Based Server Authentication . . . . . . . . . 17 80 3.3.1.2. TLS-Based Client Authentication . . . . . . . . . 17 81 3.3.1.3. Certificate-less TLS Mutual Authentication . . . . 18 82 3.4. Proof-of-Possession . . . . . . . . . . . . . . . . . . . 18 83 3.5. Linking Identity and POP information . . . . . . . . . . . 18 84 4. Protocol Exchange Details . . . . . . . . . . . . . . . . . . 20 85 4.1. Server Authorization . . . . . . . . . . . . . . . . . . . 20 86 4.2. Client Authorization . . . . . . . . . . . . . . . . . . . 20 87 4.3. Distribution of CA certificates . . . . . . . . . . . . . 21 88 4.3.1. Distribution of CA certificates request . . . . . . . 21 89 4.3.2. Bootstrap Distribution of CA certificates . . . . . . 21 90 4.3.3. Distribution of CA certificates response . . . . . . . 22 91 4.4. Client Certificate Request Functions . . . . . . . . . . . 23 92 4.4.1. Simple Enrollment of Clients . . . . . . . . . . . . . 23 93 4.4.2. Simple Re-Enrollment of Clients . . . . . . . . . . . 24 94 4.4.3. Simple Enroll and Re-Enroll Response . . . . . . . . . 24 95 4.5. Full CMC . . . . . . . . . . . . . . . . . . . . . . . . . 25 96 4.5.1. Full CMC Request . . . . . . . . . . . . . . . . . . . 25 97 4.5.2. Full CMC Response . . . . . . . . . . . . . . . . . . 26 98 4.6. Server-side Key Generation . . . . . . . . . . . . . . . . 26 99 4.6.1. Server-side Key Generation Request . . . . . . . . . . 27 100 4.6.2. Server-side Key Generation Response . . . . . . . . . 27 101 4.7. CSR Attributes . . . . . . . . . . . . . . . . . . . . . . 28 102 4.7.1. CSR Attributes Request . . . . . . . . . . . . . . . . 28 103 4.7.2. CSR Attributes Response . . . . . . . . . . . . . . . 28 104 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 105 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31 106 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 107 7.1. Normative References . . . . . . . . . . . . . . . . . . . 32 108 7.2. Informative References . . . . . . . . . . . . . . . . . . 35 109 Appendix A. Operational Scenario Example Messages . . . . . . . . 36 110 A.1. Obtaining CA Certificates . . . . . . . . . . . . . . . . 36 111 A.2. Previously Installed Signature Certificate . . . . . . . . 37 112 A.3. Username/Password Distributed Out-of-Band . . . . . . . . 39 113 A.4. Re-Enrollment . . . . . . . . . . . . . . . . . . . . . . 42 114 A.5. Server Key Generation . . . . . . . . . . . . . . . . . . 43 115 A.6. CSR Attributes . . . . . . . . . . . . . . . . . . . . . . 47 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 118 1. Introduction 120 This document profiles certificate enrollment for clients using 121 Certificate Management over CMS (CMC) [RFC5272] messages over a 122 secure transport. Enrollment over Secure Transport (EST) describes 123 the use of TLS 1.1 [RFC4346] (or a later version) and HTTP 1.1 124 [RFC2616] to provide an authenticated and authorized channel for 125 Simple PKI Requests and Responses [RFC5272]. 127 Architecturally the EST service is located between a CA and the 128 client device. It performs several functions traditionally allocated 129 to the PKI role of the Registration Authority (RA). The nature of 130 the communication of EST server to CA is not described in this 131 document. 133 EST adopts the CMP [RFC4210] model for CA certificate rollover, but 134 does not use the CMP message syntax or protocol. EST servers are 135 extensible in that new functions may be defined to provide additional 136 capabilities not specified in CMC [RFC5272]. Non-CMC-based 137 extensions such as the requesting of Certificate Signing Request 138 attributes and requests for server generated keys are defined in this 139 document. 141 EST specifies the transferring of messages securely over HTTPS 142 [RFC2818] where the HTTP headers and content types are used in 143 conjunction with TLS. HTTPS operates over TCP; this document does 144 not specify EST over DTLS/UDP. Figure 1 shows how the layers build 145 upon each other. 147 EST Layering: 149 Protocols: 150 +--------------------------------------------+ 151 | | 152 | EST messages for request/response messages | 153 | | 154 +--------------------------------------------+ 155 | | 156 | HTTP for message transfer and signaling | 157 | | 158 +--------------------------------------------+ 159 | | 160 | TLS for transport security | 161 | | 162 +--------------------------------------------+ 163 | | 164 | TCP for transport | 165 | | 166 +--------------------------------------------+ 168 Figure 1 170 [[EDNOTE: Comments such as this one, included within double brackets 171 and initiated with an 'EDNOTE', are for editorial use and shall be 172 removed as the document is polished.]] 174 1.1. Terminology 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in [RFC2119]. 180 It is assumed that the reader is familiar with the terms and concepts 181 described in PKCS#10 [RFC2314], HTTPS [RFC2818], CMP [RFC4210], CMC 182 [RFC5272][RFC5273][RFC5274], and TLS [RFC5246]. 184 2. Operational Scenario Overviews 186 This section provides an informative overview of the operational 187 scenarios to better introduce the reader to the protocol discussion. 188 This section does not include [RFC2119] key words. 190 Both the EST clients and server are configured with information that 191 will be the basis of authentication and authorization. The specific 192 initialization data depends on the methods available in the client 193 device and server, but can include shared secrets, network service 194 names and locations (e.g. a URI [RFC3986]), trust anchor information 195 (e.g. current CA certificate or third party TA(s) or a hash of the 196 CA's root certificate), and enrollment keys and certificates. 197 Depending on the enterprise's acquisition and network management 198 practices, some initialization may be performed by the vendor prior 199 to client delivery. In that case, the client device vendor will 200 provide data, such as trust anchors, to the enterprise via a secure 201 procedural mechanism. The distribution of this initial information 202 is out of scope. 204 Distribution of trust anchors and certificates can be made through 205 the EST server. However, nothing can be inferred about the 206 authenticity of these trust anchors and certificates until an out-of- 207 band mechanism from the above list is used to verify them. 209 Sections 2.1-2.3 very closely mirror the text of the Scenarios 210 Appendix of [RFC6403] with such modifications as are appropriate for 211 this profile. (Our thanks are extended to the authors of that 212 document). More importantly, Sections 2.1-2.6 mirror the set of EST 213 functions (see Figure 4) and provide an informative overview of EST's 214 capabilities. 216 The client device begins by initiating a TLS-secured HTTP session 217 with the EST server. The specific EST service requested is named in 218 an operational URI portion. The client device and server 219 authenticate each other, and the client ascertains the authorization 220 of the server. The server ascertains the authorization of the client 221 and services the request. 223 2.1. Obtaining CA Certificates 225 The EST client can request a copy of the current CA certificates. 226 The EST client is assumed to perform this operation before performing 227 other operations. 229 The EST client authenticates and authorizes the EST server when 230 requesting the current CA certificates. As detailed in 231 Section 3.3.1.1 and Section 3.3.1.3) the available options include: 233 o Verifying the EST server's HTTPS URI against the EST server's 234 certificate using third party TAs (similar to a common HTTPS 235 exchange). This allows the EST server and client to leverage 236 existing TAs that might be known to the EST client. 238 o The client can leverage a previously distributed trust anchor 239 specific to the EST server. This allows the EST client to use an 240 existing, potentially older, CA certificate to request more recent 241 CA certificates. 243 o For bootstrapping the the EST client can accept manual 244 authentication performed by the end user as detailed in 245 Section 4.3.2. 247 Client authentication is not required for this exchange, so it is 248 trivially supported by the EST server. 250 2.2. Initial Enrollment 252 After authenticating an EST server and verifying that it is 253 authorized to provide services to the client, an EST client can 254 acquire a certificate by submitting an enrollment request to that 255 server. 257 The EST server authenticates and authorizes the EST client as 258 specified in Section 3.3.1.2 and Section 4.2. The methods described 259 in the normative text that are expanded on in this overview include: 261 o Previously installed certificate (e.g., Manufacturer Installed 262 Certificate or 3rd party issued certificate); 264 o Username/password distributed out-of-band 266 2.2.1. Previously Installed Client Certificate 268 If the EST client has a previously installed certificate that was 269 issued by a 3rd party this certificate can be used to authenticate 270 the client's request for a certificate from the EST server's CA. An 271 EST client responds to the EST server's TLS certificate request 272 message with the existing certificate (i.e., it provides the 273 previously issued certificate to the EST server). The EST server 274 will authenticate the client's existing certificate and authorize the 275 client's request as described in Section 3.3.1.2. 277 2.2.2. Username/Password Distributed Out-of-Band 279 When the EST client is not authenticated during the TLS handshake 280 (see Section 3.3.1.2), or if the EST server wishes additional 281 authentication information, the EST server can requests that the EST 282 client submit a username/password using the HTTP Basic or Digest 283 Authentication methods. See Section 3.2.3. 285 Alternately, the server and client can mutually authenticate using 286 certificate-less TLS authentication (Section 3.3.1.3). 288 2.3. Client Certificate Re-issuance 290 An EST client can renew/rekey an existing client certificate by 291 submitting a re-enrollment request to an EST server. As with initial 292 enrollment, the EST server authenticates the client using any 293 combination of the existing client certificate (see Section 3.3.1.2) 294 and/or HTTP Basic or Digest Authentication with a username/password 295 (see Section 3.2.3). 297 Two common renew/rekey scenarios for clients that are already 298 enrolled are described here. One addresses the renew/rekey of 299 signature certificates and the other addresses the renew/rekey of key 300 exchange certificates. The certification request message includes 301 the same Subject and SubjectAltName as the current key exchange 302 certificate with name changes handled as specified in Section 4.4.2. 304 2.3.1. Re-issuance of Signature Certificates 306 When a signature certificate is re-issued, the existing certificate 307 can be used by an EST client for authentication. 309 2.3.2. Re-issuance of Key Exchange Certificates 311 When a key exchange certificate is re-issued an existing signature 312 certificate is used by an EST client for authentication. If there is 313 no current signature certificate available, the EST server falls back 314 on the HTTP authentication method (Section 3.2.3). 316 2.4. Server Key Generation 318 The EST client can request a server-generated certificate and key 319 pair. 321 2.5. Full PKI Request messages 323 Full PKI Request messages can be transported via EST with the Full 324 CMC Request function, allowing access to functionality not provided 325 by the Simple Enrollment of Clients functions. Full PKI Request 326 messages are defined in Sections 3.2 and 4.2 of [RFC5272]. See 327 Section 4.5 for a discussion of how EST provides a transport for 328 these functions. 330 2.6. CSR (Certificate Signing Request) Attributes Request 332 Prior to sending an enrollment request to an EST server, an EST 333 client can query the EST server for the set of additional 334 attribute(s) that the client is requested to supply in the subsequent 335 enrollment request(s). 337 3. Protocol Design and Layering 339 Figure 2 provides an expansion of Figure 1 describing how the layers 340 are used. Each aspect is described in more detail in the sections 341 that follow. 343 EST Layering: 345 Protocols and uses: 346 +---------------------------------------------------+ 347 | | 348 | Message types: | 349 | - "Simple PKI" messages | 350 | (incorporating proof-of-possession) | 351 | - CA certificate retrieval | 352 | - "Full PKI" messages (OPTIONAL) | 353 | - CSR attribute request (OPTIONAL) | 354 | - Server-generated key request (OPTIONAL) | 355 | | 356 +---------------------------------------------------+ 357 | | 358 | HTTP: | 359 | - HTTP headers and URIs for control | 360 | - Content-Type headers specify message type | 361 | - Headers for control/error messages | 362 | - URIs for selecting functions | 363 | - Basic or Digest authentication if no | 364 | client certificate | 365 | | 366 +---------------------------------------------------+ 367 | | 368 | TLS for transport security | 369 | - Authentication is REQUIRED for EST server | 370 | OPTIONAL for EST clients | 371 | - Indirectly provides proof-of-identity for EST | 372 | - Provides communications integrity | 373 | - Channel Binding [RFC5929] to link | 374 | proof-of-identity with message-based | 375 | proof-of-possession. (OPTIONAL) | 376 | | 377 +---------------------------------------------------+ 379 Figure 2 381 Specifying HTTPS as the secure transport for enrollment messages 382 introduces two 'layers' to communicate authentication and control 383 messages: TLS and HTTP. 385 The TLS layer provides message authentication and integrity during 386 transport. The proof-of-identity is supplied by either the 387 certificate exchange during the TLS handshake or within the HTTP 388 layer headers. The message type along with control/error messages 389 are included in the HTTP headers. 391 The TLS and HTTP layer provided proof-of-identity means the CMC 392 [RFC5272] Section 3.1 note that "the Simple PKI Request MUST NOT be 393 used if a proof-of-identity needs to be included" is not applicable 394 and thus the Simple PKI message types are used. 396 The TLS layer certificate exchange provides a method for authorizing 397 client enrollment requests using existing certificates. Such 398 existing certificates may have been issued by the CA (from which the 399 client is requesting a certificate) or they may have been issued 400 under a distinct PKI (e.g., an IEEE 802.1AR IDevID [IDevID] 401 credential). 403 Proof-of-possession is a distinct issue from proof-of-identity and is 404 included in the Simple PKI message type as described in Section 3.4. 405 A method of linking proof-of-identity and proof-of-possession is 406 described in Section 3.5. 408 This document also defines transport for CMC [RFC5272] specification 409 compliant with CMC Transport Protocols [RFC5273]. 411 During the protocol operations various different certificates can be 412 used. The following table provides an informative overview. End- 413 entities MAY have one or more certificates of each type listed in 414 Figure 3: 416 Certificates/Trust-anchors and their corresponding uses: 417 +--------------+--------------------+-------------------------------+ 418 | Certificate/ | Issuer | Use | 419 | TA database | | | 420 +==============+====================+===============================+ 421 | EST server | The CA served by | Presented by the EST server | 422 | certificate | the EST server | during the TLS handshake | 423 | | | | 424 | | | Section: 3.3.1.1 | 425 +--------------+--------------------+-------------------------------+ 426 | EST server | An unrelated CA | Presented by the EST server | 427 | certificate | e.g., a Web site | during the TLS handshake | 428 | | CA | | 429 | | | Section: 3.3.1.1 | 430 +--------------+--------------------+-------------------------------+ 431 | EST client | Trust anchor for | EST clients use this | 432 | Trust Anchor | the CA issuing | trust anchor database to | 433 | Database | certificates. | authenticate certificates | 434 | | | issued by the CA, including | 435 | | | EST server certificates | 436 | | | Section 3.3.1.1 | 437 +--------------+--------------------+-------------------------------+ 438 | EST client | Trust anchors for | EST clients can use this | 439 | third party | third party CAs | trust anchor database to | 440 | Trust Anchor | e.g., a list of | authenticate an EST server | 441 | Database | Web site CA root | that uses an externally | 442 | | certificates | issued certificate | 443 | | | Section: 3.3.1.1 | 444 +--------------+--------------------+-------------------------------+ 445 | EST client | An unrelated CA | Presented by the EST client | 446 | certificate | e.g., a device | to the EST server by clients | 447 | | manufacturer | that have not yet enrolled | 448 | | | Section: 3.3.1.2 | 449 +--------------+--------------------+-------------------------------+ 450 | EST client | The CA served by | Presented by the EST client | 451 | certificate | the EST server | to PKI End Entities. | 452 | | | Including to the EST server | 453 | | | during future EST operations | 454 | | | Section: 3.3.1.2 | 455 +--------------+--------------------+-------------------------------+ 456 | EST client | The CA served by | Clients can obtain certs | 457 | certificate | the EST server | that can not be used for | 458 | | | EST authentication | 459 | | | (e.g., Key Encryption certs) | 460 | | | Section: 4.4.1 | 461 +--------------+--------------------+-------------------------------+ 462 Figure 3 464 3.1. Application Layer Design 466 An EST client SHOULD have its own client certificate suitable for TLS 467 client authentication (e.g., the digitalSignature bit is set). The 468 client certificate, if available, MUST be used when authenticating to 469 the EST server. If a client does not have a certificate, then the 470 client MUST use HTTP Basic or Digest authentication credentials (see 471 Section 3.2.3). HTTP authentication provides a bootstrap for clients 472 that have not yet been issued a certificate. EST clients obtaining a 473 certificates for other protocol purposes are RECOMMENDED to first 474 obtain an appropriate certificate for use when authenticating to the 475 EST server. 477 The client also SHOULD also have a CA certificate that will be used 478 to authenticate the EST server. 480 An EST client MUST be capable of generating and parsing Simple PKI 481 messages (see Section 4.4). Generating and parsing Full PKI messages 482 is OPTIONAL (see Section 4.5). The client MUST also be able to 483 request CA certificates from the EST server and parse the returned 484 "bag" of certificates (see Section 4.3). Requesting CSR attributes 485 and parsing the returned list of attributes is OPTIONAL (see 486 Section 4.7). 488 3.2. HTTP Layer Design 490 HTTP is used to transfer EST messages. URIs are provisioned for 491 handling each media type (i.e., message type) as described in 492 Section 3.2.2. HTTP is also used for client authentication services 493 when TLS client authentication is not available due to lack of a 494 client certificate suitable for use by TLS, as detailed in Section 495 Section 3.2.3. Registered media types are used to convey EST 496 messages as specified in Figure 5. 498 HTTP 1.1 [RFC2616] and above support persistent connections. As 499 given in Section 8.1 of that RFC persistent connections may be used 500 to reduce network and processing load associated with multiple HTTP 501 requests. EST does not require or preclude persistent HTTP 502 connections and their use is out of scope of this specification. 504 3.2.1. HTTP headers for control 506 This document profiles the HTTP content-type header (as defined in 507 [RFC2046], but see Figure 5 for specific values) to indicate the 508 media type for EST messages and to specify control messages for EST. 509 The HTTP Status value is used to communicate success or failure of 510 EST functions Support for the HTTP authentication methods is 511 available for a client that does not have a certificate. 513 CMC uses the same messages for certificate renewal and certificate 514 rekey. This specification defines the renewal and rekey behavior of 515 both the client and server. It does so by using the HTTP control 516 mechanisms employed by the client and server as opposed to using CMC. 518 Various media types as indicated in the HTTP content-type header are 519 used to transfer EST messages. Media types used by EST are specified 520 in Section 3.2.4. 522 3.2.2. HTTP URIs for control 524 This profile supports six operations indicated by specific URIs: 526 Operations and their corresponding URIs: 527 +------------------------+-----------------+-------------------+ 528 | Operation |Operation Path | Details | 529 +========================+=================+===================+ 530 | Distribution of CA | /CACerts | Section 4.3 | 531 | certificates (MUST) | | | 532 +------------------------+-----------------+-------------------+ 533 | Enrollment of new | /simpleEnroll | Section 4.4 | 534 | clients (MUST) | | | 535 +------------------------+-----------------+-------------------+ 536 | Re-Enrollment of | /simpleReEnroll | Section 4.4.1 | 537 | existing clients (MUST)| | | 538 +------------------------+-----------------+-------------------+ 539 | Full CMC (OPTIONAL) | /fullCMC | Section 4.5 | 540 +------------------------+-----------------+-------------------+ 541 | Server-side Key | /serverKeyGen | Section 4.6 | 542 | Generation (OPTIONAL) | | | 543 +------------------------+-----------------+-------------------+ 544 | Request CSR attributes | /CSRAttrs | Section 4.7 | 545 | (OPTIONAL) | | | 546 +------------------------+-----------------+-------------------+ 548 Figure 4 550 An HTTP base path common for all of an EST server's requests is 551 defined in the form of an path-absolute ([RFC3986], section 3.3). 552 The operation path (Figure 4 is appended to the base path to form the 553 URI used with HTTP GET or POST to perform the desired EST operation. 555 An example: 557 With a base path of "/arbitrary/path" and an operation path of 558 "/CACerts", the EST client would combine them to form an absolute 559 path of "/arbitrary/path/CACerts". Thus, to retrieve the CA's 560 certificates, the EST client would use the following HTTP request: 562 GET /arbitrary/path/CACerts HTTP/1.1 564 Likewise, to request a new certificate in this example scheme, the 565 EST client would use the following request: 567 POST /arbitrary/path/simpleEnroll HTTP/1.1 569 The mechanisms by which the EST server interacts with an HTTPS server 570 to handle GET and POST operations at these URIs is outside the scope 571 of this document. The use of distinct operation paths simplifies 572 implementation for servers that do not perform client authentication 573 when distributing /CACerts responses. 575 EST clients are provided with the base path URI of the EST server. 576 Potential methods of distributing the URI are discussed within the 577 Security Considerations (see Section 6 and Section 4.1). 579 An EST server MAY provide additional, services using other URIs. 581 An EST server MAY use multiple base paths in order to provide service 582 for multiple CAs. Each CA would use a distinct base path, but 583 operations are otherwise the same as specified for an EST server 584 operating on behalf of only one CA. 586 3.2.3. HTTP-Based Client Authentication 588 An EST server that has authenticated itself to the client MAY request 589 HTTP-based client authentication. This request can be in addition to 590 successful TLS client authentication (Section 3.3.1.2) if EST server 591 policy requires additional authentication (for example the EST server 592 wishes to confirm the EST client "knows" a password in addition to 593 "having" an existing client certificate). Or HTTP-based client 594 authentication can be an EST server policy specified fallback in 595 situations where the EST client did not successfully complete the TLS 596 client authentication (for example if the EST client is enrolling for 597 the first time or the existing EST client certificates can not be 598 used for TLS client authentication). 600 HTTP Basic and Digest authentication MUST only be performed over TLS 601 1.1 [RFC4346] (or later). As specified in CMC: Transport Protocols 602 [RFC5273] the server "MUST NOT assume client support for any type of 603 HTTP authentication such as cookies, Basic authentication, or Digest 604 authentication". Clients intended for deployments where password 605 authentication is advantageous SHOULD support the Basic and Digest 606 authentication mechanism. Servers MAY provide configuration 607 mechanisms for administrators to enable Basic and Digest 608 authentication methods. 610 Servers that wish to use Basic and Digest authentication reject the 611 HTTP request using the HTTP defined WWW-Authenticate response-header 612 ([RFC2616], Section 14.47). At that point the client SHOULD repeat 613 the request, including the appropriate Authorization Request Header 614 ([RFC2617], Section 3.2.2) if the client is capable of using the 615 Basic or Digest authentication. If the client is not capable then 616 the client MUST terminate the connection. 618 Clients MAY set the username to the empty string ("") if they wish to 619 present a "one-time password" or "PIN" that is not associated with a 620 username. 622 Support for HTTP-based client authentication has security 623 ramifications as discussed in Section 6. The client MUST NOT respond 624 to the server's HTTP authentication request unless the client has 625 authenticated the EST server (as per Section 4.1). 627 3.2.4. Message types 629 This document uses existing media types for the messages as specified 630 by [RFC2585], [RFC5967], and CMC [RFC5272]. To support distribution 631 of multiple certificates for the CA certificate chain, the [RFC2046] 632 multipart/mixed media type is used. 634 The message type is specified in the HTTP Content-Type header with a 635 media type. The use herein is consistent with [RFC5273]. 637 For reference the messages and their corresponding media types are: 639 +--------------------+--------------------------+-------------------+ 640 | Message type |Request media type | Request section | 641 | |Response media type | Response section | 642 | |Source(s) of types | | 643 +====================+==========================+===================+ 644 | CA certificate | N/A | Section 4.3 | 645 | request | application/pkcs7-mime | Section 4.3.1 | 646 | | [RFC5751] | | 647 +--------------------+--------------------------+-------------------+ 648 | Cert enroll/renew/ | application/pkcs10 | Section 4.4/4.4.1 | 649 | rekey | application/pkcs7-mime | Section 4.4.2 | 650 | | [RFC5967] [RFC5751] | | 651 +--------------------+--------------------------+-------------------+ 652 | Full CMC | application/pkcs7-mime | Section 4.5.1 | 653 | | application/pkcs7-mime | Section 4.5.2 | 654 | | [RFC5751] | | 655 +--------------------+--------------------------+-------------------+ 656 | Server-side Key | application/pkcs10 | Section 4.6.1 | 657 | Generation | multipart/mixed | Section 4.6.2 | 658 | | (application/pkcs7-mime &| | 659 | | application/pkcs8) | | 660 | | [RFC5967] [RFC5751] | | 661 +--------------------+--------------------------+-------------------+ 662 | Request CSR | N/A | Section 4.7.1 | 663 | attributes | application/csrattrs | Section 4.7.2 | 664 | | This RFC | | 665 +--------------------+--------------------------+-------------------+ 667 Figure 5 669 3.3. TLS Layer Design 671 TLS provides communications security for the layers above it. The 672 integrity and authentication services it provides are leveraged to 673 supply proof-of-identity and to allow authorization decisions to be 674 made. The higher layer EST server and EST client are responsible for 675 ensuring that an acceptable cipher suite is used and that 676 bidirectional authentication has been established. Alternately, 677 certificate-less TLS authentication-- where neither the client nor 678 server present a certificate-- is also an acceptable method for EST 679 server and client authentication. 681 When the EST server uses a certificate for authentication, TLS client 682 authentication is the preferred method for identifying EST clients. 683 If the EST client does not yet have a suitable client certificate the 684 EST server can request HTTP Basic or Digest authentication protected 685 by the TLS encryption. Alternately, certificate-less TLS 686 authentication-- where neither the client nor server present a 687 certificate-- is also an acceptable method for EST client 688 authentication. 690 TLS channel binding information may be optionally inserted into a 691 certificate request as detailed in Section 3.5 in order to provide 692 the EST server with assurance that the authenticated TLS client 693 entity has possession of the private key for the certificate being 694 requested. 696 3.3.1. TLS for transport security 698 HTTPS [RFC2818] and specifies how HTTP messages are carried over TLS. 699 HTTPS MUST be used. TLS 1.1 [RFC4346] (or later) SHOULD be 700 supported. TLS session resumption [RFC5077] SHOULD be supported. 702 3.3.1.1. TLS-Based Server Authentication 704 The EST client authenticates the EST server as appropriate for the 705 cipher suite negotiated. The following provides details assuming the 706 TLS 1.1 [RFC4346] Section 9 Mandatory Cipher Suite 707 TLS_RSA_WITH_3DES_EDE_CBC_SHA with a TLS server certificate presented 708 during the TLS 1.1 [RFC4346] (or later) exchange-defined Server 709 Certificate message. As an alternative to authentication using a 710 certificate, an EST client MAY support certificate-less TLS 711 authentication (Section 3.3.1.3). 713 Certificate validation MUST be performed as given in [RFC5280] and 714 [RFC6125]. The EST server certificate MUST conform to the [RFC5280] 715 certificate profile. 717 The client validates the TLS server certificate using local TAs, 718 which may be in the form of certificates. If certificate 719 verification fails the client MAY follow the procedure outlined in 720 Section 4.3.2 for bootstrap distribution of CA certificates. 722 The EST client MUST perform authorization checks as specified in 723 Section 4.1. 725 3.3.1.2. TLS-Based Client Authentication 727 The EST server MUST authenticate the EST client as appropriate for 728 the cipher suite negotiated. The following provides details assuming 729 the TLS 1.1 [RFC4346] Section 9 Mandatory Cipher Suite 730 TLS_RSA_WITH_3DES_EDE_CBC_SHA with a TLS client certificate presented 731 during the TLS 1.1 [RFC4346] (or later) exchange-defined Client 732 certificate message. As an alternative to authentication using a 733 certificate, an EST server MAY support certificate-less TLS 734 authentication. (Section 3.3.1.3) 736 Clients SHOULD support [RFC4346]-defined (or later) Certificate 737 request (section 7.4.4). As required by [RFC4346], the client 738 certificate needs to indicate support for digital signatures. The 739 client SHOULD support this method in order to leverage 740 /simpleReEnroll using client authentication by existing certificate. 742 If a client does not support TLS client authentication, then it MUST 743 support HTTP-based client authentication. (Section 3.2.3). 745 The EST server MUST perform authorization checks as specified in 746 Section 4.2. 748 3.3.1.3. Certificate-less TLS Mutual Authentication 750 The client and server MAY negotiate a certificate-less cipher suite 751 for mutual authentication. When using certificate-less mutual 752 authentication in TLS for enrollment, the cipher suite MUST be 753 resistant to dictionary attack and MUST provide sufficient 754 information to perform the authorization checks. For example if the 755 cipher suite uses a pre-shared secret, provisioned in an out-of-band 756 fashion, as a credential to perform mutual authentication then 757 knowledge of the pre-shared secret implies authorization as a peer in 758 the exchange. 760 3.4. Proof-of-Possession 762 As defined in Section 2.1 of CMC [RFC5272], Proof-of-possession (POP) 763 "refers to a value that can be used to prove that the private key 764 corresponding to the public key is in the possession and can be used 765 by an end-entity." 767 The signed enrollment request provides a "Signature"-based proof-of- 768 possession. The mechanism described in Section 3.5 strengthens this 769 by optionally including "Direct"-based proof-of-possession by 770 including TLS session specific information within the data covered by 771 the enrollment request signature (thus linking the enrollment request 772 to the authenticated end-point of the TLS connection). 774 3.5. Linking Identity and POP information 776 This specification provides an OPTIONAL method of linking identity 777 and proof-of-possession by including information specific to the 778 current authenticated TLS session within the signed certification 779 request. Clients MAY use this method as a result of client 780 configuration. If configuration is not possible the client can 781 determine that this method is required by parsing the error responses 782 or by examining the CSR Attributes Response (see Section 4.7.2). 784 Linking identity and proof-of-possession proves to the server that 785 the authenticated TLS client has possession of the private key 786 associated with the certification request and that the client was 787 able to sign the certification request after the TLS session was 788 established. This is an alternative to the [RFC5272] Section 6.3- 789 defined "Linking Identity and POP information" method available if 790 Full PKI messages are used. 792 The client generating the request obtains the tls-unique value as 793 defined in Channel Bindings for TLS [RFC5929] from the TLS subsystem. 794 The tls-unique specification includes a synchronization issue as 795 described in Channel Bindings for TLS [RFC5929] section 3.1. To 796 avoid this problem EST implementations MUST use the tls-unique value 797 from the first TLS handshake. EST clients and servers use their tls- 798 unique implementation specific synchronization methods to obtain this 799 first tls-unique value. TLS "secure_renegotiation" [RFC5746] MUST be 800 used. This maintains the binding from the first tls-unique value 801 across renegotiations to the most recently negotiated connection. 803 The tls-unique value is Base 64 encoded as specified in Section 4 of 804 [RFC4648] and the resulting string is placed in the certification 805 request challenge-password field ([RFC2985], Section 5.4.1). If tls- 806 unique information is not embedded within the certification request 807 the challenge-password field MUST be empty to indicate that the 808 client did not include the optional channel-binding information (any 809 value submitted is verified by the server as tls-unique information). 811 The EST server MUST verify the tls-unique information embedded within 812 the certification request according to server policy regarding the 813 authenticated client. If the EST server forwards the request to 814 back-end infrastructure for processing it is RECOMMENDED that the 815 results of this verification be communicated. (For example this 816 communication might use the CMC "RA POP Witness Control" in a CMC 817 Full PKI Request message or the back-end infrastructure might 818 authenticate the EST server as being a trusted infrastructure element 819 that does not forward invalid requests. A detailed discussion of 820 back-end processing is out of scope). 822 When rejecting requests the EST server response is as described for 823 all enroll responses (Section 4.4.3). If a Full PKI Response is 824 included the CMCFailInfo MUST be set to popFailed. If a human 825 readable reject message is included it SHOULD include an informative 826 text message indicating that linking of identity and POP information 827 is required. 829 4. Protocol Exchange Details 831 Before processing a request, an EST server determines if the client 832 is authorized to receive the requested services. Likewise, the 833 client determines if it will accept services from the EST server. 834 These authorization decisions are described in the next two sections. 835 Assuming that both sides of the exchange are authorized, then the 836 actual operations are as described in the sections that follow. 838 4.1. Server Authorization 840 The client MUST check the EST server authorization before accepting 841 any server responses or responding to HTTP authentication requests. 843 When the server authenticates with a certificate the client MUST 844 check the URI "against the server's identity as presented in the 845 server's Certificate message" (HTTP Over TLS Section 3.1 "Server 846 Identity" [RFC2818] and [RFC6125]). The provisioned URI provides the 847 authorization statement and the server's authenticated identity 848 confirms it is the authorized server. Successful authentication 849 using a certificate-less cipher suite implies authorization of the 850 server. 852 If the URI does not match the server identity check then the TLS 853 server certificate MUST contain the id-kp-cmcRA [CMC RFC6402] 854 extended key usage extension and the TLS server certificate MUST be 855 issued by the CA the EST server is providing services for. 857 The client MUST maintain the distinction between the EST specific TA 858 for the CA issuing certificates and the TAs for third party CAs in 859 order to make this determination (see, Section 3). 861 If these checks fail then authorization of the EST server does not 862 occur except for as specified in Section 4.3.2. 864 4.2. Client Authorization 866 When the EST server receives a Simple PKI Request or rekey/renew 867 message, the decision to issue a certificate is always the CA's. The 868 EST server configuration reflects the CA policy and can use any data 869 it wishes in determining whether to issue the certificate (e.g. CSR 870 attributes, client identity, linking of client identity and proof-of- 871 possession, etc). The details are out-of-scope. EST provides the 872 EST server access to client's authenticated identity-- e.g. the TLS 873 client's certificate in addition to any HTTP user authentication 874 credentials-- to help in implementing configured policy. 876 If the client's authenticated certificate was issued by the EST 877 server CA and includes the id-kp-cmcRA [RFC6402] extended key usage 878 extension then the CA SHOULD apply policy consistent with a client 879 that is acting as an RA (such as policy to support enrollment 880 requests initiated either by the RA itself or by clients that are in 881 communication with the RA). 883 4.3. Distribution of CA certificates 885 The EST client can request a copy of the current CA certificates and 886 this function is generally performed before other EST functions. 888 4.3.1. Distribution of CA certificates request 890 EST clients MAY request TA information of the CA (in the form of 891 certificates) with an HTTPS GET message with an operation path of 892 "/CACerts". EST clients and servers MUST support the /CACerts 893 function. Clients SHOULD request an up-to-date response before 894 stored information has expired in order to maintain continuity of 895 trust. 897 The EST server SHOULD NOT require client authentication or 898 authorization to reply to this request. 900 The client MUST authenticate the EST server as specified in 901 Section 3.3.1 and check the server's authorization as given in 902 Section 4.1 or follow the procedure outlined in Section 4.3.2. 904 4.3.2. Bootstrap Distribution of CA certificates 906 If the TLS authentication or authorization fails then the client MAY 907 provisionally continue the TLS handshake to completion for the 908 purposes of accessing the /CACerts or /fullCMC method. If the EST 909 client continues with an unauthenticated connection the EST client 910 MUST extract the HTTP content data from the response (Section 4.3.3 911 or Section 4.5.2) and engage the end-user to authorize the CA 912 certificate using out-of-band pre-configuration data such as a CA 913 certificate "fingerprint" (e.g., a SHA-1, SHA-256, SHA-512 [SHS], or 914 MD5 [RFC1321] hash on the whole CA certificate). In a /fullCMC 915 response it is the Publish Trust Anchors control within the Full PKI 916 Response that must be accepted manually. It is incumbent on the end 917 user to properly verify the fingerprint or to provide valid out-of- 918 band data necessary to verify the fingerprint. 920 HTTP authentication requests MUST NOT be responded to since the 921 server is unauthenticated. The EST client uses the /CACerts response 922 to build the trust anchor for subsequent TLS server authentication. 923 EST clients MUST NOT make any other protocol exchange until after the 924 /CACerts response has been accepted and a new TLS session 925 established. 927 4.3.3. Distribution of CA certificates response 929 The EST server responds to the client HTTPS GET request with an HTTP 930 GET response that includes CA trust anchor information, in the form 931 of certificates within the Simple PKI Response. If the certificates 932 are successfully returned, the server response MUST have an HTTP 200 933 response code with a content-type of "application/pkcs7-mime". Any 934 other response code indicates an error and the client should abort 935 the protocol. 937 The EST server MUST include the current CA certificate in the 938 response. The EST server MUST include any additional certificates 939 the client would need to build a chain to the current root CA 940 certificate. For example if the EST server is configured to use a 941 subordinate CA when signing new client requests then the appropriate 942 subordinate CA certificates to chain to the root CA are included in 943 this response. 945 If support for the CMP root certificate update mechanism is provided 946 by the CA then the server MUST include the three "Root CA Key Update" 947 certificates OldWithOld, OldWithNew, and NewWithOld. These are 948 defined in Section 4.4 of CMP [RFC4210]. 950 The client can always find the current TA in the form of a self- 951 signed certificate by examining the received certificates. The CA's 952 most recent self signed certificate (e.g. NewWithNew certificate) is 953 self-signed and has the latest NotAfter date. 955 The most recent CA certificate is the certificate that is extracted 956 and authorized using out-of-band information as described in 957 Section 4.3.2. After out-of-band validation occurs each of the other 958 certificates MUST be validated using normal [RFC5280] certificate 959 path validation (using the most recent CA certificate as the TA) 960 before they can be used to build certificate paths during certificate 961 validation. 963 The response format is the CMC Simple PKI Response as defined in 964 [RFC5272]. The HTTP content-type of "application/pkcs7-mime" is 965 used. The Simple PKI response is Base64 encoded, as specified in 966 Section 4 of [RFC4648], and sandwiched between headers: 968 -----BEGIN PKCS7----- 969 MIIBhDCB7gIBADBFMQswCQYDVQQGEwJBVTETMBEGA1UECBMKU29tZS1TdGF0ZTEh 970 Simplified example of Base64 encoding of CMC Simple PKI Response 971 ED8rf3UDF6HjloiV3jBnpetx4JjZH/BlmD9HMqofVEryb1e4iZgMUvuIgwEjQwpD 972 8J4OhHvLh1o= 973 -----END PKCS7----- 975 4.4. Client Certificate Request Functions 977 EST clients MAY request a certificate from the EST server with an 978 HTTPS POST using the operation path value of "/simpleEnroll". The 979 EST server MUST support the /simpleEnroll function. EST clients MAY 980 request a renew/rekey of existing certificates with an HTTP POST 981 using the operation path value of "/simpleReEnroll". The EST server 982 SHOULD support the /simpleReEnroll function. 984 The client is RECOMMENDED to have obtained the current CA 985 certificates using Section 4.3 before performing certificate request 986 functions to ensure it can validate the EST server certificate. The 987 client MUST authenticate the EST server as specified in 988 Section 3.3.1.1. The client MUST authorize the EST server as 989 specified in Section 4.1. 991 The server MUST check client authentication as specified in 992 Section 3.3.1.2. The server MUST check client authorization as 993 specified in Section 4.2. The EST server MUST check the tls-unique 994 value as described in Section 3.5. 996 The server MAY accept the certificate request for manual 997 authorization by the administrator. (Section 4.4.3 describes the use 998 of an HTTP 202 response to the EST client if this occurs). 1000 4.4.1. Simple Enrollment of Clients 1002 When HTTPS POSTing to /simpleEnroll the client MUST include a Simple 1003 PKI Request as specified in CMC Section 3.1 (i.e., a PKCS#10 1004 Certification Request). 1006 The Certification Request signature provides proof-of-possession of 1007 the private key to the EST server. If the requested KeyUsage 1008 extensions support digital signing operations then the certification 1009 request signature MUST be generated using the private key 1010 corresponding to the public key in the CertificationRequestInfo. If 1011 the requested KeyUsage extensions do not allow for digital signing 1012 operations the request MAY sign the certificate request, however the 1013 private key MUST NOT be used to perform signature operations after 1014 certificate issuance. The use of /fullCMC operations provides access 1015 to more advanced proof-of-possession methods that SHOULD be used when 1016 the keys are not available for digital signing operations. This is 1017 consistent with the recommendations concerning submission of proof- 1018 of-possession to an RA or CA as described in [SP-800-57-Part-1]. 1020 The HTTP content-type of "application/pkcs10" is used. The format of 1021 the message is as specified in Section 6.4 of [RFC4945]. 1023 The client MAY request an additional certificate even when using an 1024 existing certificate in the TLS client authentication. For example 1025 the client can use an existing signature certificate to request a key 1026 exchange certificate. 1028 4.4.2. Simple Re-Enrollment of Clients 1030 EST clients renew/rekey certificates with an HTTPS POST using the 1031 operation path value of "/simpleReEnroll". EST clients and server 1032 MUST support the /simpleReEnroll function. 1034 The certificate request is the same format as for the "simpleEnroll" 1035 request with the same HTTP content-type. The request Subject and 1036 SubjectAltName field(s) MUST contain the identity of the certificate 1037 being renewed/rekeyed. The ChangeSubjectName attribute, as defined 1038 in [RFC6402], MAY be included in the certificate request. 1040 If the public key information in the certification request is the 1041 same as the currently issued certificate the EST server performs a 1042 renew operation. If the public key information is different than the 1043 currently issued certificate then the EST server performs a rekey 1044 operation. The specifics of these operations are out of scope of 1045 this profile. 1047 4.4.3. Simple Enroll and Re-Enroll Response 1049 If the enrollment is successful, the server response MUST have an 1050 HTTP 200 response code with a content-type of "application/ 1051 pkcs7-mime". The response data is a degenerate certs-only Simple PKI 1052 Response containing only the certificate issued. The Simple PKI 1053 response is Base64 encoded and sandwiched between headers: 1055 -----BEGIN PKCS7----- 1056 MIIBhDCB7gIBADBFMQswCQYDVQQGEwJBVTETMBEGA1UECBMKU29tZS1TdGF0ZTEh 1057 Simplified example of Base64 encoding of CMC Simple PKI Response 1058 ED8rf3UDF6HjloiV3jBnpetx4JjZH/BlmD9HMqofVEryb1e4iZgMUvuIgwEjQwpD 1059 8J4OhHvLh1o= 1060 -----END PKCS7----- 1062 When rejecting a request the server MUST specify either an HTTP 4xx/ 1063 401 error, or an HTTP 5xx error. A PKI Response with an HTTP 1064 content-type of "application/pkcs7-mime" (see Section 4.5.2) MAY be 1065 included in the response data for any error response. If the 1066 content-type is not set, the response data MUST be a plain text 1067 human-readable error message containing informative information 1068 concerning why the request was rejected (for example indicating that 1069 CSR attributes are incomplete). A client MAY elect not to parse a 1070 CMC error response in favor of a generic error message. 1072 If the server responds with an HTTP [RFC2616] 202 this indicates that 1073 the request has been accepted for processing but that a response is 1074 not yet available. The server MUST include a Retry-After header as 1075 defined for HTTP 503 responses and MAY include informative human- 1076 readable content. The client MUST wait at least the specified 1077 'retry-after' time before repeating the same request. The client 1078 repeats the initial enrollment request after the appropriate 'retry- 1079 after' interval has expired. The client SHOULD log or inform the end 1080 user of this event. The server is responsible for maintaining all 1081 state necessary to recognize and handle retry operations as the 1082 client is stateless in this regard (it simply sends the same request 1083 repeatedly until it receives a different response code). 1085 All other return codes are handled as specified in HTTP [RFC2616]. 1087 If the EST client has not obtained the current CA certificates using 1088 Section 4.3 then it may not be able to validate the certificate 1089 received. 1091 4.5. Full CMC 1093 EST clients can also request a certificate from the EST server with 1094 an HTTPS POST using the operation path value of "/fullCMC". Support 1095 for the /fullCMC function is OPTIONAL. 1097 The client SHOULD authenticate the server as specified in Server 1098 Authentication (Section 3.3.1.1). Bootstrap distribution of CA 1099 certificates is specified in Section 4.3.2. 1101 The server SHOULD authenticate the client as specified in 1102 Section 3.3.1. The server MAY depend on CMC client authentication 1103 methods instead. 1105 4.5.1. Full CMC Request 1107 If the HTTP POST to /fullCMC is not a valid Full PKI Request, the 1108 server MUST reject the message. The HTTP content-type used is 1109 "application/pkcs7-mime", as specified in [RFC5273]. 1111 4.5.2. Full CMC Response 1113 The server responds with the client's newly issued certificate or 1114 provides an error response. 1116 If the enrollment is successful the server response MUST have an HTTP 1117 200 response code with a content-type of "application/pkcs7-mime" as 1118 specified in [RFC5273]. The response data includes either the Simple 1119 PKI Response or the Full PKI Response. 1121 When rejecting a request the server MAY specify either an HTTP 4xx/ 1122 401 error or an HTTP 5xx error. A CMC response with content-type of 1123 "application/pkcs7-mime" SHOULD be included in the response data for 1124 any CMC error response. The client parses the CMC response to 1125 determine the current status. 1127 All other return codes are handled as specified in Section 4.4.3 or 1128 HTTP [RFC2616]. For example the client interprets a HTTP 404 or 501 1129 response to indicate that this service is not implemented. 1131 The Full PKI Response is Base64 encoded and sandwiched between 1132 headers: 1134 -----BEGIN PKCS7----- 1135 MIIBhDCB7gIBADBFMQswCQYDVQQGEwJBVTETMBEGA1UECBMKU29tZS1TdGF0ZTEh 1136 Simplified example of Base64 encoding of CMC Full PKI Response 1137 ED8rf3UDF6HjloiV3jBnpetx4JjZH/BlmD9HMqofVEryb1e4iZgMUvuIgwEjQwpD 1138 8J4OhHvLh1o= 1139 -----END PKCS7----- 1141 4.6. Server-side Key Generation 1143 [[EDNOTE: This section includes references 1144 [draft-ietf-pkix-cmc-serverkeygeneration-00] which has not yet been 1145 published.]] 1147 EST clients request a "private" key and associated certificate from 1148 the EST server with an HTTPS POST using the operation path value of 1149 "/serverKeyGen". Support for the /serverKeyGen function is OPTIONAL. 1151 The client MUST authenticate the server as specified in 1152 Section 3.3.1.1. The EST client is RECOMMENDED to have obtained the 1153 current CA certificates using Section 4.3 to ensure it can validate 1154 the EST server certificate. 1156 The EST server MUST authenticate the client as specified in 1157 Section 3.3.1. The server SHOULD use TLS-Based Client Authentication 1158 for authorization purposes. The EST server applies whatever 1159 authorization or policy logic it chooses to determine if the 1160 "private" key and certificate should be generated. 1162 Proper random number and key generation [RFC4086] as well as storage 1163 is a server implementation responsibility. The key pair and 1164 certificate are transferred over the TLS session; the EST server MUST 1165 verify that the current cipher suite is acceptable for securing the 1166 key data. 1168 4.6.1. Server-side Key Generation Request 1170 The certificate request is HTTPS POSTed and is the same format as for 1171 the "/simpleEnroll" and "/simpeReEnroll" path extensions with the 1172 same content-type. 1174 The Subject and SubjectAltName field(s) or ChangeSubjectName 1175 attribute in the request MAY, as can all fields in a CSR, be ignored 1176 by the server as these are only requests. The server uses these 1177 fields, along with the authenticated client identity and server 1178 policy, to determine if it wishes to generate a new "private" key 1179 when servicing the request or re-use an escrowed "private" key. The 1180 client MAY request multiple keys and certificates. 1182 In all respects the server SHOULD treat the request as it would any 1183 enroll or re-enroll request; with the only distinction being that the 1184 server MUST ignore the public key values of the certificate request 1185 and the request signature. These are included in the request only to 1186 allow re-use of existing codebases for generating and parsing such 1187 requests. 1189 4.6.2. Server-side Key Generation Response 1191 If the request is successful the server response MUST have an HTTP 1192 200 response code with a content-type of "multipart/mixed" consisting 1193 of two parts. One part is the "private" key data and the other part 1194 is the certificate data. 1196 The "private" key data MAY be an "application/pkcs8" consisting of 1197 the Base64 encoded DER-encoded PrivatekeyInfo sandwiched between the 1198 headers as described in [RFC5958]. Alternatively the "private" key 1199 data SHOULD be an "application/pkcs7-mime" containing a CMS [RFC5652] 1200 message (also as described in [RFC5958]). The content of this 1201 message is an EncryptedData or EnvelopedData content type containing 1202 the binary DER-encoded PrivatekeyInfo. The RecipientInfo MAY use any 1203 valid key management technique as determined by server policy and 1204 authenticated client identity. For example when the client uses a 1205 TLS client certificate for authentication the server can use this as 1206 the KeyTransRecipientInfo rid. The use of a CMS provides security to 1207 the AsymmetricKeyPackage: 1209 -----BEGIN PRIVATE KEY----- 1210 MIIBhDCB7gIBADBFMQswCQYDVQQGEwJBVTETMBEGA1UECBMKU29tZS1TdGF0ZTEh 1211 Simplified example of Base64 encoding of DER-encoded PrivateKeyInfo 1212 ED8rf3UDF6HjloiV3jBnpetx4JjZH/BlmD9HMqofVEryb1e4iZgMUvuIgwEjQwpD 1213 8J4OhHvLh1o= 1214 -----END PRIVATE KEY----- 1216 The certificate data part is an "application/pkcs7-mime" and exactly 1217 matches the certificate response to /simpleEnroll. If both parts are 1218 "application/pkcs7-mime" the client checks each (one will be a certs- 1219 only Simple PKI response and the other will be the CMS message with 1220 the encrypted data). 1222 When rejecting a request the server MUST specify either an HTTP 4xx/ 1223 401 error, or an HTTP 5xx error. If the content-type is not set the 1224 response data MUST be a plain text human-readable error message. 1226 Future work might define addtional certification request attributes 1227 to communicate key management information in addition to using the 1228 client's authenticated identity. Such attributes are out-of-scope of 1229 this document. 1231 4.7. CSR Attributes 1233 The CA MAY want to include client-provided attributes in certificates 1234 that it issues and some of these attributes may describe information 1235 that is not available to the CA. For this reason, the EST client MAY 1236 request a set of attributes from the EST server to include in its 1237 certification request. 1239 4.7.1. CSR Attributes Request 1241 The EST Client MAY request a list of CA-desired CSR attributes from 1242 the CA by sending an HTTPS GET message to the EST server with an 1243 operations path of "/CSRAttrs". Clients SHOULD request such a list 1244 if they have no a priori knowledge of what attributes are desired by 1245 the CA in an enrollment request or when dictated by policy. 1247 4.7.2. CSR Attributes Response 1249 If policy for the authenticated EST client indicates a CSR Attributes 1250 Response will be provided the server response MUST have an HTTP 200 1251 response code. An HTTP response code of 204 or 404 indicates that a 1252 CSR Attributes Response is not available. Regardless of the response 1253 code the EST server and CA MAY reject any subsequent enrollment 1254 requests for any reason, including incomplete CSR attributes in the 1255 request. 1257 Responses to attribute request messages MUST be encoded as content 1258 type "application/csrattrs". The syntax for application/csrattrs 1259 body is as follows: 1261 Csrattrs ::= SEQUENCE SIZE (0..MAX) OF OBJECT IDENTIFIER { } 1263 Servers include zero or more object identifiers that they wish the 1264 client to include in their certification request. When the server 1265 encodes Csrattrs as an empty SEQUENCE it means that the server has no 1266 specific additional attributes it wants in the client certification 1267 requests (this is functionally equivalent to an HTTP response code of 1268 204 or 404). The sequence is DER (preferred) or BER encoded and then 1269 base64 encoded (section 4 of [RFC4648]). The resulting text forms 1270 the application/csrattr body, without headers. 1272 For example, if a CA wishes the authenticated client to submit a 1273 certification request containing the MAC address [RFC2397] of a 1274 device and the challengePassword (indicating that Linking of Identity 1275 and POP information is requested, see Section 3.5) it takes the 1276 following object identifiers: 1278 o macAddress: 1.3.6.1.1.1.1.22 1280 o challengePassword: 1.2.840.113549.1.9.7 1282 and encodes them into an ASN.1 SEQUENCE to produce: 1284 30 14 06 07 2B 06 01 01 01 01 16 06 09 2A 86 48 86 F7 0D 01 09 07 1286 and then base64 encodes the resulting ASN.1 SEQUENCE to produce: 1288 MBQGBysGAQEBARYGCSqGSIb3DQEJBw== 1290 The EST client parses the response OID's and handles each OID 1291 independently on a best effort basis. When an OID indicates a known 1292 CSR attribute type the client SHOULD include that CSR attribute in 1293 the subsequent CSR submitted, either in the CSR attributes or in any 1294 other appropriate CSR field. When an OID is of an unknown type the 1295 OID MAY be ignored by the client. 1297 5. IANA Considerations 1299 (This section is incomplete) 1301 IANA is requested to register the following: 1303 IANA SHALL update the Application Media Types registry with the 1304 following filled-in template from [RFC4288]. 1306 The media subtype for Attributes in a CertificationRequest is 1307 application/csrattrs. 1309 Type name: application 1311 Subtype name: csrattrs 1313 Required parameters: None 1315 Optional parameters: None 1317 Encoding considerations: binary; 1319 Security Considerations: 1321 Clients request a list of attributes that servers wish to be in 1322 certification requests. The request/response SHOULD be done in 1323 a TLS-protected tunnel. 1325 Interoperability considerations: None 1327 Published specification: This memo. 1329 Applications which use this media type: 1331 Enrollment over Secure Transport (EST) 1333 Additional information: 1335 Magic number(s): None 1337 File extension: None 1339 Macintosh File Type Code(s): 1341 Person & email address to contact for further information: 1343 Dan Harkins 1345 Restrictions on usage: None 1347 Author: Dan Harkins 1349 Intended usage: COMMON 1350 Change controller: The IESG 1352 6. Security Considerations 1354 Support for Basic authentication as specified in HTTP [RFC2617] 1355 allows the server access to the client's cleartext password. This 1356 provides integration with legacy username/password databases but 1357 requires exposing the plaintext password to the EST server. Use of a 1358 PIN or one-time-password can help mitigate concerns but EST clients 1359 are RECOMMENDED to use such credentials only once to obtain an 1360 appropriate client certificate to be used during future interactions 1361 with the EST server. 1363 When the client uses a third party trust anchor database for 1364 certificate validation (see Section 3) then authorization proceeds as 1365 specified in Section 4.1. In this situation the client has validated 1366 the server as being a valid responder for the URI configured but can 1367 not directly verify that the responder is authorized as an RA within 1368 the to-be-enrolled-in PKI hierarchy. Possible avenues for an attack 1369 could be an erroneous URI injected into the client via an initial 1370 configuration method, or the server could have compromised a third 1371 party trust anchor to obtain an apparently valid server certificate. 1372 Clients using a third party trust anchor database are RECOMMENDED to 1373 only use TLS-based client authentication (to prevent leaking HTTP- 1374 based Client Authentication information). Such clients are 1375 RECOMMENDED to include "Linking Identity and POP information" 1376 (Section 3.5) in requests (to minimize the chance that such requests 1377 could be proxied to the real EST server). Additionally it is 1378 RECOMMENDED that the third party trust anchor database available for 1379 EST server authentication be carefully constructed (to reduce the 1380 risk of improperly managed third party CAs). 1382 When using a certificate-less TLS cipher suite, the shared secret 1383 used for authentication and authorization MUST be known only to the 1384 two parties to the exchange-- the client and the server. Any sharing 1385 of secrets completely voids the security afforded by a certificate- 1386 less cipher suite. Exposure of a shared secret used by a 1387 certificate-less cipher suite to a third party enables client 1388 impersonation that can results in corruption of a client's trust 1389 anchor database. 1391 Any certificate-less TLS cipher suite used with EST MUST be resistant 1392 to dictionary attack. This means that the advantage an adversary 1393 gains through attack MUST be related to interaction and not 1394 computation. Certificate-less TLS cipher suites used with EST MUST 1395 also be based on a zero knowledge protocol to enable proof of 1396 knowledge of the shared secret without exposure of the shared secret 1397 (or any derived data which can be used to determine the secret). 1398 These requirements mean that the adversary gains advantage solely 1399 through active attack and the only thing learned from each active 1400 attack is whether a single guess of the secret is successful or not. 1401 Implementations of EST that support certificate-less TLS cipher 1402 suites SHOULD provide countermeasures-- for example, exponential back 1403 off after failed attempts or locking of an account after a certain 1404 number of unsuccessful attempts-- to mitigate repeated active 1405 attacks. 1407 As described in CMC Section 6.7, "For keys that can be used as 1408 signature keys, signing the certification request with the private 1409 key serves as a POP on that key pair". The inclusion of tls-unique 1410 within the certification request links the proof-of-possession to the 1411 TLS proof-of-identity by enforcing that the POP operation occured 1412 while the TLS session is active. This strongly implies to the server 1413 that it is the authenticated client that has possession of the 1414 private key. If client authentication indicates a client with 1415 specific known behaviour this implication is strengthened but not 1416 proven. 1418 The server-side key generation method allows keys to be transported 1419 over the TLS connection to the client. The distribution of "private" 1420 key material is inherently risky and servers are NOT RECOMMENDED to 1421 support this operation by default. Clients are NOT RECOMMENDED to 1422 request this service unless there is a compelling operational 1423 benefit. Use of a third party trust anchor database is NOT 1424 RECOMMENDED for server-side key generation. The use of an encrypted 1425 CMS Server-side Key Generation Response is RECOMMENDED. 1427 Regarding the CSR attributes that the CA may list for inclusion in an 1428 enrollment request, there are no real inherent security issues with 1429 the content being conveyed but an adversary who is able to interpose 1430 herself into the conversation could exclude attributes that a server 1431 may want, include attributes that a server may not want, and render 1432 meaningless other attributes that a server may want. 1434 7. References 1436 7.1. Normative References 1438 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1439 April 1992. 1441 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1442 Extensions (MIME) Part Two: Media Types", RFC 2046, 1443 November 1996. 1445 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1446 Requirement Levels", BCP 14, RFC 2119, March 1997. 1448 [RFC2314] Kaliski, B., "PKCS #10: Certification Request Syntax 1449 Version 1.5", RFC 2314, March 1998. 1451 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 1452 Infrastructure Operational Protocols: FTP and HTTP", 1453 RFC 2585, May 1999. 1455 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1456 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1457 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1459 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1460 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1461 Authentication: Basic and Digest Access Authentication", 1462 RFC 2617, June 1999. 1464 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1466 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 1467 Classes and Attribute Types Version 2.0", RFC 2985, 1468 November 2000. 1470 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1471 Request Syntax Specification Version 1.7", RFC 2986, 1472 November 2000. 1474 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1475 Resource Identifier (URI): Generic Syntax", STD 66, 1476 RFC 3986, January 2005. 1478 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1479 Requirements for Security", BCP 106, RFC 4086, June 2005. 1481 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1482 "Internet X.509 Public Key Infrastructure Certificate 1483 Management Protocol (CMP)", RFC 4210, September 2005. 1485 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1486 Registration Procedures", BCP 13, RFC 4288, December 2005. 1488 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1489 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1491 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1492 Encodings", RFC 4648, October 2006. 1494 [RFC4945] Korver, B., "The Internet IP Security PKI Profile of 1495 IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007. 1497 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1498 "Transport Layer Security (TLS) Session Resumption without 1499 Server-Side State", RFC 5077, January 2008. 1501 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1502 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1504 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 1505 (CMC)", RFC 5272, June 2008. 1507 [RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS 1508 (CMC): Transport Protocols", RFC 5273, June 2008. 1510 [RFC5274] Schaad, J. and M. Myers, "Certificate Management Messages 1511 over CMS (CMC): Compliance Requirements", RFC 5274, 1512 June 2008. 1514 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1515 Housley, R., and W. Polk, "Internet X.509 Public Key 1516 Infrastructure Certificate and Certificate Revocation List 1517 (CRL) Profile", RFC 5280, May 2008. 1519 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1520 RFC 5652, September 2009. 1522 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 1523 "Transport Layer Security (TLS) Renegotiation Indication 1524 Extension", RFC 5746, February 2010. 1526 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 1527 for TLS", RFC 5929, July 2010. 1529 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 1530 August 2010. 1532 [RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, 1533 August 2010. 1535 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1536 Verification of Domain-Based Application Service Identity 1537 within Internet Public Key Infrastructure Using X.509 1538 (PKIX) Certificates in the Context of Transport Layer 1539 Security (TLS)", RFC 6125, March 2011. 1541 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 1542 Updates", RFC 6402, November 2011. 1544 [SHS] National Institute of Standards and Technology, "Federal 1545 Information Processing Standard Publication 180-4: Secure 1546 Hash Standard (SHS)", March 2012, . 1549 [X.680] ITU-T Recommendation, "ITU-T Recommendation X.680 Abstract 1550 Syntax Notation One (ASN.1): Specification of basic 1551 notation", November 2008, 1552 . 1554 [X.690] ITU-T Recommendation, "ITU-T Recommendation X.690 ASN.1 1555 encoding rules: Specification of Basic Encoding Rules 1556 (BER), Canonical Encoding Rules (CER) and Distinguished 1557 Encoding Rules (DER)", November 2008, 1558 . 1560 7.2. Informative References 1562 [IDevID] IEEE Std, "IEEE 802.1AR Secure Device Identifier", 1563 December 2009, . 1566 [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, 1567 August 1998. 1569 [RFC2925] White, K., "Definitions of Managed Objects for Remote 1570 Ping, Traceroute, and Lookup Operations", RFC 2925, 1571 September 2000. 1573 [RFC6403] Zieglar, L., Turner, S., and M. Peck, "Suite B Profile of 1574 Certificate Management over CMS", RFC 6403, November 2011. 1576 [SP-800-57-Part-1] 1577 National Institute of Standards and Technology, 1578 "Recommendation for Key Management - Part 1: General 1579 (Revision 3)", July 2012, . 1583 [X.520] ITU-T Recommendation, "ITU-T Recommendation X.520 The 1584 Directory: Selected attribute types", November 2008, 1585 . 1587 Appendix A. Operational Scenario Example Messages 1589 (informative) 1591 This section expands on the Operational Scenario Overviews by 1592 providing detailed examples of the messages at each TLS layer. 1594 A.1. Obtaining CA Certificates 1596 The following is an example of a valid /CACerts exchange. 1598 During the initial TLS handshake the client can ignore the optional 1599 server generated "certificate request" and can instead proceed with 1600 the HTTP GET request: 1602 GET /CACerts HTTP/1.1 1603 User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 OpenS 1604 SL/0.9.8b zlib/1.2.3 libidn/0.6.5 1605 Host: 127.0.0.1:8085 1606 Accept: */* 1608 In response the server provides the current CA certificate: 1609 <= Recv header, 38 bytes (0x26) 1610 Content-Type: application/pkcs7-mime 1611 == Info: no chunk, no close, no size. Assume close to signal end 1612 <= Recv header, 2 bytes (0x2) 1614 <= Recv data, 1111 bytes (0x457) 1615 -----BEGIN PKCS7-----.MIIDEQYJKoZIhvcNAQcCoIIDAjCCAv4CAQExADALBg 1616 kqhkiG9w0BBwGgggLkMIIC.4DCCAcigAwIBAgIJAOjxMZcXhE5wMA0GCSqGSIb3D 1617 QEBBQUAMBcxFTATBgNVBAMT.DGVzdEV4YW1wbGVDQTAeFw0xMjA3MDQxODM5Mjda 1618 Fw0xMzA3MDQxODM5MjdaMBcx.FTATBgNVBAMTDGVzdEV4YW1wbGVDQTCCASIwDQY 1619 JKoZIhvcNAQEBBQADggEPADCC.AQoCggEBALQ7SjZSt6qrnBzUnBNj9z4oxYkvMA 1620 Vh0OIOVRkNhz/2kDGsds0ne7cw.W33kYlxPba4psdLMixCT/O8ZQMpgA+QFKtwb9 1621 VPE8EFUgGzxSYHQHjhJsbg0BVaN.Ya38vjKMjvosuSXUHwkvU57SInSkMr3/aNtS 1622 T8qFfeC6Vuf/G/GLHGuHQKAy/DSo.206MjaMNmWYRVQQVErGookRA4GBF/YE+G/C 1623 SlTsCQNE0KyBFz8JWIkgYY2gYkxb7.wWMvvhaU/Esp+2DG92v9Dhs2MRgrR+WPs7 1624 Y6CYOLD5Mr5lEdkHg27IxkSAoRrI6D.fnVVEQGCj7QrrsUgfXFVYv6cCWFfhMcCA 1625 wEAAaMvMC0wDAYDVR0TBAUwAwEB/zAd.BgNVHQ4EFgQUhH9KxW5TsjkgL7kg2kxJ 1626 yy5tD/MwDQYJKoZIhvcNAQEFBQADggEB.AD+vydZo292XFb2vXojdKD57Gv4tKVm 1627 hvXRdVInntzkY/0AyFCfHJ4BwndgtMh4t.rvBD8+8dL+W3jfPjcSCcUQ/JEnFuMn 1628 b5+kivLeqOnUshETasFPBz2Xq4C1sHDno9.CWOcsjPPw08Tn4dSrzDBSq1NdXB2z 1629 9NOpaVnbpb01qQGhXSOaEvcbZcDuGiW7Di3.gV++remokuPph/s6XoZffzc7ZVzf 1630 Job6tS4RwNz01sutPybXiRWivOz7+QeCOT87.nTGlkQH/+RImUyJ2jefjAW/GDFT 1631 Pzek6cZnabAtsg32n0Pv0j0/1RTNSdYGxPIVA.2f9fhMqMz+vm3w4CFNkGZnOhAD 1632 EA.-----END PKCS7-----. 1634 A.2. Previously Installed Signature Certificate 1636 The following is an example of a valid /simpleEnroll exchange. 1637 During this exchange the EST client uses an existing certificate 1638 issued by a trusted 3rd party PKI to obtain an initial certificate 1639 from the EST server. 1641 During the initial TLS handshake the server generated "certificate 1642 request" includes both the distinguished name of the CA the EST 1643 server provides services for ("estExampleCA") and it includes the 1644 distinguished name of a trusted 3rd party CA ("estEXTERNALCA"): 1646 0d 00 00 3d 03 01 02 40 00 37 00 1a 30 18 31 16 ...=...@.7..0.1. 1647 30 14 06 03 55 04 03 13 0d 65 73 74 45 58 54 45 0...U....estEXTE 1648 52 4e 41 4c 43 41 00 19 30 17 31 15 30 13 06 03 RNALCA..0.1.0... 1649 55 04 03 13 0c 65 73 74 45 78 61 6d 70 6c 65 43 U....estExampleC 1650 41 A 1652 Which decodes as: 1654 Acceptable client certificate CA names 1655 /CN=estEXTERNALCA 1656 /CN=estExampleCA 1658 The EST client provides a certificate issued by "estEXTERNALCA" in 1659 the certificate response and the TLS handshake proceeds to 1660 completion. The EST server accepts the EST client certificate for 1661 authentication and accepts the EST client's POSTed certificate 1662 request: 1664 POST /simpleEnroll HTTP/1.1 1665 User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 OpenS 1666 SL/0.9.8b zlib/1.2.3 libidn/0.6.5 1667 Host: 127.0.0.1:8085 1668 Accept: */* 1669 Content-Type: application/pkcs10 1670 Content-Length: 952 1672 => Send data, 952 bytes (0x3b8) 1673 -----BEGIN CERTIFICATE REQUEST-----.MIIChjCCAW4CAQAwQTElMCMGA1UE 1674 AxMccmVxIGJ5IGNsaWVudCBpbiBkZW1vIHN0.ZXAgNjEYMBYGA1UEBRMPUElEOld 1675 pZGdldCBTTjo2MIIBIjANBgkqhkiG9w0BAQEF.AAOCAQ8AMIIBCgKCAQEAwhYyI+ 1676 aYezyx+kW0GVUbMKLf2BUd8BgGykkIJYxms6SH.Bv5S4ktcpYbEpR9iCmp96vK6a 1677 Ar57ArZtMmi0Y6eLX4c+njJnYhUeTivnfyfMM5d.hNVwyzKbJagm5f+RLTMfp0y0 1678 ykqrfZ1hFhcNrRzF6mJeaORTHBehMdu8RXcbmy5R.s+vjnUC4Fe3/oLHtXePyYv1 1679 qqlkk0XDrw/+lx0y4Px5tiyb84iPnQOXjG2tuStM+.iEvfpNAnwU0+3GDjl3sjx0 1680 +gTKvblp6Diw9NSaqIAKupcgWsA0JlyYkgPiJnXFKL.vy6rXoOyx3wAbGKLrKCxT 1681 l+RH3oNXf3UCH70aD758QIDAQABoAAwDQYJKoZIhvcN.AQEFBQADggEBADwpafWU 1682 BsOJ2g2oyHQ7Ksw6MwvimjhB7GhjweCcceTSLInUMk10.4E0TfNqaWcoQengMVZr 1683 IcbOb+sa69BWNB/WYIULfEtJIV23/g3n/y3JltMNw/q+R.200t0bNAViijHQHmlF 1684 6dt93tkRrTzXnhV70Ijnff08G7P9HfnXQH4Eiv3zOB6Pak.JoL7QlWQ+w5vHpPo6 1685 WGH5n2iE+Ql76F0HykGeqaR402+ae0WlGLHEvcN9wiFQVKh.KUHteU10SEPijlqf 1686 QW+hciLleX2CwuZY5MqKb4qqyDTs4HSQCBCl8jR2cXsGDuN4.PcMPp+9A1/UPuGD 1687 jhwPt/K3y6aV8zUEh8Ws=.-----END CERTIFICATE REQUEST-----. 1689 The EST server uses the trusted 3rd party CA issued certificate to 1690 perform additional authorization and issues a certificate to the 1691 client: 1693 <= Recv header, 38 bytes (0x26) 1694 Content-Type: application/pkcs7-mime 1695 == Info: no chunk, no close, no size. Assume close to signal end 1696 <= Recv header, 2 bytes (0x2) 1698 <= Recv data, 1200 bytes (0x4b0) 1699 -----BEGIN PKCS7-----.MIIDUQYJKoZIhvcNAQcCoIIDQjCCAz4CAQExADALBg 1700 kqhkiG9w0BBwGgggMkMIID.IDCCAgigAwIBAgIBBjANBgkqhkiG9w0BAQUFADAXM 1701 RUwEwYDVQQDEwxlc3RFeGFt.cGxlQ0EwHhcNMTIwNzA0MTgzOTM3WhcNMTMwNzA0 1702 MTgzOTM3WjBBMSUwIwYDVQQD.ExxyZXEgYnkgY2xpZW50IGluIGRlbW8gc3RlcCA 1703 2MRgwFgYDVQQFEw9QSUQ6V2lk.Z2V0IFNOOjYwggEiMA0GCSqGSIb3DQEBAQUAA4 1704 IBDwAwggEKAoIBAQDCFjIj5ph7.PLH6RbQZVRswot/YFR3wGAbKSQgljGazpIcG/ 1705 lLiS1ylhsSlH2IKan3q8rpoCvns.Ctm0yaLRjp4tfhz6eMmdiFR5OK+d/J8wzl2E 1706 1XDLMpslqCbl/5EtMx+nTLTKSqt9.nWEWFw2tHMXqYl5o5FMcF6Ex27xFdxubLlG 1707 z6+OdQLgV7f+gse1d4/Ji/WqqWSTR.cOvD/6XHTLg/Hm2LJvziI+dA5eMba25K0z 1708 6IS9+k0CfBTT7cYOOXeyPHT6BMq9uW.noOLD01JqogAq6lyBawDQmXJiSA+ImdcU 1709 ou/Lqteg7LHfABsYousoLFOX5Efeg1d./dQIfvRoPvnxAgMBAAGjTTBLMAkGA1Ud 1710 EwQCMAAwHQYDVR0OBBYEFJv4oLLeNxNK.OMmQDDujyNR+zaVPMB8GA1UdIwQYMBa 1711 AFIR/SsVuU7I5IC+5INpMScsubQ/zMA0G.CSqGSIb3DQEBBQUAA4IBAQCMdomfdR 1712 9vi4VUYdF+eym7F8qVUG/1jtjfaxmrzKeZ.7LQ1F758RtwG9CDu2GPHNPjjeM+DJ 1713 RQZN999eLs3Qd/DIJCNimaqdDqmkeBFC5hq.LZOxbKhSmhlR7YKjIZuyI299rOaI 1714 W54ULyz8k0zw6R1/0lMJTsDFGJM+9yDeaARE.n3vtKnUDGHsVU3fYpDENaqUunoU 1715 MZfuEdejfHhU7lVbJI1oSJbnRwBFkPr/RQ3/5.FymcrBD9RpAM5MsQIn0BONil/o 1716 JM+LjOJqyZLbBxz6P3w/OiJGYJNfFT8YudLfjZ.LDX8A8FFcReapNELC4QxE4OrA 1717 hN3sQUT2O7ndIsit4kJoQAxAA==.-----END PKCS7-----. 1719 A.3. Username/Password Distributed Out-of-Band 1721 The following is an example of a valid /simpleEnroll exchange. 1722 During this exchange the EST client uses an out-of-band distributed 1723 username/password to authenticate itself to the EST server. 1725 During the initial TLS handshake the client can ignore the optional 1726 server generated "certificate request" and can instead proceed with 1727 the HTTP POST request: 1729 POST /simpleEnroll HTTP/1.1 1730 User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 OpenS 1731 SL/0.9.8b zlib/1.2.3 libidn/0.6.5 1732 Host: 127.0.0.1:8085 1733 Accept: */* 1734 Content-Type: application/pkcs10 1735 Content-Length: 952 1737 => Send data, 952 bytes (0x3b8) 1738 -----BEGIN CERTIFICATE REQUEST-----.MIIChjCCAW4CAQAwQTElMCMGA1UE 1739 AxMccmVxIGJ5IGNsaWVudCBpbiBkZW1vIHN0.ZXAgMjEYMBYGA1UEBRMPUElEOld 1740 pZGdldCBTTjoyMIIBIjANBgkqhkiG9w0BAQEF.AAOCAQ8AMIIBCgKCAQEAz9lXz9 1741 MowulOx0W5v1k7GKlsNy7mAgmkz/wZDImBDXez.QZCb8lrO8iTD3tI0NH2xpkY3b 1742 uqFjdtQTzCmANLyNWtR1sC5GjN/EM1JSCrO/zZM.ig835RXJTP878N/jNW7EzSxb 1743 /zK5OzKJoRbZ4HgZm4NDapMfMcB4jqBdPxoPAqeR.+KTkv1+9m1vvsdKIs5Hm4Sp 1744 O2WolHPw5BCXdu5zleb6ACih7Zpd2cpHFz6ZHC0G1.Of+F//0BzkFSqWsmUomyJy 1745 WCfLCuX9grs1CNlLxw0gcMprdTxLxjc18z03ZmBCq0.qq5/mUK/tv9R2k8+WuP3a 1746 kzTUIkeHtcp6FVFl3D+TwIDAQABoAAwDQYJKoZIhvcN.AQEFBQADggEBAJH7Etuy 1747 B/oQgQeals08mD2U31FfQ/uYqjNxzZpZJSzVLGMASv9a.pNzaWdfqPdIs+ZZ+gAQ 1748 QkVcXjdbqY3pAf/EeWk+KnuAUjOIPKu3ZBPVbWbXu/Ie7.F1ekQ7TLkFNkHSxHRu 1749 2/bPIByBLRVfWNVXd3wPq+QxqMqgIjBGaTJM5kuHndYFGj.Xdf4rlGRPyOOwG/Xf 1750 QrKBB3tzpbJCy+cwOUAJFPOTO+86RUjf9Wh+yoM182vlg8O.FyEaaA/PMpl3aEcT 1751 BlRZmPx4e7FLwGIhbgE7/6K0nF99xdGd7JYPHasbcWszxD0Z.oPYm+44g0gOnhlj 1752 OWpRiKXcnngSSutRILaw=.-----END CERTIFICATE REQUEST-----. 1753 == Info: upload completely sent off: 952 out of 952 bytes 1754 == Info: HTTP 1.1 or later with persistent connection, pipelining 1755 supported 1757 The EST server accepts this request but since a client certificate 1758 was not provided for authentication/authorization the EST server 1759 responds with the WWW-authenticate header: 1760 <= Recv header, 27 bytes (0x1b) 1761 HTTP/1.1 401 Unauthorized 1762 <= Recv header, 75 bytes (0x4b) 1763 WWW-Authenticate: Digest qop="auth", realm="estrealm", nonce="13 1764 41427174" 1766 The EST client repeats the request, this time including the requested 1767 Authorization header: 1769 == Info: SSL connection using AES256-SHA 1770 == Info: Server certificate: 1771 == Info: subject: CN=127.0.0.1 1772 == Info: start date: 2012-07-04 18:39:27 GMT 1773 == Info: expire date: 2013-07-04 18:39:27 GMT 1774 == Info: common name: 127.0.0.1 (matched) 1775 == Info: issuer: CN=estExampleCA 1776 == Info: SSL certificate verify ok. 1777 == Info: Server auth using Digest with user 'estuser' 1778 => Send header, 416 bytes (0x1a0) 1779 POST /simpleEnroll HTTP/1.1 1780 Authorization: Digest username="estuser", realm="estrealm", nonc 1781 e="1341427174", uri="/simpleEnroll", cnonce="ODc0OTk2", nc=00000 1782 001, qop="auth", response="48a2b671ccb6596adfef039e134b7d5d" 1783 User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 OpenS 1784 SL/0.9.8b zlib/1.2.3 libidn/0.6.5 1785 Host: 127.0.0.1:8085 1786 Accept: */* 1787 Content-Type: application/pkcs10 1788 Content-Length: 952 1790 => Send data, 952 bytes (0x3b8) 1791 -----BEGIN CERTIFICATE REQUEST-----.MIIChjCCAW4CAQAwQTElMCMGA1UE 1792 AxMccmVxIGJ5IGNsaWVudCBpbiBkZW1vIHN0.ZXAgMjEYMBYGA1UEBRMPUElEOld 1793 pZGdldCBTTjoyMIIBIjANBgkqhkiG9w0BAQEF.AAOCAQ8AMIIBCgKCAQEAz9lXz9 1794 MowulOx0W5v1k7GKlsNy7mAgmkz/wZDImBDXez.QZCb8lrO8iTD3tI0NH2xpkY3b 1795 uqFjdtQTzCmANLyNWtR1sC5GjN/EM1JSCrO/zZM.ig835RXJTP878N/jNW7EzSxb 1796 /zK5OzKJoRbZ4HgZm4NDapMfMcB4jqBdPxoPAqeR.+KTkv1+9m1vvsdKIs5Hm4Sp 1797 O2WolHPw5BCXdu5zleb6ACih7Zpd2cpHFz6ZHC0G1.Of+F//0BzkFSqWsmUomyJy 1798 WCfLCuX9grs1CNlLxw0gcMprdTxLxjc18z03ZmBCq0.qq5/mUK/tv9R2k8+WuP3a 1799 kzTUIkeHtcp6FVFl3D+TwIDAQABoAAwDQYJKoZIhvcN.AQEFBQADggEBAJH7Etuy 1800 B/oQgQeals08mD2U31FfQ/uYqjNxzZpZJSzVLGMASv9a.pNzaWdfqPdIs+ZZ+gAQ 1801 QkVcXjdbqY3pAf/EeWk+KnuAUjOIPKu3ZBPVbWbXu/Ie7.F1ekQ7TLkFNkHSxHRu 1802 2/bPIByBLRVfWNVXd3wPq+QxqMqgIjBGaTJM5kuHndYFGj.Xdf4rlGRPyOOwG/Xf 1803 QrKBB3tzpbJCy+cwOUAJFPOTO+86RUjf9Wh+yoM182vlg8O.FyEaaA/PMpl3aEcT 1804 BlRZmPx4e7FLwGIhbgE7/6K0nF99xdGd7JYPHasbcWszxD0Z.oPYm+44g0gOnhlj 1805 OWpRiKXcnngSSutRILaw=.-----END CERTIFICATE REQUEST-----. 1807 The ESTserver uses the username/password to perform authentication/ 1808 authorization and responds with the issued certificate: 1810 <= Recv header, 38 bytes (0x26) 1811 0000: Content-Type: application/pkcs7-mime 1812 == Info: no chunk, no close, no size. Assume close to signal end 1813 <= Recv header, 2 bytes (0x2) 1815 <= Recv data, 1200 bytes (0x4b0) 1816 -----BEGIN PKCS7-----.MIIDUQYJKoZIhvcNAQcCoIIDQjCCAz4CAQExADALBg 1817 kqhkiG9w0BBwGgggMkMIID.IDCCAgigAwIBAgIBAjANBgkqhkiG9w0BAQUFADAXM 1818 RUwEwYDVQQDEwxlc3RFeGFt.cGxlQ0EwHhcNMTIwNzA0MTgzOTM0WhcNMTMwNzA0 1819 MTgzOTM0WjBBMSUwIwYDVQQD.ExxyZXEgYnkgY2xpZW50IGluIGRlbW8gc3RlcCA 1820 yMRgwFgYDVQQFEw9QSUQ6V2lk.Z2V0IFNOOjIwggEiMA0GCSqGSIb3DQEBAQUAA4 1821 IBDwAwggEKAoIBAQDP2VfP0yjC.6U7HRbm/WTsYqWw3LuYCCaTP/BkMiYENd7NBk 1822 JvyWs7yJMPe0jQ0fbGmRjdu6oWN.21BPMKYA0vI1a1HWwLkaM38QzUlIKs7/NkyK 1823 DzflFclM/zvw3+M1bsTNLFv/Mrk7.MomhFtngeBmbg0Nqkx8xwHiOoF0/Gg8Cp5H 1824 4pOS/X72bW++x0oizkebhKk7ZaiUc./DkEJd27nOV5voAKKHtml3ZykcXPpkcLQb 1825 U5/4X//QHOQVKpayZSibInJYJ8sK5f.2CuzUI2UvHDSBwymt1PEvGNzXzPTdmYEK 1826 rSqrn+ZQr+2/1HaTz5a4/dqTNNQiR4e.1ynoVUWXcP5PAgMBAAGjTTBLMAkGA1Ud 1827 EwQCMAAwHQYDVR0OBBYEFChDQpKEfG9c.e4JaMf8438tb2XOIMB8GA1UdIwQYMBa 1828 AFIR/SsVuU7I5IC+5INpMScsubQ/zMA0G.CSqGSIb3DQEBBQUAA4IBAQAn42mIVG 1829 piaY4yqFD0F8KyUhKsdNnyKeeISQxP//lp.quIieJzdWSc7bhWZNldSzNswCod8B 1830 4eJToQejLSNb8JBDC849z0tcuyHgN6N/p8z.IwI+hAlfXS9q02OECyFes4Jmzc7r 1831 erE5jtOdGsEDBIscw/A+Kv86wv6BKbagMslQ.51AJyPsL6iBhm7LPFrErJgH2kWN 1832 jDKFH9CcVFjXvgriMrLPFeqQWOpj/2XF+4m+c.f9QP5tSjieHJR1hnYk2tlodfE7 1833 iV4pJ07Mmf3yBf753VSUVybqWiMCd0Lm7oghSX.E2GAxrsU1N+N1odn+gJ2wmxTu 1834 AC2aHt9VPRViov4RRTvoQAxAA==.-----END PKCS7-----. 1836 A.4. Re-Enrollment 1838 The following is an example of a valid /simpleReEnroll exchange. 1839 During this exchange the EST client authenticates itself using an 1840 existing certificate issued by the CA the EST server provides 1841 services for. 1843 Initially this exchange is identical to enrollment using an 1844 externally issued certificate for client authentication since the 1845 server is not yet aware of the client's intention. As in that 1846 example the EST server the server generated "certificate request" 1847 includes both the distinguished name of the CA the EST server 1848 provides services for ("estExampleCA") and it includes the 1849 distinguished name of a trusted 3rd party CA ("estEXTERNALCA"). 1851 0d 00 00 3d 03 01 02 40 00 37 00 1a 30 18 31 16 ...=...@.7..0.1. 1852 30 14 06 03 55 04 03 13 0d 65 73 74 45 58 54 45 0...U....estEXTE 1853 52 4e 41 4c 43 41 00 19 30 17 31 15 30 13 06 03 RNALCA..0.1.0... 1854 55 04 03 13 0c 65 73 74 45 78 61 6d 70 6c 65 43 U....estExampleC 1855 41 A 1857 In text format this is: 1859 Acceptable client certificate CA names 1860 /CN=estEXTERNALCA 1861 /CN=estExampleCA 1863 The EST client provides a certificate issued by "estExampleCA" in the 1864 certificate response and the TLS handshake proceeds to completion. 1865 The EST server accepts the EST client certificate for authentication 1866 and accepts the EST client's POSTed certificate request. 1868 The rest of the protocol traffic is effectively identical to a normal 1869 enrollment. 1871 A.5. Server Key Generation 1873 The following is an example of a valid /serverKeyGen exchange. 1874 During this exchange the EST client authenticates itself using an 1875 existing certificate issued by the CA the EST server provides 1876 services for. 1878 The initial TLS handshake is identical to the enrollment example 1879 handshake. The HTTP POSTed message is: 1881 POST /serverKeyGen HTTP/1.1 1882 User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 OpenS 1883 SL/0.9.8b zlib/1.2.3 libidn/0.6.5 1884 Host: 127.0.0.1:8085 1885 Accept: */* 1886 Content-Type: application/pkcs10 1887 Content-Length: 968 1889 => Send data, 968 bytes (0x3c8) 1890 -----BEGIN CERTIFICATE REQUEST-----.MIICkzCCAXsCAQAwTjEyMDAGA1UE 1891 AxMpc2VydmVyS2V5R2VuIHJlcSBieSBjbGll.bnQgaW4gZGVtbyBzdGVwIDUxGDA 1892 WBgNVBAUTD1BJRDpXaWRnZXQgU046NTCCASIw.DQYJKoZIhvcNAQEBBQADggEPAD 1893 CCAQoCggEBAMnlUlq0ag/fDAVhLgrXEAD6WtZw.Y2rVGev5saWirer2n0OzghB59 1894 uJByxPo0DYBYqZRuoRF0FTL1ZZTMaZxivge0ecA.ZcoR46jwSBoceMT1jkwFyAER 1895 t9Q2EwdnJLIPo/Ib2PLJNb4Jo8NNKmxtg55BgIVi.vkIB+rMtLeYRUVL0RUaBAqX 1896 FmtXRDceVFIEY24iUQw6vESGJKpArht592aT8lyaP.24bZovuG19dd5xtTX3j37K 1897 x49SlkUvLSpD6ZavIFAZn7Yv19LBKHvRIemybUo294.QeLb/VYP1O+EAthV/igiX 1898 1DHqlUZCZp5SdyUXUwZPatFboNwEVR0R3MJwVECAwEA.AaAAMA0GCSqGSIb3DQEB 1899 BQUAA4IBAQAqhHezK5/tvbXleHO/aTBVYO9l414NM+WA.wJcnS2UaJYScPBqlYK/ 1900 gij+dqAtFE+5ukAj56t7HnooI4EFo9r8jqCHewx7iLZYh.JDxo4hWOsAvHV+Iziy 1901 jkhJNdHBIqGM7Gd5f/2VJLEPQPmwNOL5P+2O4eQC/QeEYc.bAmfhOS8b/ZH09/9T 1902 PeaeQpjspjOui/100OuLE8KvU3FM0sXMYt1Va0A0jxzl+5k.EiEJo+ltXsQwdP0H 1903 csoTNBN+j3K18omJQS0e91X8v0xkMWYhUtonXD0YZ6SO/B9c.AE6GTADHA/xpSvA 1904 cqlWa+FHxjwEMXdmViHvMUywo31fDZ/TUvCPX.-----END CERTIFICATE REQUE 1905 ST-----. 1907 After processing the request the EST server response is: 1908 <= Recv header, 17 bytes (0x11) 1909 HTTP/1.1 200 OK 1910 <= Recv header, 16 bytes (0x10) 1911 Status: 200 OK 1912 <= Recv header, 67 bytes (0x43) 1913 Content-Type: multipart/mixed ; boundary=estServerExampleBoundar 1914 y 1915 == Info: no chunk, no close, no size. Assume close to signal end 1916 <= Recv header, 2 bytes (0x2) 1918 <= Recv data, 3234 bytes (0xca2) 1919 This is the preamble. It is to be ignored, though it.is a handy 1920 place for estServer to include an explanatory note.including con 1921 tact or support information..--estServerExampleBoundary.Content- 1922 Type=application/pkcs8..-----BEGIN PRIVATE KEY-----.MIIEvQIBADAN 1923 BgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC0781l7tri0yii.Mb9ZZYch8ze 1924 izXrjMPF/Rxoz2C9IU2THCrhPGXGQMne/zivce0m8/BMkkUc+DsSM.tzxn4l+9tI 1925 sVDkAe4FyzN0hLd/zawgj6kUoCi3mxZnb2rWaRYAmM5w41ImDV3blv.aMUKDSJhV 1926 bQ+z/G1W1TRx3iWi5CMHYb+1pJXPTJz/GuWr/b/+Efqwz2ZlwGcj4Dx.Igbx9vG0 1927 mftIIxM4TUX28KBbaLgJbalsiuOx3C2bEyaSPerdzqgvXFHGGAhg1FU8.DQiQEki 1928 nn66GPMtm1SNgitxFxWouFqpsax5MWn/i52TfEaF2PNThOuzKtilweJhk.g0gMIQ 1929 TXAgMBAAECggEANlrz8XNX/lxBELixK0H83o4aYKYqDKZfZkUN8hU33xpu.Y/0sc 1930 VbLbu46WzysoIfJFyUC+zFJnbMCCOPjGbI/4NWkEqc9TAlKz+wDo+hf5bf0.ypFr 1931 EmikHk8R3fkpnvKi69ldw0iYnqcFVhq7VtGrSmJcy6Hckwbk7EBoUZGL0wtp.xlO 1932 6XlhksAvn8+75qoWzsNhi7S/L0IVCVLbUaV3hodTHlH5M4daFbqyRWD7UiPKt.Q3 1933 hdw1rpyVZg8ZbBFp0Ej4f9GdRaq88SIKMKCDu3t9ibn/v1kEte+PxhuwyW+d0o.h 1934 kKSEW0yLKCzQm5tujsPq0UVzPBkLJACUnFAi+a4AQKBgQDu6VLH2eYoTjPPTyAv. 1935 vOJnNWP7oMzyJ4/eFqdE9m+2Ajm/0qaMY95ftZ+GpEKggvC6Z5DFevEmgH4Sg2+G 1936 .gFd93diyRPScVbNE8SmpXxLPU2UoykVmICuQZzLDNE18B3buxAm2GJ219NEnZOe 1937 c.jPMOV/IcG1aLzTqQssL3zo/0gQKBgQDB4Olpg3EBggtJ/+dlkLHUw8c7Pe3UyL 1938 kS.VxVsyQwioYt8xMeCWuPvPNFcOjcW53KN/YSpCVjpttKGsPtLibMlKYKgasEqg 1939 cvl.Vb5OFtA/jNAP3mdAgCzBn6IF1NhVQe2dclo5puZ0gO38HDWq7EtqSi9Q0JSM 1940 g3YC.QNcOORptVwKBgQCHrCafaYWDhA11/+g2U9x6Yd56ifF43rCbnV+2EQCVaqQ 1941 i49xC.w4AH+Bs0mdlgT5unL6MOEmgZxkRR/SP7TKzixHYHnpMOqLhaQV24Wk5TQH 1942 ek92D7.wu8aXRB9vBj4g0CuDNO6/jWpm/KenXXN+Fka3ySVg4zdbVmBzJJdqYckg 1943 QKBgFXS.zSBzGgwz1/F7AaDZK49m1wPnhyeBb0OqHwbX/LI71rZ1mWef+nSF9Juh 1944 /Y77B5/J.UPdO9vgGgS00nRk0LIRP2s5OU5IQgQTVLvf8a1UmbVgI+KX511Yi5yM 1945 ztEwRcjEX.VM9ejXeXN0I57pvqG/xCOK3Kl2eYLh4TO9/E8WjjAoGAA1mqUV4Hnf 1946 4yvF1rydMp.fpvoWekiiRE33iEbYZNATYhsl7uxwn760pqVifkq2DSrZeYm4+lw9 1947 jwWMtUoPzpg.CJYMoGl846nhiZrbbJ5b5twoLV6GRmkk/CfOxPXNzCtSoQA86HHq 1948 7rRdhXSau/bY.EXc91tnhLjFzZxdBgrd+f4k=.-----END PRIVATE KEY-----. 1949 --estServerExampleBoundary.Content-Type: application/pkcs7-mime. 1950 .-----BEGIN PKCS7-----.MIIDPAYJKoZIhvcNAQcCoIIDLTCCAykCAQExADALB 1951 gkqhkiG9w0BBwGgggMPMIID.CzCCAfOgAwIBAgIBBTANBgkqhkiG9w0BAQUFADAX 1952 MRUwEwYDVQQDEwxlc3RFeGFt.cGxlQ0EwHhcNMTIwNzA0MTgzOTM2WhcNMTMwNzA 1953 0MTgzOTM2WjAsMSowKAYDVQQD.EyFzZXJ2ZXJzaWRlIGtleSBnZW5lcmF0ZWQgcm 1954 VzcG9uc2UwggEiMA0GCSqGSIb3.DQEBAQUAA4IBDwAwggEKAoIBAQC0781l7tri0 1955 yiiMb9ZZYch8zeizXrjMPF/Rxoz.2C9IU2THCrhPGXGQMne/zivce0m8/BMkkUc+ 1956 DsSMtzxn4l+9tIsVDkAe4FyzN0hL.d/zawgj6kUoCi3mxZnb2rWaRYAmM5w41ImD 1957 V3blvaMUKDSJhVbQ+z/G1W1TRx3iW.i5CMHYb+1pJXPTJz/GuWr/b/+Efqwz2Zlw 1958 Gcj4DxIgbx9vG0mftIIxM4TUX28KBb.aLgJbalsiuOx3C2bEyaSPerdzqgvXFHGG 1959 Ahg1FU8DQiQEkinn66GPMtm1SNgitxF.xWouFqpsax5MWn/i52TfEaF2PNThOuzK 1960 tilweJhkg0gMIQTXAgMBAAGjTTBLMAkG.A1UdEwQCMAAwHQYDVR0OBBYEFLylcQN 1961 0D5xTfRdayv+0GDULR2+EMB8GA1UdIwQY.MBaAFIR/SsVuU7I5IC+5INpMScsubQ 1962 /zMA0GCSqGSIb3DQEBBQUAA4IBAQButIeM.DB9PkwlGGe7zqvUWVD8y99zowwV6A 1963 rAOXWX+JO0bihgMtZaUfvPCX/LhZVEKDAki.W5orjAEvIu10b6l38ZzX2oyJgkYy 1964 Mmbb14lzTsRyjiqFw9j1PXxwgZvhwcaCF4b7.eDUUBQIeZg3AnkQrEwnHR5oVIN5 1965 8qo0P7PSKC3Vl3H6DlQh3y7w87nN12923/wk0.v/bS3lv7lDX3HdmbQD1r2KPtBs 1966 JGF4jMdstT7FTx32ZFKObycbK7WJ4LHytNJDci.4iXf+B0S3D6Zbf1cXj80/W+jC 1967 GvU0+4SV3cgEXFE5VQvXd8x40W4h0dTSkQCDPOS.nPj4Dl/PsLqX3lDboQAxAA== 1968 .-----END PKCS7-----.--estServerExampleBoundary--.This is the ep 1969 ilogue. It is also to be ignored.. 1971 In text format this is: 1973 HTTP/1.1 200 OK 1974 Status: 200 OK 1975 Content-Type: multipart/mixed ; boundary=estServerExampleBoundary 1976 This is the preamble. It is to be ignored, though it 1977 is a handy place for estServer to include an explanatory note 1978 including contact or support information. 1979 --estServerExampleBoundary 1980 Content-Type=application/pkcs8 1982 -----BEGIN PRIVATE KEY----- 1983 MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC0781l7tri0yii 1984 Mb9ZZYch8zeizXrjMPF/Rxoz2C9IU2THCrhPGXGQMne/zivce0m8/BMkkUc+DsSM 1985 tzxn4l+9tIsVDkAe4FyzN0hLd/zawgj6kUoCi3mxZnb2rWaRYAmM5w41ImDV3blv 1986 aMUKDSJhVbQ+z/G1W1TRx3iWi5CMHYb+1pJXPTJz/GuWr/b/+Efqwz2ZlwGcj4Dx 1987 Igbx9vG0mftIIxM4TUX28KBbaLgJbalsiuOx3C2bEyaSPerdzqgvXFHGGAhg1FU8 1988 DQiQEkinn66GPMtm1SNgitxFxWouFqpsax5MWn/i52TfEaF2PNThOuzKtilweJhk 1989 g0gMIQTXAgMBAAECggEANlrz8XNX/lxBELixK0H83o4aYKYqDKZfZkUN8hU33xpu 1990 Y/0scVbLbu46WzysoIfJFyUC+zFJnbMCCOPjGbI/4NWkEqc9TAlKz+wDo+hf5bf0 1991 ypFrEmikHk8R3fkpnvKi69ldw0iYnqcFVhq7VtGrSmJcy6Hckwbk7EBoUZGL0wtp 1992 xlO6XlhksAvn8+75qoWzsNhi7S/L0IVCVLbUaV3hodTHlH5M4daFbqyRWD7UiPKt 1993 Q3hdw1rpyVZg8ZbBFp0Ej4f9GdRaq88SIKMKCDu3t9ibn/v1kEte+PxhuwyW+d0o 1994 hkKSEW0yLKCzQm5tujsPq0UVzPBkLJACUnFAi+a4AQKBgQDu6VLH2eYoTjPPTyAv 1995 vOJnNWP7oMzyJ4/eFqdE9m+2Ajm/0qaMY95ftZ+GpEKggvC6Z5DFevEmgH4Sg2+G 1996 gFd93diyRPScVbNE8SmpXxLPU2UoykVmICuQZzLDNE18B3buxAm2GJ219NEnZOec 1997 jPMOV/IcG1aLzTqQssL3zo/0gQKBgQDB4Olpg3EBggtJ/+dlkLHUw8c7Pe3UyLkS 1998 VxVsyQwioYt8xMeCWuPvPNFcOjcW53KN/YSpCVjpttKGsPtLibMlKYKgasEqgcvl 1999 Vb5OFtA/jNAP3mdAgCzBn6IF1NhVQe2dclo5puZ0gO38HDWq7EtqSi9Q0JSMg3YC 2000 QNcOORptVwKBgQCHrCafaYWDhA11/+g2U9x6Yd56ifF43rCbnV+2EQCVaqQi49xC 2001 w4AH+Bs0mdlgT5unL6MOEmgZxkRR/SP7TKzixHYHnpMOqLhaQV24Wk5TQHek92D7 2002 wu8aXRB9vBj4g0CuDNO6/jWpm/KenXXN+Fka3ySVg4zdbVmBzJJdqYckgQKBgFXS 2003 zSBzGgwz1/F7AaDZK49m1wPnhyeBb0OqHwbX/LI71rZ1mWef+nSF9Juh/Y77B5/J 2004 UPdO9vgGgS00nRk0LIRP2s5OU5IQgQTVLvf8a1UmbVgI+KX511Yi5yMztEwRcjEX 2005 VM9ejXeXN0I57pvqG/xCOK3Kl2eYLh4TO9/E8WjjAoGAA1mqUV4Hnf4yvF1rydMp 2006 fpvoWekiiRE33iEbYZNATYhsl7uxwn760pqVifkq2DSrZeYm4+lw9jwWMtUoPzpg 2007 CJYMoGl846nhiZrbbJ5b5twoLV6GRmkk/CfOxPXNzCtSoQA86HHq7rRdhXSau/bY 2008 EXc91tnhLjFzZxdBgrd+f4k= 2009 -----END PRIVATE KEY----- 2010 --estServerExampleBoundary 2011 Content-Type: application/pkcs7-mime 2013 -----BEGIN PKCS7----- 2014 MIIDPAYJKoZIhvcNAQcCoIIDLTCCAykCAQExADALBgkqhkiG9w0BBwGgggMPMIID 2015 CzCCAfOgAwIBAgIBBTANBgkqhkiG9w0BAQUFADAXMRUwEwYDVQQDEwxlc3RFeGFt 2016 cGxlQ0EwHhcNMTIwNzA0MTgzOTM2WhcNMTMwNzA0MTgzOTM2WjAsMSowKAYDVQQD 2017 EyFzZXJ2ZXJzaWRlIGtleSBnZW5lcmF0ZWQgcmVzcG9uc2UwggEiMA0GCSqGSIb3 2018 DQEBAQUAA4IBDwAwggEKAoIBAQC0781l7tri0yiiMb9ZZYch8zeizXrjMPF/Rxoz 2019 2C9IU2THCrhPGXGQMne/zivce0m8/BMkkUc+DsSMtzxn4l+9tIsVDkAe4FyzN0hL 2020 d/zawgj6kUoCi3mxZnb2rWaRYAmM5w41ImDV3blvaMUKDSJhVbQ+z/G1W1TRx3iW 2021 i5CMHYb+1pJXPTJz/GuWr/b/+Efqwz2ZlwGcj4DxIgbx9vG0mftIIxM4TUX28KBb 2022 aLgJbalsiuOx3C2bEyaSPerdzqgvXFHGGAhg1FU8DQiQEkinn66GPMtm1SNgitxF 2023 xWouFqpsax5MWn/i52TfEaF2PNThOuzKtilweJhkg0gMIQTXAgMBAAGjTTBLMAkG 2024 A1UdEwQCMAAwHQYDVR0OBBYEFLylcQN0D5xTfRdayv+0GDULR2+EMB8GA1UdIwQY 2025 MBaAFIR/SsVuU7I5IC+5INpMScsubQ/zMA0GCSqGSIb3DQEBBQUAA4IBAQButIeM 2026 DB9PkwlGGe7zqvUWVD8y99zowwV6ArAOXWX+JO0bihgMtZaUfvPCX/LhZVEKDAki 2027 W5orjAEvIu10b6l38ZzX2oyJgkYyMmbb14lzTsRyjiqFw9j1PXxwgZvhwcaCF4b7 2028 eDUUBQIeZg3AnkQrEwnHR5oVIN58qo0P7PSKC3Vl3H6DlQh3y7w87nN12923/wk0 2029 v/bS3lv7lDX3HdmbQD1r2KPtBsJGF4jMdstT7FTx32ZFKObycbK7WJ4LHytNJDci 2030 4iXf+B0S3D6Zbf1cXj80/W+jCGvU0+4SV3cgEXFE5VQvXd8x40W4h0dTSkQCDPOS 2031 nPj4Dl/PsLqX3lDboQAxAA== 2032 -----END PKCS7----- 2033 --estServerExampleBoundary-- 2034 This is the epilogue. It is also to be ignored. 2036 A.6. CSR Attributes 2038 The following is an example of a valid /CSRAttrs exchange. During 2039 this exchange the EST client authenticates itself using an existing 2040 certificate issued by the CA the EST server provides services for. 2042 The initial TLS handshake is identical to the enrollment example 2043 handshake. The HTTP GET request: 2044 GET /CSRAttrs HTTP/1.1 2045 User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenS 2046 SL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 2047 Host: 127.0.0.1:8085 2048 Accept: */* 2050 In response the server provides suggested attributes that are 2051 appropriate for the authenticated client: 2052 <= Recv header, 36 bytes (0x24) 2053 Content-Type: application/csrattrs 2054 == Info: no chunk, no close, no size. Assume close to signal end 2055 <= Recv header, 2 bytes (0x2) 2057 <= Recv data, 33 bytes (0x21) 2058 0000: MBQGBysGAQEBARYGCSqGSIb3DQEJBw==. 2060 Authors' Addresses 2062 Max Pritikin (editor) 2063 Cisco Systems, Inc. 2064 510 McCarthy Drive 2065 Milpitas, CA 95035 2066 USA 2068 Email: pritikin@cisco.com 2069 Peter E. Yee (editor) 2070 AKAYLA, Inc. 2071 7150 Moorland Drive 2072 Clarksville, MD 21029 2073 USA 2075 Email: peter@akayla.com 2077 Dan Harkins (editor) 2078 Aruba Networks 2079 1322 Crossman Avenue 2080 Sunnyvale, CA 94089-1113 2081 USA 2083 Email: dharkins@arubanetworks.com