tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7030

 
 
 

Enrollment over Secure Transport

Part 3 of 4, p. 25 to 41
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 25 
4.  Protocol Exchange Details

   Before processing a request, an EST server determines if the client
   is authorized to receive the requested services.  Likewise, the
   client determines if it will make requests to the EST server.  These
   authorization decisions are described in the next two sections.
   Assuming that both sides of the exchange are authorized, then the
   actual operations are as described in subsequent sections.

4.1.  Distribution of CA Certificates

   The EST client can request a copy of the current CA certificates.
   This function is generally performed before other EST functions.

4.1.1.  Bootstrap Distribution of CA Certificates

   It is possible that the client was not configured with an Implicit TA
   database that allows a bootstrap installation of the Explicit TA
   database as described in 4.1.3.  This section describes an alternate
   method by which minimally configured EST clients can populate their
   Explicit TA database.

   If the EST client application does not specify either an Explicit TA
   database or an Implicit TA database, then the initial TLS server
   authentication and authorization will fail.  The client MAY
   provisionally continue the TLS handshake to completion for the
   purposes of accessing the /cacerts or /fullcmc method.  If the EST
   client continues with an unauthenticated connection, the client MUST
   extract the HTTP content data from the response (Sections 4.1.3 or
   4.3.2) and engage a human user to authorize the CA certificate using
   out-of-band data such as a CA certificate "fingerprint" (e.g., a
   SHA-256 or SHA-512 [SHS] hash on the whole CA certificate).  In a
   /fullcmc response, it is the Publish Trust Anchors control (CMC
   [RFC5272], Section 6.15) within the Full PKI Response that must be
   accepted manually.  It is incumbent on the user to properly verify
   the TA information, or to provide the "fingerprint" data during
   configuration that is necessary to verify the TA information.

   HTTP authentication requests MUST NOT be responded to if the server
   has not been authenticated as specified in Section 3.3.1 or if the
   optional certificate-less authentication is used as specified in
   Section 3.3.3.

   The EST client uses the /cacerts response to establish an Explicit
   Trust Anchor database for subsequent TLS authentication of the EST
   server.  EST clients MUST NOT engage in any other protocol exchange

Top      Up      ToC       Page 26 
   until after the /cacerts response has been accepted and a new TLS
   session has been established (using TLS certificate-based
   authentication).

4.1.2.  CA Certificates Request

   EST clients request the EST CA TA database information of the CA (in
   the form of certificates) with an HTTPS GET message using an
   operation path of "/cacerts".  EST clients and servers MUST support
   the /cacerts function.  Clients SHOULD request an up-to-date response
   before stored information has expired in order to ensure the EST CA
   TA database is up to date.

   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 3.3.1 if certificate-based authentication is used or
   Section 3.3.3 if the optional certificate-less authentication is
   used, and check the server's authorization as given in Section 3.6,
   or follow the procedure outlined in Section 4.1.1.

4.1.3.  CA Certificates Response

   If successful, the server response MUST have an HTTP 200 response
   code.  Any other response code indicates an error and the client MUST
   abort the protocol.

   A successful response MUST be a certs-only CMC Simple PKI Response,
   as defined in [RFC5272], containing the certificates described in the
   following paragraph.  The HTTP content-type of
   "application/pkcs7-mime" is used.  The Simple PKI Response is sent
   with a Content-Transfer-Encoding of "base64" [RFC2045].

   The EST server MUST include the current root CA certificate in the
   response.  The EST server MUST include any additional certificates
   the client would need to build a chain from an EST CA-issued
   certificate to the current EST CA TA.  For example, if the EST CA is
   a subordinate CA, then all the appropriate subordinate CA
   certificates necessary to build a chain to the root EST CA are
   included in the response.

   The EST server SHOULD include the three "Root CA Key Update"
   certificates OldWithOld, OldWithNew, and NewWithOld in the response
   chain.  These are defined in Section 4.4 of CMP [RFC4210].  The EST
   client MUST be able to handle these certificates in the response.
   The EST CA's most recent self-signed certificate (e.g., NewWithNew
   certificate) is self-signed and has the latest NotAfter date.  If the

