tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7030

 
 
 

Enrollment over Secure Transport

Part 2 of 4, p. 10 to 24
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 10 
3.  Protocol Design and Layering

   Figure 2 provides an expansion of Figure 1, describing how the layers
   are used.  Each aspect is described in more detail in the sections
   that follow.

   EST Layering:

   Protocols and uses:
   +----------------------------------------------------+
   |                                                    |
   | Message types:                                     |
   |   - "Simple PKI" messages                          |
   |     (incorporates proof-of-possession)             |
   |   - CA certificate retrieval                       |
   |   - "Full PKI" messages (OPTIONAL)                 |
   |     (incorporates proof-of-possession)             |
   |   - CSR Attributes Request (OPTIONAL)              |
   |   - Server-generated key request (OPTIONAL)        |
   |                                                    |
   +----------------------------------------------------+
   |                                                    |
   | HTTP:                                              |
   |   - HTTP headers and URIs for control              |
   |      - Content-Type headers specify message type   |
   |      - Headers for control/error messages          |
   |      - URIs for selecting functions                |
   |   - Basic or Digest authentication (OPTIONAL)      |
   |                                                    |
   +----------------------------------------------------+
   |                                                    |
   | TLS for transport security:                        |
   |   - Authentication of the EST server               |
   |   - Authentication of the EST client (OPTIONAL)    |
   |   - Provides communications integrity              |
   |     and confidentiality                            |
   |   - Supplies channel-binding [RFC5929] information |
   |     to link proof-of-identity with message-based   |
   |     proof-of-possession (OPTIONAL)                 |
   |                                                    |
   +----------------------------------------------------+

                                 Figure 2

   Specifying HTTPS as the secure transport for enrollment messages
   introduces two "layers" to communicate authentication and control
   messages: TLS and HTTP.

Top      Up      ToC       Page 11 
   The TLS layer provides integrity and confidentiality during
   transport.  The proof-of-identity is supplied by TLS handshake
   authentication and optionally also by the HTTP layer headers.  The
   message type and control/error messages are included in the HTTP
   headers.

   CMC ([RFC5272], Section 3.1) notes that "the Simple PKI Request MUST
   NOT be used if a proof-of-identity needs to be included".  Since the
   TLS and HTTP layers can provide proof-of-identity for EST clients and
   servers, the Simple PKI message types are used.

   The TLS layer certificate exchange provides a method for authorizing
   client enrollment requests using existing certificates.  Such
   certificates may have been issued by the 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 Initial Device Identifier
   (IDevID) [IDevID] credential).

   Proof-of-possession (POP) is a distinct issue from proof-of-identity
   and is included in the Simple PKI message type as described in
   Section 3.4.  A method of linking proof-of-identity and
   proof-of-possession is described in Section 3.5.

   This document also defines transport for CMC [RFC5272] that complies
   with the CMC Transport Protocols [RFC5273].  CMC's POP and
   proof-of-identity mechanisms are defined in CMC, but the mechanisms
   here can also be used in conjunction with those mechanisms in "Full
   PKI" messages.

   During protocol exchanges, different certificates can be used.  The
   following table provides an informative overview.  End-entities can
   have one or more certificates of each type listed in Figure 3 and use
   one or more trust anchor databases of each type listed in Figure 4.

