One document matched: draft-ietf-tls-multiple-cert-status-extension-01.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="no"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-tls-multiple-cert-status-extension-01"
     ipr="pre5378Trust200902">
  <front>
    <title abbrev="Multiple Certificate Status Extension">The TLS Multiple
    Certificate Status Request Extension</title>

    <author fullname="Yngve N. Pettersen" initials="Y." surname="Pettersen">
      <organization>Opera Software ASA</organization>

      <address>
        <email>yngve@opera.com</email>
      </address>
    </author>

    <date day="8" month="July" year="2012"/>

    <abstract>
      <t>This document defines the Transport Layer Security (TLS) Certificate
      Status Version 2 Extension to allow clients to specify and support
      multiple certificate status methods. Also defined is a new method that a
      server can use to provide status information (i.e., based on the Online
      Certificate Status Protocol and Server-Based Certificate Validation
      Protocol) not just about the server's own certificate, but also the
      status of intermediate certificates in the chain.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>The Transport Layer Security (TLS) Extension <xref target="RFC6066"/>
      framework defines, among other extensions, the Certificate Status
      Extension that clients can use to request the server's copy of the
      current status of its certificate. The benefits of this extension
      include a reduced number of roundtrips and network delays for the client
      to verify the status of the server's certificate and a reduced load on
      the certificate issuer's status response servers, thus solving a problem
      that can become significant when the issued certificate is presented by
      a frequently visited server.</t>

      <t>There are two problems with the existing Certificate Status
      extension. First, it does not provide functionality to request the
      status information about intermediate Certification Authority (CA)
      certificates, which means the client has to request status information
      through other methods, such as Certificate Revocation Lists (CRLs), thus
      adding additional delay. Second, the current format of the extension and
      requirements in the TLS protocol prevents a client from offering the
      server multiple status methods; there are two methods available, the
      Online Certificate Status Protocol (OCSP) <xref target="RFC2560"/> and
      the Server-Based Certificate Validation Protocol (SCVP) <xref
      target="RFC5055"/>.</t>

      <t>Many CAs now issue intermediate CA certificates that not only specify
      the publication point for their CRLs in CRL Distribution Point <xref
      target="RFC5280"/>, but also specify a URL for their OCSP <xref
      target="RFC2560"/> server in Authority Information Access <xref
      target="RFC5280"/>. Given that client-cached CRLs are frequently out of
      date, clients would benefit from using OCSP, or other protocols, to
      access up-to-date status information about intermediate CA certificates.
      The benefit to the issuing CA is less clear, as providing the bandwidth
      for the OCSP responder can be costly, especially for CAs with many
      high-traffic subscriber sites, and this cost is a concern for many CAs.
      There are cases where OCSP requests for a single high-traffic site
      caused significant network problems for the issuing CA.</t>

      <t>Clients will benefit from the TLS server providing certificate status
      information regardless of type, not just for the server certificate, but
      also for the intermediate CA certificates. Combining the status checks
      into one extension will reduce the roundtrips needed to complete the
      handshake by the client to just those needed for negotiating the TLS
      connection. Also, for the Certification Authorities, the load on their
      servers will depend on the number of certificates they have issued, not
      on the number of visitors to those sites.</t>

      <t>For such a new system to be introduced seamlessly, clients need to be
      able to indicate support for the existing OCSP Certificate Status method
      and a new multiple-OCSP mode or the new SCVP mode.</t>

      <t>Unfortunately, the definition of the Certificate Status extension
      only allows a single Certificate Status extension to be defined in a
      single extension record in the handshake, and the TLS Protocol <xref
      target="RFC5246"/> only allows a single record in the extension list for
      any given extension. This means that it is not possible for clients to
      indicate support for new methods while still supporting older methods,
      which would cause problems for interoperability between newer clients
      and older servers. This will not just be an issue for the multiple
      status request mode proposed above, but also for any other future status
      methods that might be introduced. This will be true not just for the
      current PKIX infrastructure <xref target="RFC5280"/>, but also for
      alternative PKI structures.</t>

      <t>The solution to this problem is to define a new extension,
      status_request_v2, with an extended format that allows the client to
      indicate support for multiple status request methods. This is
      implemented using a list of CertificateStatusRequestItem records in the
      extension record. As the server will select the single status method
      based on the selected cipher suite and the certificate presented, no
      significant changes are needed in the server's extension format.</t>

      <section title="Requirements Language">
        <t>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 <xref
        target="RFC2119">RFC 2119</xref>.</t>
      </section>
    </section>

    <section title="Multiple Certificate Status Extension">
      <t/>

      <section anchor="NewExtension" title="New extension">
        <t>The extension defined by this document is indicated by the
        "status_request_v2" in the ExtensionType enum, which uses the
        following value:</t>

        <figure>
          <artwork><![CDATA[
  enum {
    status_request_v2(XX), (65535)
  } ExtensionType;]]></artwork>
        </figure>

        <t>[[ EDITOR: The value used for status_request_v2 has been left as
        "XX". This value will be assigned when this draft progresses to
        RFC.]]</t>

        <t/>
      </section>

      <section anchor="MultiRecord"
               title="Multiple Certificate Status Request record">
        <t>Clients that support a certificate status protocol (i.e., OCSP and
        SCVP) may send the status_request_v2 extension to the server in order
        to use the TLS handshake to transfer such data instead of downloading
        it through separate connections. When using this extension, the
        "extension_data" field of the extension SHALL contain a
        CertificateStatusRequestList where:</t>

        <figure>
          <artwork><![CDATA[ 
  struct {
    CertificateStatusType status_type;
    uint16 request_length; /* Length of request field in bytes */
    select (status_type) {
      case ocsp: OCSPStatusRequest;
      case ocsp_multi: OCSPStatusRequest;
      case scvp: SCVPStatusRequest;
    } request;
  } CertificateStatusRequestItem;

  enum { 
      ocsp(1), ocsp_multi(YY), scvp (AA),(255) 
    } CertificateStatusType;

  struct {
    ResponderID responder_id_list<0..2^16-1>;
    Extensions request_extensions;
  } OCSPStatusRequest;

  struct {
    ResponderID responder_id_list<0..2^16-1>;
    Extensions request_extensions;
  } SCVPStatusRequest;

  opaque ResponderID<1..2^16-1>;
  opaque Extensions<0..2^16-1>;

  struct {
    CertificateStatusRequestItem certificate_status_req_list<1..2^16-1>
  } CertificateStatusRequestList

]]></artwork>
        </figure>

        <t>[[ EDITOR: The values used for ocsp_multi and scvp have been left
        as "YY" and "AA", respectively. These values will be assigned when
        this draft progresses to RFC.]]</t>

        <t>In the OCSPStatusRequest and SCVPStatusRequest structures, the
        "ResponderIDs" provide a list of OCSP and SCVP responders
        (respectively) that the client trusts. A zero-length
        "responder_id_list" sequence has the special meaning that the
        responders are implicitly known to the server, e.g., by prior
        arrangement, or are identfied by the certificates used by the server.
        "Extensions" is a DER encoding <xref target="CCITT.X690.2002"/> of the
        OCSP and SCVP request extensions (respectively).</t>

        <t>Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as
        defined in <xref target="RFC2560"/> (for OCSP) and <xref
        target="RFC5055"/> (for SCVP). "Extensions" is imported from <xref
        target="RFC5280"/>. A zero-length "request_extensions" value means
        that there are no extensions (as opposed to a zero-length ASN.1
        SEQUENCE, which is not valid for the "Extensions" type).</t>

        <t>In the case of the "id-pkix-ocsp-nonce" OCSP extension, <xref
        target="RFC2560"/> is unclear about its encoding; for clarification,
        the nonce MUST be a DER-encoded OCTET STRING, which is encapsulated as
        another OCTET STRING (note that implementations based on an existing
        OCSP client will need to be checked for conformance to this
        requirement).</t>

        <t>The list of CertificateStatusRequestItem entries MUST be in order
        of preference.</t>

        <t>A server that receive a client hello containing the
        "status_request_v2" extension MAY return a suitable certificate status
        response message to the client along with the server's certificate
        message. If OCSP is requested, it SHOULD use the information contained
        in the extension when selecting an OCSP responder and SHOULD include
        request_extensions in the OCSP request.</t>

        <t>The server returns a certificate status response along with its
        certificate by sending a "CertificateStatus" message immediately after
        the "Certificate" message (and before any "ServerKeyExchange" or
        "CertificateRequest" messages). If a server returns a
        "CertificateStatus" message in response to a status_request_v2
        request, then the server MUST have included an extension of type
        "status_request_v2" with empty "extension_data" in the extended server
        hello. The "CertificateStatus" message is conveyed using the handshake
        message type "certificate_status" as follows (see also <xref
        target="RFC6066"/>):</t>

        <figure>
          <artwork><![CDATA[
  struct {
    CertificateStatusType status_type;
    select (status_type) {
      case ocsp: OCSPResponse;
      case ocsp_multi: OCSPResponseList;
      case scvp: SCVPResponse;
    } response;
  } CertificateStatus;

  opaque OCSPResponse<0..2^24-1>;

  opaque SCVPResponse<0..2^24-1>;

  struct {
    OCSPResponse ocsp_response_list<1..2^24-1>
  } OCSPResponseList

]]></artwork>
        </figure>

        <t>An "OCSPResponse" element contains a complete, DER-encoded OCSP
        response (using the ASN.1 syntax <xref target="CCITT.X680.2002"/> of
        type OCSPResponse as defined in <xref target="RFC2560"/>). Only one
        OCSP response, with a length of at least one byte, may be sent for
        status_type "ocsp".</t>

        <t>An "SCVPResponse" element contains a complete, DER-encoded SCVP
        response (using the ASN.1 syntax <xref target="CCITT.X680.2002"/> of
        type CVResponse as defined in <xref target="RFC5055"/>). Only one SCVP
        response, with a length of at least one byte, may be sent for
        status_type "scvp". An SCVP response can include the status of
        intermediate certificates.</t>

        <t>An "ocsp_response_list" contains a list of "OCSPResponse" elements,
        as specified above, each containing the OCSP response for the matching
        corresponding certificate in the server's Certificate TLS handshake
        message. That is, the first entry is the OCSP response for the first
        certificate in the Certificate list, the second entry is the response
        for the second certificate, and so on. The list MAY contain fewer OCSP
        responses than there were certificates in the Certificate handshake
        message, but there MUST NOT be more responses than there were
        certificates in the list. Individual elements of the list MAY have a
        length of 0 (zero) bytes, if the server does not have the OCSP
        response for that particular certificate stored, in which case, the
        client MUST act as if a response was not received for that particular
        certificate. If the client receives a "ocsp_response_list" that does
        not contain a response for one or more of the certificates in the
        completed certificate chain, the client SHOULD attempt to validate the
        certificate using an alternative retrieval method, such as downloading
        the relevant CRL; OCSP SHOULD in this situation only be used for the
        end entity certificate, not intermediate CA certificates, for reasons
        stated above.</t>

        <t>Note that a server MAY also choose not to send a
        "CertificateStatus" message, even if it has received a
        "status_request_v2" extension in the client hello message and has sent
        a "status_request_v2" extension in the server hello message.
        Additionally, note that that a server MUST NOT send the
        "CertificateStatus" message unless it received either a
        "status_request" or "status_request_v2" extension in the client hello
        message and sent a corresponding "status_request" or
        "status_request_v2" extension in the server hello message.</t>

        <t>Clients requesting a certificate response and receiving either one
        or more OCSP responses or a SCVP response in a "CertificateStatus"
        message MUST check the response(s) and abort the handshake, if the
        response is a revoked status or is otherwise not satisfactory with a
        bad_certificate_status_response(113) alert. This alert is always
        fatal.</t>

        <t>[[Open issue: At least one reviewer has suggested that the client
        should treat an unsatisfactory (non-revoked) response as an empty
        response for that particular response and fall back to the alternative
        method described above]]</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t><xref target="NewExtension"/> defines the new TLS Extension
      status_request_v2 enum, which should be added to the ExtensionType
      Values list in the IANA TLS category after IETF Concensus has decided to
      add the value.</t>

      <t><xref target="MultiRecord"/> describes a TLS CertificateStatusType
      Registry to be maintained by the IANA. CertificateStatusType values are
      to be assigned via IETF Review as defined in <xref target="RFC5226"/>.
      The initial registry corresponds to the definition of "ExtensionType" in
      <xref target="MultiRecord"/>.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>General Security Considerations for TLS Extensions are covered in
      <xref target="RFC5246"/>. Security Considerations for the particular
      extension specified in this document are given below. In general,
      implementers should continue to monitor the state of the art and address
      any weaknesses identified.</t>

      <section title="Security Considerations for status_request_v2">
        <t>If a client requests an OCSP or SCVP response, it must take into
        account that an attacker's server using a compromised key could (and
        probably would) pretend not to support the extension. In this case, a
        client that requires OCSP or SCVP validation of certificates SHOULD
        either contact the OCSP or SCVP server directly or abort the
        handshake.</t>

        <t>Use of the OCSP (id-pkix-ocsp-nonce) or SCVP nonce request
        extension may improve security against attacks that attempt to replay
        OCSP or SCVP responses; see Section 4.4.1 of <xref target="RFC2560"/>
        and Section 9 of <xref target="RFC5055"/> for further details.</t>

        <t>The security considerations of <xref target="RFC2560"/> apply to
        OCSP requests and responses, and the security considerations of <xref
        target="RFC5055"/> apply to SCVP erquests and responses.</t>
      </section>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>This document is based on <xref target="RFC6066"/> authored by Donald
      Eastlake 3rd.</t>

      <t>The SCVP status type description is based on text provided by Sean
      Turner.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include='reference.RFC.5055'?>

      <?rfc include="reference.RFC.2560"?>

      <?rfc include="reference.RFC.5226"?>

      <?rfc include="reference.RFC.5246"?>

      <?rfc include="reference.RFC.5280"?>

      <?rfc include="reference.RFC.6066"?>

      <?rfc include='reference.CCITT.X680.2002'?>

      <?rfc include='reference.CCITT.X690.2002'?>
    </references>
  </back>
</rfc>