Top      Up      ToC       Page 27 
   EST server does not include these in the response, then after the
   current EST CA certificate expires, the EST clients will need to be
   reinitialized with the PKI using the Bootstrap Distribution of CA
   certificates (Section 4.1.1) method, which involves user interaction.

   After out-of-band validation occurs, all the other certificates MUST
   be validated using normal [RFC5280] certificate path validation
   (using the most recent CA certificate as the TA) before they can be
   used to build certificate paths during certificate validation.

   The EST client MUST store the extracted EST CA certificate as an
   Explicit TA database entry for subsequent EST server authentication.
   The EST client SHOULD disable use of Implicit TA database entries for
   this EST server now that an Explicit TA database entry is available.
   If the client disables the Implicit TA database, and if the EST
   server certificate was verified using an Implicit TA database entry,
   then the client MUST include the "Trusted CA Indication" extension in
   future TLS sessions [RFC6066].  This indicates to the server that
   only an EST server certificate authenticatable by the Explicit TA
   database entry is now acceptable (otherwise, the EST server might
   continue to use a server certificate that is only verifiable by a now
   disabled Implicit TA).

   The EST client SHOULD also make the CA Certificate response
   information available to the end-entity software for use when
   validating peer certificates.

4.2.  Client Certificate Request Functions

   EST clients request a certificate from the EST server with an HTTPS
   POST using the operation path value of "/simpleenroll".  EST clients
   request a renew/rekey of existing certificates with an HTTP POST
   using the operation path value of "/simplereenroll".  EST servers
   MUST support the /simpleenroll and /simplereenroll functions.

   It is RECOMMENDED that a client obtain the current CA certificates,
   as described in Section 4.1, before performing certificate request
   functions.  This ensures that the client will be able to validate the
   EST server certificate.  The client MUST authenticate the EST server
   as specified in Section 3.3.1 if certificate-based authentication is
   used or Section 3.3.3 if the optional certificate-less authentication
   is used.  The client MUST verify the authorization of the EST server
   as specified in Section 3.6.

   The server MUST authenticate the client as specified in Section 3.3.2
   if certificate-based authentication is used or Section 3.3.3 if the
   optional certificate-less authentication is used.  The server MUST
   verify client authorization as specified in Section 3.7.  The EST

Top      Up      ToC       Page 28 
   server MUST check the tls-unique value, as described in Section 3.5,
   if one is submitted by the client.

   The server MAY accept a certificate request for manual authorization
   checking by an administrator.  (Section 4.2.3 describes the use of an
   HTTP 202 response to the EST client if this occurs.)