Top      Up      ToC       Page 12 
   Certificates and their corresponding uses:
   +--------------+--------------------+-------------------------------+
   | Certificate  | Issuer             | Use and section references    |
   +==============+====================+===============================+
   | EST server   | The CA served by   | Presented by the EST server   |
   | certificate  | the EST server     | during the TLS handshake.     |
   |              |                    |                               |
   |              |                    | Section 3.3.1                 |
   +--------------+--------------------+-------------------------------+
   | EST server   | A CA               | Presented by the EST server   |
   | certificate  | authenticatable by | during the TLS handshake.     |
   |              | a third-party TA,  |                               |
   |              | e.g., a web server | Section 3.3.1 and             |
   |              | CA                 | Security Considerations       |
   +--------------+--------------------+-------------------------------+
   | Third-party  | A CA               | Presented by the EST client   |
   | EST client   | authenticatable by | to the EST server by clients  |
   | certificate  | a third-party TA,  | that have not yet enrolled.   |
   |              | e.g., a device     |                               |
   |              | manufacturer       | Section 3.3.2                 |
   +--------------+--------------------+-------------------------------+
   | EST client   | The CA served by   | Presented to the EST server   |
   | certificate  | the EST server     | during future EST operations. |
   |              |                    |                               |
   |              |                    | Section 3.3.2                 |
   +--------------+--------------------+-------------------------------+
   | End-entity   | The CA served by   | Clients can obtain certs      |
   | certificate  | the EST server     | that are intended for         |
   |              |                    | non-EST uses.  This includes  |
   |              |                    | certs that cannot be used     |
   |              |                    | for EST operations.           |
   |              |                    |                               |
   |              |                    | Section 4.2.3                 |
   +--------------+--------------------+-------------------------------+


                                 Figure 3

Top      Up      ToC       Page 13 
   Trust anchor databases and their corresponding uses:
   +--------------+----------------------------------------------------+
   | TA database  | Use and section references                         |
   +==============+====================================================+
   | EST server   | EST servers use this TA database to authenticate   |
   | Explicit     | certificates issued by the EST CA, including EST   |
   | TA database  | client certificates during enroll/re-enroll        |
   |              | operations.                                        |
   |              |                                                    |
   |              | Section 3.3.2                                      |
   +--------------+----------------------------------------------------+
   | EST server   | EST servers use this TA database to authenticate   |
   | Implicit     | certificates issued by third-party TAs;            |
   | TA database  | e.g., EST client certificates issued by a device   |
   |              | manufacturer.                                      |
   |              | An Implicit TA database can be disabled.           |
   |              |                                                    |
   |              | Section 3.3.2                                      |
   +--------------+----------------------------------------------------+
   | EST client   | EST clients use this TA database to authenticate   |
   | Explicit     | certificates issued by the EST CA, including EST   |
   | TA database  | server certificates.                               |
   |              |                                                    |
   |              | Sections 3.1, 3.3.1, 3.6.1, and 4.1.1              |
   +--------------+----------------------------------------------------+
   | EST client   | EST clients use this TA database to                |
   | Implicit     | authenticate an EST server that uses an externally |
   | TA database  | issued certificate.                                |
   |              | An Implicit TA database can be disabled.           |
   |              |                                                    |
   |              | Sections 3.1, 3.3.1, 3.6.2, and                    |
   |              | Security Considerations                            |
   +--------------+----------------------------------------------------+


                                 Figure 4

3.1.  Application Layer

   The EST client MUST be capable of generating and parsing Simple PKI
   messages (see Section 4.2).  Generating and parsing Full PKI messages
   is OPTIONAL (see Section 4.3).  The client MUST also be able to
   request CA certificates from the EST server and parse the returned
   "bag" of certificates (see Section 4.1).  Requesting CSR attributes
   and parsing the returned list of attributes is OPTIONAL (see
   Section 4.5).

