| PKIX | M. Pritikin, Ed. |
| Internet-Draft | Cisco Systems, Inc. |
| Intended status: Standards Track | P. Yee, Ed. |
| Expires: September 11, 2012 | AKAYLA, Inc. |
| March 12, 2012 |
Enrollment over Secure Transport
draft-ietf-pkix-est-01
This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple yet functional certificate management protocol targeting simple Public Key Infrastructure clients that need to acquire client certificate(s) and associated Certification Authority (CA) certificate(s).
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 11, 2012.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document specifies a protocol for certificate Enrollment over Secure Transport (EST). EST is designed to be easily implemented by clients and servers using common "off the shelf" PKI, HTTP, and TLS components. An EST server providing certificate management functions is operated by (or on behalf of) a CA or RA. The goal is to provide a small set of functions for certificate enrollment that are simpler to implement and use than full CMP or CMC. While less functional than those protocols, EST satisfies basic needs by providing an easily implemented means for both devices as well as user-operated computers to request certificates.
The TLS [RFC4346] protocol combines with a limited set of features of the Certificate Management over CMS (CMC) [RFC5272] to provide the security for EST. In the most basic cases, CMC "simple" messages are used for certificate requests and responses, but EST also allows the optional use of "full" CMC messages as needed. EST adopts the CMP model for CA certificate distribution, but does not incorporate its syntax or protocol. An EST server supports several means of authenticating a certificate requester, leveraging the layering of the protocols that make up EST.
EST Layering: Protocols: +---------------------------------------------------+ | | | 4) EST messages for requests/responses | | | +---------------------------------------------------+ | | | 3) HTTP for message carriage and signaling | | | +---------------------------------------------------+ | | | 2) TLS for transport security | | | +---------------------------------------------------+ | | | 1) TCP/IP | | | +---------------------------------------------------+
EST works by transporting CMC messages securely. These message can be "simple" CMC messages but optionally, "full" CMC messages may also be used. The messages are sent over an HTTPS transport in which HTTP headers and content types are used in conjunction with TLS security. TCP/IP sits under HTTPS; this document does not specify EST over DTLS or UDP. Figure 1 shows how the layers build upon each other.
[[EDNOTE: Comments such as this one, included within double brackets and initiated with an 'EDNOTE', are for editorial use and shall be removed as the document is polished.]]
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
[[EDNOTE: The following section is still included here for succinctness. It will eventually be published independently as draft-ietf-pkix-estr-00.]]
The following describes goals and technical requirements for initial PKI certificate enrollment along with a rationale for each requirement.
The goal of this enrollment protocol is to provide a simple and easy-to-implement method for end-entities to request, obtain, and update a certificate issued from a specified Certification Authority. The following certificate management operations are required. Additional operations NEED NOT be supported (via this protocol) although the protocol design SHOULD be extensible:
End-Entity proof-of-identity authentication mechanisms:
End-Entity proof-of-possession:
Key algorithms:
Server Identity mechanism:
EST provides the following services: 1) acquisition of CA certificates, 2) certificate enrollment, 3) certificate renewal, and 4) transport of "full" CMC messages.
The following provides an expansion of Figure 1 describing how the layers are used. Each aspect is profiled in detail in the sections below.
EST Layering: Protocols and uses: +---------------------------------------------------+ | | | 4) Message types: | | - CMC "Simple PKI" messages | | (including proof-of-possession) | | - CA certificates retrieval | | - "Full" CMC messages (optional) | | | +---------------------------------------------------+ | | | 3) HTTP: | | - HTTP headers and URIs for control | | - Content-Type headers specify message type | | - Headers for control/error messages | | - URIs for selecting operations | | - Basic authentication in some cases | | | +---------------------------------------------------+ | | | 2) TLS for transport security | | - Authentication for EST server and optionally | | EST client | | - Indirectly provides proof-of-identity for EST| | - Communications integrity | | - "Channel binding" to link proof-of-identity | | with message based proof-of-possession. | | (optional) | | | +---------------------------------------------------+
An EST client application SHOULD have its own client certificate and a copy of a CA certificate. The client certificate is used to provide client authentication for EST and MAY be used in other certificate consuming protocols as well. The client's copy of the CA certificate is used to authenticate the EST server.
An EST client application MUST be capable of generating and parsing simple CMC messages (see Section 5.4). Generating and parsing full CMC messages is optional (see Section 5.5). The application MUST also be able to request CA certificates from the EST server and parse the returned "bag" of certificates (see Section 5.3).
HTTP is used to transport EST requests and responses. Specific URIs are provisioned for handling each type of request as given in Section 4.2.1. HTTP is also used for client authentication services when TLS client authentication is not available, as detailed in Section Section 4.2.3. HTTP message types are used to convey EST requests and responses as specified in Figure 5.
This document profiles the HTTP content-type header to indicate the message type and to provide the protocol control messages. Support for the HTTP username/password methods is profiled.
CMC [RFC5272] does not provide explicit messages for renewal and rekey. This profile clarifies the renewal and rekey behavior of both the client and server. It does so by specifying the HTTP control mechanisms required of the client and server without requiring a distinct message type.
Various media types as indicated in the HTTP content-type header are used to transport EST messages. Valid media times are specified in Section 4.2.4.
This profile supports four operations indicated by specific URIs:
Operations and their corresponding URIs: +------------------------+-----------------+ | Operation |Operation Path | +========================+=================+===================+ | Distribution of CA | /CACerts | Section 5.3 | | certificates | | | +------------------------+-----------------+-------------------+ | Enrollment of new | /simpleEnroll | Section 5.4 | | clients | | | +------------------------+-----------------+-------------------+ | Re-Enrollment of | /simpleReEnroll | Section 5.4.1 | | existing clients | | | +------------------------+-----------------+-------------------+ | Full CMC | /fullCMC | Section 5.5 | +------------------------+-----------------+-------------------+ | Server-side Key | /serverKeyGen | Section 5.6 | | Generation | | | +------------------------+-----------------+-------------------+
In the common manner of HTTP based interactions each operation is accessed by forming the URI as follows:
"GET" BASEPATH OPERATIONPATH "POST" BASEPATH OPERATIONPATH
where:
When a URI is formed, the BASEPATH and OPERATIONPATH are combined to form the abs_path [RFC2616]. The means by which clients acquire the BASEPATH URI are outside the scope of this document. The following are two example base URIs:
The following examples are valid complete URIs under this specification:
The mechanisms by which the EST server interacts with an HTTPS server to handle GET and POST operations at these URIs is outside the scope of this document. The use of distinct URIs simplifies implementation for servers that do not perform client authentication when distributing "CACerts" responses.
An EST server MAY provide additional, non-EST services on other URIs.
[[EDNOTE: This does not use the mechanism specified in "Defining Well-Known Uniform Resource Identifiers (URIs)" [RFC5785]. That would be a possibility here for a base URL of "https://example.org/.well-known/EST" but such would preclude the flexibility associated with multiple base URLs being handled by the same server unless some form of "?designator=value" is included.]]
While TLS client authentication is the preferred method for authentication of EST requests, there are times when TLS client authentication is not possible. In those cases, an EST server MAY fall back to using HTTP-based client authentication, as specified below.
Basic and Digest authentication MUST only be performed over TLS [RFC4346]. As specified in CMC: Transport Protocols [RFC5273] the server "MUST NOT assume client support for any type of HTTP authentication such as cookies, Basic authentication, or Digest authentication". Clients intended for deployments where password authentication is advantageous SHOULD support the Basic and Digest authentication mechanism. Servers MAY provide configuration mechanisms for administrators to enable Basic [RFC2616] and Digest [RFC2617] authentication methods.
Servers that support Basic and Digest authentication methods MAY reject requests using the HTTP [RFC2616] defined WWW-Authenticate response-header (Section 14.47). At that point the client SHOULD repeat the request, including the appropriate HTTP [RFC2617] Authorization Request Header (Section 3.2.2).
Support for Basic authentication as specified in HTTP [RFC2617] allows the server access to the client's cleartext password. This provides integration with legacy username/password databases but requires exposing the plaintext password to the EST server. The client MUST NOT respond to this request unless the client has authenticated the EST server (as per Section 5.2).
Clients MAY set the username to the empty string ("") if they wish to present a "one-time password" or "PIN" that is not associated with a username.
This document uses existing media types for the messages as specified by Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP [RFC2585] and The application/pkcs10 Media Type [RFC5967] and CMC [RFC5272]. To support distribution of multiple application/pkix-cert's for the CA certificate chain the [RFC2046] multipart/mixed media type is used.
The message type is specified in the HTTP Content-Type header.
For reference the messages and their corresponding MIME and media types are:
+-------------------+--------------------------+-------------------+ | Message type |Request type | Request section | | |Response type | Response section | +===================+==========================+===================+ | CA certificate | N/A | Section 5.3 | | request | multipart/mixed | Section 5.3.1 | | | (application/pkix-cert's)| | +-------------------+--------------------------+-------------------+ | Cert enroll/renew | application/pkcs10 | Section 5.4/5.4.1 | | | application/pkix-cert | Section 5.4.2 | +-------------------+--------------------------+-------------------+ | Full CMC | application/pkcs7-mime | Section 5.5.1 | | | application/pkcs7-mime | Section 5.5.2 | +-------------------+--------------------------+-------------------+ | Server-side Key | application/pkcs10 | Section 5.6.1 | | Generation | multipart/mixed | Section 5.6.2 | | | (application/pkcs7-cert &| | | | application/pkix-privkey)| | +-------------------+--------------------------+-------------------+
TLS provides communications security for the layers above it. Specifically, the integrity and authentication services it provides are leveraged to provide proof-of-identity and to allow authorization decisions to be made.
HTTPS MUST be used. TLS 'session resumption' SHOULD be supported.
HTTPS is defined in HTTP Over TLS [RFC2818] and is a definition of how HTTP messages are carried over TLS. HTTPS is a commonly used secure transport and can be easily layered on top of extremely simple client or server code. In some environments HTTPS can be utilized through an external process. Specifying HTTPS as the secure transport for PKI enrollment messages introduces two potential 'layers' for communication of authorization and control messages during the protocol exchange: TLS and HTTP.
CMC [RFC5272] section 3.1 notes that "the Simple PKI Request MUST NOT be used if a proof-of-identity needs to be included". This precludes use of these messages if inline authentication and/or authorization is required, unless a secured transport that provides proof-of-identity is also specified. Many simple clients engaged in certificate enrollment operations will have a TLS client implementation available for secure transport, so use of TLS is specified herein. This document specifies a method for authorizing client enrollment requests using existing certificates. Such existing certificates may have been issued by the Certification Authority (CA) (from which the client is requesting a certificate) or they may have been issued under a distinct PKI (e.g., an IEEE 802.1AR IDevID [IDevID] credential). Additionally this document specifies username/password authentication methods beyond those included in CMC [RFC5272]. Authentication and authorization mechanisms required for certificate issuance (and renew/rekey) are provided by HTTP and HTTPS mechanisms as described in this document.
Proof-of-possession is a distinct issue from proof-of-identity and is addressed in Section 4.4.
This document also defines transport for the full CMC [RFC5272] specification compliant with CMC Transport Protocols [RFC5273].
The client MUST validate the TLS server certificate presented during the TLS 1.1 [RFC4346] (or above) exchange-defined Server Certificate message or the client MUST independently validate the response contents. Validation is performed as given in [RFC5280] and [RFC6125]. The cipher suites are detailed in Section 6.
There are multiple methods of validation depending on the current state of the client:
Methods 1 and 2 are essentially validation as given in [RFC5280]. Method 1 is as described in [RFC6125], Section 6.6.1 "Match Found". Method 2 is described in [RFC6125] as "No Match Found, Pinned Certificate". Method 3 is described in [RFC6125], Section 6.6.4 as "Fallback" and describes the process of "pinning" the received certificate.
If one of these validation methods succeeds the CA certificate(s) are stored and "pinned" for future use. If none of these validation methods succeeds the client MUST reject the EST server response and SHOULD log and/or inform the end user.
Clients SHOULD support [RFC4346] defined Certificate request (section 7.4.4). As required by [RFC4346], the client certificate needs to indicate support for digital signatures. The client SHOULD support this method in order to leverage /simpleReEnroll using client authentication by existing certificate.
The certificate presented by the client MAY be from the same PKI as the Server Certificate, from a completely different PKI. The certificate supplied during authentication is used during client authorization [ClientAuthorization].
As discussed in Appendix C of CRMF [RFC4211], Proof-of-possession (POP) "means that the CA is adequately convinced that the entity requesting a certificate for the public key Y, has access to the corresponding private key X".
The signed enrollment request provides a "Signature"-based proof-of-possession. The mechanism described in Section 4.5 strengthens this by optionally including identity linking information within the data covered by the enrollment request signature (thus ensuring that the enrollment request was signed after the TLS tunnel was established).
This specification provides a method of linking identity and proof-of-possession by including information specific to the current authenticated TLS session within the signed certification request. This proves to the server that the authenticated TLS client has possession of the private key associated with the certification request and that the client was able to sign the certification request after the TLS session was established. This is an alternative to the [RFC5272] Section 6.3-defined "Linking Identity and POP information" method available if full CMC messages are used.
The client generating the request SHOULD obtain the tls-unique value as defined in Channel Bindings for TLS [RFC5929] from the TLS subsystem. The tls-unique value is encoded as specified in Section 4 of Base64 [RFC4648] and the resulting string is placed in the certification request challenge-password field.
The tls-unique specification includes a synchronization issue as described in Channel Bindings for TLS [RFC5929] section 3.1. This problem is avoided for EST implementations. The tls-unique value used MUST be from the first TLS handshake. EST client and servers must use their tls-unique implementation specific synchronization methods to obtain this first tls-unique value.
Any TLS renegotiation MUST use "secure_renegotiation" [RFC5746] (thus maintaining the binding). Mandating secure renegotiation secures this method of avoiding the synchronization issues encountered when using the most recent tls-unique value (which is defined as the the value from the most recent TLS handshake).
The server SHOULD verify the tls-unique information. This ensures that the authenticated TLS client is in possession of the private key used to sign the certification request.
[[EDNOTE: A specific error code (TBD) is returned indicating this additional linkage might be useful. This would be similar to the "WWW-Authenticate response-header" control message. Alternatively simply rejecting the request with an informative text message would work in many use cases.]]
The tls-unique value is encoded into the certification request by the client but back-end infrastructure elements that process the request after the EST server might not have access to the initial TLS session. Such infrastructure elements validate the source of the certification request to determine if POP checks have already been performed. For example if the EST client authentication results in an authenticated client identity of an RA that is known to independently verify the proof-of-possession then the back-end infrastructure does not need to perform proof-of-possession checks a second time. If the EST server forwards a request to a back-end process it SHOULD communicate the authentication results. This communication might use the CMC [RFC5272] "RA POP Witness Control" in a CMC Full PKI Request message or other mechanisms which are out-of-scope of this document.
Before processing a request, an EST server determines if the client is authorized to receive the requested services. Likewise, the client must make a determination if it will accept services from the EST server. Those determinations are described in the next two sections. Assuming that both sides of the exchange are authorized, then the actual operations are as described in the sections following.
When the EST server receives a CMC Simple PKI Request or rekey/renew message, the decision to issue a certificates is always a matter of local policy. Thus the CA can use any data it wishes in making that determination. The EST protocol exchange provides the EST server access to the TLS client certificate in addition to any HTTP user authentication credentials to help in that determination. The communication channel between the TLS server implementation and the EST software implementation is out-of-scope of this document.
If the client authentication is incomplete (for example if the client certificate is self-signed or issued by an unknown PKI or if the client offered an unknown username/password during HTTP authentication) the server MAY extract the certificate request for manual authorization by the administrator.
The client MUST check the EST server authorization before accepting the server's response. The presented certificate MUST be an end-entity certificate such as a CMC Registration Authority (RA) certificate.
There are multiple methods for checking authorization corresponding to the method of server authentication used (see Section 4.3.1.1):
Before engaging in enrollment operations, clients MUST request trust anchor information (in the form of certificates) by sending an HTTPS GET message to the EST base URI with the relative path extension '/CACerts'. Clients SHOULD request an up-to-date response before stored information has expired.
The EST server SHOULD NOT require client authentication or authorization to reply to this request.
The client MUST authenticate the EST server as specified in Section 4.3.1. If the authentication and authorization is not successful then the client MAY extract the CA certificate and engage the end-user to authorize the CA certificate using out-of-band pre-configuration data such as a CA certificate "fingerprint" (e.g., a SHA-1, SHA-256, SHA-512, or MD5 hash on the whole CA certificate). In this case it is incumbent on the end user to properly verify the fingerprint or to provide valid out-of-band data necessary to verify the fingerprint.
Subsequent connections to the EST server SHOULD validate the TLS server certificate using the stored CA certificates as described in Section 4.3.1.
The EST server MUST respond to the client HTTPS GET message with CA trust anchor information in the form of a certificate. Additionally the server MUST include any "Root CA Key Update" CMP [RFC4210] certificates.
The response format is the media type multipart/mixed. Within each parallel part is an entity of media type application/pkix-cert. One part MUST be the the current self-signed CA certificate. The EST server MUST include any additional certificates the client would need to build a chain to the root certificate. For example if the EST server is configured to use a subordinate CA when signing new client requests then the appropriate subordinate CA certificates must be included in this response.
Additional parts MAY be included. The server SHOULD support distribution of an updated root certificate, prior to the expiration of the current root certificate, so that clients can leverage their existing stored credential to obtain the update. If support for the CMP root certificate update mechanism is desired, then there MUST be the three additional CMP [RFC4210]-defined Root CA Key Update certificates: OldWithOld, OldWithNew, and NewWithOld.
The client can always find the current self-signed CA certificate by examining the certificates received. The NewWithNew certificate is self-signed and has the latest NotAfter date.
The NewWithNew certificate is the certificate that is extracted and authorized using out-of-band information as described in Section 5.3. When out-of-band validation occurs each of the other three certificates MUST be validated using normal [RFC5280] certificate path validation (using the NewWithNew certificate as the trust anchor) before they can be used to build certificate paths during peer certificate validation.
At any time the client MAY request a certificate from the EST base URI with the OPERATIONPATH "/simpleEnroll'.
When HTTPS POSTing to the 'SimpleEnroll' location the client MUST include a CMC Simple PKI Request as specified in CMC [RFC5272] Section 3.1 (i.e., a PKCS#10 Certification Request [RFC2986]).
The content-type of "application/pkcs10" MUST be specified. The format of the request is as specified in Section 6.4 of [RFC4945].
The server MUST authenticate the client as specified in Section 4.3.1. The server applies whatever authorization or policy logic it chooses in determining if the certificate should be issued. The client MAY request an additional certificate even when using an existing certificate in the TLS client authentication.
The client MUST authenticate the EST server as specified in Section 4.3.1.1.
At any time a client MAY request renew/rekey of its certificate from the EST base URI with the OPERATIONPATH "/simpleReEnroll'.
The certificate request is the same format as for the "simpleEnroll" path extension with the same content-type.
The EST server MUST handle enrollment requests submitted to the "simpleReEnroll" URI as renewal or rekey request. (This is an alternative to the /fullCMC method of depending on the method of identifying a renewal or rekey request specified in Section 2 of [RFC5272], that "renewal and rekey requests look the same as any certification request, except that the identity proof is supplied by existing certificates from a trusted CA".) The proof of client identity is supplied by client authentication during the HTTPS handshake. When attempting to renew or rekey the client SHOULD use its existing certificate for TLS client authentication (Section 4.3.1.2).
[[EDNOTE: [RFC6403] defines a method of recognizing a re-enroll based on PKCS10 contents, see section 4.1. The method described herein is explicit.]]
The server responds to a 'simpleEnroll' or 'simpleReEnroll' request with the client's newly issued certificate or it provides an error response.
If the enrollment is successful the server response MUST have an HTTP 200 response code with a content-type of "application/pkix-cert". The response data is the certificate formatted as specified in Section 6.1 of [RFC4945].
When rejecting a request the server MUST specify either an HTTP [RFC2616] 4xx/401 error, or an HTTP 5xx error. A CMC Simple PKI Response with an HTTP content-type of "application/pkcs7-mime" MAY be included in the response data for any error response. If the content-type is not set the response data MUST be a plain text human-readable error message. A client MAY elect not to parse a CMC error response in favor of a generic error message.
If the server responds with an HTTP [RFC2616] 202 this indicates that the request has been accepted for processing but that a response is not yet available. The server MUST include a Retry-After header as defined for HTTP 503 responses and MAY include informative human-readable content. The client MUST wait at least the specified 'retry-after' time before repeating the same request. The client repeats the initial enrollment request after the appropriate 'retry-after' interval has expired. The client SHOULD log or inform the end user of this event. The server is responsible for maintaining all state necessary to recognize and handle retry operations as the client is stateless in this regard (it simply sends the same request repeatedly until it receives a different response code).
All other return codes are handled as specified in HTTP [RFC2616].
At any time the client MAY request a certificate from the EST base URI with the OPERATIONPATH "/fullCMC".
The client MUST authenticate the server as specified in Server Authentication [TLSserverAuthC].
The server SHOULD authenticate the client as specified in Section 4.3.1. The server MAY depend on CMC client authentication methods instead.
When HTTPS POSTing to the "fullCMC" location the client MUST include a valid CMC message. The content-type MUST be set to "application/pkcs7-mime" as specified in [RFC5273].
The server responds with the client's newly issued certificate or provides an error response.
If the enrollment is successful the server response MUST have an HTTP 200 response code with a content-type of "application/pkcs7-mime" as specified in [RFC5273]. The response data includes either the CMC Simple PKI Response or the CMC Full PKI Response.
When rejecting a request the server MAY specify either an HTTP 4xx/401 error or an HTTP 5xx error. A CMC response with content-type of "application/pkcs7-mime" MUST be included in the response data for any error response. The client MUST parse the CMC response to determine the current status.
All other return codes are handled as specified in Section 5.4.2 or HTTP [RFC2616].
[[EDNOTE: This section is provisional as a response to review feedback. It is not fully integrated with the rest of this document.]]
At any time the client MAY request a "private" keypair and associated certificate from the EST base URI with the OPERATIONPATH "/serverKeyGen".
The client MUST authenticate the server as specified in Section 4.3.1.1.
The document [serverkeygen] describes a number of options for how the client can authenticate itself and for how server generated key material can be sent to the client. This document does not attempt to provide all these options as they are available using the "/fullCMC" method. Instead a direct method for clients to access a server provided key and certificate is described.
The server MUST authenticate the client as specified in Section 4.3.1. The server applies whatever authorization or policy logic it chooses to determine if the "private" key and certificate should be distributed. The server SHOULD use TLS-Based Client Authentication for authorization purposes. The server SHOULD respond to repeated requests from the same client with the same "private" key and certificate. Clients that wish multiple "private" keys and certificates using this method MUST use different client identities.
Proper random number and key generation and storage is a server implementation responsibility.
The certificate request is HTTPS POSTed and is the same format as for the "/simpleEnroll" path extension with the same content-type.
The public key values of the certificate request and the request signature MUST be ignored by the server. The server response MUST use the same SubjectPublicKeyInfo as requested or the request MUST be denied.
If the request is successful the server response MUST have an HTTP 200 response code with a content-type of "multipart/mixed" consisting of two parts. The first part is the "private" key data and the second part is the certificate data.
The first submessage is an "application/pkix-privkey" consisting of the PEM-encoded DER-encoded PrivatekeyInfo between the PEM headers as described in [RFC5958]:
-----BEGIN PRIVATE KEY----- MIIBhDCB7gIBADBFMQswCQYDVQQGEwJBVTETMBEGA1UECBMKU29tZS1TdGF0ZTEh Simplified example of Base64 encoding of DER-encoded PrivateKeyInfo ED8rf3UDF6HjloiV3jBnpetx4JjZH/BlmD9HMqofVEryb1e4iZgMUvuIgwEjQwpD 8J4OhHvLh1o= -----END PRIVATE KEY-----
The second submessage is an "application/pkix-cert" and exactly matches the certificate response to /simpleEnroll.
When rejecting a request the server MUST specify either an HTTP 4xx/401 error, or an HTTP 5xx error. If the content-type is not set the response data MUST be a plain text human-readable error message.
[[EDNOTE: do we have an existing MIME type we can use for the privatekey?]]
This section details the specific cryptographic algorithms and cipher suite requirements.
The client SHOULD offer the Suite B compliant cipher suites as indicated in [RFC5430], Section 4 "Suite B Compliance and Interoperability Requirements". For greatest interoperability the client SHOULD also offer TLS_RSA_WITH_AES_128_CBC_SHA.
When the client accesses the "simpleReEnroll" method the TLS cipher suite in use MUST be appropriate for the existing certificate. The certificate type used determines the appropriate signatureAlgorithm for the PKCS#10 Certification Request [RFC2986]. For example if a [RFC5430] cipher suite is used the signatureAlgorithm MAY be ecdsa-with-sha256 for P-256 certification requests, or MAY be ecdsa-with-sha384 for P-384 certification requests.
[[EDNOTE: This is in alignment with [RFC6403] section 4.1. To encourage algorithm agility, discussions of the MUST/SHOULD algorithms should be in a distinct document.]]
The editors would like to thank Stephen Kent, Vinod Arjun, Jan Vilhuber, Sean Turner, and others for their feedback and prototypes of early drafts.
(This section is incomplete)
The following aspects should be registered with IANA Considerations:
The RA Authorization certificate policy extension OID as discussed in Section 5.2 requires registration with IANA.
[[EDNOTE: The URLs specified in Section 1 probably do not need to be registered with IANA.]]
(This section is incomplete)
"Badges? We ain't got no badges. We don't need no badges! I don't have to show you any stinkin' badges!" -- The Treasure of the Sierra Madre.
As described in CMC Section 6.7 [RFC5272], "For keys that can be used as signature keys, signing the certification request with the private key serves as a POP on that key pair". The inclusion of tls-unique within the certification request links the the proof-of-possession to the TLS proof-of-identity. For support of keys that can not be used for signing the certification request the full CMC specification MUST be used.
As given in Section 4.3.1.2 clients use an existing certificate for TLS client authentication. If a certificate with appropriate key usage is not available the client MAY generate one. If a self-signed certificate with appropriate key usage is used the server SHOULD require HTTP-based client authentication according to server policy as described in Section 4.3.1.2 and Section 5.1. The server MAY fall back on manual authorization by the server administrator.
Clients authenticate EST servers by means of TLS authentication. If a client does not possess a root certificate suitable for validating an EST server certificate, it MAY rely upon other trusted root certificates it has (such as those found in its HTTPS store). The client then is able to retrieve additional root certificates as given in Section 5.3. Alternatively, a server certificate MAY be authenticated manually as specified in Section 4.3.1.1 #3.
As noted in Section 4.3.1.1 servers use an existing certificate for TLS server authentication. When the server certificate is issued by a mutually trusted PKI hierarchy, validation proceeds as specified in Section 5.2. In this situation the client has validated the server as being a valid responder for the URI configured but can not directly verify that the responder is authorized as an RA within the to-be-enrolled PKI hierarchy. A client may thus be enticed to expose username/password or certificate enrollment requests to an unauthorized server (if the server presents a valid HTTPS certificate for an erroneous URL that the client has been tricked into using). Proof-of-identity and Proof-of-possession checks by the CA prevent an illegitimate RA from leveraging such misconfigured clients to act as a man-in-the-middle during client authenticated operations but it is possible for such illegitimate RAs to send the client doctored messages or erroneous CA certificate lists. If the illegitimate RA has successfully phished a username/password or PIN from the client it might try to use these values to enroll its own keypair with the real PKI hierarchy. EST servers identified with an externally issued server certificate SHOULD require HTTPS-based client authentication [TLSclientAuthC]. Similarly EST clients SHOULD use an existing client certificate to identify themselves and otherwise prevent "private data" (obviously including passwords but also including private identity information) from being exposed during the enrollment exchange a weak server authorization method is used.
Section 4.2.3 allows clients to optionally authenticate using HTTP-based authentication in place of TLS-based authentication. HTTP-based authentication MUST NOT take place unless performed over a TLS-protected link.
The server-side key generation method allows keys to be transported over the TLS connection to the client. The distribution of "private" key material is inherently risky and servers are NOT RECOMMENDED to support this operation by default. Clients are NOT RECOMMENDED to request this service unless there is a compelling operational benefit such as the use of [BGPsec RPKI].
| [RFC4211] | Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, September 2005. |
| [RFC6403] | Zieglar, L., Turner, S. and M. Peck, "Suite B Profile of Certificate Management over CMS", RFC 6403, November 2011. |
| [IDevID] | IEEE Std, , "IEEE 802.1AR Secure Device Identifier", December 2009. |
(informative)
(This section is incomplete)
Clients MAY use DNS-SD or similar discovery algorithms to determine the EST base URL. In such cases it is expected that method 2 [TLSserverAuthC] be used during server authentication.
(informative)
In some deployments it may be beneficial to use a TLS concentrator to offload the TLS processing from the server. In such a deployment the TLS client authentication result must, in some way, be forwarded to the server.
The TLS server SHOULD NOT reject the connection based on PKIX validation of the client certificate. The client certificate SHOULD be passed to the EST layer for verification and authorization. This allows support of external TLS concentrators, or an external web server, that might provide an independent TLS implementation.
The TLS concentrator MUST validate the TLS [RFC4346] Section 7.4.8 'Certificate Verify'.
A TLS concentrator MUST insert the client certificate into the HTTP header. The TLS concentrator MUST first remove any existing client certificates, possibly inserted by a nefarious client, from the HTTP headers before forwarding the HTTP connection to the server.
[TBD - need to better understand what would happen in the case of proxy's or multiple concentrators. Or specifically state that as out of scope.]
[TBD - the HTTP header field names etc shall be specified here]
The EST server MUST be specifically configured by the administrator to accept this mechanism.
(informative)
In some deployments it may be beneficial to use a HTTPS server that runs the EST server as a CGI application. In such a deployment the HTTPS server client authentication result must, in some way, be forwarded to the server.
An HTTPS server MUST insert the client certificate into environment variables before calling a server CGI application.
[TBD - describe the CGI environment variables here. Can likely follow the apache example].
An HTTP server MUST insert the client certificate into environment variables before calling a server CGI application.
[TBD - describe the CGI environment variables here. Can likely follow the apache example].
(informative)
SCEP has been used instead of a full implementation of CMC for the same simplicity reasons discussed in Section 1. Such implementations would benefit from being updated to this specification in the following ways:
Updating an SCEP client implementation to support this protocol involves the following changes to the SCEP implementation. There is no server-side indication that SCEP clients should be so modified so this depends on a client-side configuration:
These simplifications to an existing SCEP implementation result in an SCEP client that is compliant with CMC when using the EST transport.
Implementation note: The use of tls-unique-securerenegotiation precludes the use of SCEP 'challenge-password' within the pkcs10 for password/PIN assertion. Instead these values must be asserted with the Section 4.2.3 described mechanism. A side effect of this is that a client communicating with an EST server can not embed an SCEP 'challenge-password' within the PKCS#10. An EST service running as an RA thus can not forward the PKCS#10 using SCEP to an SCEP server that expects the 'challenge-password' to be populated.