4.2.1.  Simple Enrollment of Clients

   When HTTPS POSTing to /simpleenroll, the client MUST include a Simple
   PKI Request as specified in CMC [RFC5272], Section 3.1 (i.e., a PKCS
   #10 Certification Request [RFC2986]).

   The Certification Signing Request (CSR) signature provides
   proof-of-possession of the client-possessed private key to the EST
   server.  If the CSR KeyUsage extension indicates that the private key
   can be used to generate digital signatures, then the client MUST
   generate the CSR signature using the private key.  If the key can be
   used to generate digital signatures but the requested CSR KeyUsage
   extension prohibits generation of digital signatures, then the CSR
   signature MAY still be generated using the private key, but the key
   MUST NOT be used for any other signature operations (this is
   consistent with the recommendations concerning submission of
   proof-of-possession to an RA or CA as described in
   [SP-800-57-Part-1]).  The use of /fullcmc operations provides access
   to more advanced proof-of-possession methods that are used when the
   key pair cannot be used for digital signature generation (see
   Section 4.3).

   The HTTP content-type of "application/pkcs10" is used here.  The
   format of the message is as specified in [RFC5967] with a Content-
   Transfer-Encoding of "base64" [RFC2045].

   If the EST client authenticated using a previously installed
   certificate issued by a third-party CA (see Section 2.2.1), the
   client MAY include the ChangeSubjectName attribute, as defined in
   [RFC6402], in the CSR to request that the subjectName and
   SubjectAltName be changed in the new certificate.

   The EST client MAY request additional certificates even when using an
   existing certificate in the TLS client authentication.  For example,
   the client can use an existing certificate for TLS client
   authentication when requesting a certificate that cannot be used for
   TLS client authentication.

Top      Up      ToC       Page 29 
4.2.2.  Simple Re-enrollment of Clients

   EST clients renew/rekey certificates with an HTTPS POST using the
   operation path value of "/simplereenroll".

   A certificate request employs the same format as the "simpleenroll"
   request, using the same HTTP content-type.  The request Subject field
   and SubjectAltName extension MUST be identical to the corresponding
   fields in the certificate being renewed/rekeyed.  The
   ChangeSubjectName attribute, as defined in [RFC6402], MAY be included
   in the CSR to request that these fields be changed in the new
   certificate.

   If the Subject Public Key Info in the certification request is the
   same as the current client certificate, then the EST server renews
   the client certificate.  If the public key information in the
   certification request is different than the current client
   certificate, then the EST server rekeys the client certificate.

4.2.3.  Simple Enroll and Re-enroll Response

   If the enrollment is successful, the server response MUST contain an
   HTTP 200 response code with a content-type of
   "application/pkcs7-mime".

   A successful response MUST be a certs-only CMC Simple PKI Response,
   as defined in [RFC5272], containing only the certificate that was
   issued.  The HTTP content-type of "application/pkcs7-mime" with an
   smime-type parameter "certs-only" is used, as specified in [RFC5273].

   The server MUST answer with a suitable 4xx or 5xx HTTP [RFC2616]
   error code when a problem occurs.  A Simple PKI Response with an HTTP
   content-type of "application/pkcs7-mime" (see Section 4.3.2) MAY be
   included in the response data to convey an error response.  If the
   content-type is not set, the response data MUST be a plaintext human-
   readable error message containing explanatory information describing
   why the request was rejected (for example, indicating that CSR
   attributes are incomplete).

   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.  The server also 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

Top      Up      ToC       Page 30 
   for maintaining all states 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].

   If the client closes the TLS connections while waiting for the Retry-
   After time to expire, then the client initiates a new TLS connection
   and performs all applicable security checks.  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.

   The EST client MAY also make the certificate response, and associated
   private key, available to end-entity software for use as an
   end-entity certificate.

4.3.  Full CMC

   An EST client can request a certificate from an EST server with an
   HTTPS POST using the operation path value of "/fullcmc".  Support for
   the /fullcmc function is OPTIONAL for both clients and servers.

4.3.1.  Full CMC Request

   If the HTTP POST to /fullcmc is not a valid Full PKI Request, the
   server MUST reject the message.  The HTTP content-type used is
   "application/pkcs7-mime" with an smime-type parameter "CMC-request",
   as specified in [RFC5273].  The body of the message is the binary
   value of the encoding of the PKI Request with a
   Content-Transfer-Encoding of "base64" [RFC2045].

4.3.2.  Full CMC Response

   If the enrollment is successful, the server response MUST include an
   HTTP 200 response code with a content-type of
   "application/pkcs7-mime" as specified in [RFC5273].  The response
   data includes either the Simple PKI Response with an smime-type
   parameter of "certs-only" or the Full PKI Response with an smime-type
   parameter "CMC-response", as specified in Section 3.2.1 of [RFC5751].
   The body of the message is the binary value of the encoding of the
   PKI Response with a Content-Transfer-Encoding of "base64" [RFC2045].

Top      Up      ToC       Page 31 
   When rejecting a request, the server MUST specify either an HTTP 4xx
   error or an HTTP 5xx error.  A CMC response with the content-type of
   "application/pkcs7-mime" MUST be included in the response data for
   any CMC error response.

   All other return codes are handled as specified in Section 4.2.3 or
   HTTP [RFC2616].  For example, a client interprets an HTTP 404 or 501
   response to indicate that this service is not implemented.