Top      Up      ToC       Page 14 
   Details of the EST client application configuration are out of scope
   of the protocol discussion but are necessary for understanding the
   prerequisites of initiating protocol operations.  The EST client is
   RECOMMENDED to be configured with TA databases for Section 3.3.1 or
   with a secret key for Section 3.3.3.  Implementations conforming to
   this standard MUST provide the ability to designate Explicit TAs.
   For human usability reasons, a "fingerprint" of an Explicit TA
   database entry can be configured for bootstrapping as discussed in
   Section 4.1.1.  Configuration of an Implicit TA database, perhaps by
   its inclusion within the EST client distribution or available from
   the operating system, provides flexibility along with the caveats
   detailed in Section 6.  Implementations conforming to this standard
   MUST provide the ability to disable use of any Implicit TA database.

   The EST client is configured with sufficient information to form the
   EST server URI.  This can be the full operation path segment (e.g.,
   https://www.example.com/.well-known/est/ or
   https://www.example.com/.well-known/est/arbitraryLabel1), or the EST
   client can be configured with a tuple composed of the authority
   portion of the URI along with the OPTIONAL label (e.g.,
   "www.example.com:80" and "arbitraryLabel1") or just the authority
   portion of the URI.

3.2.  HTTP Layer

   HTTP is used to transfer EST messages.  URIs are defined for handling
   each media type (i.e., message type) as described in Section 3.2.2.
   HTTP is also used for client authentication services when TLS client
   authentication is not available, due to the lack of a client
   certificate suitable for use by TLS (see Section 3.2.3).  HTTP
   authentication can also be used in addition to TLS client
   authentication if the EST server wishes additional authentication
   information, as noted in Section 2.2.3.  Registered media types are
   used to convey EST messages as specified in Figure 6.

   HTTP 1.1 [RFC2616] and above support persistent connections.  As
   described in Section 8.1 of RFC 2616, persistent connections may be
   used to reduce network and processing loads associated with multiple
   HTTP requests.  EST does not require or preclude persistent HTTP
   connections.

Top      Up      ToC       Page 15 
3.2.1.  HTTP Headers for Control

   The HTTP Status value is used to communicate success or failure of an
   EST function.  HTTP authentication is used by a client when requested
   by the server.

   The media types specified in the HTTP Content-Type header indicate
   which EST message is being transferred.  Media types used by EST are
   specified in Section 3.2.4.

   HTTP redirections (3xx status codes) to the same web origin (see
   [RFC6454]) SHOULD be handled by the client without user input so long
   as all applicable security checks (Sections 3.3 and 3.6) have been
   enforced on the initial connection.  The client initiates a new TLS
   connection and performs all applicable security checks when
   redirected to other web origin servers.  Redirections to other web
   origins require the EST client to obtain user input for non-GET or
   HEAD requests as specified in [RFC2616].  Additionally, if the client
   has already generated a CSR that includes linking identity and POP
   information (Section 3.5), then the CSR will need to be recreated to
   incorporate the tls-unique from the new, redirected session.  Note:
   the key pair need not be regenerated.  These are processing and
   interface burdens on the client.  EST server administrators are
   advised to take this into consideration.

Top      Up      ToC       Page 16 
3.2.2.  HTTP URIs for Control

   The EST server MUST support the use of the path-prefix of "/.well-
   known/" as defined in [RFC5785] and the registered name of "est".
   Thus, a valid EST server URI path begins with
   "https://www.example.com/.well-known/est".  Each EST operation is
   indicated by a path-suffix that indicates the intended operation:

   Operations and their corresponding URIs:
   +------------------------+-----------------+-------------------+
   | Operation              |Operation path   | Details           |
   +========================+=================+===================+
   | Distribution of CA     | /cacerts        | Section 4.1       |
   | Certificates (MUST)    |                 |                   |
   +------------------------+-----------------+-------------------+
   | Enrollment of          | /simpleenroll   | Section 4.2       |
   | Clients (MUST)         |                 |                   |
   +------------------------+-----------------+-------------------+
   | Re-enrollment of       | /simplereenroll | Section 4.2.2     |
   | Clients (MUST)         |                 |                   |
   +------------------------+-----------------+-------------------+
   | Full CMC (OPTIONAL)    | /fullcmc        | Section 4.3       |
   +------------------------+-----------------+-------------------+
   | Server-Side Key        | /serverkeygen   | Section 4.4       |
   | Generation (OPTIONAL)  |                 |                   |
   +------------------------+-----------------+-------------------+
   | CSR Attributes         | /csrattrs       | Section 4.5       |
   | (OPTIONAL)             |                 |                   |
   +------------------------+-----------------+-------------------+

                                 Figure 5

   The operation path (Figure 5) is appended to the path-prefix to form
   the URI used with HTTP GET or POST to perform the desired EST
   operation.  An example valid URI absolute path for the "/cacerts"
   operation is "/.well-known/est/cacerts".  To retrieve the CA's
   certificates, the EST client would use the following HTTP
   request-line:

   GET /.well-known/est/cacerts HTTP/1.1

   Likewise, to request a new certificate in this example scheme, the
   EST client would use the following request-line:

   POST /.well-known/est/simpleenroll HTTP/1.1

Top      Up      ToC       Page 17 
   The use of distinct operation paths simplifies implementation for
   servers that do not perform client authentication when distributing
   /cacerts responses.

   An EST server MAY provide service for multiple CAs as indicated by an
   OPTIONAL additional path segment between the registered application
   name and the operation path.  To avoid conflict, the CA label MUST
   NOT be the same as any defined operation path segment.  The EST
   server MUST provide services regardless of whether the additional
   path segment is present.  The following are three example valid URIs:

   1.  https://www.example.com/.well-known/est/cacerts

   2.  https://www.example.com/.well-known/est/arbitraryLabel1/cacerts

   3.  https://www.example.com/.well-known/est/arbitraryLabel2/cacerts

   In this specification, the distinction between enroll and renew/rekey
   is explicitly indicated by the HTTP URI.  When requesting /fullcmc
   operations, CMC [RFC5272] uses the same messages for certificate
   renewal and certificate rekey.

   An EST server can provide additional services using other URIs.

3.2.3.  HTTP-Based Client Authentication

   The EST server MAY request HTTP-based client authentication.  This
   request can be in addition to successful TLS client authentication
   (Section 3.3.2) if EST server policy requires additional
   authentication.  (For example, the EST server may require that an EST
   client "knows" a password in addition to "having" an existing client
   certificate.)  Or, HTTP-based client authentication can be an EST
   server policy-specified fallback in situations where the EST client
   did not successfully complete the TLS client authentication.  (This
   might arise if the EST client is enrolling for the first time or if
   the certificates available to an EST client cannot be used for TLS
   client authentication.)

   HTTP Basic and Digest authentication MUST only be performed over TLS
   1.1 [RFC4346] or later versions.  NULL and anon cipher suites MUST
   NOT be used because they do not provide confidentiality or support
   mutual certificate-based or certificate-less authentication,
   respectively.  As specified in "Certificate Management over CMS
   (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 SHOULD
   support the Basic and Digest authentication mechanism.

Top      Up      ToC       Page 18 
   Servers that wish to use Basic and Digest authentication reject the
   HTTP request using the HTTP-defined WWW-Authenticate response-header
   ([RFC2616], Section 14.47).  The client is expected to retry the
   request, including the appropriate Authorization Request header
   ([RFC2617], Section 3.2.2), if the client is capable of using the
   Basic or Digest authentication.  If the client is not capable of
   retrying the request or it is not capable of Basic or Digest
   authentication, then the client MUST terminate the connection.

   A client MAY set the username to the empty string ("") if it is
   presenting a password that is not associated with a username.

   Support for HTTP-based client authentication has security
   ramifications as discussed in Section 6.  The client MUST NOT respond
   to the server's HTTP authentication request unless the client has
   authorized the EST server (as per Section 3.6).

Top      Up      ToC       Page 19 
3.2.4.  Message Types

   This document uses existing media types for the messages as specified
   by FTP and HTTP [RFC2585], application/pkcs10 [RFC5967], and CMC
   [RFC5272].

   For consistency with [RFC5273], each distinct EST message type uses
   an HTTP Content-Type header with a specific media type.

   The EST messages and their corresponding media types for each
   operation are:

   +--------------------+--------------------------+-------------------+
   | Message type       | Request media type       | Request section(s)|
   |                    | Response media type(s)   | Response section  |
   | (per operation)    | Source(s) of types       |                   |
   +====================+==========================+===================+
   | Distribution of CA | N/A                      | Section 4.1       |
   | Certificates       | application/pkcs7-mime   | Section 4.1.1     |
   |                    | [RFC5751]                |                   |
   | /cacerts           |                          |                   |
   +--------------------+--------------------------+-------------------+
   | Client Certificate | application/pkcs10       | Sections 4.2/4.2.1|
   | Request Functions  | application/pkcs7-mime   | Section 4.2.2     |
   |                    | [RFC5967] [RFC5751]      |                   |
   | /simpleenroll      |                          |                   |
   | /simplereenroll    |                          |                   |
   +--------------------+--------------------------+-------------------+
   | Full CMC           | application/pkcs7-mime   | Section 4.3.1     |
   |                    | application/pkcs7-mime   | Section 4.3.2     |
   | /fullcmc           | [RFC5751]                |                   |
   +--------------------+--------------------------+-------------------+
   | Server-Side Key    | application/pkcs10       | Section 4.4.1     |
   | Generation         | multipart/mixed          | Section 4.4.2     |
   |                    | (application/pkcs7-mime &|                   |
   |                    | application/pkcs8)       |                   |
   |                    | [RFC5967] [RFC5751]      |                   |
   | /serverkeygen      | [RFC5958]                |                   |
   +--------------------+--------------------------+-------------------+
   | CSR Attributes     | N/A                      | Section 4.5.1     |
   |                    | application/csrattrs     | Section 4.5.2     |
   |                    | (This document)          |                   |
   | /csrattrs          |                          |                   |
   +--------------------+--------------------------+-------------------+

                                 Figure 6

Top      Up      ToC       Page 20 
3.3.  TLS Layer

   TLS provides authentication, which in turn enables authorization
   decisions.  The EST server and EST client are responsible for
   ensuring that an acceptable cipher suite is negotiated and that
   mutual authentication has been performed.  TLS authentication is most
   commonly enabled with the use of certificates [RFC5280].
   Alternately, certificate-less TLS authentication, where neither the
   client nor server present a certificate, is also an acceptable method
   for EST mutual authentication (Section 3.3.3).  The EST server MUST
   be authenticated during the TLS handshake unless the client is
   requesting Bootstrap Distribution of CA certificates (Section 4.1.1)
   or Full CMC (Section 4.3).

   HTTPS [RFC2818] specifies how HTTP messages are carried over TLS.
   HTTPS MUST be used.  TLS 1.1 [RFC4346] (or a later version) MUST be
   used for all EST communications.  TLS session resumption [RFC5077]
   SHOULD be supported.

   TLS channel-binding information can be inserted into a certificate
   request, as detailed in Section 3.5, in order to provide the EST
   server with assurance that the authenticated TLS client has access to
   the private key for the certificate being requested.  The EST server
   MUST implement Section 3.5.

3.3.1.  TLS-Based Server Authentication

   TLS server authentication with certificates MUST be supported.

   The EST client authenticates the EST server as defined for the cipher
   suite negotiated.  The following text provides details assuming a
   certificate-based cipher suite, such as the TLS 1.1 [RFC4346]
   mandatory cipher suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA).

   Certificate validation MUST be performed as per [RFC5280].  The EST
   server certificate MUST conform to the [RFC5280] certificate profile.

   The client validates the TLS server certificate using the EST client
   Explicit and, if enabled, Implicit TA database(s).  The client MUST
   maintain a distinction between the use of Explicit and Implicit TA
   databases during authentication in order to support proper
   authorization.  The EST client MUST perform authorization checks as
   specified in Section 3.6.

   If certificate validation fails, the client MAY follow the procedure
   outlined in Section 4.1.1 for Bootstrap Distribution of CA
   certificates.

Top      Up      ToC       Page 21 
3.3.2.  TLS-Based Client Authentication

   TLS client authentication is the RECOMMENDED method for identifying
   EST clients.  HTTP-based client authentication (Section 3.2.3) MAY be
   used.

   The EST server authenticates the EST client as defined for the cipher
   suite negotiated.  The following text provides details assuming a
   certificate-based cipher suite such as the TLS 1.1 [RFC4346]
   mandatory cipher suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA).  The EST
   server MUST support certificate-based client authentication.

   Generally, the client will use an existing certificate for renew or
   rekey operations.  If the certificate to be renewed or rekeyed is
   appropriate for the negotiated cipher suite, then the client MUST use
   it for the TLS handshake, otherwise the client SHOULD use an
   alternate certificate that is suitable for the cipher suite and
   contains the same subject identity information.  When requesting an
   enroll operation, the client MAY use a client certificate issued by a
   third party to authenticate itself.

   Certificate validation MUST be performed as per [RFC5280].  The EST
   client certificate MUST conform to the [RFC5280] certificate profile.

   The server validates the TLS client certificate using the EST server
   Explicit and, if enabled, Implicit TA database(s).  The server MUST
   maintain a distinction between the use of Explicit and Implicit TA
   databases during authentication in order to support proper
   authorization.

   The EST server MUST perform authorization checks as specified in
   Section 3.7.

   If a client does not support TLS client authentication, then it MUST
   support HTTP-based client authentication (Section 3.2.3) or
   certificate-less TLS authentication (Section 3.3.3).

