idnits 2.17.1 draft-ietf-pkix-est-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (March 12, 2012) is 4428 days in the past. Is this intentional? 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: 'RFC5785' is mentioned on line 458, but not defined ** Obsolete undefined reference: RFC 5785 (Obsoleted by RFC 8615) == Missing Reference: 'RFC5958' is mentioned on line 999, but not defined == Missing Reference: 'BGPsec RPKI' is mentioned on line 1125, but not defined == Unused Reference: 'RFC2986' is defined on line 1153, but no explicit reference was found in the text == Unused Reference: 'RFC4210' is defined on line 1157, but no explicit reference was found in the text ** 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 2986 ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 5430 (Obsoleted by RFC 6460) ** Downref: Normative reference to an Informational RFC: RFC 5967 ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX M. Pritikin, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track P. Yee, Ed. 5 Expires: September 13, 2012 AKAYLA, Inc. 6 March 12, 2012 8 Enrollment over Secure Transport 9 draft-ietf-pkix-est-01 11 Abstract 13 This document profiles certificate enrollment for clients using 14 Certificate Management over CMS (CMC) messages over a secure 15 transport. This profile, called Enrollment over Secure Transport 16 (EST), describes a simple yet functional certificate management 17 protocol targeting simple Public Key Infrastructure clients that need 18 to acquire client certificate(s) and associated Certification 19 Authority (CA) certificate(s). 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 13, 2012. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 57 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Operational Scenario Overviews . . . . . . . . . . . . . . . . 7 59 4. Protocol Design and Layering . . . . . . . . . . . . . . . . . 9 60 4.1. Application Layer Design . . . . . . . . . . . . . . . . . 9 61 4.2. HTTP Layer Design . . . . . . . . . . . . . . . . . . . . 10 62 4.2.1. HTTP headers for control . . . . . . . . . . . . . . . 10 63 4.2.2. HTTP URIs for control . . . . . . . . . . . . . . . . 10 64 4.2.3. HTTP-Based Client Authentication . . . . . . . . . . . 12 65 4.2.4. Message types . . . . . . . . . . . . . . . . . . . . 13 66 4.3. TLS Layer Design . . . . . . . . . . . . . . . . . . . . . 14 67 4.3.1. TLS for transport security . . . . . . . . . . . . . . 14 68 4.3.1.1. TLS-Based Server Authentication . . . . . . . . . 14 69 4.3.1.2. TLS-Based Client Authentication . . . . . . . . . 16 70 4.4. Proof-of-Possession . . . . . . . . . . . . . . . . . . . 16 71 4.5. Linking Identity and POP information . . . . . . . . . . . 16 72 5. Protocol Exchange Details . . . . . . . . . . . . . . . . . . 17 73 5.1. Client Authorization . . . . . . . . . . . . . . . . . . . 18 74 5.2. Server Authorization . . . . . . . . . . . . . . . . . . . 18 75 5.3. Distribution of CA certificates . . . . . . . . . . . . . 19 76 5.3.1. Distribution of CA certificates response . . . . . . . 19 77 5.4. Simple Enrollment of Clients . . . . . . . . . . . . . . . 20 78 5.4.1. Simple Re-Enrollment of Clients . . . . . . . . . . . 20 79 5.4.2. Simple Enroll and Re-Enroll Response . . . . . . . . . 21 80 5.5. Full CMC . . . . . . . . . . . . . . . . . . . . . . . . . 22 81 5.5.1. Full CMC Request . . . . . . . . . . . . . . . . . . . 22 82 5.5.2. Full CMC Response . . . . . . . . . . . . . . . . . . 22 83 5.6. Server-side Key Generation . . . . . . . . . . . . . . . . 22 84 5.6.1. Server-side Key Generation Request . . . . . . . . . . 23 85 5.6.2. Server-side Key Generation Response . . . . . . . . . 23 86 6. Cryptographic Algorithms . . . . . . . . . . . . . . . . . . . 24 87 7. Contributors/Acknowledgements . . . . . . . . . . . . . . . . 24 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 91 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 92 10.2. Informative References . . . . . . . . . . . . . . . . . . 28 93 Appendix A. Server Discovery . . . . . . . . . . . . . . . . . . 28 94 Appendix B. External TLS concentrator . . . . . . . . . . . . . . 28 95 Appendix C. CGI Server implementation . . . . . . . . . . . . . . 29 96 Appendix D. Updating SCEP implementations . . . . . . . . . . . . 29 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 99 1. Introduction 101 This document specifies a protocol for certificate Enrollment over 102 Secure Transport (EST). EST is designed to be easily implemented by 103 clients and servers using common "off the shelf" PKI, HTTP, and TLS 104 components. An EST server providing certificate management functions 105 is operated by (or on behalf of) a CA or RA. The goal is to provide 106 a small set of functions for certificate enrollment that are simpler 107 to implement and use than full CMP or CMC. While less functional 108 than those protocols, EST satisfies basic needs by providing an 109 easily implemented means for both devices as well as user-operated 110 computers to request certificates. 112 The TLS [RFC4346] protocol combines with a limited set of features of 113 the Certificate Management over CMS (CMC) [RFC5272] to provide the 114 security for EST. In the most basic cases, CMC "simple" messages are 115 used for certificate requests and responses, but EST also allows the 116 optional use of "full" CMC messages as needed. EST adopts the CMP 117 model for CA certificate distribution, but does not incorporate its 118 syntax or protocol. An EST server supports several means of 119 authenticating a certificate requester, leveraging the layering of 120 the protocols that make up EST. 122 EST works by transporting CMC messages securely. These message can 123 be "simple" CMC messages but optionally, "full" CMC messages may also 124 be used. The messages are sent over an HTTPS transport in which HTTP 125 headers and content types are used in conjunction with TLS security. 126 TCP/IP sits under HTTPS; this document does not specify EST over DTLS 127 or UDP. Figure 1 shows how the layers build upon each other. 129 EST Layering: 131 Protocols: 132 +---------------------------------------------------+ 133 | | 134 | 4) EST messages for requests/responses | 135 | | 136 +---------------------------------------------------+ 137 | | 138 | 3) HTTP for message carriage and signaling | 139 | | 140 +---------------------------------------------------+ 141 | | 142 | 2) TLS for transport security | 143 | | 144 +---------------------------------------------------+ 145 | | 146 | 1) TCP/IP | 147 | | 148 +---------------------------------------------------+ 150 Figure 1 152 [[EDNOTE: Comments such as this one, included within double brackets 153 and initiated with an 'EDNOTE', are for editorial use and shall be 154 removed as the document is polished.]] 156 1.1. Requirements Language 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in [RFC2119]. 162 2. Requirements 164 [[EDNOTE: The following section is still included here for 165 succinctness. It will eventually be published independently as 166 draft-ietf-pkix-estr-00.]] 168 The following describes goals and technical requirements for initial 169 PKI certificate enrollment along with a rationale for each 170 requirement. 172 G1 "Completeness". Server and client implementations compliant with 173 this document MUST be able to interoperate without reference to 174 subsequent profiles or additional future specifications. 176 The goal of this enrollment protocol is to provide a simple and easy- 177 to-implement method for end-entities to request, obtain, and update a 178 certificate issued from a specified Certification Authority. The 179 following certificate management operations are required. Additional 180 operations NEED NOT be supported (via this protocol) although the 181 protocol design SHOULD be extensible: 183 M1 "Distribution of current CA certificates". Clients MUST be able 184 to obtain the current certificate for the CA under which the 185 client's certificate was issued. Certificates have a finite 186 lifetime and will need to be updated on a periodic basis. It must 187 be possible for the client to obtain the updated CA certificates. 189 M2 "Enrollment". A client MUST be able to use the protocol to submit 190 a certificate request and obtain a certificate. 192 M3 "Renew/Rekey". Certificates have a finite lifetime and will need 193 to be updated on a periodic basis. A client MUST be able to use 194 the protocol for certificate renewal or rekey operations. 196 M4 "Server-side Key Generation". In some infrastructures it may not 197 be appropriate for the client to generate its own keys. A client 198 MUST be able to use this protocol but allow the server to make all 199 key generation and distribution decisions. 201 End-Entity proof-of-identity authentication mechanisms: 203 A1 "Username/Password". It MUST be possible to identify a username 204 specified client as being in possession of an associated symmetric 205 key. This allows users currently in possession of a username and 206 password to obtain a certificate. 208 A2 "Password". It MUST be possible to identify a client without 209 reference to a "username". A common operational model is to 210 distribute a "one-time password" that is presented to a CA or RA 211 to authorize enrollment. 213 A3 "Existing Certificate". It MUST be possible to authenticate a 214 client by making use of an existing certificate associated with 215 the client. A certificate used for client identification need not 216 be issued under the same PKI as the certificate that is being 217 requested. This allows clients that are already in a PKI to use a 218 certificate from that PKI to obtain additional certificates. 219 Additionally this capability allows a client who has a certificate 220 issued by a 3rd party, such as a certificate issued by a device 221 manufacturer, to leverage that credential during initial 222 enrollment. 224 A4 "Username/password and Certificate". It MUST be possible to 225 authenticate a client by using a combination of a username and 226 password and an existing certificate. This is a combination of A1 227 and A3. This supports "two-factor authentication" where the 228 client proves possession of the private keys for an existing 229 certificate stored within a hardware device and knowledge of a 230 username/password. 232 A5 "Password and certificate". It MUST be possible to authenticate a 233 client by using a combination of a secret value that is not 234 associated with a "username" and an existing certificate. This is 235 a combination of A2 and A3. This requirement is similar to A4 236 except that the client is in possession of a "one-time password". 238 End-Entity proof-of-possession: 240 P1 Proof-of-possession of subject keys MUST be supported. As 241 discussed in Appendix C of [RFC4211], Proof-of-possession "means 242 that the CA is adequately convinced that the entity requesting a 243 certificate for the public key Y, has access to the corresponding 244 private key X". 246 Key algorithms: 248 K1 "Algorithm agility". The protocol MUST support algorithm agility. 249 It must be possible to employ different cryptographic algorithms 250 for securing the transport or for signing the certificates. The 251 protocol SHOULD demonstrate this agility by being shown to work 252 with existing RSA-based solutions as well as providing for other 253 algorithms such as Elliptic Curve cryptography. 255 Server Identity mechanism: 257 I1 "RA certificate". It MUST be possible for a client to verify 258 authorization of the EST server as a representative of the CA. 259 The protocol operations allow the client to send a username/ 260 password or (one-time) password to the EST server. These values 261 cannot be safely transmitted to an unauthorized server. 263 3. Operational Scenario Overviews 265 EST provides the following services: 1) acquisition of CA 266 certificates, 2) certificate enrollment, 3) certificate renewal, and 267 4) transport of "full" CMC messages. 269 1) Acquisition of CA certificates: 271 The client retrieves the current CA certificates from the EST 272 server. The client uses HTTPS to ensure the identity of the EST 273 server. If the client successfully authenticates the server the 274 certificates are accepted directly, otherwise a manual 275 authentication operation is permitted. 277 2) Certificate Enrollment 279 The client sends a certification request via HTTPS (HTTP over TLS) 280 to the EST server. The client uses TLS to ensure the identity of 281 the EST server, and the server uses TLS client authentication to 282 verify the identity of the client. TLS-protected HTTP client 283 authentication may also be employed by the EST server if TLS 284 authentication does not suffice to verify the identity of the 285 client. The certification request includes proof-of-possession 286 (of the client's private key), and a mechanism is defined that 287 allows the server to link the EST client's TLS identity to this 288 specific certification request. The server responds with the 289 newly issued certificate. 291 3) Certificate Renewal (re-enrollment) 293 This is highly similar to the initial enrollment. Because it is 294 explicitly a re-enrollment attempt the server verifies the client 295 identity using TLS client certificate authentication. Only 296 certificates that are suitable for TLS client authentication can 297 be re-enrolled using this operation because of the reliance on the 298 TLS authentication. For other types of certificates, use of the 299 full CMC operation is required. 301 4) Full CMC messages 303 Full CMC messages can be transported allowing access to 304 functionality not provided by the simple CMC message. When using 305 full CMC messages the HTTPS connection does not need to be 306 authenticated. "Full" CMC messages are as defined in Sections 3.2 307 and 4.2 of [RFC5272]. Support for full CMC message transport is 308 optional. 310 4. Protocol Design and Layering 312 The following provides an expansion of Figure 1 describing how the 313 layers are used. Each aspect is profiled in detail in the sections 314 below. 316 EST Layering: 318 Protocols and uses: 319 +---------------------------------------------------+ 320 | | 321 | 4) Message types: | 322 | - CMC "Simple PKI" messages | 323 | (including proof-of-possession) | 324 | - CA certificates retrieval | 325 | - "Full" CMC messages (optional) | 326 | | 327 +---------------------------------------------------+ 328 | | 329 | 3) HTTP: | 330 | - HTTP headers and URIs for control | 331 | - Content-Type headers specify message type | 332 | - Headers for control/error messages | 333 | - URIs for selecting operations | 334 | - Basic authentication in some cases | 335 | | 336 +---------------------------------------------------+ 337 | | 338 | 2) TLS for transport security | 339 | - Authentication for EST server and optionally | 340 | EST client | 341 | - Indirectly provides proof-of-identity for EST| 342 | - Communications integrity | 343 | - "Channel binding" to link proof-of-identity | 344 | with message based proof-of-possession. | 345 | (optional) | 346 | | 347 +---------------------------------------------------+ 349 Figure 2 351 4.1. Application Layer Design 353 An EST client application SHOULD have its own client certificate and 354 a copy of a CA certificate. The client certificate is used to 355 provide client authentication for EST and MAY be used in other 356 certificate consuming protocols as well. The client's copy of the CA 357 certificate is used to authenticate the EST server. 359 An EST client application MUST be capable of generating and parsing 360 simple CMC messages (see Section 5.4). Generating and parsing full 361 CMC messages is optional (see Section 5.5). The application MUST 362 also be able to request CA certificates from the EST server and parse 363 the returned "bag" of certificates (see Section 5.3). 365 4.2. HTTP Layer Design 367 HTTP is used to transport EST requests and responses. Specific URIs 368 are provisioned for handling each type of request as given in 369 Section 4.2.1. HTTP is also used for client authentication services 370 when TLS client authentication is not available, as detailed in 371 Section Section 4.2.3. HTTP message types are used to convey EST 372 requests and responses as specified in Figure 4. 374 4.2.1. HTTP headers for control 376 This document profiles the HTTP content-type header to indicate the 377 message type and to provide the protocol control messages. Support 378 for the HTTP username/password methods is profiled. 380 CMC does not provide explicit messages for renewal and rekey. This 381 profile clarifies the renewal and rekey behavior of both the client 382 and server. It does so by specifying the HTTP control mechanisms 383 required of the client and server without requiring a distinct 384 message type. 386 Various media types as indicated in the HTTP content-type header are 387 used to transport EST messages. Valid media times are specified in 388 Section 4.2.4. 390 4.2.2. HTTP URIs for control 392 This profile supports four operations indicated by specific URIs: 394 Operations and their corresponding URIs: 395 +------------------------+-----------------+ 396 | Operation |Operation Path | 397 +========================+=================+===================+ 398 | Distribution of CA | /CACerts | Section 5.3 | 399 | certificates | | | 400 +------------------------+-----------------+-------------------+ 401 | Enrollment of new | /simpleEnroll | Section 5.4 | 402 | clients | | | 403 +------------------------+-----------------+-------------------+ 404 | Re-Enrollment of | /simpleReEnroll | Section 5.4.1 | 405 | existing clients | | | 406 +------------------------+-----------------+-------------------+ 407 | Full CMC | /fullCMC | Section 5.5 | 408 +------------------------+-----------------+-------------------+ 409 | Server-side Key | /serverKeyGen | Section 5.6 | 410 | Generation | | | 411 +------------------------+-----------------+-------------------+ 413 Figure 3 415 In the common manner of HTTP based interactions each operation is 416 accessed by forming the URI as follows: 418 "GET" BASEPATH OPERATIONPATH 419 "POST" BASEPATH OPERATIONPATH 421 where: 423 o BASEPATH is a common path for all EST operations 425 o OPERATIONPATH specifies the specific operation. 427 When a URI is formed, the BASEPATH and OPERATIONPATH are combined to 428 form the abs_path [RFC2616]. The means by which clients acquire the 429 BASEPATH URI are outside the scope of this document. The following 430 are two example base URIs: 432 o With BASEPATH having the value of /arbitrary/base/path 434 o https://example.org/arbitrary/base/path 436 o https://example2.org:8080/arbitrary/base/path 438 The following examples are valid complete URIs under this 439 specification: 441 o With BASEPATH having the value /base/path 443 o https://example.org/base/path/CACerts 445 o https://example2.org:8080/base/path/simpleEnroll 447 o https://example3.org/base/path/fullCMC 449 The mechanisms by which the EST server interacts with an HTTPS server 450 to handle GET and POST operations at these URIs is outside the scope 451 of this document. The use of distinct URIs simplifies implementation 452 for servers that do not perform client authentication when 453 distributing "CACerts" responses. 455 An EST server MAY provide additional, non-EST services on other URIs. 457 [[EDNOTE: This does not use the mechanism specified in "Defining 458 Well-Known Uniform Resource Identifiers (URIs)" [RFC5785]. That 459 would be a possibility here for a base URL of 460 "https://example.org/.well-known/EST" but such would preclude the 461 flexibility associated with multiple base URLs being handled by the 462 same server unless some form of "?designator=value" is included.]] 464 4.2.3. HTTP-Based Client Authentication 466 While TLS client authentication is the preferred method for 467 authentication of EST requests, there are times when TLS client 468 authentication is not possible. In those cases, an EST server MAY 469 fall back to using HTTP-based client authentication, as specified 470 below. 472 Basic and Digest authentication MUST only be performed over TLS 473 [RFC4346]. As specified in CMC: Transport Protocols [RFC5273] the 474 server "MUST NOT assume client support for any type of HTTP 475 authentication such as cookies, Basic authentication, or Digest 476 authentication". Clients intended for deployments where password 477 authentication is advantageous SHOULD support the Basic and Digest 478 authentication mechanism. Servers MAY provide configuration 479 mechanisms for administrators to enable Basic [RFC2616] and Digest 480 [RFC2617] authentication methods. 482 Servers that support Basic and Digest authentication methods MAY 483 reject requests using the HTTP defined WWW-Authenticate response- 484 header (Section 14.47). At that point the client SHOULD repeat the 485 request, including the appropriate HTTP [RFC2617] Authorization 486 Request Header (Section 3.2.2). 488 Support for Basic authentication as specified in HTTP allows the 489 server access to the client's cleartext password. This provides 490 integration with legacy username/password databases but requires 491 exposing the plaintext password to the EST server. The client MUST 492 NOT respond to this request unless the client has authenticated the 493 EST server (as per Section 5.2). 495 Clients MAY set the username to the empty string ("") if they wish to 496 present a "one-time password" or "PIN" that is not associated with a 497 username. 499 4.2.4. Message types 501 This document uses existing media types for the messages as specified 502 by Internet X.509 Public Key Infrastructure Operational Protocols: 503 FTP and HTTP [RFC2585] and The application/pkcs10 Media Type 504 [RFC5967] and CMC [RFC5272]. To support distribution of multiple 505 application/pkix-cert's for the CA certificate chain the [RFC2046] 506 multipart/mixed media type is used. 508 The message type is specified in the HTTP Content-Type header. 510 For reference the messages and their corresponding MIME and media 511 types are: 513 +-------------------+--------------------------+-------------------+ 514 | Message type |Request type | Request section | 515 | |Response type | Response section | 516 +===================+==========================+===================+ 517 | CA certificate | N/A | Section 5.3 | 518 | request | multipart/mixed | Section 5.3.1 | 519 | | (application/pkix-cert's)| | 520 +-------------------+--------------------------+-------------------+ 521 | Cert enroll/renew | application/pkcs10 | Section 5.4/5.4.1 | 522 | | application/pkix-cert | Section 5.4.2 | 523 +-------------------+--------------------------+-------------------+ 524 | Full CMC | application/pkcs7-mime | Section 5.5.1 | 525 | | application/pkcs7-mime | Section 5.5.2 | 526 +-------------------+--------------------------+-------------------+ 527 | Server-side Key | application/pkcs10 | Section 5.6.1 | 528 | Generation | multipart/mixed | Section 5.6.2 | 529 | | (application/pkcs7-cert &| | 530 | | application/pkix-privkey)| | 531 +-------------------+--------------------------+-------------------+ 533 Figure 4 535 4.3. TLS Layer Design 537 TLS provides communications security for the layers above it. 538 Specifically, the integrity and authentication services it provides 539 are leveraged to provide proof-of-identity and to allow authorization 540 decisions to be made. 542 4.3.1. TLS for transport security 544 HTTPS MUST be used. TLS 'session resumption' SHOULD be supported. 546 HTTPS is defined in HTTP Over TLS [RFC2818] and is a definition of 547 how HTTP messages are carried over TLS. HTTPS is a commonly used 548 secure transport and can be easily layered on top of extremely simple 549 client or server code. In some environments HTTPS can be utilized 550 through an external process. Specifying HTTPS as the secure 551 transport for PKI enrollment messages introduces two potential 552 'layers' for communication of authorization and control messages 553 during the protocol exchange: TLS and HTTP. 555 CMC [RFC5272] section 3.1 notes that "the Simple PKI Request MUST NOT 556 be used if a proof-of-identity needs to be included". This precludes 557 use of these messages if inline authentication and/or authorization 558 is required, unless a secured transport that provides proof-of- 559 identity is also specified. Many simple clients engaged in 560 certificate enrollment operations will have a TLS client 561 implementation available for secure transport, so use of TLS is 562 specified herein. This document specifies a method for authorizing 563 client enrollment requests using existing certificates. Such 564 existing certificates may have been issued by the Certification 565 Authority (CA) (from which the client is requesting a certificate) or 566 they may have been issued under a distinct PKI (e.g., an IEEE 802.1AR 567 IDevID [IDevID] credential). Additionally this document specifies 568 username/password authentication methods beyond those included in CMC 569 [RFC5272]. Authentication and authorization mechanisms required for 570 certificate issuance (and renew/rekey) are provided by HTTP and HTTPS 571 mechanisms as described in this document. 573 Proof-of-possession is a distinct issue from proof-of-identity and is 574 addressed in Section 4.4. 576 This document also defines transport for the full CMC [RFC5272] 577 specification compliant with CMC Transport Protocols [RFC5273]. 579 4.3.1.1. TLS-Based Server Authentication 581 The client MUST validate the TLS server certificate presented during 582 the TLS 1.1 [RFC4346] (or above) exchange-defined Server Certificate 583 message or the client MUST independently validate the response 584 contents. Validation is performed as given in [RFC5280] and 585 [RFC6125]. The cipher suites are detailed in Section 6. 587 There are multiple methods of validation depending on the current 588 state of the client: 590 1. If the client has a store of trust anchors, which may be in the 591 form of certificates, for validating TLS connections the client 592 MAY validate the TLS server certificate using the standard HTTPS 593 logic of checking the server's identity as presented in the 594 server's Certificate message against the URI provisioned for the 595 EST server (see HTTP Over TLS [RFC2818], Section 3.1 "Server 596 Identity" and [RFC6125]). This method makes it possible for 597 clients with a store of trust anchors to securely obtain the CA 598 certificate by leveraging the HTTPS security model. The EST 599 server URI SHOULD be made available to the client in a secure 600 fashion so that the client only obtains EST functions from a 601 desired server. 603 2. If the client already has one or more trust anchors associated 604 with this EST server, the client MUST validate the EST server 605 certificate using these trust anchors. The EST server URI MAY be 606 made available to the client in an insecure fashion. The EST 607 server certificate MUST contain the id-kp-cmcRA [CMC RFC5272bis] 608 extended key usage extension. 610 3. If the client does not yet have a trust anchor associated with 611 this EST server then the client MAY provisionally accept the TLS 612 connection, but the HTTP content data MUST be accepted manually 613 as described in Section 5.3. HTTP authentication requests MUST 614 NOT be responded to since the server is unauthenticated (only the 615 content data is accepted manually). 617 Methods 1 and 2 are essentially validation as given in [RFC5280]. 618 Method 1 is as described in [RFC6125], Section 6.6.1 "Match Found". 619 Method 2 is described in [RFC6125] as "No Match Found, Pinned 620 Certificate". Method 3 is described in [RFC6125], Section 6.6.4 as 621 "Fallback" and describes the process of "pinning" the received 622 certificate. 624 If one of these validation methods succeeds the CA certificate(s) are 625 stored and "pinned" for future use. If none of these validation 626 methods succeeds the client MUST reject the EST server response and 627 SHOULD log and/or inform the end user. 629 4.3.1.2. TLS-Based Client Authentication 631 Clients SHOULD support [RFC4346] defined Certificate request (section 632 7.4.4). As required by [RFC4346], the client certificate needs to 633 indicate support for digital signatures. The client SHOULD support 634 this method in order to leverage /simpleReEnroll using client 635 authentication by existing certificate. 637 The certificate presented by the client MAY be from the same PKI as 638 the Server Certificate, from a completely different PKI. The 639 certificate supplied during authentication is used during client 640 authorization (Section 5.1). 642 4.4. Proof-of-Possession 644 As discussed in Appendix C of CRMF [RFC4211], Proof-of-possession 645 (POP) "means that the CA is adequately convinced that the entity 646 requesting a certificate for the public key Y, has access to the 647 corresponding private key X". 649 The signed enrollment request provides a "Signature"-based proof-of- 650 possession. The mechanism described in Section 4.5 strengthens this 651 by optionally including identity linking information within the data 652 covered by the enrollment request signature (thus ensuring that the 653 enrollment request was signed after the TLS tunnel was established). 655 4.5. Linking Identity and POP information 657 This specification provides a method of linking identity and proof- 658 of-possession by including information specific to the current 659 authenticated TLS session within the signed certification request. 660 This proves to the server that the authenticated TLS client has 661 possession of the private key associated with the certification 662 request and that the client was able to sign the certification 663 request after the TLS session was established. This is an 664 alternative to the [RFC5272] Section 6.3-defined "Linking Identity 665 and POP information" method available if full CMC messages are used. 667 The client generating the request SHOULD obtain the tls-unique value 668 as defined in Channel Bindings for TLS [RFC5929] from the TLS 669 subsystem. The tls-unique value is encoded as specified in Section 4 670 of Base64 [RFC4648] and the resulting string is placed in the 671 certification request challenge-password field. 673 The tls-unique specification includes a synchronization issue as 674 described in Channel Bindings for TLS [RFC5929] section 3.1. This 675 problem is avoided for EST implementations. The tls-unique value 676 used MUST be from the first TLS handshake. EST client and servers 677 must use their tls-unique implementation specific synchronization 678 methods to obtain this first tls-unique value. 680 Any TLS renegotiation MUST use "secure_renegotiation" [RFC5746] (thus 681 maintaining the binding). Mandating secure renegotiation secures 682 this method of avoiding the synchronization issues encountered when 683 using the most recent tls-unique value (which is defined as the the 684 value from the most recent TLS handshake). 686 The server SHOULD verify the tls-unique information. This ensures 687 that the authenticated TLS client is in possession of the private key 688 used to sign the certification request. 690 [[EDNOTE: A specific error code (TBD) is returned indicating this 691 additional linkage might be useful. This would be similar to the 692 "WWW-Authenticate response-header" control message. Alternatively 693 simply rejecting the request with an informative text message would 694 work in many use cases.]] 696 The tls-unique value is encoded into the certification request by the 697 client but back-end infrastructure elements that process the request 698 after the EST server might not have access to the initial TLS 699 session. Such infrastructure elements validate the source of the 700 certification request to determine if POP checks have already been 701 performed. For example if the EST client authentication results in 702 an authenticated client identity of an RA that is known to 703 independently verify the proof-of-possession then the back-end 704 infrastructure does not need to perform proof-of-possession checks a 705 second time. If the EST server forwards a request to a back-end 706 process it SHOULD communicate the authentication results. This 707 communication might use the CMC "RA POP Witness Control" in a CMC 708 Full PKI Request message or other mechanisms which are out-of-scope 709 of this document. 711 5. Protocol Exchange Details 713 Before processing a request, an EST server determines if the client 714 is authorized to receive the requested services. Likewise, the 715 client must make a determination if it will accept services from the 716 EST server. Those determinations are described in the next two 717 sections. Assuming that both sides of the exchange are authorized, 718 then the actual operations are as described in the sections 719 following. 721 5.1. Client Authorization 723 When the EST server receives a CMC Simple PKI Request or rekey/renew 724 message, the decision to issue a certificates is always a matter of 725 local policy. Thus the CA can use any data it wishes in making that 726 determination. The EST protocol exchange provides the EST server 727 access to the TLS client certificate in addition to any HTTP user 728 authentication credentials to help in that determination. The 729 communication channel between the TLS server implementation and the 730 EST software implementation is out-of-scope of this document. 732 If the client authentication is incomplete (for example if the client 733 certificate is self-signed or issued by an unknown PKI or if the 734 client offered an unknown username/password during HTTP 735 authentication) the server MAY extract the certificate request for 736 manual authorization by the administrator. 738 5.2. Server Authorization 740 The client MUST check the EST server authorization before accepting 741 the server's response. The presented certificate MUST be an end- 742 entity certificate such as a CMC Registration Authority (RA) 743 certificate. 745 There are multiple methods for checking authorization corresponding 746 to the method of server authentication used (see Section 4.3.1.1): 748 1. If the client authenticated the EST server using the client's TLS 749 trust anchors store, then the client MUST have obtained the EST 750 server's URI in a secure fashion. The client MUST check the URI 751 "against the server's identity as presented in the server's 752 Certificate message" (Section 3.1 "Server Identity" [RFC2818] and 753 [RFC6125]). The securely configured URI provides the 754 authorization statement and the server's authenticated identity 755 confirms it is the authorized server. 757 2. If the previous check fails or is not applicable, or if the EST 758 server's URI was made available to the client in an insecure 759 fashion, then the EST server certificate MUST contain the id-kp- 760 cmcRA [CMC RFC5272bis] extended key usage extension. The client 761 MUST further verify the server's authorization by checking that 762 the [RFC5280]-defined certificate policy extension sequence 763 contains the 'RA Authorization' policy OID. The RA Authorization 764 policy OID is defined as: id-cmc [[EDNOTE: TBD, perhaps 35]]. 765 The RA Authorization policy information MUST NOT contain any 766 optional qualifiers. 768 3. If fallback logic was invoked to accept the certificate manually, 769 then that authentication implies authorization of the EST server. 771 5.3. Distribution of CA certificates 773 Before engaging in enrollment operations, clients MUST request trust 774 anchor information (in the form of certificates) by sending an HTTPS 775 GET message to the EST base URI with the relative path extension 776 '/CACerts'. Clients SHOULD request an up-to-date response before 777 stored information has expired. 779 The EST server SHOULD NOT require client authentication or 780 authorization to reply to this request. 782 The client MUST authenticate the EST server as specified in 783 Section 4.3.1. If the authentication and authorization is not 784 successful then the client MAY extract the CA certificate and engage 785 the end-user to authorize the CA certificate using out-of-band pre- 786 configuration data such as a CA certificate "fingerprint" (e.g., a 787 SHA-1, SHA-256, SHA-512, or MD5 hash on the whole CA certificate). 788 In this case it is incumbent on the end user to properly verify the 789 fingerprint or to provide valid out-of-band data necessary to verify 790 the fingerprint. 792 Subsequent connections to the EST server SHOULD validate the TLS 793 server certificate using the stored CA certificates as described in 794 Section 4.3.1. 796 5.3.1. Distribution of CA certificates response 798 The EST server MUST respond to the client HTTPS GET message with CA 799 trust anchor information in the form of a certificate. Additionally 800 the server MUST include any "Root CA Key Update" CMP certificates. 802 The response format is the media type multipart/mixed. Within each 803 parallel part is an entity of media type application/pkix-cert. One 804 part MUST be the the current self-signed CA certificate. The EST 805 server MUST include any additional certificates the client would need 806 to build a chain to the root certificate. For example if the EST 807 server is configured to use a subordinate CA when signing new client 808 requests then the appropriate subordinate CA certificates must be 809 included in this response. 811 Additional parts MAY be included. The server SHOULD support 812 distribution of an updated root certificate, prior to the expiration 813 of the current root certificate, so that clients can leverage their 814 existing stored credential to obtain the update. If support for the 815 CMP root certificate update mechanism is desired, then there MUST be 816 the three additional CMP-defined Root CA Key Update certificates: 817 OldWithOld, OldWithNew, and NewWithOld. 819 The client can always find the current self-signed CA certificate by 820 examining the certificates received. The NewWithNew certificate is 821 self-signed and has the latest NotAfter date. 823 The NewWithNew certificate is the certificate that is extracted and 824 authorized using out-of-band information as described in Section 5.3. 825 When out-of-band validation occurs each of the other three 826 certificates MUST be validated using normal [RFC5280] certificate 827 path validation (using the NewWithNew certificate as the trust 828 anchor) before they can be used to build certificate paths during 829 peer certificate validation. 831 5.4. Simple Enrollment of Clients 833 At any time the client MAY request a certificate from the EST base 834 URI with the OPERATIONPATH "/simpleEnroll'. 836 When HTTPS POSTing to the 'SimpleEnroll' location the client MUST 837 include a CMC Simple PKI Request as specified in CMC Section 3.1 838 (i.e., a PKCS#10 Certification Request). 840 The content-type of "application/pkcs10" MUST be specified. The 841 format of the request is as specified in Section 6.4 of [RFC4945]. 843 The server MUST authenticate the client as specified in 844 Section 4.3.1. The server applies whatever authorization or policy 845 logic it chooses in determining if the certificate should be issued. 846 The client MAY request an additional certificate even when using an 847 existing certificate in the TLS client authentication. 849 The client MUST authenticate the EST server as specified in 850 Section 4.3.1.1. 852 5.4.1. Simple Re-Enrollment of Clients 854 At any time a client MAY request renew/rekey of its certificate from 855 the EST base URI with the OPERATIONPATH "/simpleReEnroll'. 857 The certificate request is the same format as for the "simpleEnroll" 858 path extension with the same content-type. 860 The EST server MUST handle enrollment requests submitted to the 861 "simpleReEnroll" URI as renewal or rekey request. (This is an 862 alternative to the /fullCMC method of depending on the method of 863 identifying a renewal or rekey request specified in Section 2 of 865 [RFC5272], that "renewal and rekey requests look the same as any 866 certification request, except that the identity proof is supplied by 867 existing certificates from a trusted CA".) The proof of client 868 identity is supplied by client authentication during the HTTPS 869 handshake. When attempting to renew or rekey the client SHOULD use 870 its existing certificate for TLS client authentication 871 (Section 4.3.1.2). 873 [[EDNOTE: [RFC6403] defines a method of recognizing a re-enroll based 874 on PKCS10 contents, see section 4.1. The method described herein is 875 explicit.]] 877 5.4.2. Simple Enroll and Re-Enroll Response 879 The server responds to a 'simpleEnroll' or 'simpleReEnroll' request 880 with the client's newly issued certificate or it provides an error 881 response. 883 If the enrollment is successful the server response MUST have an HTTP 884 200 response code with a content-type of "application/pkix-cert". 885 The response data is the certificate formatted as specified in 886 Section 6.1 of [RFC4945]. 888 When rejecting a request the server MUST specify either an HTTP 4xx/ 889 401 error, or an HTTP 5xx error. A CMC Simple PKI Response with an 890 HTTP content-type of "application/pkcs7-mime" MAY be included in the 891 response data for any error response. If the content-type is not set 892 the response data MUST be a plain text human-readable error message. 893 A client MAY elect not to parse a CMC error response in favor of a 894 generic error message. 896 If the server responds with an HTTP 202 this indicates that the 897 request has been accepted for processing but that a response is not 898 yet available. The server MUST include a Retry-After header as 899 defined for HTTP 503 responses and MAY include informative human- 900 readable content. The client MUST wait at least the specified 901 'retry-after' time before repeating the same request. The client 902 repeats the initial enrollment request after the appropriate 'retry- 903 after' interval has expired. The client SHOULD log or inform the end 904 user of this event. The server is responsible for maintaining all 905 state necessary to recognize and handle retry operations as the 906 client is stateless in this regard (it simply sends the same request 907 repeatedly until it receives a different response code). 909 All other return codes are handled as specified in HTTP. 911 5.5. Full CMC 913 At any time the client MAY request a certificate from the EST base 914 URI with the OPERATIONPATH "/fullCMC". 916 The client MUST authenticate the server as specified in Server 917 Authentication (Section 4.3.1.1). 919 The server SHOULD authenticate the client as specified in 920 Section 4.3.1. The server MAY depend on CMC client authentication 921 methods instead. 923 5.5.1. Full CMC Request 925 When HTTPS POSTing to the "fullCMC" location the client MUST include 926 a valid CMC message. The content-type MUST be set to "application/ 927 pkcs7-mime" as specified in [RFC5273]. 929 5.5.2. Full CMC Response 931 The server responds with the client's newly issued certificate or 932 provides an error response. 934 If the enrollment is successful the server response MUST have an HTTP 935 200 response code with a content-type of "application/pkcs7-mime" as 936 specified in [RFC5273]. The response data includes either the CMC 937 Simple PKI Response or the CMC Full PKI Response. 939 When rejecting a request the server MAY specify either an HTTP 4xx/ 940 401 error or an HTTP 5xx error. A CMC response with content-type of 941 "application/pkcs7-mime" MUST be included in the response data for 942 any error response. The client MUST parse the CMC response to 943 determine the current status. 945 All other return codes are handled as specified in Section 5.4.2 or 946 HTTP [RFC2616]. 948 5.6. Server-side Key Generation 950 [[EDNOTE: This section is provisional as a response to review 951 feedback. It is not fully integrated with the rest of this 952 document.]] 954 At any time the client MAY request a "private" keypair and associated 955 certificate from the EST base URI with the OPERATIONPATH 956 "/serverKeyGen". 958 The client MUST authenticate the server as specified in 959 Section 4.3.1.1. 961 The document [serverkeygen] describes a number of options for how the 962 client can authenticate itself and for how server generated key 963 material can be sent to the client. This document does not attempt 964 to provide all these options as they are available using the 965 "/fullCMC" method. Instead a direct method for clients to access a 966 server provided key and certificate is described. 968 The server MUST authenticate the client as specified in 969 Section 4.3.1. The server applies whatever authorization or policy 970 logic it chooses to determine if the "private" key and certificate 971 should be distributed. The server SHOULD use TLS-Based Client 972 Authentication for authorization purposes. The server SHOULD respond 973 to repeated requests from the same client with the same "private" key 974 and certificate. Clients that wish multiple "private" keys and 975 certificates using this method MUST use different client identities. 977 Proper random number and key generation and storage is a server 978 implementation responsibility. 980 5.6.1. Server-side Key Generation Request 982 The certificate request is HTTPS POSTed and is the same format as for 983 the "/simpleEnroll" path extension with the same content-type. 985 The public key values of the certificate request and the request 986 signature MUST be ignored by the server. The server response MUST 987 use the same SubjectPublicKeyInfo as requested or the request MUST be 988 denied. 990 5.6.2. Server-side Key Generation Response 992 If the request is successful the server response MUST have an HTTP 993 200 response code with a content-type of "multipart/mixed" consisting 994 of two parts. The first part is the "private" key data and the 995 second part is the certificate data. 997 The first submessage is an "application/pkix-privkey" consisting of 998 the PEM-encoded DER-encoded PrivatekeyInfo between the PEM headers as 999 described in [RFC5958]: 1001 -----BEGIN PRIVATE KEY----- 1002 MIIBhDCB7gIBADBFMQswCQYDVQQGEwJBVTETMBEGA1UECBMKU29tZS1TdGF0ZTEh 1003 Simplified example of Base64 encoding of DER-encoded PrivateKeyInfo 1004 ED8rf3UDF6HjloiV3jBnpetx4JjZH/BlmD9HMqofVEryb1e4iZgMUvuIgwEjQwpD 1005 8J4OhHvLh1o= 1006 -----END PRIVATE KEY----- 1007 The second submessage is an "application/pkix-cert" and exactly 1008 matches the certificate response to /simpleEnroll. 1010 When rejecting a request the server MUST specify either an HTTP 4xx/ 1011 401 error, or an HTTP 5xx error. If the content-type is not set the 1012 response data MUST be a plain text human-readable error message. 1014 [[EDNOTE: do we have an existing MIME type we can use for the 1015 privatekey?]] 1017 6. Cryptographic Algorithms 1019 This section details the specific cryptographic algorithms and cipher 1020 suite requirements. 1022 The client SHOULD offer the Suite B compliant cipher suites as 1023 indicated in [RFC5430], Section 4 "Suite B Compliance and 1024 Interoperability Requirements". For greatest interoperability the 1025 client SHOULD also offer TLS_RSA_WITH_AES_128_CBC_SHA. 1027 When the client accesses the "simpleReEnroll" method the TLS cipher 1028 suite in use MUST be appropriate for the existing certificate. The 1029 certificate type used determines the appropriate signatureAlgorithm 1030 for the PKCS#10 Certification Request. For example if a [RFC5430] 1031 cipher suite is used the signatureAlgorithm MAY be ecdsa-with-sha256 1032 for P-256 certification requests, or MAY be ecdsa-with-sha384 for 1033 P-384 certification requests. 1035 [[EDNOTE: This is in alignment with [RFC6403] section 4.1. To 1036 encourage algorithm agility, discussions of the MUST/SHOULD 1037 algorithms should be in a distinct document.]] 1039 7. Contributors/Acknowledgements 1041 The editors would like to thank Stephen Kent, Vinod Arjun, Jan 1042 Vilhuber, Sean Turner, and others for their feedback and prototypes 1043 of early drafts. 1045 8. IANA Considerations 1047 (This section is incomplete) 1049 The following aspects should be registered with IANA Considerations: 1051 The RA Authorization certificate policy extension OID as discussed in 1052 Section 5.2 requires registration with IANA. 1054 [[EDNOTE: The URLs specified in Section 1 probably do not need to be 1055 registered with IANA.]] 1057 9. Security Considerations 1059 (This section is incomplete) 1061 "Badges? We ain't got no badges. We don't need no badges! I don't 1062 have to show you any stinkin' badges!" -- The Treasure of the Sierra 1063 Madre. 1065 As described in CMC Section 6.7, "For keys that can be used as 1066 signature keys, signing the certification request with the private 1067 key serves as a POP on that key pair". The inclusion of tls-unique 1068 within the certification request links the the proof-of-possession to 1069 the TLS proof-of-identity. For support of keys that can not be used 1070 for signing the certification request the full CMC specification MUST 1071 be used. 1073 As given in Section 4.3.1.2 clients use an existing certificate for 1074 TLS client authentication. If a certificate with appropriate key 1075 usage is not available the client MAY generate one. If a self-signed 1076 certificate with appropriate key usage is used the server SHOULD 1077 require HTTP-based client authentication according to server policy 1078 as described in Section 4.3.1.2 and Section 5.1. The server MAY fall 1079 back on manual authorization by the server administrator. 1081 Clients authenticate EST servers by means of TLS authentication. If 1082 a client does not possess a root certificate suitable for validating 1083 an EST server certificate, it MAY rely upon other trusted root 1084 certificates it has (such as those found in its HTTPS store). The 1085 client then is able to retrieve additional root certificates as given 1086 in Section 5.3. Alternatively, a server certificate MAY be 1087 authenticated manually as specified in Section 4.3.1.1 #3. 1089 As noted in Section 4.3.1.1 servers use an existing certificate for 1090 TLS server authentication. When the server certificate is issued by 1091 a mutually trusted PKI hierarchy, validation proceeds as specified in 1092 Section 5.2. In this situation the client has validated the server 1093 as being a valid responder for the URI configured but can not 1094 directly verify that the responder is authorized as an RA within the 1095 to-be-enrolled PKI hierarchy. A client may thus be enticed to expose 1096 username/password or certificate enrollment requests to an 1097 unauthorized server (if the server presents a valid HTTPS certificate 1098 for an erroneous URL that the client has been tricked into using). 1100 Proof-of-identity and Proof-of-possession checks by the CA prevent an 1101 illegitimate RA from leveraging such misconfigured clients to act as 1102 a man-in-the-middle during client authenticated operations but it is 1103 possible for such illegitimate RAs to send the client doctored 1104 messages or erroneous CA certificate lists. If the illegitimate RA 1105 has successfully phished a username/password or PIN from the client 1106 it might try to use these values to enroll its own keypair with the 1107 real PKI hierarchy. EST servers identified with an externally issued 1108 server certificate SHOULD require HTTPS-based client authentication 1109 (Section 4.3.1.2). Similarly EST clients SHOULD use an existing 1110 client certificate to identify themselves and otherwise prevent 1111 "private data" (obviously including passwords but also including 1112 private identity information) from being exposed during the 1113 enrollment exchange a weak server authorization method is used. 1115 Section 4.2.3 allows clients to optionally authenticate using HTTP- 1116 based authentication in place of TLS-based authentication. HTTP- 1117 based authentication MUST NOT take place unless performed over a TLS- 1118 protected link. 1120 The server-side key generation method allows keys to be transported 1121 over the TLS connection to the client. The distribution of "private" 1122 key material is inherently risky and servers are NOT RECOMMENDED to 1123 support this operation by default. Clients are NOT RECOMMENDED to 1124 request this service unless there is a compelling operational benefit 1125 such as the use of [BGPsec RPKI]. 1127 10. References 1129 10.1. Normative References 1131 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1132 Extensions (MIME) Part Two: Media Types", RFC 2046, 1133 November 1996. 1135 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1136 Requirement Levels", BCP 14, RFC 2119, March 1997. 1138 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 1139 Infrastructure Operational Protocols: FTP and HTTP", 1140 RFC 2585, May 1999. 1142 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1143 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1144 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1146 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1147 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1148 Authentication: Basic and Digest Access Authentication", 1149 RFC 2617, June 1999. 1151 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1153 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1154 Request Syntax Specification Version 1.7", RFC 2986, 1155 November 2000. 1157 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1158 "Internet X.509 Public Key Infrastructure Certificate 1159 Management Protocol (CMP)", RFC 4210, September 2005. 1161 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1162 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1164 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1165 Encodings", RFC 4648, October 2006. 1167 [RFC4945] Korver, B., "The Internet IP Security PKI Profile of 1168 IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007. 1170 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 1171 (CMC)", RFC 5272, June 2008. 1173 [RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS 1174 (CMC): Transport Protocols", RFC 5273, June 2008. 1176 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1177 Housley, R., and W. Polk, "Internet X.509 Public Key 1178 Infrastructure Certificate and Certificate Revocation List 1179 (CRL) Profile", RFC 5280, May 2008. 1181 [RFC5430] Salter, M., Rescorla, E., and R. Housley, "Suite B Profile 1182 for Transport Layer Security (TLS)", RFC 5430, March 2009. 1184 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 1185 "Transport Layer Security (TLS) Renegotiation Indication 1186 Extension", RFC 5746, February 2010. 1188 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 1189 for TLS", RFC 5929, July 2010. 1191 [RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, 1192 August 2010. 1194 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1195 Verification of Domain-Based Application Service Identity 1196 within Internet Public Key Infrastructure Using X.509 1197 (PKIX) Certificates in the Context of Transport Layer 1198 Security (TLS)", RFC 6125, March 2011. 1200 10.2. Informative References 1202 [IDevID] IEEE Std, "IEEE 802.1AR Secure Device Identifier", 1203 December 2009, . 1206 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 1207 Certificate Request Message Format (CRMF)", RFC 4211, 1208 September 2005. 1210 [RFC6403] Zieglar, L., Turner, S., and M. Peck, "Suite B Profile of 1211 Certificate Management over CMS", RFC 6403, November 2011. 1213 Appendix A. Server Discovery 1215 (informative) 1217 (This section is incomplete) 1219 Clients MAY use DNS-SD or similar discovery algorithms to determine 1220 the EST base URL. In such cases it is expected that method 2 1221 (Section 4.3.1.1) be used during server authentication. 1223 Appendix B. External TLS concentrator 1225 (informative) 1227 In some deployments it may be beneficial to use a TLS concentrator to 1228 offload the TLS processing from the server. In such a deployment the 1229 TLS client authentication result must, in some way, be forwarded to 1230 the server. 1232 The TLS server SHOULD NOT reject the connection based on PKIX 1233 validation of the client certificate. The client certificate SHOULD 1234 be passed to the EST layer for verification and authorization. This 1235 allows support of external TLS concentrators, or an external web 1236 server, that might provide an independent TLS implementation. 1238 The TLS concentrator MUST validate the TLS Section 7.4.8 'Certificate 1239 Verify'. 1241 A TLS concentrator MUST insert the client certificate into the HTTP 1242 header. The TLS concentrator MUST first remove any existing client 1243 certificates, possibly inserted by a nefarious client, from the HTTP 1244 headers before forwarding the HTTP connection to the server. 1246 [TBD - need to better understand what would happen in the case of 1247 proxy's or multiple concentrators. Or specifically state that as out 1248 of scope.] 1250 [TBD - the HTTP header field names etc shall be specified here] 1252 The EST server MUST be specifically configured by the administrator 1253 to accept this mechanism. 1255 Appendix C. CGI Server implementation 1257 (informative) 1259 In some deployments it may be beneficial to use a HTTPS server that 1260 runs the EST server as a CGI application. In such a deployment the 1261 HTTPS server client authentication result must, in some way, be 1262 forwarded to the server. 1264 An HTTPS server MUST insert the client certificate into environment 1265 variables before calling a server CGI application. 1267 [TBD - describe the CGI environment variables here. Can likely 1268 follow the apache example]. 1270 An HTTP server MUST insert the client certificate into environment 1271 variables before calling a server CGI application. 1273 [TBD - describe the CGI environment variables here. Can likely 1274 follow the apache example]. 1276 Appendix D. Updating SCEP implementations 1278 (informative) 1280 SCEP has been used instead of a full implementation of CMC for the 1281 same simplicity reasons discussed in Section 1. Such implementations 1282 would benefit from being updated to this specification in the 1283 following ways: 1285 o Implementing a subset of CMC provides an enhancement path if the 1286 full CMC functionality is required. 1288 o The use of HTTPS as a transport is often perceived as more secure. 1289 Although the SCEP protocol specification includes mechanisms (and 1290 complexity) to address security issues avoiding a vendor 1291 requirement to educate systems administrators is beneficial. 1292 Implementors can benefit from the wide availability of existing 1293 HTTPS/TLS libraries. 1295 o SCEP servers can use their CA certificate to protect SCEP traffic 1296 in ways that are not appropriate. (See SCEP draft Section 8.2). 1297 This specification precludes those misuses. 1299 o The SCEP draft Appendix D renew and rekey functionalities imply a 1300 'flag moment' where the PKI infrastructure transitions from an 1301 (expired) CA certificate to a new CA certificate. This 1302 specification specifies the better mechanism defined in CMP. 1304 Updating an SCEP client implementation to support this protocol 1305 involves the following changes to the SCEP implementation. There is 1306 no server-side indication that SCEP clients should be so modified so 1307 this depends on a client-side configuration: 1309 o The SCEP client supports HTTPS server authentication and 1310 authorization as detailed Section 4.3.1.1. 1312 o The SCEP client supports HTTPS client authentication as detailed 1313 in Section 4.3.1.2. 1315 o When performing the "Get CA Cert" SCEP transaction the client 1316 supports the Section 5.3 described CMC Simple PKI Response (ref 1317 CMC 4.1, which is extremely similar to the SCEP "CA/RA Certificate 1318 Response Message Format" if not exactly the same). 1320 o When performing the certificate enrollment via SCEP PKCSReq the 1321 outgoing message is simplified to be only the inner PKCS10 (ref 1322 CMC section 3.2.1.2.1). 1324 o When handling the certificate enrollment response the response 1325 format is simplified to be only the SCEP inner 'messageData' 1326 containing the actual certificates in the degenerate PKCS7 form. 1327 (ref CMC 4.1) The only 'authenticatedAttributes' value of 1328 remaining importance is the 'pkiStatus' and this value is now 1329 found in the HTTP header as defined in Section 5.4.2. 1331 o Polling is simplified with clients repeatedly establishing the 1332 full HTTPS connection; no polling specific state information is 1333 encoded into the EST messages. 1335 o GetCert is deprecated. 1337 o GetCRL is deprecated. 1339 These simplifications to an existing SCEP implementation result in an 1340 SCEP client that is compliant with CMC when using the EST transport. 1342 Implementation note: The use of tls-unique-securerenegotiation 1343 precludes the use of SCEP 'challenge-password' within the pkcs10 for 1344 password/PIN assertion. Instead these values must be asserted with 1345 the Section 4.2.3 described mechanism. A side effect of this is that 1346 a client communicating with an EST server can not embed an SCEP 1347 'challenge-password' within the PKCS#10. An EST service running as 1348 an RA thus can not forward the PKCS#10 using SCEP to an SCEP server 1349 that expects the 'challenge-password' to be populated. 1351 Authors' Addresses 1353 Max Pritikin (editor) 1354 Cisco Systems, Inc. 1355 510 McCarthy Drive 1356 Milpitas, CA 95035 1357 USA 1359 Email: pritikin@cisco.com 1361 Peter E. Yee (editor) 1362 AKAYLA, Inc. 1363 7150 Moorland Drive 1364 Clarksville, MD 21029 1365 USA 1367 Email: peter@akayla.com