4.4.  Server-Side Key Generation

   An EST client may request a private key and associated certificate
   from an EST server using an HTTPS POST with an operation path value
   of "/serverkeygen".  Support for the /serverkeygen function is
   OPTIONAL.

   A client MUST authenticate an EST server, as specified in
   Section 3.3.1 if certificate-based authentication is used or
   Section 3.3.3 if the optional certificate-less authentication is
   used, and check the server's authorization as given in Section 3.6.

   The EST server MUST authenticate the client, as specified in
   Section 3.3.2 if certificate-based authenticated is used or
   Section 3.3.3 if the optional certificate-less authentication is
   used, and check the client's authorization as given in Section 3.7.
   The EST server applies whatever authorization or logic it chooses to
   determine if the private key and certificate should be provided.

   Cipher suites that have a NULL confidentiality algorithm MUST NOT be
   used as they will disclose the contents of an unprotected private
   key.

   Proper random number and key generation [RFC4086] is a server
   implementation responsibility, and server archiving of generated keys
   is determined by CA policy.  The key pair and certificate are
   transferred over the TLS session.  The cipher suite used to return
   the private key and certificate MUST offer confidentiality
   commensurate with the private key being delivered to the client.

   The EST client MAY request additional certificates even when using an
   existing certificate in the TLS client authentication.  For example,
   the client can use an existing certificate for TLS client
   authentication when requesting a certificate that cannot be used for
   TLS client authentication.

Top      Up      ToC       Page 32 
4.4.1.  Server-Side Key Generation Request

   The certificate request is HTTPS POSTed and is the same format as for
   the "/simpleenroll" and "/simplereenroll" path extensions with the
   same content-type and transfer encoding.

   In all respects, the server SHOULD treat the CSR as it would any
   enroll or re-enroll CSR; the only distinction here is that the server
   MUST ignore the public key values and signature in the CSR.  These
   are included in the request only to allow re-use of existing
   codebases for generating and parsing such requests.

   If the client desires to receive the private key with encryption that
   exists outside of and in addition to that of the TLS transport used
   by EST or if server policy requires that the key be delivered in such
   a form, the client MUST include an attribute in the CSR indicating
   the encryption key to be used.  Both symmetric and asymmetric
   encryption are supported as described in the following subsections.
   The client MUST also include an SMIMECapabilities attribute
   ([RFC2633], Section 2.5) in the CSR to indicate the key encipherment
   algorithms the client is willing to use.

   It is strongly RECOMMENDED that the clients request that the returned
   private key be afforded the additional security of the Cryptographic
   Message Syntax (CMS) EnvelopedData in addition to the TLS-provided
   security to protect against unauthorized disclosure.

4.4.1.1.  Requests for Symmetric Key Encryption of the Private Key

   To specify a symmetric encryption key to be used to encrypt the
   server-generated private key, the client MUST include a
   DecryptKeyIdentifier attribute (as defined in Section 2.2.5 of
   [RFC4108]) specifying the identifier of the secret key to be used by
   the server to encrypt the private key.  While that attribute was
   originally designated for specifying a firmware encryption key, it
   exactly mirrors the requirements for specifying a secret key to
   encrypt a private key.  If the server does not have a secret key
   matching the identifier specified by the client, the request MUST be
   terminated and an error returned to the client.  Distribution of the
   key specified by the DecryptKeyIdentifier to the key generator and
   the client is outside the scope of this document.