3.3.3.  Certificate-Less TLS Mutual Authentication

   Certificate-less TLS cipher suites provide a way to perform mutual
   authentication in situations where neither the client nor server have
   certificates, do not desire to use certificates, or do not have the
   trust anchors necessary to verify a certificate.  The client and
   server MAY negotiate a certificate-less cipher suite for mutual
   authentication.

   When using certificate-less mutual authentication in TLS for
   enrollment, the cipher suite MUST be based on a protocol that is

Top      Up      ToC       Page 22 
   resistant to dictionary attack and MUST be based on a zero knowledge
   protocol.  Transport Layer Security-Secure Remote Password (TLS-SRP)
   cipher suites, i.e., those with _SRP_ in the name, listed in
   Section 2.7 of [RFC5054] are suitable for this purpose.  Section 6
   lists the characteristics of a cipher suite that are suitable for use
   in certificate-less mutual authentication for enrollment.

   Successful authentication using a certificate-less cipher suite
   proves knowledge of a pre-shared secret that implicitly authorizes a
   peer in the exchange.

3.4.  Proof-of-Possession

   As defined in Section 2.1 of CMC [RFC5272], proof-of-possession (POP)
   "refers to a value that can be used to prove that the private key
   corresponding to the public key is in the possession of and can be
   used by an end-entity".

   The signed enrollment request provides a signature-based
   proof-of-possession.  The mechanism described in Section 3.5
   strengthens this by optionally including "Direct"-based
   proof-of-possession [RFC5272] by including TLS session-specific
   information within the data covered by the enrollment request
   signature (thus linking the enrollment request to the authenticated
   end point of the TLS connection).

