idnits 2.17.1 draft-ietf-pkix-est-05.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 7 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 (February 24, 2013) is 4077 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 750, but not defined ** Obsolete undefined reference: RFC 5751 (Obsoleted by RFC 8551) == Unused Reference: 'RFC1321' is defined on line 1616, but no explicit reference was found in the text == Unused Reference: 'RFC2986' is defined on line 1648, but no explicit reference was found in the text == Unused Reference: 'RFC5652' is defined on line 1705, but no explicit reference was found in the text == Unused Reference: 'RFC2712' is defined on line 1759, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 2314 (Obsoleted by RFC 2986) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Downref: Normative reference to an Informational RFC: RFC 2985 ** Downref: Normative reference to an Informational RFC: RFC 2986 ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) ** Downref: Normative reference to an Informational RFC: RFC 5054 ** Obsolete normative reference: RFC 5077 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Downref: Normative reference to an Informational RFC: RFC 5967 ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' Summary: 16 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX M. Pritikin, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track P. Yee, Ed. 5 Expires: August 28, 2013 AKAYLA, Inc. 6 D. Harkins, Ed. 7 Aruba Networks 8 February 24, 2013 10 Enrollment over Secure Transport 11 draft-ietf-pkix-est-05 13 Abstract 15 This document profiles certificate enrollment for clients using 16 Certificate Management over CMS (CMC) messages over a secure 17 transport. This profile, called Enrollment over Secure Transport 18 (EST), describes a simple yet functional certificate management 19 protocol targeting Public Key Infrastructure (PKI) clients that need 20 to acquire client certificates and associated Certification Authority 21 (CA) certificate(s). It also supports client-generated public/ 22 private key pairs as well as key pairs generated by the CA. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 28, 2013. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 60 2. Operational Scenario Overviews . . . . . . . . . . . . . . . . 6 61 2.1. Obtaining CA Certificates . . . . . . . . . . . . . . . . 7 62 2.2. Initial Enrollment . . . . . . . . . . . . . . . . . . . . 8 63 2.2.1. Certificate TLS authentication . . . . . . . . . . . . 8 64 2.2.2. Certificate-less TLS authentication . . . . . . . . . 8 65 2.2.3. HTTP-based client authentication . . . . . . . . . . . 9 66 2.3. Client Certificate Re-issuance . . . . . . . . . . . . . . 9 67 2.4. Server Key Generation . . . . . . . . . . . . . . . . . . 9 68 2.5. Full PKI Request messages . . . . . . . . . . . . . . . . 9 69 2.6. Certificate Signing Request (CSR) Attributes Request . . . 9 70 3. Protocol Design and Layering . . . . . . . . . . . . . . . . . 10 71 3.1. Application Layer . . . . . . . . . . . . . . . . . . . . 14 72 3.2. HTTP Layer . . . . . . . . . . . . . . . . . . . . . . . . 15 73 3.2.1. HTTP headers for control . . . . . . . . . . . . . . . 15 74 3.2.2. HTTP URIs for control . . . . . . . . . . . . . . . . 16 75 3.2.3. HTTP-Based Client Authentication . . . . . . . . . . . 17 76 3.2.4. Message types . . . . . . . . . . . . . . . . . . . . 18 77 3.3. TLS Layer . . . . . . . . . . . . . . . . . . . . . . . . 19 78 3.3.1. TLS-Based Server Authentication . . . . . . . . . . . 20 79 3.3.2. TLS-Based Client Authentication . . . . . . . . . . . 20 80 3.3.3. Certificate-less TLS Mutual Authentication . . . . . . 21 81 3.4. Proof-of-Possession . . . . . . . . . . . . . . . . . . . 21 82 3.5. Linking Identity and PoP information . . . . . . . . . . . 22 83 3.6. Server Authorization . . . . . . . . . . . . . . . . . . . 23 84 3.6.1. Client use of Explicit TA Database . . . . . . . . . . 23 85 3.6.2. Client use of Implicit TA Database . . . . . . . . . . 23 86 3.7. Client Authorization . . . . . . . . . . . . . . . . . . . 23 87 4. Protocol Exchange Details . . . . . . . . . . . . . . . . . . 24 88 4.1. Distribution of CA certificates . . . . . . . . . . . . . 24 89 4.1.1. Bootstrap Distribution of CA certificates . . . . . . 24 90 4.1.2. Distribution of CA certificates request . . . . . . . 25 91 4.1.3. Distribution of CA certificates response . . . . . . . 25 92 4.2. Client Certificate Request Functions . . . . . . . . . . . 26 93 4.2.1. Simple Enrollment of Clients . . . . . . . . . . . . . 27 94 4.2.2. Simple Re-Enrollment of Clients . . . . . . . . . . . 28 95 4.2.3. Simple Enroll and Re-Enroll Response . . . . . . . . . 28 97 4.3. Full CMC . . . . . . . . . . . . . . . . . . . . . . . . . 29 98 4.3.1. Full CMC Request . . . . . . . . . . . . . . . . . . . 29 99 4.3.2. Full CMC Response . . . . . . . . . . . . . . . . . . 29 100 4.4. Server-side Key Generation . . . . . . . . . . . . . . . . 30 101 4.4.1. Server-side Key Generation Request . . . . . . . . . . 30 102 4.4.2. Server-side Key Generation Response . . . . . . . . . 31 103 4.5. CSR Attributes . . . . . . . . . . . . . . . . . . . . . . 32 104 4.5.1. CSR Attributes Request . . . . . . . . . . . . . . . . 32 105 4.5.2. CSR Attributes Response . . . . . . . . . . . . . . . 32 106 5. Contributors/Acknowledgements . . . . . . . . . . . . . . . . 34 107 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 108 7. Security Considerations . . . . . . . . . . . . . . . . . . . 35 109 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 110 8.1. Normative References . . . . . . . . . . . . . . . . . . . 37 111 8.2. Informative References . . . . . . . . . . . . . . . . . . 40 112 Appendix A. Operational Scenario Example Messages . . . . . . . . 41 113 A.1. Obtaining CA Certificates . . . . . . . . . . . . . . . . 41 114 A.2. Certificate TLS authentication . . . . . . . . . . . . . . 42 115 A.3. Username/Password Distributed Out-of-Band . . . . . . . . 44 116 A.4. Re-Enrollment . . . . . . . . . . . . . . . . . . . . . . 47 117 A.5. Server Key Generation . . . . . . . . . . . . . . . . . . 48 118 A.6. CSR Attributes . . . . . . . . . . . . . . . . . . . . . . 52 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 121 1. Introduction 123 This document profiles certificate enrollment for clients using 124 Certificate Management over CMS (CMC) [RFC5272] messages over a 125 secure transport. Enrollment over Secure Transport (EST) describes 126 the use of Transport Layer Security (TLS) 1.1 [RFC4346] (or a later 127 version) and Hypertext Transfer Protocol (HTTP) 1.1 [RFC2616] (or a 128 later version) to provide an authenticated and authorized channel for 129 Simple PKI (Public Key Infrastructure) Requests and Responses 130 [RFC5272]. 132 Architecturally, the EST service is located between a CA and a client 133 device. It performs several functions traditionally allocated to the 134 RA (Registration Authority) role in a PKI. The nature of 135 communication between an EST server and a CA is not described in this 136 document. 138 EST adopts the Certificate Management Protocol (CMP) [RFC4210] model 139 for CA certificate rollover, but does not use the CMP message syntax 140 or protocol. EST servers are extensible in that new functions may be 141 defined to provide additional capabilities not specified in CMC 142 [RFC5272], and this document defines two such extensions, one for 143 requesting Certificate Signing Request attributes, and another for 144 requesting server-generated keys. 146 EST specifies how to transfer messages securely via HTTP over TLS 147 (HTTPS) [RFC2818], where the HTTP headers and content types are used 148 in conjunction with TLS. HTTPS operates over TCP; this document does 149 not specify EST over Datagram Transport Layer Security/User Datagram 150 Protocol (DTLS/UDP). Figure 1 shows how the layers build upon each 151 other. 153 EST Layering: 155 Protocols: 156 +--------------------------------------------+ 157 | | 158 | EST request/response messages | 159 | | 160 +--------------------------------------------+ 161 | | 162 | HTTP for message transfer and signaling | 163 | | 164 +--------------------------------------------+ 165 | | 166 | TLS for transport security | 167 | | 168 +--------------------------------------------+ 169 | | 170 | TCP for transport | 171 | | 172 +--------------------------------------------+ 174 Figure 1 176 [[EDNOTE: Comments such as this one, included within double brackets 177 and initiated with an 'EDNOTE', are for editorial use and shall be 178 removed as the document is polished.]] 180 1.1. Terminology 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in [RFC2119]. 186 It is assumed that the reader is familiar with the terms and concepts 187 described in Public Key Cryptography Standard (PKCS) #10 [RFC2314], 188 HTTPS [RFC2818], CMP [RFC4210], CMC [RFC5272][RFC5273][RFC5274], and 189 TLS [RFC4346]. 191 In addition to the terms defined in the terminology section of CMC 192 [RFC5272] the following terms are defined for clarity: 194 EST CA: For certificate issuing services, the EST CA is reached 195 through the EST Server; the CA could be logically "behind" the EST 196 Server or embedded within it. 198 Third-Party Trust Anchor (TA): Any Trust Anchor that is not 199 authoritative for the PKI hierarchy the EST server is providing 200 services for. 202 Explicit Trust Anchor: Any Trust Anchor that is explicitly 203 configured on the client for use during EST TLS authentication. 204 For example a TA that is manually configured on the EST client or 205 bootstrapped as described in Section 4.1.1. (See more details in 206 Section 3.6 and Section 7). 208 Implicit Trust Anchor: Any third-party Trust Anchor that is 209 available on the client for use during TLS authentication but is 210 not specifically indicated for use during EST TLS authentication. 211 For example TAs commonly used by web browsers to authenticate web 212 servers. The authorization model for these TAs is different from 213 the authorization model for Explicit Trust Anchors. (See more 214 details in Section 3.6.1, Section 3.6.2and Section 7). 216 Certificate-less TLS: Use of a TLS cipher suite in which neither the 217 client nor server use a certificate to authenticate. The 218 credential used for authentication is a word, phrase, code or key 219 that is shared between the client and server. The credential must 220 be uniquely shared between the client and server in order to 221 provide authentication of an individual client. 223 2. Operational Scenario Overviews 225 This section provides an informative overview of the operational 226 scenarios to better introduce the reader to the protocol discussion. 227 This section does not include RFC 2119 key words. 229 Both the EST clients and server are configured with information that 230 provides the basis for bidirectional authentication and for 231 authorization. The specific initialization data depends on the 232 methods available in the client device and server, but can include 233 shared secrets, network service names and locations (e.g., a Uniform 234 Resource Identifier (URI) [RFC3986]), trust anchor information (e.g., 235 a CA certificate or a hash of a TA's certificate), and enrollment 236 keys and certificates. Depending on an enterprise's acquisition and 237 network management practices, some initialization may be performed by 238 the vendor prior to delivery of client hardware and software. In 239 that case, the client device vendor may provide data, such as trust 240 anchors, to the enterprise via a secure procedure. The distribution 241 of this initial information is out of scope. 243 Distribution of trust anchors and other certificates can be effected 244 via the EST server. However, nothing can be inferred about the 245 authenticity of this data until an out-of-band mechanism is used to 246 verify them. 248 Sections 2.1-2.3 very closely mirror the text of the Scenarios 249 Appendix of [RFC6403] with such modifications as are appropriate for 250 this profile. Sections 2.1-2.6, below, enumerate the set of EST 251 functions (see Figure 5) and provide an informative overview of EST's 252 capabilities. 254 The general client/server interaction proceeds as follows: The client 255 device initiates a TLS-secured HTTP session with an EST server. A 256 specific EST service is requested based on a portion of the URI used 257 for the session. The client device and server authenticate each 258 other. The client verifies that the server is authorized to serve 259 this client. The server verifies that the client is authorized to 260 make use of this server and the request that the client has made. 261 The server acts upon the client request. 263 2.1. Obtaining CA Certificates 265 The EST client can request a copy of the current EST CA certificates 266 from the EST server. The EST client is assumed to perform this 267 operation before performing other operations. 269 Throughout this document we assume the EST CA has a certificate that 270 is used by the client to verify signed objects issued by the CA, 271 e.g., certificates and certificate revocation lists (CRLs), and that 272 a separate end-entity (EE) certificate is used when EST protocol 273 communication requires additional encryption. This operation is used 274 to obtain the EST CA certificate(s). 276 The EST client authenticates and verifies the authorization scope of 277 the EST server when requesting the current CA certificate(s). As 278 detailed in Section 3.3.1 and Section 3.3.3, available options 279 include: 281 o Verifying the EST server's HTTPS URI against the EST server's 282 certificate using Implicit TAs (similar to a common HTTPS 283 exchange). This allows the EST server and client to leverage 284 existing TAs that might be known to the EST client. 286 o The client can leverage a previously distributed trust anchor 287 specific to the EST server. This allows the EST client to use an 288 existing, potentially older, CA certificate to request a current 289 CA certificate. 291 o For bootstrapping, the EST client can rely upon manual 292 authentication performed by the end user as detailed in 293 Section 4.1.1. 295 Client authentication is not required for this exchange, so it is 296 trivially supported by the EST server. 298 2.2. Initial Enrollment 300 After authenticating an EST server and verifying that it is 301 authorized to provide services to the client, an EST client can 302 acquire a certificate for itself by submitting an enrollment request 303 to that server. 305 The EST server authenticates and authorizes the EST client as 306 specified in Section 3.3.2, Section 3.3.3 and Section 3.7. The 307 methods described in the normative text that are discussed in this 308 overview include: 310 o TLS with a previously issued client certificate (e.g., an existing 311 certificate issued by the EST CA); 313 o TLS with a previously installed certificate (e.g., manufacturer 314 installed certificate or a certificate issued by some other 315 party); 317 o Certificate-less TLS (e.g., with a shared credential distributed 318 out-of-band); 320 o HTTP-based with a username/password distributed out-of-band. 322 2.2.1. Certificate TLS authentication 324 If the EST client has a previously installed certificate issued by a 325 third party CA, this certificate can be used to authenticate the 326 client's request for a certificate from the EST server (if that CA is 327 recognized by the EST server). An EST client responds to the EST 328 server's TLS certificate request message with the existing 329 certificate already held by the client. The EST server will verify 330 the client's existing certificate and authorize the client's request 331 as described in Section 3.3.2. 333 2.2.2. Certificate-less TLS authentication 335 The EST client and EST server can be mutually authenticated using a 336 certificate-less TLS cipher suite (see Section 3.3.3). 338 2.2.3. HTTP-based client authentication 340 The EST server can optionally also request that the EST client submit 341 a username/password using the HTTP Basic or Digest Authentication 342 methods (see Section 3.2.3). This approach is desirable if the EST 343 client cannot be authenticated during the TLS handshake (see Section 344 3.3.2) or the EST server policy requires additional authentication 345 information. See Section 3.2.3. 347 2.3. Client Certificate Re-issuance 349 An EST client can renew/rekey its existing client certificate by 350 submitting a re-enrollment request to an EST server. 352 When the current EST client certificate can be used for TLS client 353 authentication (Section 3.3.2) the client presents this certificate 354 to the EST server for client authentication. When the to be re- 355 issued EST client certificate cannot be used for TLS client 356 authentication, any of the authentication methods used for initial 357 enrollment can be used. 359 For example if the client has an alternative certificate issued by 360 the EST CA that can be used for TLS client authentication, then it 361 can be used. 363 The certificate request message includes the same Subject and 364 SubjectAltName as the current certificate. Name changes are 365 requested as specified in Section 4.2.2. 367 2.4. Server Key Generation 369 The EST client can request a server-generated certificate and key 370 pair (see Section 4.4). 372 2.5. Full PKI Request messages 374 Full PKI Request [RFC5272] messages can be transported via EST using 375 the Full CMC Request function. This affords access to functions not 376 provided by the Simple Enrollment functions. Full PKI Request 377 messages are defined in Sections 3.2 and 4.2 of [RFC5272]. See 378 Section 4.3 for a discussion of how EST provides a transport for 379 these messages. 381 2.6. Certificate Signing Request (CSR) Attributes Request 383 Prior to sending an enrollment request to an EST server, an EST 384 client can query the EST server for a set of additional attribute(s) 385 that the client is requested to use in a subsequent enrollment 386 request. 388 These attributes can provide additional descriptive information that 389 the EST server cannot access itself, such as the MAC address of an 390 interface. Alternatively, these attributes can indicate the kind of 391 enrollment request, such as a specific elliptic curve or a specific 392 hash function that the client is expected to use when generating the 393 CSR. 395 3. Protocol Design and Layering 397 Figure 2 provides an expansion of Figure 1 describing how the layers 398 are used. Each aspect is described in more detail in the sections 399 that follow. 401 EST Layering: 403 Protocols and uses: 404 +---------------------------------------------------+ 405 | | 406 | Message types: | 407 | - "Simple PKI" messages | 408 | (incorporating proof-of-possession) | 409 | - CA certificate retrieval | 410 | - "Full PKI" messages (OPTIONAL) | 411 | - CSR attribute request (OPTIONAL) | 412 | - Server-generated key request (OPTIONAL) | 413 | | 414 +---------------------------------------------------+ 415 | | 416 | HTTP: | 417 | - HTTP headers and URIs for control | 418 | - Content-Type headers specify message type | 419 | - Headers for control/error messages | 420 | - URIs for selecting functions | 421 | - Basic or Digest authentication (OPTIONAL) | 422 | | 423 +---------------------------------------------------+ 424 | | 425 | TLS for transport security | 426 | - Authentication of the EST server | 427 | - Authentication of the EST client (OPTIONAL) | 428 | - Provides communications integrity | 429 | and confidentiality | 430 | - Channel Binding [RFC5929] to link | 431 | proof-of-identity with message-based | 432 | proof-of-possession. (OPTIONAL) | 433 | | 434 +---------------------------------------------------+ 436 Figure 2 438 Specifying HTTPS as the secure transport for enrollment messages 439 introduces two 'layers' to communicate authentication and control 440 messages: TLS and HTTP. 442 The TLS layer provides integrity and confidentiality during 443 transport. The proof-of-identity is supplied by TLS handshake 444 authentication and optionally also by the HTTP layer headers. The 445 message type and control/error messages are included in the HTTP 446 headers. 448 CMC [RFC5272] Section 3.1 notes that "the Simple PKI Request MUST NOT 449 be used if a proof-of-identity needs to be included". Since the TLS 450 and HTTP layers provide proof-of-identity for EST clients and servers 451 the Simple PKI message types are used. 453 The TLS layer certificate exchange provides a method for authorizing 454 client enrollment requests using existing certificates. Such 455 certificates may have been issued by the CA (from which the client is 456 requesting a certificate) or they may have been issued under a 457 distinct PKI (e.g., an IEEE 802.1AR IDevID [IDevID] credential). 459 Proof-of-possession (PoP) is a distinct issue from proof-of-identity 460 and is included in the Simple PKI message type as described in 461 Section 3.4. A method of linking proof-of-identity and proof-of- 462 possession is described in Section 3.5. 464 This document also defines transport for CMC [RFC5272] that complies 465 with CMC Transport Protocols [RFC5273]. 467 During protocol exchanges different certificates can be used. The 468 following table provides an informative overview. End-entities MAY 469 have one or more certificates of each type listed in Figure 3 and use 470 one or more Trust Anchor databases of each type listed in Figure 4. 472 Certificates and their corresponding uses: 473 +--------------+--------------------+-------------------------------+ 474 | Certificate | Issuer | Use and section references | 475 +==============+====================+===============================+ 476 | EST server | The CA served by | Presented by the EST server | 477 | certificate | the EST server | during the TLS handshake | 478 | | | | 479 | | | Section 3.3.1 | 480 +--------------+--------------------+-------------------------------+ 481 | EST server | A CA | Presented by the EST server | 482 | certificate | authenticatable by | during the TLS handshake | 483 | | a third-party TA | | 484 | | e.g., a web server | Section 3.3.1, and | 485 | | CA | Security Considerations | 486 +--------------+--------------------+-------------------------------+ 487 | EST client | A CA | Presented by the EST client | 488 | certificate | authenticatable by | to the EST server by clients | 489 | | a third-party TA | that have not yet enrolled | 490 | | e.g., a device | | 491 | | manufacturer | Section 3.3.2 | 492 +--------------+--------------------+-------------------------------+ 493 | EST client | The CA served by | Presented by the EST client | 494 | certificate | the EST server | to PKI End Entities. | 495 | | | Including to the EST server | 496 | | | during future EST operations | 497 | | | | 498 | | | Section 3.3.2 | 499 +--------------+--------------------+-------------------------------+ 500 | EST client | The CA served by | Presented by the EST client | 501 | certificate | the EST server | to PKI End Entities. | 502 | | | Clients can obtain certs | 503 | | | that cannot be used for EST | 504 | | | client authentication | 505 | | | | 506 | | | Section 4.2.1 | 507 +--------------+--------------------+-------------------------------+ 509 Figure 3 511 Trust Anchor databases and their corresponding uses: 512 +--------------+----------------------------------------------------+ 513 | TA database | Use and section references | 514 +==============+====================================================+ 515 | EST server | EST servers use this TA database to authenticate | 516 | EST CA | certificates issued by the EST CA, including EST | 517 | TA database | client certificates during enroll/re-enroll | 518 | | operations | 519 | | | 520 | | Section 3.3.2 | 521 +--------------+----------------------------------------------------+ 522 | EST server | EST servers use this TA database to authenticate | 523 | Third-Party | certificates issued by third-party TAs. | 524 | TA database | e.g., EST client certificates issued by a device | 525 | | manufacturer | 526 | | | 527 | | Section 3.3.2 | 528 +--------------+----------------------------------------------------+ 529 | EST client | EST clients use this TA database to authenticate | 530 | Explicit | certificates issued by the EST CA, including EST | 531 | TA database | server certificates. | 532 | | | 533 | | Section 3.1, Section 3.3.1, Section 3.6.1 and | 534 | | Section 4.1.1 | 535 +--------------+----------------------------------------------------+ 536 | EST client | EST clients use this trust anchor database to | 537 | Implicit | authenticate an EST server that uses an externally | 538 | TA database | issued certificate. | 539 | | | 540 | | | 541 | | Section 3.1, Section 3.3.1, Section 3.6.2 | 542 | | and Security Considerations | 543 +--------------+----------------------------------------------------+ 545 Figure 4 547 3.1. Application Layer 549 The EST client MUST be capable of generating and parsing Simple PKI 550 messages (see Section 4.2). Generating and parsing Full PKI messages 551 is OPTIONAL (see Section 4.3). The client MUST also be able to 552 request CA certificates from the EST server and parse the returned 553 "bag" of certificates (see Section 4.1). Requesting CSR attributes 554 and parsing the returned list of attributes is OPTIONAL (see 555 Section 4.5). 557 Details of the EST client application configuration are out of scope 558 of the protocol discussion but are necessary for understanding the 559 prerequisites of initiating protocol operations. The EST client is 560 RECOMMENDED to be configured with TA databases for Section 3.3.1 or 561 with a secret key for Section 3.3.3. Implementations conforming to 562 this standard MUST provide the ability to designate Explicit TAs. 563 For human usability reasons a "fingerprint" of an Explicit TA 564 database entry can be configured for bootstrapping as discussed in 565 Section 4.1.1. Configuration of an Implicit TA database, perhaps by 566 its inclusion within the EST client distribution or available from 567 the operating system, provides flexibility along with the caveats 568 detailed in Section 7. Implementations conforming to this standard 569 MUST provide the ability to disable use of any Implicit TA database. 571 The EST client is configured with sufficient information to form the 572 EST server URI. This can be the full operation path segment (e.g. 573 https://www.example.com/.well-known/est/ or 574 https://www.example.com/.well-known/est/arbitraryLabel1) or the EST 575 client can be configured with a tuple composed of the authority 576 portion of the URI along with the OPTIONAL label (e.g. 577 "www.example.com:80", "arbitraryLabel1") or just the authority 578 portion of the URI. 580 3.2. HTTP Layer 582 HTTP is used to transfer EST messages. URIs are defined for handling 583 each media type (i.e., message type) as described in Section 3.2.2. 584 HTTP is also used for client authentication services when TLS client 585 authentication is not available, due to lack of a client certificate 586 suitable for use by TLS (see Section Section 3.2.3). HTTP 587 authentication can also be used in addition to TLS client 588 authentication if the EST server wishes additional authentication 589 information, as noted in Section 2.2.3. Registered media types are 590 used to convey EST messages as specified in Figure 6. 592 HTTP 1.1 [RFC2616] and above support persistent connections. As 593 described in Section 8.1 of that RFC, persistent connections may be 594 used to reduce network and processing load associated with multiple 595 HTTP requests. EST does not require or preclude persistent HTTP 596 connections and their use is out of scope of this specification. 598 3.2.1. HTTP headers for control 600 This document profiles the HTTP content-type header (as defined in 601 [RFC2046], but see Figure 6 for specific values) to indicate the 602 media type for EST messages and to specify control messages for EST. 603 The HTTP Status value is used to communicate success or failure of an 604 EST function. HTTP authentication is used by a client when requested 605 by the server. 607 The media types indicated in the HTTP content-type header indicates 608 which EST message is being transferred. Media types used by EST are 609 specified in Section 3.2.4. 611 3.2.2. HTTP URIs for control 613 The EST server MUST use the [RFC5785] defined path-prefix of "/.well- 614 known/" and the registered name of "est". Thus a valid EST server 615 URI path begins with "https://www.example.com/.well-known/est". Each 616 EST operation is indicated by a path-suffix that indicates the 617 intended operation: 619 Operations and their corresponding URIs: 620 +------------------------+-----------------+-------------------+ 621 | Operation |Operation Path | Details | 622 +========================+=================+===================+ 623 | Distribution of CA | /CACerts | Section 4.1 | 624 | certificates (MUST) | | | 625 +------------------------+-----------------+-------------------+ 626 | Enrollment of new | /simpleEnroll | Section 4.2. | 627 | clients (MUST) | | | 628 +------------------------+-----------------+-------------------+ 629 | Re-Enrollment of | /simpleReEnroll | Section 4.2.2 | 630 | existing clients (MUST)| | | 631 +------------------------+-----------------+-------------------+ 632 | Full CMC (OPTIONAL) | /fullCMC | Section 4.3 | 633 +------------------------+-----------------+-------------------+ 634 | Server-side Key | /serverKeyGen | Section 4.4 | 635 | Generation (OPTIONAL) | | | 636 +------------------------+-----------------+-------------------+ 637 | Request CSR attributes | /CSRAttrs | Section 4.5 | 638 | (OPTIONAL) | | | 639 +------------------------+-----------------+-------------------+ 641 Figure 5 643 The operation path (Figure 5) is appended to the path-prefix to form 644 the URI used with HTTP GET or POST to perform the desired EST 645 operation. An example valid URI absolute path for the "/CACerts" 646 operation is "/.well-known/est/CACerts". To retrieve the CA's 647 certificates, the EST client would use the following HTTP request: 649 GET /.well-known/est/CACerts HTTP/1.1 651 Likewise, to request a new certificate in this example scheme, the 652 EST client would use the following request: 654 POST /.well-known/est/simpleEnroll HTTP/1.1 655 The use of distinct operation paths simplifies implementation for 656 servers that do not perform client authentication when distributing 657 /CACerts responses. 659 An EST server MAY provide service for multiple CAs as indicated by an 660 OPTIONAL additional path segment between the registered application 661 name and the operation path. To avoid conflict the CA label MUST NOT 662 be the same as any defined operation path segment. The EST server 663 MUST provide services when the additional path segment is not 664 included. The following are three example valid URIs: 666 1. https://www.example.com/.well-known/est/CACerts 668 2. https://www.example.com/.well-known/est/arbitraryLabel1/CACerts 670 3. https://www.example.com/.well-known/est/arbitraryLabel2/CACerts 672 In this specification the distinction between enroll and renew/rekey 673 is explicitly indicated by the HTTP URI. When requesting /fullCMC 674 operations CMC uses the same messages for certificate renewal and 675 certificate rekey. 677 An EST server MAY provide additional services using other URIs. 679 3.2.3. HTTP-Based Client Authentication 681 The EST server MAY request HTTP-based client authentication. This 682 request can be in addition to successful TLS client authentication 683 (Section 3.3.2) if EST server policy requires additional 684 authentication. (For example the EST server may require that an EST 685 client "knows" a password in addition to "having" an existing client 686 certificate). Or HTTP-based client authentication can be an EST 687 server policy specified fallback in situations where the EST client 688 did not successfully complete the TLS client authentication. (This 689 might arise if the EST client is enrolling for the first time or if 690 the certificates available to an EST client cannot be used for TLS 691 client authentication). 693 HTTP Basic and Digest authentication MUST only be performed over TLS 694 1.1 [RFC4346] or later versions. As specified in CMC: Transport 695 Protocols [RFC5273] the server "MUST NOT assume client support for 696 any type of HTTP authentication such as cookies, Basic 697 authentication, or Digest authentication". Clients SHOULD support 698 the Basic and Digest authentication mechanism. 700 Servers that wish to use Basic and Digest authentication reject the 701 HTTP request using the HTTP defined WWW-Authenticate response-header 702 ([RFC2616], Section 14.47). The client is expected to retry the 703 request, including the appropriate Authorization Request Header 704 ([RFC2617], Section 3.2.2), if the client is capable of using the 705 Basic or Digest authentication. If the client is not capable of 706 retrying the request or it is not capable of Basic or Digest 707 authentication, then the client MUST terminate the connection. 709 A client MAY set the username to the empty string ("") if it is 710 presenting a password that is not associated with a username. 712 Support for HTTP-based client authentication has security 713 ramifications as discussed in Section 7. The client MUST NOT respond 714 to the server's HTTP authentication request unless the client has 715 authenticated the EST server (as per Section 3.6). 717 3.2.4. Message types 719 This document uses existing media types for the messages as specified 720 by [RFC2585], [RFC5967], and CMC [RFC5272]. To support distribution 721 of multiple certificates for a CA certificate path, the [RFC2046] 722 multipart/mixed media type is used. 724 For consistency with [RFC5273], each distinct EST message type uses 725 an HTTP Content-Type header with a specific media type. 727 The EST messages and their corresponding media types are: 729 +--------------------+--------------------------+-------------------+ 730 | Message type |Request media type | Request section(s)| 731 | |Response media type(s) | Response section | 732 | |Source(s) of types | | 733 +====================+==========================+===================+ 734 | CA certificate | N/A | Section 4.1 | 735 | request | application/pkcs7-mime | Section 4.1.1 | 736 | | [RFC5751] | | 737 +--------------------+--------------------------+-------------------+ 738 | Cert enroll/renew/ | application/pkcs10 | Section 4.2/4.2.1 | 739 | rekey | application/pkcs7-mime | Section 4.2.2 | 740 | | [RFC5967] [RFC5751] | | 741 +--------------------+--------------------------+-------------------+ 742 | Full CMC | application/pkcs7-mime | Section 4.3.1 | 743 | | application/pkcs7-mime | Section 4.3.2 | 744 | | [RFC5751] | | 745 +--------------------+--------------------------+-------------------+ 746 | Server-side Key | application/pkcs10 | Section 4.4.1 | 747 | Generation | multipart/mixed | Section 4.4.2 | 748 | | (application/pkcs7-mime &| | 749 | | application/pkcs8) | | 750 | | [RFC5967] [RFC5751] & | | 751 | | [RFC5958] | | 752 +--------------------+--------------------------+-------------------+ 753 | Request CSR | N/A | Section 4.5.1 | 754 | attributes | application/csrattrs | Section 4.5.2 | 755 | | This RFC | | 756 +--------------------+--------------------------+-------------------+ 758 Figure 6 760 3.3. TLS Layer 762 TLS provides authentication, which in turn enables authorization 763 decisions. The EST server and EST client are responsible for 764 ensuring that an acceptable cipher suite is negotiated and that 765 bidirectional authentication has been performed. Alternately, 766 certificate-less TLS authentication, where neither the client nor 767 server present a certificate, is also an acceptable method for EST 768 mutual authentication. 770 HTTPS [RFC2818] specifies how HTTP messages are carried over TLS. 771 HTTPS MUST be used. TLS 1.1 [RFC4346] (or a later version) MUST be 772 used TLS session resumption [RFC5077] SHOULD be supported. 774 TLS channel binding information MAY be inserted into a certificate 775 request as detailed in Section 3.5 in order to provide the EST server 776 with assurance that the authenticated TLS client has access to the 777 private key for the certificate being requested. 779 3.3.1. TLS-Based Server Authentication 781 The EST server MUST be authenticated during the TLS handshake unless 782 the client is requesting Bootstrap Distribution of CA certificates 783 (Section 4.1.1) or Full CMC (Section 4.3). 785 The EST client authenticates the EST server as defined for the cipher 786 suite negotiated. The following text provides details assuming a 787 certificate-based cipher suite, such as the TLS 1.1 [RFC4346] 788 mandatory cipher suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA). As an 789 alternative to authentication using a certificate, an EST client MAY 790 support certificate-less TLS authentication (Section 3.3.3). 792 Certificate validation MUST be performed as per [RFC5280]. The EST 793 server certificate MUST conform to the [RFC5280] certificate profile. 795 The client validates the TLS server certificate using the EST client 796 Explicit and, if enabled, Implicit TA database(s). The client MUST 797 maintain a distinction between the use of Explicit and Implicit TA 798 databases during authentication in order to support proper 799 authorization. The EST client MUST perform authorization checks as 800 specified in Section 3.6. 802 If certificate validation fails, the client MAY follow the procedure 803 outlined in Section 4.1.1 for bootstrap distribution of CA 804 certificates. 806 3.3.2. TLS-Based Client Authentication 808 TLS client authentication is the RECOMMENDED method for identifying 809 EST clients. HTTP-Based Client Authentication (Section 3.2.3) MAY be 810 used. 812 The EST server authenticates the EST client as defined for the cipher 813 suite negotiated. The following text provides details assuming a 814 certificate-based cipher suite such as the TLS 1.1 [RFC4346] 815 mandatory cipher suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA). The EST 816 server MUST support certificate based client authentication. As an 817 alternative or as an addition to authentication using a certificate, 818 an EST server MAY support certificate-less TLS authentication 819 (Section 3.3.3). 821 Generally, the client will use an existing certificate for renew or 822 rekey operations. If the certificate to be renewed or rekeyed is 823 appropriate for the negotiated cipher suite, then the client MUST use 824 it for the TLS handshake, otherwise the client SHOULD use an 825 alternate certificate that is suitable for the cipher suite and 826 contains the same subject identity information. When requesting an 827 enroll operation the client MAY use a third-party issued client 828 certificate to authenticate itself. The EST server MUST perform 829 authorization checks as specified in Section 3.7. 831 If a client does not support TLS client authentication, then it MUST 832 support HTTP-based client authentication (Section 3.2.3) or 833 certificate-less TLS authentication (Section 3.3.3). 835 3.3.3. Certificate-less TLS Mutual Authentication 837 Certificate-less TLS cipher suites provide a way to perform mutual 838 authentication in situations where neither the client nor server have 839 certificates, do not desire to use certificates, or do not have the 840 trust anchors necessary to verify a certificate. The client and 841 server MAY negotiate a certificate-less cipher suite for mutual 842 authentication. 844 When using certificate-less mutual authentication in TLS for 845 enrollment, the cipher suite MUST be based on a protocol that is 846 resistant to dictionary attack and MUST be based on a zero knowledge 847 protocol. TLS-SRP ciphersuites listed in section 2.7 of [RFC5054] 848 are suitable for this purpose. Section 7 lists the characteristics 849 of a ciphersuite that are suitable for use in certificate-less mutual 850 authentication for enrollment. 852 Successful authentication using a certificate-less cipher suite 853 proves knowledge of a pre-shared secret which implicitly authorizes a 854 peer in the exchange. 856 3.4. Proof-of-Possession 858 As defined in Section 2.1 of CMC [RFC5272], Proof-of-possession (POP) 859 "refers to a value that can be used to prove that the private key 860 corresponding to the public key is in the possession and can be used 861 by an end-entity." 863 The signed enrollment request provides a signature-based proof-of- 864 possession. The mechanism described in Section 3.5 strengthens this 865 by optionally including "Direct"-based proof-of-possession [RFC5272] 866 by including TLS session-specific information within the data covered 867 by the enrollment request signature (thus linking the enrollment 868 request to the authenticated end-point of the TLS connection). 870 3.5. Linking Identity and PoP information 872 Server policy will determine whether the server requires the 873 mechanism specified in this section be used by the client. This 874 specification provides an OPTIONAL method of linking identity and 875 proof-of-possession by including information specific to the current 876 authenticated TLS session within the signed certification request. 877 The client can determine if the server requires the linking of 878 identity and PoP by examining the CSR Attributes Response (see 879 Section 4.5.2). Regardless of the CSR Attributes Response, clients 880 are RECOMMENDED to link identity and PoP by embedding tls-unique 881 information in the certification request. If tls-unique information 882 is included by the client, the server MUST verify it. The EST server 883 MAY reject requests without tls-unique information as indicated by 884 server policy. 886 Linking identity and proof-of-possession proves to the server that 887 the authenticated TLS client has possession of the private key 888 associated with the certification request and that the client was 889 able to sign the certification request after the TLS session was 890 established. This is an alternative to the [RFC5272] Section 6.3- 891 defined "Linking Identity and POP information" method available if 892 Full PKI messages are used. 894 The client generating the request obtains the tls-unique value as 895 defined in Channel Bindings for TLS [RFC5929] from the TLS subsystem. 896 The tls-unique specification includes a synchronization problem as 897 described in Channel Bindings for TLS [RFC5929] section 3.1. To 898 avoid this problem, EST implementations that support this feature 899 MUST use the tls-unique value from the first TLS handshake. EST 900 clients and servers use their tls-unique implementation specific 901 synchronization methods to obtain this first tls-unique value. TLS 902 "secure_renegotiation" [RFC5746] MUST be used. This maintains the 903 binding from the first tls-unique value across renegotiations to the 904 most recently negotiated connection. 906 The tls-unique value is base 64-encoded as specified in Section 4 of 907 [RFC4648] and the resulting string is placed in the certification 908 request challenge-password field ([RFC2985], Section 5.4.1). If tls- 909 unique information is not embedded within the certification request 910 the challenge-password field MUST be empty to indicate that the 911 client did not include the optional channel-binding information (any 912 value submitted is verified by the server as tls-unique information). 914 If the EST server makes use of a back-end infrastructure for 915 processing, it is RECOMMENDED that the results of this verification 916 be communicated. (For example this communication might use the CMC 917 "RA POP Witness Control" in a CMC Full PKI Request message. Or an 918 EST server might TLS authenticate an EST client as being a trusted 919 infrastructure element that does not forward invalid requests. A 920 detailed discussion of back-end processing is out of scope). 922 When rejecting requests, the EST server response is as described for 923 all enroll responses (Section 4.2.3). If a Full PKI Response is 924 included, the CMCFailInfo MUST be set to popFailed. If a human 925 readable reject message is included it SHOULD include an informative 926 text message indicating that linking of identity and POP information 927 is required. 929 3.6. Server Authorization 931 The client MUST check EST server authorization before accepting any 932 server responses or responding to HTTP authentication requests. 934 The EST client authorization method depends on which method was used 935 to authenticate the server. When the Explicit TA database is used to 936 authenticate the EST server then Section 3.6.1 applies. When the 937 Implicit TA database is used to authenticate the EST server then 938 Section 3.6.2 applies. Successful authentication using a 939 certificate-less cipher suite implies authorization of the server. 941 The client MAY perform bootstrapping as specified in Section 4.1.1 942 even if these checks fail. 944 3.6.1. Client use of Explicit TA Database 946 When the EST client Explicit TA database is used to validate the EST 947 server certificate the client MUST check either the configured URI 948 against the server's identity, or the EST server certificate MUST 949 contain the id-kp-cmcRA [RFC6402] extended key usage extension. 951 3.6.2. Client use of Implicit TA Database 953 When the EST client Implicit TA database is used to validate the EST 954 server certificate, the client MUST check the URI "against the 955 server's identity as presented in the server's Certificate message" 956 (HTTP Over TLS Section 3.1 "Server Identity" [RFC2818] and 957 [RFC6125]). The provisioned URI provides the basis for 958 authorization, and the server's authenticated identity confirms it is 959 the authorized server. 961 3.7. Client Authorization 963 The decision to issue a certificate to a client is always controlled 964 by local CA policy. The EST server configuration reflects this CA 965 policy. This document does not specify any constraints on such 966 policy. EST provides the EST server access to each client's 967 authenticated identity -- e.g., the TLS client's certificate in 968 addition to any HTTP user authentication credentials -- to help in 969 implementing such policy. 971 If the client's certificate was issued by the EST CA, and it includes 972 the id-kp-cmcRA [RFC6402] extended key usage extension, then the 973 client is a Registration Authority (RA) as described in [RFC5272] and 974 [RFC6402]. In this case the EST server SHOULD apply authorization 975 policy consistent with an RA client. For example when handling 976 /simpleEnroll requests the EST server could be configured to accept 977 PoP linking information that does not match the current TLS session 978 because the authenticated EST client RA has verified this information 979 when acting as an EST server (as specified in Section 3.5). More 980 specific RA mechanisms are available if the EST client uses /fullCMC 981 methods. 983 4. Protocol Exchange Details 985 Before processing a request, an EST server determines if the client 986 is authorized to receive the requested services. Likewise, the 987 client determines if it will make requests to the EST server. These 988 authorization decisions are described in the next two sections. 989 Assuming that both sides of the exchange are authorized, then the 990 actual operations are as described in subsequent sections. 992 4.1. Distribution of CA certificates 994 The EST client can request a copy of the current CA certificates. 995 This function is generally performed before other EST functions. 997 4.1.1. Bootstrap Distribution of CA certificates 999 It is possible that the client was not configured with the TA 1000 database(s) necessary to validate the EST server certificate. This 1001 section describes a method by which minimally configured EST clients 1002 can populate their Explicit TA database. 1004 If the EST client application does not specify either an Explicit TA 1005 database or a Implicit TA database then the initial TLS server 1006 authentication and authorization will fail. The client MAY 1007 provisionally continue the TLS handshake to completion for the 1008 purposes of accessing the /CACerts or /fullCMC method. If the EST 1009 client continues with an unauthenticated connection, the client MUST 1010 extract the HTTP content data from the response (Section 4.1.3 or 1011 Section 4.3.2) and engage a human user to authorize the CA 1012 certificate using out-of-band data such as a CA certificate 1013 "fingerprint" (e.g., a SHA-256 or SHA-512 [SHS] hash on the whole CA 1014 certificate). In a /fullCMC response it is the Publish Trust Anchors 1015 control within the Full PKI Response that must be accepted manually. 1016 It is incumbent on the user to properly verify the TA information, or 1017 to provide the "fingerprint" data during configuration that is 1018 necessary to verify the TA information. 1020 HTTP authentication requests MUST NOT be responded to if the server 1021 has not been authenticated. 1023 The EST client uses the /CACerts response to establish an Explicit 1024 Trust Anchor database for subsequent TLS authentication of the EST 1025 server. EST clients MUST NOT engage in any other protocol exchange 1026 until after the /CACerts response has been accepted and a new TLS 1027 session has been established (using TLS certificate-based 1028 authentication). 1030 4.1.2. Distribution of CA certificates request 1032 EST clients request the Explicit TA database information of the CA 1033 (in the form of certificates) with an HTTPS GET message using an 1034 operation path of "/CACerts". EST clients and servers MUST support 1035 the /CACerts function. Clients SHOULD request an up-to-date response 1036 before stored information has expired in order to ensure the EST CA 1037 TA database is up to date. 1039 The EST server MUST NOT require client authentication or 1040 authorization to reply to this request. 1042 The client MUST authenticate the EST server as specified in 1043 Section 3.3.1 and Section 3.3.3 and check the server's authorization 1044 as given in Section 3.6 or follow the procedure outlined in 1045 Section 4.1.1. 1047 4.1.3. Distribution of CA certificates response 1049 The EST server responds to a Distribution of CA certificates request 1050 with the EST CA certificates within a Simple PKI Response. If the 1051 certificates are successfully returned, the server response MUST have 1052 an HTTP 200 response code with a content-type of "application/ 1053 pkcs7-mime". Any other response code indicates an error and the 1054 client MUST abort the protocol. 1056 The EST server MUST include the current root CA certificate in the 1057 response. The EST server MUST include any additional certificates 1058 the client would need to build a chain from an EST CA issued 1059 certificate to the current EST CA TA. For example if the EST CA is a 1060 subordinate CA then all the appropriate subordinate CA certificates 1061 necessary to build a chain to the root EST CA are included in the 1062 response. 1064 The EST server SHOULD include the three "Root CA Key Update" 1065 certificates OldWithOld, OldWithNew, and NewWithOld in the response 1066 chain. These are defined in Section 4.4 of CMP [RFC4210]. The EST 1067 client MUST be able to handle these certificates in the response. 1068 The EST CA's most recent self-signed certificate (e.g. NewWithNew 1069 certificate) is self-signed and has the latest NotAfter date. If the 1070 EST server does not include these in the response then after the 1071 current EST CA certificate expires the EST clients will need to be 1072 (re)enrolled with the PKI using the Bootstrap Distribution of CA 1073 certificates (Section 4.1.1) method which involves user interaction. 1075 If the CA certificate was authorized in an out-of-band manner then, 1076 after such validation occurs, all the other certificates MUST be 1077 validated using normal [RFC5280] certificate path validation (using 1078 the most recent CA certificate as the TA) before they can be used to 1079 build certificate paths during certificate validation. 1081 The EST client MUST store the extracted EST CA certificate as an 1082 Explicit TA database entry for subsequent EST server authentication. 1083 The EST client SHOULD disable use of Implicit TA database entries for 1084 this EST server, now that an Explicit TA database entry is available. 1085 If the client does this then the client MUST include a "Trusted CA 1086 Indication" extension in future TLS sessions [RFC4366] to indicate to 1087 the server that only an EST Server certificate authenticatable by the 1088 Explicit TA database entry is acceptable. The EST client also makes 1089 the CA Certificate response information available to the end-entity 1090 software for use when validating peer certificates. 1092 The response format is the CMC Simple PKI Response, as defined in 1093 [RFC5272]. The HTTP content-type of "application/pkcs7-mime" is 1094 used. The Simple PKI response is base 64-encoded, as specified in 1095 Section 4 of [RFC4648], and sandwiched between headers: 1097 -----BEGIN PKCS7----- 1098 MIIBhDCB7gIBADBFMQswCQYDVQQGEwJBVTETMBEGA1UECBMKU29tZS1TdGF0ZTEh 1099 Simplified example of base 64 encoding of CMC Simple PKI Response 1100 ED8rf3UDF6HjloiV3jBnpetx4JjZH/BlmD9HMqofVEryb1e4iZgMUvuIgwEjQwpD 1101 8J4OhHvLh1o= 1102 -----END PKCS7----- 1104 4.2. Client Certificate Request Functions 1106 EST clients request a certificate from the EST server with an HTTPS 1107 POST using the operation path value of "/simpleEnroll". EST clients 1108 request a renew/rekey of existing certificates with an HTTP POST 1109 using the operation path value of "/simpleReEnroll". EST servers 1110 MUST support the /simpleEnroll and /simpleReEnroll functions. 1112 It is RECOMMENDED that a client obtain the current CA certificates, 1113 as described in Section 4.1, before performing certificate request 1114 functions. This ensures that the client will be able to validate the 1115 EST server certificate. The client MUST authenticate the EST server 1116 as specified in Section 3.3.1 and Section 3.3.3. The client MUST 1117 verify the authorization the EST server as specified in Section 3.6. 1119 The server MUST authenticate the client as specified in Section 3.3.2 1120 and Section 3.3.3. The server MUST verify client authorization as 1121 specified in Section 3.7. The EST server MUST check the tls-unique 1122 value as described in Section 3.5 if one is submitted by the client. 1124 The server MAY accept a certificate request for manual authorization 1125 checking by an administrator. (Section 4.2.3 describes the use of an 1126 HTTP 202 response to the EST client if this occurs). 1128 4.2.1. Simple Enrollment of Clients 1130 When HTTPS POSTing to /simpleEnroll the client MUST include a Simple 1131 PKI Request as specified in CMC Section 3.1 (i.e., a PKCS#10 1132 Certification Request). 1134 The Certification Signing Request (CSR) signature provides proof-of- 1135 possession of the private key to the EST server. If the CSR KeyUsage 1136 extension indicates the private key can be used to generate digital 1137 signatures then the CSR signature MUST be generated using the private 1138 key. If the key can be used to generate digital signatures but the 1139 requested CSR KeyUsage extension prohibits generation of digital 1140 signatures then the CSR signature MUST still be generated using the 1141 private key but the key MUST NOT be used to for any other signature 1142 operations (this is consistent with the recommendations concerning 1143 submission of proof-of-possession to an RA or CA as described in 1144 [SP-800-57-Part-1]). The use of /fullCMC operations provides access 1145 to more advanced proof-of-possession methods that MUST be used when 1146 the key pair can not be used for digital signature generation (see 1147 Section 4.3). 1149 The HTTP content-type of "application/pkcs10" is used here. The 1150 format of the message is as specified in Section 6.4 of [RFC4945]. 1152 The EST client MAY request additional certificates even when using an 1153 existing certificate in the TLS client authentication. For example 1154 the client can use an existing certificate for TLS client 1155 authentication when requesting a certificate that cannot be used for 1156 TLS client authentication. 1158 4.2.2. Simple Re-Enrollment of Clients 1160 EST clients renew/rekey certificates with an HTTPS POST using the 1161 operation path value of "/simpleReEnroll". 1163 A certificate request employs the same format as the "simpleEnroll" 1164 request, using the same HTTP content-type. The request Subject field 1165 and SubjectAltName extension MUST be identical to the corresponding 1166 fields in the certificate being renewed/rekeyed. The 1167 ChangeSubjectName attribute, as defined in [RFC6402], MAY be included 1168 in the CSR to request that these fields be changed in the new 1169 certificate. 1171 If the Subject Public Key Info in the certification request is the 1172 same as the current client certificate, the EST server performs a 1173 renew operation. If the public key information is different than the 1174 currently issued certificate then the EST server performs a rekey 1175 operation. 1177 4.2.3. Simple Enroll and Re-Enroll Response 1179 If the enrollment is successful, the server response MUST contain an 1180 HTTP 200 response code with a content-type of "application/ 1181 pkcs7-mime". The response data is a certs-only Simple PKI Response 1182 containing only the certificate that was issued. The Simple PKI 1183 response is base 64-encoded and sandwiched between headers: 1185 -----BEGIN PKCS7----- 1186 MIIBhDCB7gIBADBFMQswCQYDVQQGEwJBVTETMBEGA1UECBMKU29tZS1TdGF0ZTEh 1187 Simplified example of base 64 encoding of CMC Simple PKI Response 1188 ED8rf3UDF6HjloiV3jBnpetx4JjZH/BlmD9HMqofVEryb1e4iZgMUvuIgwEjQwpD 1189 8J4OhHvLh1o= 1190 -----END PKCS7----- 1192 When rejecting a request the server MUST specify either an HTTP 4xx 1193 error, or an HTTP 5xx error. A Simple PKI Response with an HTTP 1194 content-type of "application/pkcs7-mime" (see Section 4.3.2) MAY be 1195 included in the response data to convey an error response. If the 1196 content-type is not set the response data MUST be a plain text human- 1197 readable error message containing informative information describing 1198 why the request was rejected (for example indicating that CSR 1199 attributes are incomplete). 1201 If the server responds with an HTTP [RFC2616] 202, this indicates 1202 that the request has been accepted for processing but that a response 1203 is not yet available. The server MUST include a Retry-After header 1204 as defined for HTTP 503 responses. The server also MAY include 1205 informative human-readable content. The client MUST wait at least 1206 the specified 'retry-after' time before repeating the same request. 1207 The client repeats the initial enrollment request after the 1208 appropriate 'retry-after' interval has expired. The client SHOULD 1209 log or inform the end user of this event. The server is responsible 1210 for maintaining all state necessary to recognize and handle retry 1211 operations as the client is stateless in this regard; it simply sends 1212 the same request repeatedly until it receives a different response 1213 code. 1215 All other return codes are handled as specified in HTTP [RFC2616]. 1217 4.3. Full CMC 1219 An EST client can request a certificate from an EST server with an 1220 HTTPS POST using the operation path value of "/fullCMC". Support for 1221 the /fullCMC function is OPTIONAL for both clients and servers. 1223 4.3.1. Full CMC Request 1225 If the HTTP POST to /fullCMC is not a valid Full PKI Request, the 1226 server MUST reject the message. The HTTP content-type used is 1227 "application/pkcs7-mime", as specified in [RFC5273]. 1229 4.3.2. Full CMC Response 1231 The server responds with the client's newly issued certificate or 1232 provides an error response. 1234 If the enrollment is successful, the server response MUST include an 1235 HTTP 200 response code with a content-type of "application/ 1236 pkcs7-mime" as specified in [RFC5273]. The response data includes 1237 either the Simple PKI Response or the Full PKI Response as specified 1238 in Section 3.2 of [RFC5272]. 1240 When rejecting a request, the server MUST specify either an HTTP 4xx 1241 error or an HTTP 5xx error. A CMC response with content-type of 1242 "application/pkcs7-mime" SHOULD be included in the response data for 1243 any CMC error response. If the content-type is not set the response 1244 data MUST be a plain text human-readable error message containing 1245 informative information describing why the request was rejected (for 1246 example indicating that CSR attributes are incomplete). 1248 All other return codes are handled as specified in Section 4.2.3 or 1249 HTTP [RFC2616]. For example, a client interprets an HTTP 404 or 501 1250 response to indicate that this service is not implemented. 1252 The Full PKI Response is base 64-encoded and sandwiched between 1253 headers: 1255 -----BEGIN PKCS7----- 1256 MIIBhDCB7gIBADBFMQswCQYDVQQGEwJBVTETMBEGA1UECBMKU29tZS1TdGF0ZTEh 1257 Simplified example of base 64 encoding of CMC Full PKI Response 1258 ED8rf3UDF6HjloiV3jBnpetx4JjZH/BlmD9HMqofVEryb1e4iZgMUvuIgwEjQwpD 1259 8J4OhHvLh1o= 1260 -----END PKCS7----- 1262 4.4. Server-side Key Generation 1264 An EST client may request a private key and associated certificate 1265 from an EST server using an HTTPS POST with an operation path value 1266 of "/serverKeyGen". Support for the /serverKeyGen function is 1267 OPTIONAL. 1269 A client MUST authenticate an EST server as specified in 1270 Section 3.3.1 and Section 3.3.3. 1272 The EST server MUST authenticate the client as specified in 1273 Section 3.3.2 and Section 3.3.3. The server SHOULD use Client 1274 Authorization for authorization purposes. The EST server applies 1275 whatever authorization or logic it chooses to determine if the 1276 private key and certificate should be provided. 1278 Proper random number and key generation [RFC4086] is a server 1279 implementation responsibility and server storage of generated keys is 1280 a local option. The key pair and certificate are transferred over 1281 the TLS session. The cipher suite used to return the private key and 1282 certificate MUST offer confidentiality commensurate with the private 1283 key being delivered to the client. 1285 The EST client MAY request additional certificates even when using an 1286 existing certificate in the TLS client authentication. For example 1287 the client can use an existing certificate for TLS client 1288 authentication when requesting a certificate that cannot be used for 1289 TLS client authentication. 1291 4.4.1. Server-side Key Generation Request 1293 The certificate request is HTTPS POSTed and is the same format as for 1294 the "/simpleEnroll" and "/simpeReEnroll" path extensions with the 1295 same content-type. 1297 In all respects the server SHOULD treat the CSR as it would any 1298 enroll or re-enroll CSR; the only distinction here is that the server 1299 MUST ignore the public key values and signature in the CSR. These 1300 are included in the request only to allow re-use of existing 1301 codebases for generating and parsing such requests. 1303 If the client desires to receive the private key with encryption that 1304 exists outside and in addition to that of the TLS transport used by 1305 EST or if server policy requires that the key be delivered in such a 1306 form, the client MUST include a DecryptKeyIdentifier attribute (as 1307 defined in Section 2.2.5, [RFC4108]) specifying the identifier of the 1308 secret key to be used by the server to encrypt the private key. 1309 While that attribute was originally designated for specifying a 1310 firmware encryption key, it exactly mirrors the requirements for 1311 specifying a private key encryption key. If the server does not have 1312 a secret key matching the identifier specified by the client, the 1313 request must be terminated and an error returned to the client. 1314 Distribution of the key specified by the DecryptKeyIdentifer to the 1315 key generator and the client is outside the scope of this document. 1317 4.4.2. Server-side Key Generation Response 1319 If the request is successful, the server response MUST have an HTTP 1320 200 response code with a content-type of "multipart/mixed" consisting 1321 of two parts. One part is the private key data and the other part is 1322 the certificate data. 1324 The format in which the private key data part is returned is 1325 dependent on whether the private key is being returned with 1326 additional encryption on top of that provided by TLS. 1328 o If additional encryption is being employed, the private key is 1329 placed inside of a CMS SignedData. The SignedData is signed by 1330 the party that generated the private key, which may or may not be 1331 the EST server. The SignedData is further protected inside of a 1332 CMS EnvelopedData, as described in Section 4 of [RFC5958]. The 1333 EnvelopedData content is encrypted using the secret key 1334 identified in the request. The EnvelopedData is returned in the 1335 response as an "application/pkcs7-mime" part. 1337 o If additional encryption is not being employed, the private key 1338 data MUST be an "application/pkcs8". An "application/pkcs8" part 1339 consists of the base 64-encoded DER-encoded PrivateKeyInfo 1340 sandwiched between headers as described in [RFC5958]. 1342 The certificate data part is an "application/pkcs7-mime" and exactly 1343 matches the certificate response to /simpleEnroll. If both parts are 1344 "application/pkcs7-mime" the client checks each; one will be a certs- 1345 only Simple PKI response and the other will be the CMS message with 1346 the encrypted data. 1348 -----BEGIN PRIVATE KEY----- 1349 MIIBhDCB7gIBADBFMQswCQYDVQQGEwJBVTETMBEGA1UECBMKU29tZS1TdGF0ZTEh 1350 Simplified example of base 64 encoding of DER-encoded PrivateKeyInfo 1351 ED8rf3UDF6HjloiV3jBnpetx4JjZH/BlmD9HMqofVEryb1e4iZgMUvuIgwEjQwpD 1352 8J4OhHvLh1o= 1353 -----END PRIVATE KEY----- 1355 or 1357 -----BEGIN PKCS7----- 1358 MIIBhDCB7gIBADBFMQswCQYDVQQGEwJBVTETMBEGA1UECBMKU29tZS1TdGF0ZTEh 1359 Simplified example of base 64 encoding of CMS secured Private key 1360 ED8rf3UDF6HjloiV3jBnpetx4JjZH/BlmD9HMqofVEryb1e4iZgMUvuIgwEjQwpD 1361 8J4OhHvLh1o= 1362 -----END PKCS7----- 1364 When rejecting a request, the server MUST specify either an HTTP 4xx 1365 error, or an HTTP 5xx error. If the content-type is not set, the 1366 response data MUST be a plain text human-readable error message. 1368 4.5. CSR Attributes 1370 CA policy may allow inclusion of client-provided attributes in 1371 certificates that it issues, and some of these attributes may 1372 describe information that is not available to the CA. In addition, a 1373 CA may desire to certify a certain type of public key and a client 1374 may not have a priori knowledge of that fact. Therefore, clients 1375 SHOULD request a list of expected attributes that are required, or 1376 desired, by the CA in an enrollment request, or if dictated by local 1377 policy. 1379 Requesting CSR Attributes is optional but clients are advised that 1380 CA's may refuse enrollment requests that are not encoded according to 1381 the CA's policy. 1383 4.5.1. CSR Attributes Request 1385 The EST client requests a list of CA-desired CSR attributes from the 1386 CA by sending an HTTPS GET message to the EST server with an 1387 operations path of "/CSRAttrs". 1389 4.5.2. CSR Attributes Response 1391 If locally configured policy for an authenticated EST client 1392 indicates a CSR Attributes Response is to be provided, the server 1393 response MUST include an HTTP 200 response code. An HTTP response 1394 code of 204 or 404 indicates that a CSR Attributes Response is not 1395 available. Regardless of the response code, the EST server and CA 1396 MAY reject any subsequent enrollment requests for any reason, e.g., 1397 incomplete CSR attributes in the request. 1399 If the CA requires a particular crypto system (e.g., certification of 1400 a public key based on a certain elliptic curve) it MUST provide that 1401 information in the CSR Attributes response. If an EST server 1402 requires the linking of identity and PoP information (see 1403 Section 3.5) it MUST include the challengePassword OID in the CSR 1404 Attributes response. 1406 Responses to attribute request messages MUST be encoded as content 1407 type "application/csrattrs". The syntax for application/csrattrs 1408 body is as follows: 1410 Csrattrs ::= SEQUENCE SIZE (0..MAX) OF OBJECT IDENTIFIER { } 1412 An EST server includes zero or more object identifiers that it 1413 requests the client to include in a certification request. When the 1414 server encodes Csrattrs as an empty SEQUENCE it means that the server 1415 has no specific additional attributes it requests in a client 1416 certification request (this is functionally equivalent to an HTTP 1417 response code of 204 or 404.) The sequence is Distinguished Encoding 1418 Rules (DER) encoded and then base 64 encoded (section 4 of 1419 [RFC4648]). The resulting text forms the application/csrattr body, 1420 without headers. 1422 For example, if a CA requests a client to submit a certification 1423 request containing the Media Access Control (MAC) address [RFC2397] 1424 of a device, the challengePassword (indicating that Linking of 1425 Identity and POP information is requested, see Section 3.5), to use 1426 the the secp384r1 elliptic curve, and to use the SH384 hash function 1427 then it sends the following object identifiers: 1429 o macAddress: 1.3.6.1.1.1.1.22 1431 o challengePassword: 1.2.840.113549.1.9.7 1433 o the secp384r1 elliptic curve: 1.3.132.0.4 1435 o the SHA384 hash function: 2.16.840.1.101.3.4.2.2 1437 and encodes them into an ASN.1 SEQUENCE to produce: 1439 30 26 06 07 2B 06 01 01 01 01 16 06 09 2A 86 48 86 F7 0D 01 09 07 1440 06 05 2B 81 04 00 04 06 09 60 86 48 01 65 03 04 02 02 1442 and then base 64 encodes the resulting ASN.1 SEQUENCE to produce: 1444 MCYGBysGAQEBARYGCSqGSIb3DQEJBwYFK4EEAAQGCWCGSAFlAwQCAg== 1446 The EST client parses the OID's in the response and handles each OID 1447 independently. When an OID indicates a known descriptive CSR 1448 attribute type, the client SHOULD include the requested information 1449 in the subsequent CSR that it submits, either in the CSR attributes 1450 or in any other appropriate CSR field. When an OID indicates a 1451 particular way to generate the CSR, the client SHOULD generate its 1452 CSR according to the parsed OID. When an OID is of an unknown type 1453 the OID MUST be ignored by the client. 1455 5. Contributors/Acknowledgements 1457 The editors would like to thank Stephen Kent, Vinod Arjun, Jan 1458 Vilhuber, Sean Turner, Russ Housley, and others for their feedback 1459 and prototypes of early drafts. Our thanks also go the authors of 1460 [RFC6403] around whose document we structured part of this 1461 specification. 1463 6. IANA Considerations 1465 IANA is requested to register the following: 1467 IANA SHALL update the well-known URI registry with the following 1468 filled-in template from [RFC5785]. 1470 URI suffix: est 1472 Change controller: IETF 1474 IANA SHALL update the Application Media Types registry with the 1475 following filled-in template from [RFC4288]. 1477 The media subtype for Attributes in a CertificationRequest is 1478 application/csrattrs. 1480 Type name: application 1482 Subtype name: csrattrs 1484 Required parameters: None 1486 Optional parameters: None 1488 Encoding considerations: binary; 1489 Security Considerations: 1491 Clients request a list of attributes that servers wish to be in 1492 certification requests. The request/response SHOULD be done in 1493 a TLS-protected tunnel. 1495 Interoperability considerations: None 1497 Published specification: This memo. 1499 Applications which use this media type: 1501 Enrollment over Secure Transport (EST) 1503 Additional information: 1505 Magic number(s): None 1507 File extension: None 1509 Macintosh File Type Code(s): 1511 Person & email address to contact for further information: 1513 Dan Harkins 1515 Restrictions on usage: None 1517 Author: Dan Harkins 1519 Intended usage: COMMON 1521 Change controller: The IESG 1523 7. Security Considerations 1525 Support for Basic authentication as specified in HTTP [RFC2617] 1526 allows the server access to a client's cleartext password. This 1527 provides support for legacy username/password databases but requires 1528 exposing the plaintext password to the EST server. Use of a PIN or 1529 one-time-password can help mitigate such exposure, but it is 1530 RECOMMENDED that EST clients use such credentials only once to obtain 1531 a client certificate (that will be used during future interactions 1532 with the EST server). 1534 When a client uses the Implicit TA database for certificate 1535 validation (see Section 3) then authorization proceeds as specified 1536 in Section 3.6.2. In this situation, the client has validated the 1537 server as being a certified-by-a-third-party responder for the URI 1538 configured, but cannot verify that the responder is authorized to act 1539 as an RA for the PKI in which the client is trying to enroll. 1540 Clients using an implicit trust anchor database are RECOMMENDED to 1541 only use TLS-based client authentication (to prevent exposing HTTP- 1542 based Client Authentication information). It is RECOMMENDED that 1543 such clients include "Linking Identity and POP information" 1544 (Section 3.5) in requests (to prevent such requests from being 1545 forwarded to a real EST server by a MITM). It is RECOMMENDED that 1546 the implicit trust anchor database used for EST server authentication 1547 be carefully managed, to reduce the chance of a third-party CA with 1548 poor certification practices from being trusted. Disabling the 1549 implicit trust anchor database after succesfully recieving the 1550 Distribution of CA Certificates response (Section 4.1.3) limits any 1551 vulnerability to the first TLS enchange. 1553 Certificate-less TLS ciphersuites that maintain security and perform 1554 the mutual authentiation necessary for enrollment have the following 1555 properties: 1557 o the only information leaked by an active attack is whether a 1558 single guess of the secret is correct or not. 1560 o any advantage an adversary gains is through interaction and not 1561 compuation. 1563 o it is possible to perform countermeasures, such as exponential 1564 backoff after a certain number of failed attempts, to frustrate 1565 repeated active attacks. 1567 Using a certificate-less ciphersuite that does not have the 1568 properties listed above would render the results of enrollment void 1569 and potentially result in certificates being issued to 1570 unauthenticated and/or unauthorized entities. 1572 When using a certificate-less TLS cipher suite, the shared secret 1573 used for authentication and authorization cannot be shared with an 1574 entity that is not a party to the exchange: someone other than the 1575 client and the server. Any additional sharing of secrets voids the 1576 security afforded by a certificate-less cipher suite. Exposure of a 1577 shared secret used by a certificate-less cipher suite to a third- 1578 party enables client impersonation that can results in corruption of 1579 a client's trust anchor database. 1581 As described in CMC Section 6.7, "For keys that can be used as 1582 signature keys, signing the certification request with the private 1583 key serves as a POP on that key pair". The inclusion of tls-unique 1584 within the certification request links the proof-of-possession to the 1585 TLS proof-of-identity by enforcing that the POP operation occurred 1586 while the TLS session was active. This implies to the server that 1587 the authenticated client currently has access to the private key. If 1588 the authenticated client is known to have specific capabilities, such 1589 as hardware protection for authentication credentials and key 1590 storage, this implication is strengthened but not proven. 1592 The server-side key generation method allows keys to be transported 1593 over the TLS connection to the client. The distribution of private 1594 key material is inherently risky. Private key distribution uses the 1595 encryption mode of the negotiated TLS cipher suite. Keys are not 1596 protected by preferred key wrapping methods such as AES Key Wrap 1597 [RFC3394] or as specified in [RFC5958] as encryption of the private 1598 key beyond that provided by TLS is optional. It is RECOMMEND that 1599 EST servers not support this operation by default. It is RECOMMENDED 1600 that clients not request this service unless there is a compelling 1601 operational benefit. Use of an implicit trust anchor database is NOT 1602 RECOMMENDED when server-side key generation is employed. The use of 1603 an encrypted CMS Server-side Key Generation Response is RECOMMENDED. 1605 Regarding the CSR attributes that the CA may list for inclusion in an 1606 enrollment request, there are no real inherent security issues with 1607 the content being conveyed but an adversary who is able to interpose 1608 herself into the conversation could exclude attributes that a server 1609 may want, include attributes that a server may not want, and render 1610 meaningless other attributes that a server may want. 1612 8. References 1614 8.1. Normative References 1616 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1617 April 1992. 1619 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1620 Extensions (MIME) Part Two: Media Types", RFC 2046, 1621 November 1996. 1623 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1624 Requirement Levels", BCP 14, RFC 2119, March 1997. 1626 [RFC2314] Kaliski, B., "PKCS #10: Certification Request Syntax 1627 Version 1.5", RFC 2314, March 1998. 1629 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 1630 Infrastructure Operational Protocols: FTP and HTTP", 1631 RFC 2585, May 1999. 1633 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1634 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1635 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1637 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1638 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1639 Authentication: Basic and Digest Access Authentication", 1640 RFC 2617, June 1999. 1642 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1644 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 1645 Classes and Attribute Types Version 2.0", RFC 2985, 1646 November 2000. 1648 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1649 Request Syntax Specification Version 1.7", RFC 2986, 1650 November 2000. 1652 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1653 Resource Identifier (URI): Generic Syntax", STD 66, 1654 RFC 3986, January 2005. 1656 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1657 Requirements for Security", BCP 106, RFC 4086, June 2005. 1659 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 1660 Protect Firmware Packages", RFC 4108, August 2005. 1662 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1663 "Internet X.509 Public Key Infrastructure Certificate 1664 Management Protocol (CMP)", RFC 4210, September 2005. 1666 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1667 Registration Procedures", RFC 4288, December 2005. 1669 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1670 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1672 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1673 and T. Wright, "Transport Layer Security (TLS) 1674 Extensions", RFC 4366, April 2006. 1676 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1677 Encodings", RFC 4648, October 2006. 1679 [RFC4945] Korver, B., "The Internet IP Security PKI Profile of 1680 IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007. 1682 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 1683 "Using the Secure Remote Password (SRP) Protocol for TLS 1684 Authentication", RFC 5054, November 2007. 1686 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1687 "Transport Layer Security (TLS) Session Resumption without 1688 Server-Side State", RFC 5077, January 2008. 1690 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 1691 (CMC)", RFC 5272, June 2008. 1693 [RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS 1694 (CMC): Transport Protocols", RFC 5273, June 2008. 1696 [RFC5274] Schaad, J. and M. Myers, "Certificate Management Messages 1697 over CMS (CMC): Compliance Requirements", RFC 5274, 1698 June 2008. 1700 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1701 Housley, R., and W. Polk, "Internet X.509 Public Key 1702 Infrastructure Certificate and Certificate Revocation List 1703 (CRL) Profile", RFC 5280, May 2008. 1705 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1706 RFC 5652, September 2009. 1708 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 1709 "Transport Layer Security (TLS) Renegotiation Indication 1710 Extension", RFC 5746, February 2010. 1712 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 1713 Uniform Resource Identifiers (URIs)", RFC 5785, 1714 April 2010. 1716 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 1717 for TLS", RFC 5929, July 2010. 1719 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 1720 August 2010. 1722 [RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, 1723 August 2010. 1725 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1726 Verification of Domain-Based Application Service Identity 1727 within Internet Public Key Infrastructure Using X.509 1728 (PKIX) Certificates in the Context of Transport Layer 1729 Security (TLS)", RFC 6125, March 2011. 1731 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 1732 Updates", RFC 6402, November 2011. 1734 [SHS] National Institute of Standards and Technology, "Federal 1735 Information Processing Standard Publication 180-4: Secure 1736 Hash Standard (SHS)", March 2012, . 1739 [X.680] ITU-T Recommendation, "ITU-T Recommendation X.680 Abstract 1740 Syntax Notation One (ASN.1): Specification of basic 1741 notation", November 2008, 1742 . 1744 [X.690] ITU-T Recommendation, "ITU-T Recommendation X.690 ASN.1 1745 encoding rules: Specification of Basic Encoding Rules 1746 (BER), Canonical Encoding Rules (CER) and Distinguished 1747 Encoding Rules (DER)", November 2008, 1748 . 1750 8.2. Informative References 1752 [IDevID] IEEE Std, "IEEE 802.1AR Secure Device Identifier", 1753 December 2009, . 1756 [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, 1757 August 1998. 1759 [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher 1760 Suites to Transport Layer Security (TLS)", RFC 2712, 1761 October 1999. 1763 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 1764 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 1766 [RFC6403] Zieglar, L., Turner, S., and M. Peck, "Suite B Profile of 1767 Certificate Management over CMS", RFC 6403, November 2011. 1769 [SP-800-57-Part-1] 1770 National Institute of Standards and Technology, 1771 "Recommendation for Key Management - Part 1: General 1772 (Revision 3)", July 2012, . 1776 [X.520] ITU-T Recommendation, "ITU-T Recommendation X.520 The 1777 Directory: Selected attribute types", November 2008, 1778 . 1780 Appendix A. Operational Scenario Example Messages 1782 (informative) 1784 This section expands on the Operational Scenario Overviews by 1785 providing detailed examples of the messages at each TLS layer. 1787 A.1. Obtaining CA Certificates 1789 The following is an example of a valid /CACerts exchange. 1791 During the initial TLS handshake the client can ignore the optional 1792 server generated "certificate request" and can instead proceed with 1793 the HTTP GET request: 1795 GET /CACerts HTTP/1.1 1796 User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 OpenS 1797 SL/0.9.8b zlib/1.2.3 libidn/0.6.5 1798 Host: 127.0.0.1:8085 1799 Accept: */* 1801 In response the server provides the current CA certificate: 1803 <= Recv header, 38 bytes (0x26) 1804 Content-Type: application/pkcs7-mime 1805 == Info: no chunk, no close, no size. Assume close to signal end 1806 <= Recv header, 2 bytes (0x2) 1808 <= Recv data, 1111 bytes (0x457) 1809 -----BEGIN PKCS7-----.MIIDEQYJKoZIhvcNAQcCoIIDAjCCAv4CAQExADALBg 1810 kqhkiG9w0BBwGgggLkMIIC.4DCCAcigAwIBAgIJAOjxMZcXhE5wMA0GCSqGSIb3D 1811 QEBBQUAMBcxFTATBgNVBAMT.DGVzdEV4YW1wbGVDQTAeFw0xMjA3MDQxODM5Mjda 1812 Fw0xMzA3MDQxODM5MjdaMBcx.FTATBgNVBAMTDGVzdEV4YW1wbGVDQTCCASIwDQY 1813 JKoZIhvcNAQEBBQADggEPADCC.AQoCggEBALQ7SjZSt6qrnBzUnBNj9z4oxYkvMA 1814 Vh0OIOVRkNhz/2kDGsds0ne7cw.W33kYlxPba4psdLMixCT/O8ZQMpgA+QFKtwb9 1815 VPE8EFUgGzxSYHQHjhJsbg0BVaN.Ya38vjKMjvosuSXUHwkvU57SInSkMr3/aNtS 1816 T8qFfeC6Vuf/G/GLHGuHQKAy/DSo.206MjaMNmWYRVQQVErGookRA4GBF/YE+G/C 1817 SlTsCQNE0KyBFz8JWIkgYY2gYkxb7.wWMvvhaU/Esp+2DG92v9Dhs2MRgrR+WPs7 1818 Y6CYOLD5Mr5lEdkHg27IxkSAoRrI6D.fnVVEQGCj7QrrsUgfXFVYv6cCWFfhMcCA 1819 wEAAaMvMC0wDAYDVR0TBAUwAwEB/zAd.BgNVHQ4EFgQUhH9KxW5TsjkgL7kg2kxJ 1820 yy5tD/MwDQYJKoZIhvcNAQEFBQADggEB.AD+vydZo292XFb2vXojdKD57Gv4tKVm 1821 hvXRdVInntzkY/0AyFCfHJ4BwndgtMh4t.rvBD8+8dL+W3jfPjcSCcUQ/JEnFuMn 1822 b5+kivLeqOnUshETasFPBz2Xq4C1sHDno9.CWOcsjPPw08Tn4dSrzDBSq1NdXB2z 1823 9NOpaVnbpb01qQGhXSOaEvcbZcDuGiW7Di3.gV++remokuPph/s6XoZffzc7ZVzf 1824 Job6tS4RwNz01sutPybXiRWivOz7+QeCOT87.nTGlkQH/+RImUyJ2jefjAW/GDFT 1825 Pzek6cZnabAtsg32n0Pv0j0/1RTNSdYGxPIVA.2f9fhMqMz+vm3w4CFNkGZnOhAD 1826 EA.-----END PKCS7-----. 1828 A.2. Certificate TLS authentication 1830 The following is an example of a valid /simpleEnroll exchange. 1831 During this exchange the EST client uses an existing certificate 1832 issued by a thirt-party CA to obtain an initial certificate from the 1833 EST server. 1835 During the initial TLS handshake the server generated "certificate 1836 request" includes both the distinguished name of the EST CA 1837 ("estExampleCA") and it includes the distinguished name of a third- 1838 party CA ("estEXTERNALCA"): 1840 0d 00 00 3d 03 01 02 40 00 37 00 1a 30 18 31 16 ...=...@.7..0.1. 1841 30 14 06 03 55 04 03 13 0d 65 73 74 45 58 54 45 0...U....estEXTE 1842 52 4e 41 4c 43 41 00 19 30 17 31 15 30 13 06 03 RNALCA..0.1.0... 1843 55 04 03 13 0c 65 73 74 45 78 61 6d 70 6c 65 43 U....estExampleC 1844 41 A 1846 Which decodes as: 1848 Acceptable client certificate CA names 1849 /CN=estEXTERNALCA 1850 /CN=estExampleCA 1851 The EST client provides a certificate issued by "estEXTERNALCA" in 1852 the certificate response and the TLS handshake proceeds to 1853 completion. The EST server accepts the EST client certificate for 1854 authentication and accepts the EST client's POSTed certificate 1855 request: 1856 POST /simpleEnroll HTTP/1.1 1857 User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 OpenS 1858 SL/0.9.8b zlib/1.2.3 libidn/0.6.5 1859 Host: 127.0.0.1:8085 1860 Accept: */* 1861 Content-Type: application/pkcs10 1862 Content-Length: 952 1864 => Send data, 952 bytes (0x3b8) 1865 -----BEGIN CERTIFICATE REQUEST-----.MIIChjCCAW4CAQAwQTElMCMGA1UE 1866 AxMccmVxIGJ5IGNsaWVudCBpbiBkZW1vIHN0.ZXAgNjEYMBYGA1UEBRMPUElEOld 1867 pZGdldCBTTjo2MIIBIjANBgkqhkiG9w0BAQEF.AAOCAQ8AMIIBCgKCAQEAwhYyI+ 1868 aYezyx+kW0GVUbMKLf2BUd8BgGykkIJYxms6SH.Bv5S4ktcpYbEpR9iCmp96vK6a 1869 Ar57ArZtMmi0Y6eLX4c+njJnYhUeTivnfyfMM5d.hNVwyzKbJagm5f+RLTMfp0y0 1870 ykqrfZ1hFhcNrRzF6mJeaORTHBehMdu8RXcbmy5R.s+vjnUC4Fe3/oLHtXePyYv1 1871 qqlkk0XDrw/+lx0y4Px5tiyb84iPnQOXjG2tuStM+.iEvfpNAnwU0+3GDjl3sjx0 1872 +gTKvblp6Diw9NSaqIAKupcgWsA0JlyYkgPiJnXFKL.vy6rXoOyx3wAbGKLrKCxT 1873 l+RH3oNXf3UCH70aD758QIDAQABoAAwDQYJKoZIhvcN.AQEFBQADggEBADwpafWU 1874 BsOJ2g2oyHQ7Ksw6MwvimjhB7GhjweCcceTSLInUMk10.4E0TfNqaWcoQengMVZr 1875 IcbOb+sa69BWNB/WYIULfEtJIV23/g3n/y3JltMNw/q+R.200t0bNAViijHQHmlF 1876 6dt93tkRrTzXnhV70Ijnff08G7P9HfnXQH4Eiv3zOB6Pak.JoL7QlWQ+w5vHpPo6 1877 WGH5n2iE+Ql76F0HykGeqaR402+ae0WlGLHEvcN9wiFQVKh.KUHteU10SEPijlqf 1878 QW+hciLleX2CwuZY5MqKb4qqyDTs4HSQCBCl8jR2cXsGDuN4.PcMPp+9A1/UPuGD 1879 jhwPt/K3y6aV8zUEh8Ws=.-----END CERTIFICATE REQUEST-----. 1881 The EST server uses the trusted third party CA issued certificate to 1882 perform additional authorization and issues a certificate to the 1883 client: 1885 <= Recv header, 38 bytes (0x26) 1886 Content-Type: application/pkcs7-mime 1887 == Info: no chunk, no close, no size. Assume close to signal end 1888 <= Recv header, 2 bytes (0x2) 1890 <= Recv data, 1200 bytes (0x4b0) 1891 -----BEGIN PKCS7-----.MIIDUQYJKoZIhvcNAQcCoIIDQjCCAz4CAQExADALBg 1892 kqhkiG9w0BBwGgggMkMIID.IDCCAgigAwIBAgIBBjANBgkqhkiG9w0BAQUFADAXM 1893 RUwEwYDVQQDEwxlc3RFeGFt.cGxlQ0EwHhcNMTIwNzA0MTgzOTM3WhcNMTMwNzA0 1894 MTgzOTM3WjBBMSUwIwYDVQQD.ExxyZXEgYnkgY2xpZW50IGluIGRlbW8gc3RlcCA 1895 2MRgwFgYDVQQFEw9QSUQ6V2lk.Z2V0IFNOOjYwggEiMA0GCSqGSIb3DQEBAQUAA4 1896 IBDwAwggEKAoIBAQDCFjIj5ph7.PLH6RbQZVRswot/YFR3wGAbKSQgljGazpIcG/ 1897 lLiS1ylhsSlH2IKan3q8rpoCvns.Ctm0yaLRjp4tfhz6eMmdiFR5OK+d/J8wzl2E 1898 1XDLMpslqCbl/5EtMx+nTLTKSqt9.nWEWFw2tHMXqYl5o5FMcF6Ex27xFdxubLlG 1899 z6+OdQLgV7f+gse1d4/Ji/WqqWSTR.cOvD/6XHTLg/Hm2LJvziI+dA5eMba25K0z 1900 6IS9+k0CfBTT7cYOOXeyPHT6BMq9uW.noOLD01JqogAq6lyBawDQmXJiSA+ImdcU 1901 ou/Lqteg7LHfABsYousoLFOX5Efeg1d./dQIfvRoPvnxAgMBAAGjTTBLMAkGA1Ud 1902 EwQCMAAwHQYDVR0OBBYEFJv4oLLeNxNK.OMmQDDujyNR+zaVPMB8GA1UdIwQYMBa 1903 AFIR/SsVuU7I5IC+5INpMScsubQ/zMA0G.CSqGSIb3DQEBBQUAA4IBAQCMdomfdR 1904 9vi4VUYdF+eym7F8qVUG/1jtjfaxmrzKeZ.7LQ1F758RtwG9CDu2GPHNPjjeM+DJ 1905 RQZN999eLs3Qd/DIJCNimaqdDqmkeBFC5hq.LZOxbKhSmhlR7YKjIZuyI299rOaI 1906 W54ULyz8k0zw6R1/0lMJTsDFGJM+9yDeaARE.n3vtKnUDGHsVU3fYpDENaqUunoU 1907 MZfuEdejfHhU7lVbJI1oSJbnRwBFkPr/RQ3/5.FymcrBD9RpAM5MsQIn0BONil/o 1908 JM+LjOJqyZLbBxz6P3w/OiJGYJNfFT8YudLfjZ.LDX8A8FFcReapNELC4QxE4OrA 1909 hN3sQUT2O7ndIsit4kJoQAxAA==.-----END PKCS7-----. 1911 A.3. Username/Password Distributed Out-of-Band 1913 The following is an example of a valid /simpleEnroll exchange. 1914 During this exchange the EST client uses an out-of-band distributed 1915 username/password to authenticate itself to the EST server. 1917 During the initial TLS handshake the client can ignore the optional 1918 server generated "certificate request" and can instead proceed with 1919 the HTTP POST request: 1921 POST /simpleEnroll HTTP/1.1 1922 User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 OpenS 1923 SL/0.9.8b zlib/1.2.3 libidn/0.6.5 1924 Host: 127.0.0.1:8085 1925 Accept: */* 1926 Content-Type: application/pkcs10 1927 Content-Length: 952 1929 => Send data, 952 bytes (0x3b8) 1930 -----BEGIN CERTIFICATE REQUEST-----.MIIChjCCAW4CAQAwQTElMCMGA1UE 1931 AxMccmVxIGJ5IGNsaWVudCBpbiBkZW1vIHN0.ZXAgMjEYMBYGA1UEBRMPUElEOld 1932 pZGdldCBTTjoyMIIBIjANBgkqhkiG9w0BAQEF.AAOCAQ8AMIIBCgKCAQEAz9lXz9 1933 MowulOx0W5v1k7GKlsNy7mAgmkz/wZDImBDXez.QZCb8lrO8iTD3tI0NH2xpkY3b 1934 uqFjdtQTzCmANLyNWtR1sC5GjN/EM1JSCrO/zZM.ig835RXJTP878N/jNW7EzSxb 1935 /zK5OzKJoRbZ4HgZm4NDapMfMcB4jqBdPxoPAqeR.+KTkv1+9m1vvsdKIs5Hm4Sp 1936 O2WolHPw5BCXdu5zleb6ACih7Zpd2cpHFz6ZHC0G1.Of+F//0BzkFSqWsmUomyJy 1937 WCfLCuX9grs1CNlLxw0gcMprdTxLxjc18z03ZmBCq0.qq5/mUK/tv9R2k8+WuP3a 1938 kzTUIkeHtcp6FVFl3D+TwIDAQABoAAwDQYJKoZIhvcN.AQEFBQADggEBAJH7Etuy 1939 B/oQgQeals08mD2U31FfQ/uYqjNxzZpZJSzVLGMASv9a.pNzaWdfqPdIs+ZZ+gAQ 1940 QkVcXjdbqY3pAf/EeWk+KnuAUjOIPKu3ZBPVbWbXu/Ie7.F1ekQ7TLkFNkHSxHRu 1941 2/bPIByBLRVfWNVXd3wPq+QxqMqgIjBGaTJM5kuHndYFGj.Xdf4rlGRPyOOwG/Xf 1942 QrKBB3tzpbJCy+cwOUAJFPOTO+86RUjf9Wh+yoM182vlg8O.FyEaaA/PMpl3aEcT 1943 BlRZmPx4e7FLwGIhbgE7/6K0nF99xdGd7JYPHasbcWszxD0Z.oPYm+44g0gOnhlj 1944 OWpRiKXcnngSSutRILaw=.-----END CERTIFICATE REQUEST-----. 1945 == Info: upload completely sent off: 952 out of 952 bytes 1946 == Info: HTTP 1.1 or later with persistent connection, pipelining 1947 supported 1949 The EST server accepts this request but since a client certificate 1950 was not provided for authentication/authorization the EST server 1951 responds with the WWW-authenticate header: 1952 <= Recv header, 27 bytes (0x1b) 1953 HTTP/1.1 401 Unauthorized 1954 <= Recv header, 75 bytes (0x4b) 1955 WWW-Authenticate: Digest qop="auth", realm="estrealm", nonce="13 1956 41427174" 1958 The EST client repeats the request, this time including the requested 1959 Authorization header: 1961 == Info: SSL connection using AES256-SHA 1962 == Info: Server certificate: 1963 == Info: subject: CN=127.0.0.1 1964 == Info: start date: 2012-07-04 18:39:27 GMT 1965 == Info: expire date: 2013-07-04 18:39:27 GMT 1966 == Info: common name: 127.0.0.1 (matched) 1967 == Info: issuer: CN=estExampleCA 1968 == Info: SSL certificate verify ok. 1969 == Info: Server auth using Digest with user 'estuser' 1970 => Send header, 416 bytes (0x1a0) 1971 POST /simpleEnroll HTTP/1.1 1972 Authorization: Digest username="estuser", realm="estrealm", nonc 1973 e="1341427174", uri="/simpleEnroll", cnonce="ODc0OTk2", nc=00000 1974 001, qop="auth", response="48a2b671ccb6596adfef039e134b7d5d" 1975 User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 OpenS 1976 SL/0.9.8b zlib/1.2.3 libidn/0.6.5 1977 Host: 127.0.0.1:8085 1978 Accept: */* 1979 Content-Type: application/pkcs10 1980 Content-Length: 952 1982 => Send data, 952 bytes (0x3b8) 1983 -----BEGIN CERTIFICATE REQUEST-----.MIIChjCCAW4CAQAwQTElMCMGA1UE 1984 AxMccmVxIGJ5IGNsaWVudCBpbiBkZW1vIHN0.ZXAgMjEYMBYGA1UEBRMPUElEOld 1985 pZGdldCBTTjoyMIIBIjANBgkqhkiG9w0BAQEF.AAOCAQ8AMIIBCgKCAQEAz9lXz9 1986 MowulOx0W5v1k7GKlsNy7mAgmkz/wZDImBDXez.QZCb8lrO8iTD3tI0NH2xpkY3b 1987 uqFjdtQTzCmANLyNWtR1sC5GjN/EM1JSCrO/zZM.ig835RXJTP878N/jNW7EzSxb 1988 /zK5OzKJoRbZ4HgZm4NDapMfMcB4jqBdPxoPAqeR.+KTkv1+9m1vvsdKIs5Hm4Sp 1989 O2WolHPw5BCXdu5zleb6ACih7Zpd2cpHFz6ZHC0G1.Of+F//0BzkFSqWsmUomyJy 1990 WCfLCuX9grs1CNlLxw0gcMprdTxLxjc18z03ZmBCq0.qq5/mUK/tv9R2k8+WuP3a 1991 kzTUIkeHtcp6FVFl3D+TwIDAQABoAAwDQYJKoZIhvcN.AQEFBQADggEBAJH7Etuy 1992 B/oQgQeals08mD2U31FfQ/uYqjNxzZpZJSzVLGMASv9a.pNzaWdfqPdIs+ZZ+gAQ 1993 QkVcXjdbqY3pAf/EeWk+KnuAUjOIPKu3ZBPVbWbXu/Ie7.F1ekQ7TLkFNkHSxHRu 1994 2/bPIByBLRVfWNVXd3wPq+QxqMqgIjBGaTJM5kuHndYFGj.Xdf4rlGRPyOOwG/Xf 1995 QrKBB3tzpbJCy+cwOUAJFPOTO+86RUjf9Wh+yoM182vlg8O.FyEaaA/PMpl3aEcT 1996 BlRZmPx4e7FLwGIhbgE7/6K0nF99xdGd7JYPHasbcWszxD0Z.oPYm+44g0gOnhlj 1997 OWpRiKXcnngSSutRILaw=.-----END CERTIFICATE REQUEST-----. 1999 The ESTserver uses the username/password to perform authentication/ 2000 authorization and responds with the issued certificate: 2002 <= Recv header, 38 bytes (0x26) 2003 0000: Content-Type: application/pkcs7-mime 2004 == Info: no chunk, no close, no size. Assume close to signal end 2005 <= Recv header, 2 bytes (0x2) 2007 <= Recv data, 1200 bytes (0x4b0) 2008 -----BEGIN PKCS7-----.MIIDUQYJKoZIhvcNAQcCoIIDQjCCAz4CAQExADALBg 2009 kqhkiG9w0BBwGgggMkMIID.IDCCAgigAwIBAgIBAjANBgkqhkiG9w0BAQUFADAXM 2010 RUwEwYDVQQDEwxlc3RFeGFt.cGxlQ0EwHhcNMTIwNzA0MTgzOTM0WhcNMTMwNzA0 2011 MTgzOTM0WjBBMSUwIwYDVQQD.ExxyZXEgYnkgY2xpZW50IGluIGRlbW8gc3RlcCA 2012 yMRgwFgYDVQQFEw9QSUQ6V2lk.Z2V0IFNOOjIwggEiMA0GCSqGSIb3DQEBAQUAA4 2013 IBDwAwggEKAoIBAQDP2VfP0yjC.6U7HRbm/WTsYqWw3LuYCCaTP/BkMiYENd7NBk 2014 JvyWs7yJMPe0jQ0fbGmRjdu6oWN.21BPMKYA0vI1a1HWwLkaM38QzUlIKs7/NkyK 2015 DzflFclM/zvw3+M1bsTNLFv/Mrk7.MomhFtngeBmbg0Nqkx8xwHiOoF0/Gg8Cp5H 2016 4pOS/X72bW++x0oizkebhKk7ZaiUc./DkEJd27nOV5voAKKHtml3ZykcXPpkcLQb 2017 U5/4X//QHOQVKpayZSibInJYJ8sK5f.2CuzUI2UvHDSBwymt1PEvGNzXzPTdmYEK 2018 rSqrn+ZQr+2/1HaTz5a4/dqTNNQiR4e.1ynoVUWXcP5PAgMBAAGjTTBLMAkGA1Ud 2019 EwQCMAAwHQYDVR0OBBYEFChDQpKEfG9c.e4JaMf8438tb2XOIMB8GA1UdIwQYMBa 2020 AFIR/SsVuU7I5IC+5INpMScsubQ/zMA0G.CSqGSIb3DQEBBQUAA4IBAQAn42mIVG 2021 piaY4yqFD0F8KyUhKsdNnyKeeISQxP//lp.quIieJzdWSc7bhWZNldSzNswCod8B 2022 4eJToQejLSNb8JBDC849z0tcuyHgN6N/p8z.IwI+hAlfXS9q02OECyFes4Jmzc7r 2023 erE5jtOdGsEDBIscw/A+Kv86wv6BKbagMslQ.51AJyPsL6iBhm7LPFrErJgH2kWN 2024 jDKFH9CcVFjXvgriMrLPFeqQWOpj/2XF+4m+c.f9QP5tSjieHJR1hnYk2tlodfE7 2025 iV4pJ07Mmf3yBf753VSUVybqWiMCd0Lm7oghSX.E2GAxrsU1N+N1odn+gJ2wmxTu 2026 AC2aHt9VPRViov4RRTvoQAxAA==.-----END PKCS7-----. 2028 A.4. Re-Enrollment 2030 The following is an example of a valid /simpleReEnroll exchange. 2031 During this exchange the EST client authenticates itself using an 2032 existing certificate issued by the EST CA. 2034 Initially this exchange is identical to enrollment using an 2035 externally issued certificate for client authentication since the 2036 server is not yet aware of the client's intention. As in that 2037 example the EST server the server generated "certificate request" 2038 includes both the distinguished name of the CA the EST server 2039 provides services for ("estExampleCA") and it includes the 2040 distinguished name of a trusted third party CA ("estEXTERNALCA"). 2042 0d 00 00 3d 03 01 02 40 00 37 00 1a 30 18 31 16 ...=...@.7..0.1. 2043 30 14 06 03 55 04 03 13 0d 65 73 74 45 58 54 45 0...U....estEXTE 2044 52 4e 41 4c 43 41 00 19 30 17 31 15 30 13 06 03 RNALCA..0.1.0... 2045 55 04 03 13 0c 65 73 74 45 78 61 6d 70 6c 65 43 U....estExampleC 2046 41 A 2048 In text format this is: 2050 Acceptable client certificate CA names 2051 /CN=estEXTERNALCA 2052 /CN=estExampleCA 2054 The EST client provides a certificate issued by "estExampleCA" in the 2055 certificate response and the TLS handshake proceeds to completion. 2056 The EST server accepts the EST client certificate for authentication 2057 and accepts the EST client's POSTed certificate request. 2059 The rest of the protocol traffic is effectively identical to a normal 2060 enrollment. 2062 A.5. Server Key Generation 2064 The following is an example of a valid /serverKeyGen exchange. 2065 During this exchange the EST client authenticates itself using an 2066 existing certificate issued by the CA the EST server provides 2067 services for. 2069 The initial TLS handshake is identical to the enrollment example 2070 handshake. The HTTP POSTed message is: 2072 POST /serverKeyGen HTTP/1.1 2073 User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 OpenS 2074 SL/0.9.8b zlib/1.2.3 libidn/0.6.5 2075 Host: 127.0.0.1:8085 2076 Accept: */* 2077 Content-Type: application/pkcs10 2078 Content-Length: 968 2080 => Send data, 968 bytes (0x3c8) 2081 -----BEGIN CERTIFICATE REQUEST-----.MIICkzCCAXsCAQAwTjEyMDAGA1UE 2082 AxMpc2VydmVyS2V5R2VuIHJlcSBieSBjbGll.bnQgaW4gZGVtbyBzdGVwIDUxGDA 2083 WBgNVBAUTD1BJRDpXaWRnZXQgU046NTCCASIw.DQYJKoZIhvcNAQEBBQADggEPAD 2084 CCAQoCggEBAMnlUlq0ag/fDAVhLgrXEAD6WtZw.Y2rVGev5saWirer2n0OzghB59 2085 uJByxPo0DYBYqZRuoRF0FTL1ZZTMaZxivge0ecA.ZcoR46jwSBoceMT1jkwFyAER 2086 t9Q2EwdnJLIPo/Ib2PLJNb4Jo8NNKmxtg55BgIVi.vkIB+rMtLeYRUVL0RUaBAqX 2087 FmtXRDceVFIEY24iUQw6vESGJKpArht592aT8lyaP.24bZovuG19dd5xtTX3j37K 2088 x49SlkUvLSpD6ZavIFAZn7Yv19LBKHvRIemybUo294.QeLb/VYP1O+EAthV/igiX 2089 1DHqlUZCZp5SdyUXUwZPatFboNwEVR0R3MJwVECAwEA.AaAAMA0GCSqGSIb3DQEB 2090 BQUAA4IBAQAqhHezK5/tvbXleHO/aTBVYO9l414NM+WA.wJcnS2UaJYScPBqlYK/ 2091 gij+dqAtFE+5ukAj56t7HnooI4EFo9r8jqCHewx7iLZYh.JDxo4hWOsAvHV+Iziy 2092 jkhJNdHBIqGM7Gd5f/2VJLEPQPmwNOL5P+2O4eQC/QeEYc.bAmfhOS8b/ZH09/9T 2093 PeaeQpjspjOui/100OuLE8KvU3FM0sXMYt1Va0A0jxzl+5k.EiEJo+ltXsQwdP0H 2094 csoTNBN+j3K18omJQS0e91X8v0xkMWYhUtonXD0YZ6SO/B9c.AE6GTADHA/xpSvA 2095 cqlWa+FHxjwEMXdmViHvMUywo31fDZ/TUvCPX.-----END CERTIFICATE REQUE 2096 ST-----. 2098 Because the DecryptKeyIdentifier attribute is not included in the 2099 request the response does not include additional encryption beyond 2100 the TLS session. The EST server response is: 2101 <= Recv header, 17 bytes (0x11) 2102 HTTP/1.1 200 OK 2103 <= Recv header, 16 bytes (0x10) 2104 Status: 200 OK 2105 <= Recv header, 67 bytes (0x43) 2106 Content-Type: multipart/mixed ; boundary=estServerExampleBoundar 2107 y 2108 == Info: no chunk, no close, no size. Assume close to signal end 2109 <= Recv header, 2 bytes (0x2) 2111 <= Recv data, 3234 bytes (0xca2) 2112 This is the preamble. It is to be ignored, though it.is a handy 2113 place for estServer to include an explanatory note.including con 2114 tact or support information..--estServerExampleBoundary.Content- 2115 Type=application/pkcs8..-----BEGIN PRIVATE KEY-----.MIIEvQIBADAN 2116 BgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC0781l7tri0yii.Mb9ZZYch8ze 2117 izXrjMPF/Rxoz2C9IU2THCrhPGXGQMne/zivce0m8/BMkkUc+DsSM.tzxn4l+9tI 2118 sVDkAe4FyzN0hLd/zawgj6kUoCi3mxZnb2rWaRYAmM5w41ImDV3blv.aMUKDSJhV 2119 bQ+z/G1W1TRx3iWi5CMHYb+1pJXPTJz/GuWr/b/+Efqwz2ZlwGcj4Dx.Igbx9vG0 2120 mftIIxM4TUX28KBbaLgJbalsiuOx3C2bEyaSPerdzqgvXFHGGAhg1FU8.DQiQEki 2121 nn66GPMtm1SNgitxFxWouFqpsax5MWn/i52TfEaF2PNThOuzKtilweJhk.g0gMIQ 2122 TXAgMBAAECggEANlrz8XNX/lxBELixK0H83o4aYKYqDKZfZkUN8hU33xpu.Y/0sc 2123 VbLbu46WzysoIfJFyUC+zFJnbMCCOPjGbI/4NWkEqc9TAlKz+wDo+hf5bf0.ypFr 2124 EmikHk8R3fkpnvKi69ldw0iYnqcFVhq7VtGrSmJcy6Hckwbk7EBoUZGL0wtp.xlO 2125 6XlhksAvn8+75qoWzsNhi7S/L0IVCVLbUaV3hodTHlH5M4daFbqyRWD7UiPKt.Q3 2126 hdw1rpyVZg8ZbBFp0Ej4f9GdRaq88SIKMKCDu3t9ibn/v1kEte+PxhuwyW+d0o.h 2127 kKSEW0yLKCzQm5tujsPq0UVzPBkLJACUnFAi+a4AQKBgQDu6VLH2eYoTjPPTyAv. 2128 vOJnNWP7oMzyJ4/eFqdE9m+2Ajm/0qaMY95ftZ+GpEKggvC6Z5DFevEmgH4Sg2+G 2129 .gFd93diyRPScVbNE8SmpXxLPU2UoykVmICuQZzLDNE18B3buxAm2GJ219NEnZOe 2130 c.jPMOV/IcG1aLzTqQssL3zo/0gQKBgQDB4Olpg3EBggtJ/+dlkLHUw8c7Pe3UyL 2131 kS.VxVsyQwioYt8xMeCWuPvPNFcOjcW53KN/YSpCVjpttKGsPtLibMlKYKgasEqg 2132 cvl.Vb5OFtA/jNAP3mdAgCzBn6IF1NhVQe2dclo5puZ0gO38HDWq7EtqSi9Q0JSM 2133 g3YC.QNcOORptVwKBgQCHrCafaYWDhA11/+g2U9x6Yd56ifF43rCbnV+2EQCVaqQ 2134 i49xC.w4AH+Bs0mdlgT5unL6MOEmgZxkRR/SP7TKzixHYHnpMOqLhaQV24Wk5TQH 2135 ek92D7.wu8aXRB9vBj4g0CuDNO6/jWpm/KenXXN+Fka3ySVg4zdbVmBzJJdqYckg 2136 QKBgFXS.zSBzGgwz1/F7AaDZK49m1wPnhyeBb0OqHwbX/LI71rZ1mWef+nSF9Juh 2137 /Y77B5/J.UPdO9vgGgS00nRk0LIRP2s5OU5IQgQTVLvf8a1UmbVgI+KX511Yi5yM 2138 ztEwRcjEX.VM9ejXeXN0I57pvqG/xCOK3Kl2eYLh4TO9/E8WjjAoGAA1mqUV4Hnf 2139 4yvF1rydMp.fpvoWekiiRE33iEbYZNATYhsl7uxwn760pqVifkq2DSrZeYm4+lw9 2140 jwWMtUoPzpg.CJYMoGl846nhiZrbbJ5b5twoLV6GRmkk/CfOxPXNzCtSoQA86HHq 2141 7rRdhXSau/bY.EXc91tnhLjFzZxdBgrd+f4k=.-----END PRIVATE KEY-----. 2142 --estServerExampleBoundary.Content-Type: application/pkcs7-mime. 2143 .-----BEGIN PKCS7-----.MIIDPAYJKoZIhvcNAQcCoIIDLTCCAykCAQExADALB 2144 gkqhkiG9w0BBwGgggMPMIID.CzCCAfOgAwIBAgIBBTANBgkqhkiG9w0BAQUFADAX 2145 MRUwEwYDVQQDEwxlc3RFeGFt.cGxlQ0EwHhcNMTIwNzA0MTgzOTM2WhcNMTMwNzA 2146 0MTgzOTM2WjAsMSowKAYDVQQD.EyFzZXJ2ZXJzaWRlIGtleSBnZW5lcmF0ZWQgcm 2147 VzcG9uc2UwggEiMA0GCSqGSIb3.DQEBAQUAA4IBDwAwggEKAoIBAQC0781l7tri0 2148 yiiMb9ZZYch8zeizXrjMPF/Rxoz.2C9IU2THCrhPGXGQMne/zivce0m8/BMkkUc+ 2149 DsSMtzxn4l+9tIsVDkAe4FyzN0hL.d/zawgj6kUoCi3mxZnb2rWaRYAmM5w41ImD 2150 V3blvaMUKDSJhVbQ+z/G1W1TRx3iW.i5CMHYb+1pJXPTJz/GuWr/b/+Efqwz2Zlw 2151 Gcj4DxIgbx9vG0mftIIxM4TUX28KBb.aLgJbalsiuOx3C2bEyaSPerdzqgvXFHGG 2152 Ahg1FU8DQiQEkinn66GPMtm1SNgitxF.xWouFqpsax5MWn/i52TfEaF2PNThOuzK 2153 tilweJhkg0gMIQTXAgMBAAGjTTBLMAkG.A1UdEwQCMAAwHQYDVR0OBBYEFLylcQN 2154 0D5xTfRdayv+0GDULR2+EMB8GA1UdIwQY.MBaAFIR/SsVuU7I5IC+5INpMScsubQ 2155 /zMA0GCSqGSIb3DQEBBQUAA4IBAQButIeM.DB9PkwlGGe7zqvUWVD8y99zowwV6A 2156 rAOXWX+JO0bihgMtZaUfvPCX/LhZVEKDAki.W5orjAEvIu10b6l38ZzX2oyJgkYy 2157 Mmbb14lzTsRyjiqFw9j1PXxwgZvhwcaCF4b7.eDUUBQIeZg3AnkQrEwnHR5oVIN5 2158 8qo0P7PSKC3Vl3H6DlQh3y7w87nN12923/wk0.v/bS3lv7lDX3HdmbQD1r2KPtBs 2159 JGF4jMdstT7FTx32ZFKObycbK7WJ4LHytNJDci.4iXf+B0S3D6Zbf1cXj80/W+jC 2160 GvU0+4SV3cgEXFE5VQvXd8x40W4h0dTSkQCDPOS.nPj4Dl/PsLqX3lDboQAxAA== 2161 .-----END PKCS7-----.--estServerExampleBoundary--.This is the ep 2162 ilogue. It is also to be ignored.. 2164 In text format this is: 2166 HTTP/1.1 200 OK 2167 Status: 200 OK 2168 Content-Type: multipart/mixed ; boundary=estServerExampleBoundary 2170 This is the preamble. It is to be ignored, though it 2171 is a handy place for estServer to include an explanatory note 2172 including contact or support information. 2173 --estServerExampleBoundary 2174 Content-Type=application/pkcs8 2176 -----BEGIN PRIVATE KEY----- 2177 MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC0781l7tri0yii 2178 Mb9ZZYch8zeizXrjMPF/Rxoz2C9IU2THCrhPGXGQMne/zivce0m8/BMkkUc+DsSM 2179 tzxn4l+9tIsVDkAe4FyzN0hLd/zawgj6kUoCi3mxZnb2rWaRYAmM5w41ImDV3blv 2180 aMUKDSJhVbQ+z/G1W1TRx3iWi5CMHYb+1pJXPTJz/GuWr/b/+Efqwz2ZlwGcj4Dx 2181 Igbx9vG0mftIIxM4TUX28KBbaLgJbalsiuOx3C2bEyaSPerdzqgvXFHGGAhg1FU8 2182 DQiQEkinn66GPMtm1SNgitxFxWouFqpsax5MWn/i52TfEaF2PNThOuzKtilweJhk 2183 g0gMIQTXAgMBAAECggEANlrz8XNX/lxBELixK0H83o4aYKYqDKZfZkUN8hU33xpu 2184 Y/0scVbLbu46WzysoIfJFyUC+zFJnbMCCOPjGbI/4NWkEqc9TAlKz+wDo+hf5bf0 2185 ypFrEmikHk8R3fkpnvKi69ldw0iYnqcFVhq7VtGrSmJcy6Hckwbk7EBoUZGL0wtp 2186 xlO6XlhksAvn8+75qoWzsNhi7S/L0IVCVLbUaV3hodTHlH5M4daFbqyRWD7UiPKt 2187 Q3hdw1rpyVZg8ZbBFp0Ej4f9GdRaq88SIKMKCDu3t9ibn/v1kEte+PxhuwyW+d0o 2188 hkKSEW0yLKCzQm5tujsPq0UVzPBkLJACUnFAi+a4AQKBgQDu6VLH2eYoTjPPTyAv 2189 vOJnNWP7oMzyJ4/eFqdE9m+2Ajm/0qaMY95ftZ+GpEKggvC6Z5DFevEmgH4Sg2+G 2190 gFd93diyRPScVbNE8SmpXxLPU2UoykVmICuQZzLDNE18B3buxAm2GJ219NEnZOec 2191 jPMOV/IcG1aLzTqQssL3zo/0gQKBgQDB4Olpg3EBggtJ/+dlkLHUw8c7Pe3UyLkS 2192 VxVsyQwioYt8xMeCWuPvPNFcOjcW53KN/YSpCVjpttKGsPtLibMlKYKgasEqgcvl 2193 Vb5OFtA/jNAP3mdAgCzBn6IF1NhVQe2dclo5puZ0gO38HDWq7EtqSi9Q0JSMg3YC 2194 QNcOORptVwKBgQCHrCafaYWDhA11/+g2U9x6Yd56ifF43rCbnV+2EQCVaqQi49xC 2195 w4AH+Bs0mdlgT5unL6MOEmgZxkRR/SP7TKzixHYHnpMOqLhaQV24Wk5TQHek92D7 2196 wu8aXRB9vBj4g0CuDNO6/jWpm/KenXXN+Fka3ySVg4zdbVmBzJJdqYckgQKBgFXS 2197 zSBzGgwz1/F7AaDZK49m1wPnhyeBb0OqHwbX/LI71rZ1mWef+nSF9Juh/Y77B5/J 2198 UPdO9vgGgS00nRk0LIRP2s5OU5IQgQTVLvf8a1UmbVgI+KX511Yi5yMztEwRcjEX 2199 VM9ejXeXN0I57pvqG/xCOK3Kl2eYLh4TO9/E8WjjAoGAA1mqUV4Hnf4yvF1rydMp 2200 fpvoWekiiRE33iEbYZNATYhsl7uxwn760pqVifkq2DSrZeYm4+lw9jwWMtUoPzpg 2201 CJYMoGl846nhiZrbbJ5b5twoLV6GRmkk/CfOxPXNzCtSoQA86HHq7rRdhXSau/bY 2202 EXc91tnhLjFzZxdBgrd+f4k= 2203 -----END PRIVATE KEY----- 2204 --estServerExampleBoundary 2205 Content-Type: application/pkcs7-mime 2207 -----BEGIN PKCS7----- 2208 MIIDPAYJKoZIhvcNAQcCoIIDLTCCAykCAQExADALBgkqhkiG9w0BBwGgggMPMIID 2209 CzCCAfOgAwIBAgIBBTANBgkqhkiG9w0BAQUFADAXMRUwEwYDVQQDEwxlc3RFeGFt 2210 cGxlQ0EwHhcNMTIwNzA0MTgzOTM2WhcNMTMwNzA0MTgzOTM2WjAsMSowKAYDVQQD 2211 EyFzZXJ2ZXJzaWRlIGtleSBnZW5lcmF0ZWQgcmVzcG9uc2UwggEiMA0GCSqGSIb3 2212 DQEBAQUAA4IBDwAwggEKAoIBAQC0781l7tri0yiiMb9ZZYch8zeizXrjMPF/Rxoz 2213 2C9IU2THCrhPGXGQMne/zivce0m8/BMkkUc+DsSMtzxn4l+9tIsVDkAe4FyzN0hL 2214 d/zawgj6kUoCi3mxZnb2rWaRYAmM5w41ImDV3blvaMUKDSJhVbQ+z/G1W1TRx3iW 2215 i5CMHYb+1pJXPTJz/GuWr/b/+Efqwz2ZlwGcj4DxIgbx9vG0mftIIxM4TUX28KBb 2216 aLgJbalsiuOx3C2bEyaSPerdzqgvXFHGGAhg1FU8DQiQEkinn66GPMtm1SNgitxF 2217 xWouFqpsax5MWn/i52TfEaF2PNThOuzKtilweJhkg0gMIQTXAgMBAAGjTTBLMAkG 2218 A1UdEwQCMAAwHQYDVR0OBBYEFLylcQN0D5xTfRdayv+0GDULR2+EMB8GA1UdIwQY 2219 MBaAFIR/SsVuU7I5IC+5INpMScsubQ/zMA0GCSqGSIb3DQEBBQUAA4IBAQButIeM 2220 DB9PkwlGGe7zqvUWVD8y99zowwV6ArAOXWX+JO0bihgMtZaUfvPCX/LhZVEKDAki 2221 W5orjAEvIu10b6l38ZzX2oyJgkYyMmbb14lzTsRyjiqFw9j1PXxwgZvhwcaCF4b7 2222 eDUUBQIeZg3AnkQrEwnHR5oVIN58qo0P7PSKC3Vl3H6DlQh3y7w87nN12923/wk0 2223 v/bS3lv7lDX3HdmbQD1r2KPtBsJGF4jMdstT7FTx32ZFKObycbK7WJ4LHytNJDci 2224 4iXf+B0S3D6Zbf1cXj80/W+jCGvU0+4SV3cgEXFE5VQvXd8x40W4h0dTSkQCDPOS 2225 nPj4Dl/PsLqX3lDboQAxAA== 2226 -----END PKCS7----- 2227 --estServerExampleBoundary-- 2228 This is the epilogue. It is also to be ignored. 2230 A.6. CSR Attributes 2232 The following is an example of a valid /CSRAttrs exchange. During 2233 this exchange the EST client authenticates itself using an existing 2234 certificate issued by the CA the EST server provides services for. 2236 The initial TLS handshake is identical to the enrollment example 2237 handshake. The HTTP GET request: 2238 GET /CSRAttrs HTTP/1.1 2239 User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenS 2240 SL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 2241 Host: 127.0.0.1:8085 2242 Accept: */* 2244 In response the server provides suggested attributes that are 2245 appropriate for the authenticated client: 2246 <= Recv header, 36 bytes (0x24) 2247 Content-Type: application/csrattrs 2248 == Info: no chunk, no close, no size. Assume close to signal end 2249 <= Recv header, 2 bytes (0x2) 2251 <= Recv data, 33 bytes (0x21) 2252 0000: MBQGBysGAQEBARYGCSqGSIb3DQEJBw==. 2254 Authors' Addresses 2256 Max Pritikin (editor) 2257 Cisco Systems, Inc. 2258 510 McCarthy Drive 2259 Milpitas, CA 95035 2260 USA 2262 Email: pritikin@cisco.com 2264 Peter E. Yee (editor) 2265 AKAYLA, Inc. 2266 7150 Moorland Drive 2267 Clarksville, MD 21029 2268 USA 2270 Email: peter@akayla.com 2272 Dan Harkins (editor) 2273 Aruba Networks 2274 1322 Crossman Avenue 2275 Sunnyvale, CA 94089-1113 2276 USA 2278 Email: dharkins@arubanetworks.com