Top      Up      ToC       Page 33 
4.4.1.2.  Requests for Asymmetric Encryption of the Private Key

   To specify an asymmetric encryption key to be used to encrypt the
   server-generated private key, the client MUST include an
   AsymmetricDecryptKeyIdentifier attribute.  The
   AsymmetricDecryptKeyIdentifier attribute is defined as:

   id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= {
       id-aa 54 }

   The asymmetric-decrypt-key-identifier attribute values have ASN.1
   type AsymmetricDecryptKeyIdentifier (where ASN.1 is defined in
   [X.680])::

      AsymmetricDecryptKeyIdentifier ::= OCTET STRING

   If the server does not have a public key matching the identifier
   specified by the client, the request MUST be terminated and an error
   returned to the client.  Distribution of the key specified by the
   AsymmetricDecryptKeyIdentifier to the key generator and the client is
   outside the scope of this document.  If the key identified is bound
   to an X.509 certificate, then the key MUST either explicitly support
   keyTransport or keyAgreement or its use MUST be unrestricted.

4.4.2.  Server-Side Key Generation Response

   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: one part is the private key data and the other part is
   the certificate data.

   The format in which the private key data part is returned is
   dependent on whether the private key is being returned with
   additional encryption on top of that provided by TLS.

   If additional encryption is not being employed, the private key data
   MUST be placed in an "application/pkcs8".  An "application/pkcs8"
   part consists of the base64-encoded DER-encoded [X.690]
   PrivateKeyInfo with a Content-Transfer-Encoding of "base64"
   [RFC2045].

   If additional encryption is being employed, the private key is placed
   inside of a CMS SignedData.  The SignedData is signed by the party
   that generated the private key, which may or may not be the EST
   server or the EST CA.  The SignedData is further protected by placing
   it inside of a CMS EnvelopedData, as described in Section 4 of
   [RFC5958].  The following list shows how the EncryptedData is used,
   depending on the type of protection key specified by the client.

Top      Up      ToC       Page 34 
   o  If the client specified a symmetric encryption key to protect the
      server-generated private key, the EnvelopedData content is
      encrypted using the secret key identified in the request.  The
      EnvelopedData RecipientInfo field MUST indicate the key-encryption
      kekri key management technique.  The values are as follows:
      version is set to 4, key-encryption key identifier (kekid) is set
      to the value of the DecryptKeyIdentifier from Section 4.4.1.1;
      keyEncryptionAlgorithm is set to one of the key wrap algorithms
      that the client included in the SMIMECapabilities accompanying the
      request; and encryptedKey is the encrypted key.

   o  If the client specified an asymmetric encryption key suitable for
      key transport operations to protect the server-generated private
      key, the EnvelopedData content is encrypted using a randomly
      generated symmetric encryption key.  The cryptographic strength of
      the symmetric encryption key SHOULD be equivalent to the client-
      specified asymmetric key.  The EnvelopedData RecipientInfo field
      MUST indicate the KeyTransRecipientInfo (ktri) key management
      technique.  In KeyTransRecipientInfo, the RecipientIdentifier
      (rid) is either the subjectKeyIdentifier copied from the attribute
      defined in Section 4.4.1.2 or the server determines an associated
      issuerAndSerialNumber from the attribute; version is derived from
      the choice of rid [RFC5652], keyEncryptionAlgorithm is set to one
      of the key wrap algorithms that the client included in the
      SMIMECapabilities accompanying the request, and encryptedKey is
      the encrypted key.

   o  If the client specified an asymmetric encryption key suitable for
      key agreement operations to protect the server-generated private
      key, the EnvelopedData content is encrypted using a randomly
      generated symmetric encryption key.  The cryptographic strength of
      the symmetric encryption key SHOULD be equivalent to the client-
      specified asymmetric key.  The EnvelopedData RecipientInfo field
      MUST indicate the KeyAgreeRecipientInfo (kari) key management
      technique.  In the KeyAgreeRecipientInfo type, version,
      originator, and user keying material (ukm) are as in [RFC5652],
      and keyEncryptionAlgorithm is set to one of the key wrap
      algorithms that the client included in the SMIMECapabilities
      accompanying the request.  The recipient's key identifier is
      either copied from the attribute defined in Section 4.4.1.2 to
      subjectKeyIdentifier or the server determines an
      IssuerAndSerialNumber that corresponds to the value provided in
      the attribute.

   In all three additional encryption cases, the EnvelopedData is
   returned in the response as an "application/pkcs7-mime" part with an
   smime-type parameter of "server-generated-key" and a Content-
   Transfer-Encoding of "base64".