3.5.  Linking Identity and POP Information

   Server policy will determine whether clients are required to use the
   mechanism specified in this section.  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.  The client can determine if the
   server requires the linking of identity and POP by examining the CSR
   Attributes Response (see Section 4.5.2).  Regardless of the CSR
   Attributes Response, clients SHOULD link identity and POP by
   embedding tls-unique information in the certification request.  If
   tls-unique information is included by the client, the server MUST
   verify it.  The EST server MAY reject requests without tls-unique
   information as indicated by server policy.

   Linking identity and proof-of-possession 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 "Linking Identity and POP
   Information" method defined by Section 6 of [RFC5272] that is
   available if Full PKI messages are used.

Top      Up      ToC       Page 23 
   The client generating the CSR obtains the tls-unique value from the
   TLS subsystem as described in Channel Bindings for TLS [RFC5929].
   The EST client operations between obtaining the tls-unique value
   through generation of the CSR that contains the current tls-unique
   value and the subsequent verification of this value by the EST server
   are the "phases of the application protocol during which application-
   layer authentication occurs"; these operations are protected by the
   synchronization interoperability mechanism described in the "Channel
   Bindings for TLS" interoperability notes in Section 3.1 of [RFC5929].

   When performing renegotiation, TLS "secure_renegotiation" [RFC5746]
   MUST be used.

   The tls-unique value is base64 encoded as specified in Section 4 of
   [RFC4648], and the resulting string is placed in the certification
   request challenge-password field ([RFC2985], Section 5.4.1).  The
   challenge-password field is limited to 255 bytes (Section 7.4.9 of
   [RFC5246] indicates that no existing cipher suite would result in an
   issue with this limitation).  If the challenge-password attribute is
   absent, the client did not include the optional channel-binding
   information (the presence of the challenge-password attribute
   indicates the inclusion of tls-unique information).

   If the EST server makes use of a back-end infrastructure for
   processing, it is RECOMMENDED that the results of this verification
   be communicated.  (For example, this communication might use the CMC
   [RFC5272] "RA POP Witness Control" in a CMC Full PKI Request message.
   Or, an EST server might TLS-authenticate an EST client as being a
   trusted infrastructure element that does not forward invalid
   requests.  A detailed discussion of back-end processing is out of
   scope.)

   When rejecting requests, the EST server response is as described for
   all enroll responses (Section 4.2.3).  If a Full PKI Response is
   included, the CMCFailInfo MUST be set to popFailed.  If a human-
   readable reject message is included, it SHOULD include an informative
   text message indicating that the linking of identity and POP
   information is required.