Top      Up      ToC       Page 35 
   The certificate data part is an "application/pkcs7-mime" and exactly
   matches the certificate response to /simpleenroll.

   When rejecting a request, the server MUST specify either an HTTP 4xx
   error or an HTTP 5xx error.  If the content-type is not set, the
   response data MUST be a plaintext human-readable error message.

4.5.  CSR Attributes

   CA policy may allow inclusion of client-provided attributes in
   certificates that it issues, and some of these attributes may
   describe information that is not available to the CA.  In addition, a
   CA may desire to certify a certain type of public key and a client
   may not have a priori knowledge of that fact.  Therefore, clients
   SHOULD request a list of expected attributes that are required, or
   desired, by the CA in an enrollment request or if dictated by local
   policy.

   The EST server SHOULD NOT require client authentication or
   authorization to reply to this request.

   Requesting CSR attributes is optional, but clients are advised that
   CAs may refuse enrollment requests that are not encoded according to
   the CA's policy.

4.5.1.  CSR Attributes Request

   The EST client requests a list of CA-desired CSR attributes from the
   CA by sending an HTTPS GET message to the EST server with an
   operations path of "/csrattrs".

4.5.2.  CSR Attributes Response

   If locally configured policy for an authenticated EST client
   indicates a CSR Attributes Response is to be provided, the server
   response MUST include an HTTP 200 response code.  An HTTP response
   code of 204 or 404 indicates that a CSR Attributes Response is not
   available.  Regardless of the response code, the EST server and CA
   MAY reject any subsequent enrollment requests for any reason, e.g.,
   incomplete CSR attributes in the request.

Top      Up      ToC       Page 36 
   Responses to attribute request messages MUST be encoded as the
   content-type of "application/csrattrs" with a
   Content-Transfer-Encoding of "base64" [RFC2045].  The syntax for
   application/csrattrs body is as follows:

   CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID

   AttrOrOID ::= CHOICE (oid OBJECT IDENTIFIER, attribute Attribute }

   Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
        type   ATTRIBUTE.&id({IOSet}),
        values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) }

   An EST server includes zero or more OIDs or attributes [RFC2986] that
   it requests the client to use in the certification request.  The
   client MUST ignore any OID or attribute it does not recognize.  When
   the server encodes CSR Attributes as an empty SEQUENCE, it means that
   the server has no specific additional information it desires in a
   client certification request (this is functionally equivalent to an
   HTTP response code of 204 or 404).

   If the CA requires a particular crypto system or use of a particular
   signature scheme (e.g., certification of a public key based on a
   certain elliptic curve, or signing using a certain hash algorithm) it
   MUST provide that information in the CSR Attribute Response.  If an
   EST server requires the linking of identity and POP information (see
   Section 3.5), it MUST include the challengePassword OID in the CSR
   Attributes Response.

   The structure of the CSR Attributes Response SHOULD, to the greatest
   extent possible, reflect the structure of the CSR it is requesting.
   Requests to use a particular signature scheme (e.g. using a
   particular hash function) are represented as an OID to be reflected
   in the SignatureAlgorithm of the CSR.  Requests to use a particular
   crypto system (e.g., certification of a public key based on a certain
   elliptic curve) are represented as an attribute, to be reflected as
   the AlgorithmIdentifier of the SubjectPublicKeyInfo, with a type
   indicating the algorithm and the values indicating the particular
   parameters specific to the algorithm.  Requests for descriptive
   information from the client are made by an attribute, to be
   represented as Attributes of the CSR, with a type indicating the
   [RFC2985] extensionRequest and the values indicating the particular
   attributes desired to be included in the resulting certificate's
   extensions.

   The sequence is Distinguished Encoding Rules (DER) encoded [X.690]
   and then base64 encoded (Section 4 of [RFC4648]).  The resulting text
   forms the application/csrattr body, without headers.

Top      Up      ToC       Page 37 
   For example, if a CA requests a client to submit a certification
   request containing the challengePassword (indicating that linking of
   identity and POP information is requested; see Section 3.5), an
   extensionRequest with the Media Access Control (MAC) address
   ([RFC2307]) of the client, and to use the secp384r1 elliptic curve
   and to sign with the SHA384 hash function.  Then, it takes the
   following:

         OID:        challengePassword (1.2.840.113549.1.9.7)

         Attribute:  type = extensionRequest (1.2.840.113549.1.9.14)
                     value = macAddress (1.3.6.1.1.1.1.22)

         Attribute:  type = id-ecPublicKey (1.2.840.10045.2.1)
                     value = secp384r1 (1.3.132.0.34)

         OID:        ecdsaWithSHA384 (1.2.840.10045.4.3.3)

   and encodes them into an ASN.1 SEQUENCE to produce:

       30 41 06 09 2a 86 48 86 f7 0d 01 09 07 30 12 06 07 2a 86 48 ce 3d
       02 01 31 07 06 05 2b 81 04 00 22 30 16 06 09 2a 86 48 86 f7 0d 01
       09 0e 31 09 06 07 2b 06 01 01 01 01 16 06 08 2a 86 48 ce 3d 04 03
       03

   and then base64 encodes the resulting ASN.1 SEQUENCE to produce:

       MEEGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMBYGCSqGSIb3DQEJDjEJ
       BgcrBgEBAQEWBggqhkjOPQQDAw==

5.  IANA Considerations

   Section 4.4.1.2 defines an OID that has been registered in an arc
   delegated by the IANA to the PKIX working group.

   IANA has registered the following:

   IANA updated the well-known URI registry with the following filled-in
   template from [RFC5785].

      URI suffix: est

      Change controller: IETF

Top      Up      ToC       Page 38 
   IANA has updated the "Application Media Types" registry with the
   following filled-in templates from [RFC6838].

   The media subtype for CSR attributes in a CSR Attributes Response is
   application/csrattrs.

       Type name: application

       Subtype name: csrattrs

       Required parameters: None

       Optional parameters: None

       Encoding considerations: binary;

       Security Considerations:

         Clients request a list of attributes that servers wish to be in
         certification requests.  The request/response is normally done
         in a TLS-protected tunnel.

       Interoperability considerations: None

       Published specification: This memo.

       Applications which use this media type: Enrollment over Secure
       Transport (EST)

       Additional information:

         Magic number(s): None

         File extension: .csrattrs

       Person & email address to contact for further information:

         Dan Harkins <dharkins@arubanetworks.com>

       Restrictions on usage: None

       Author: Dan Harkins <dharkins@arubanetworks.com>

       Intended usage: COMMON

       Change controller: The IESG <iesg@ietf.org>

Top      Up      ToC       Page 39 
   The application/pkcs7-mime content-type defines the optional
   "smime-type" parameter [RFC5751] with a set of specific values.  This
   document adds another value, "server-generated-key", as the parameter
   value for Server-side Key Generation Response.