3.6.  Server Authorization

   The client MUST check EST server authorization before accepting any
   server responses or responding to HTTP authentication requests.

   The EST client authorization method depends on which method was used
   to authenticate the server.  When the Explicit TA database is used to
   authenticate the EST server, then Section 3.6.1 applies.  When the
   Implicit TA database is used to authenticate the EST server, then

Top      Up      ToC       Page 24 
   Section 3.6.2 applies.  Successful authentication using a
   certificate-less cipher suite implies authorization of the server.

   The client MAY perform bootstrapping as specified in Section 4.1.1
   even if these checks fail.

3.6.1.  Client Use of Explicit TA Database

   When the EST client Explicit TA database is used to validate the EST
   server certificate, the client MUST check either the configured URI
   or the most recent HTTP redirection URI against the server's identity
   according to the rules specified in [RFC6125], Section 6.4, or the
   EST server certificate MUST contain the id-kp-cmcRA [RFC6402]
   extended key usage extension.

3.6.2.  Client Use of Implicit TA Database

   When the EST client Implicit TA database is used to validate the EST
   server certificate, the client MUST check the configured URI and each
   HTTP redirection URI according to the rules specified in [RFC6125],
   Section 6.4.  The provisioned URI or the most recent HTTP redirection
   URI provides the basis for authorization, and the server's
   authenticated identity confirms it is the authorized server.

3.7.  Client Authorization

   The decision to issue a certificate to a client is always controlled
   by local CA policy.  The EST server configuration reflects this CA
   policy.  This document does not specify any constraints on such
   policy.  EST provides the EST server access to each client's
   authenticated identity -- e.g., the TLS client's certificate in
   addition to any HTTP user authentication credentials -- to help in
   implementing such policy.

   If the client's certificate was issued by the EST CA, and it includes
   the id-kp-cmcRA [RFC6402] extended key usage extension, then the
   client is a Registration Authority (RA) as described in [RFC5272] and
   [RFC6402].  In this case, the EST server SHOULD apply authorization
   policy consistent with an RA client.  For example, when handling
   /simpleenroll requests, the EST server could be configured to accept
   POP linking information that does not match the current TLS session
   because the authenticated EST client RA has verified this information
   when acting as an EST server (as specified in Section 3.5).  More
   specific RA mechanisms are available if the EST client uses /fullcmc
   methods.


Next RFC Part