6.  Security Considerations

   Support for Basic authentication, as specified in HTTP [RFC2617],
   allows the server access to a client's cleartext password.  This
   provides support for legacy username/password databases but requires
   exposing the plaintext password to the EST server.  Use of a PIN or
   one-time password can help mitigate such exposure, but it is
   RECOMMENDED that EST clients use such credentials only once to obtain
   a client certificate (that will be used during future interactions
   with the EST server).

   When a client uses the Implicit TA database for certificate
   validation (see Section 3), then authorization proceeds as specified
   in Section 3.6.2.  In this situation, the client has validated the
   server as being a responder that is certified by a third party for
   the URI configured, but it cannot verify that the responder is
   authorized to act as an RA for the PKI in which the client is trying
   to enroll.  Clients using an Implicit Trust Anchor database are
   RECOMMENDED to use only TLS-based client authentication (to prevent
   exposing HTTP-based client authentication information).  It is
   RECOMMENDED that such clients include "Linking Identity and POP
   Information" (Section 3.5) in requests (to prevent such requests from
   being forwarded to a real EST server by a man in the middle).  It is
   RECOMMENDED that the Implicit Trust Anchor database used for EST
   server authentication be carefully managed to reduce the chance of a
   third-party CA with poor certification practices from being trusted.
   Disabling the Implicit Trust Anchor database after successfully
   receiving the Distribution of CA certificates response
   (Section 4.1.3) limits any vulnerability to the first TLS exchange.

   Certificate-less TLS cipher suites that maintain security and perform
   the mutual authentication necessary for enrollment have the following
   properties:

   o  the only information leaked by an active attack is whether or not
      a single guess of the secret is correct.

   o  any advantage an adversary gains is through interaction and not
      computation.

   o  it is possible to perform countermeasures, such as exponential
      backoff after a certain number of failed attempts, to frustrate
      repeated active attacks.

Top      Up      ToC       Page 40 
   Using a certificate-less cipher suite that does not have the
   properties listed above would render the results of enrollment void
   and potentially result in certificates being issued to
   unauthenticated and/or unauthorized entities.

   When using a certificate-less TLS cipher suite, the shared secret
   used for authentication and authorization cannot be shared with an
   entity that is not a party to the exchange: someone other than the
   client and the server.  Any additional sharing of secrets voids the
   security afforded by a certificate-less cipher suite.  Exposure of a
   shared secret used by a certificate-less cipher suite to a third
   party enables client impersonation that can result in corruption of a
   client's trust anchor database.

   TLS cipher suites that include "_EXPORT_" and "_DES_" in their names
   MUST NOT be used.  These ciphers do not offer a sufficient level of
   protection; 40-bit crypto in 2013 doesn't offer acceptable
   protection, and the use of DES is deprecated.

   As described in CMC, Section 6.7 of [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 proof-of-possession
   to the TLS proof-of-identity by enforcing that the POP operation
   occurred while the TLS session was active.  This implies to the
   server that the authenticated client currently has access to the
   private key.  If the authenticated client is known to have specific
   capabilities, such as hardware protection for authentication
   credentials and key storage, this implication is strengthened but not
   proven.

   The server-side key generation method allows keys to be transported
   over the TLS connection to the client without any application-layer
   protection.  The distribution of private key material is inherently
   risky.  Private key distribution uses the encryption mode of the
   negotiated TLS cipher suite.  Keys are not protected by preferred key
   wrapping methods such as AES Key Wrap [RFC3394] or as specified in
   [RFC5958] as encryption of the private key beyond that provided by
   TLS is optional.  It is RECOMMENDED that EST servers not support this
   operation by default.  It is RECOMMENDED that clients not request
   this service unless there is a compelling operational benefit.  Use
   of an Implicit Trust Anchor database is NOT RECOMMENDED when
   server-side key generation is employed.  The use of an encrypted CMS
   Server-Side Key Generation Response is RECOMMENDED.

   Regarding the CSR attributes that the CA may list for inclusion in an
   enrollment request, there are no real inherent security issues with
   the content being conveyed, but an adversary who is able to interpose

Top      Up      ToC       Page 41 
   herself into the conversation could exclude attributes that a server
   may want, include attributes that a server may not want, and render
   meaningless other attributes that a server may want.

   ASN.1 encoding rules (e.g., DER and BER) have a type-length-value
   structure, and it is easy to construct malicious content with invalid
   length fields that can cause buffer overrun conditions.  ASN.1
   encoding rules allow for arbitrary levels of nesting, which may make
   it possible to construct malicious content that will cause a stack
   overflow.  Interpreters of ASN.1 structures should be aware of these
   issues and should take appropriate measures to guard against buffer
   overflows and stack overruns in particular, and malicious content in
   general.



(page 41 continued on part 4)

Next RFC Part