TLS                                                            R. Segers
Internet-Draft                           Federal Aviation Administration
Intended status: Standards Track                               A. Kopman
Expires: 30 December 2022                                Concepts Beyond
                                                            28 June 2022


      Transport Layer Security (TLS) Extension: Validation Request
                draft-segers-tls-cert-validation-ext-02

Abstract

   This document describes the Path Validation extension to the
   Transport Layer Security (TLS) and Datagram Transport Layer Security
   (DTLS) protocols.

   The Path Validation Extension provides a new protocol for TLS/DTLS
   allowing inclusion of certificate path validation information in the
   TLS/DTLS handshake.

Status of This Memo

   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 https://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 30 December 2022.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.










Segers & Kopman         Expires 30 December 2022                [Page 1]


Internet-Draft        Validation Request Extension             June 2022


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Validation Request Extension  . . . . . . . . . . . . . . . .   4
   3.  Path Validation Request . . . . . . . . . . . . . . . . . . .   5
     3.1.  SCVP Validation Request . . . . . . . . . . . . . . . . .   6
       3.1.1.  Responder URIs  . . . . . . . . . . . . . . . . . . .   6
       3.1.2.  Trust Anchors . . . . . . . . . . . . . . . . . . . .   6
       3.1.3.  Validation Extensions . . . . . . . . . . . . . . . .   7
       3.1.4.  TLS Server CVRequest  . . . . . . . . . . . . . . . .   7
   4.  Path Validation Response  . . . . . . . . . . . . . . . . . .  12
     4.1.  SCVP Validation Response  . . . . . . . . . . . . . . . .  12
       4.1.1.  SCVP Response Processing by TLS Server  . . . . . . .  13
       4.1.2.  SCVP Response Processing by TLS Client  . . . . . . .  14
     4.2.  Path Validation Cache . . . . . . . . . . . . . . . . . .  14
   5.  Error Alerts  . . . . . . . . . . . . . . . . . . . . . . . .  15
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
     6.1.  Reference for TLS Alerts and ExtensionTypes . . . . . . .  15
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
     7.1.  Support for Extension . . . . . . . . . . . . . . . . . .  16
     7.2.  Replay Attacks  . . . . . . . . . . . . . . . . . . . . .  16
     7.3.  Extension Modifications . . . . . . . . . . . . . . . . .  16
     7.4.  Unrelated Path Validation Response  . . . . . . . . . . .  17
     7.5.  Trust Anchor Maintenance  . . . . . . . . . . . . . . . .  17
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1.  Introduction

   This document describes an extension to TLS 1.3 [RFC8446] and DTLS
   1.3 [RFC9147] for the inclusion of certificate path validation
   information in the TLS/DTLS handshake.  Specifically, this extension
   covers the use of the Server-based Certificate Validation Protocol
   (SCVP) [RFC5055] for path validation.  However, the extension is
   designed to allow for expansion to other path validation protocols.





Segers & Kopman         Expires 30 December 2022                [Page 2]


Internet-Draft        Validation Request Extension             June 2022


   This extension is defined for TLS and DTLS protocols.  For
   convenience, the protocol will be referred to as TLS for the rest of
   the document.  DTLS will only be specifically mentioned in cases
   where the protocols differ.

   The TLS standard specifies that certificates should always be
   verified to ensure proper signing by a trusted Certificate Authority
   (CA) in Part Appendix C.2 of TLS 1.3 [RFC8446].  The establishment of
   trust requires construction and validation of a trust path from the
   end-entity certificate to a trust anchor.  This validation can be a
   complex process of chaining certificates, validating revocation
   information, and enforcing organizational policies.  Therefore,
   constrained clients may wish to delegate certificate path
   construction and validation to a trusted server.  Additionally, to
   ensure that policies are consistently enforced throughout an
   ecosystem, centralization of certificate validation may be needed.
   Protocols such as Server-based Certificate Validation Protocol (SCVP)
   allow simplification of client implementations and consistent
   application of validation policies by delegating validation to a
   server.

   The extension described here allows a TLS client to request that the
   TLS server return the certificate path validation corresponding to
   its certificate.  If the server supports this extension, it performs
   the appropriate certificate validation queries and returns it to the
   client.  The server returns the path validation as an extension to
   the Certificate message.  Since path building and validation has been
   performed, the server can return only the end-entity certificate to
   be used for authentication, and does not need to return any
   supporting certificates in the chain.  This further reduces the
   bandwidth consumption.  The server can use a previously cached
   validation response, but it will need to retrieve it periodically as
   described in Section 4.2.  The client then examines the returned
   validation response and the response signature using a local trust
   anchor.

   TLS clients and servers MAY use the extension described in this
   document.  The extension is designed to be backwards compatible,
   meaning that TLS clients that support the extension can talk to TLS
   servers that do not support the extension, and vice versa.

1.1.  Requirements Language

   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 RFC 2119 [RFC2119].





Segers & Kopman         Expires 30 December 2022                [Page 3]


Internet-Draft        Validation Request Extension             June 2022


2.  Validation Request Extension

   A new extension type (validation_request (TBD)) is added to the
   extensions used in the client hello and certificate handshake
   messages.  The extension type is specified as follows.

   enum {
        validation_request(TBD), (65535)
   } ExtensionType;

   To indicate their desire to receive certificate path validation
   information, TLS clients MAY include an extension of type
   validation_request in the (extended) client hello.  The
   extension_data field of the validation_request extension MUST contain
   a PathValidationRequest.  The PathValidationRequest MUST consist of a
   PathValidationType and Request as defined in Section 3.

   Servers that receive a client hello containing the validation_request
   extension MAY return a suitable certificate path validation response
   to the client along with their certificate.

   Servers return a certificate path validation response along with
   their certificate by adding the validation_request extension to the
   extension block of the TLS server certificate.  The Certificate
   message containing the TLS server end-entity certificate SHOULD
   contain the extension with extension_type validation_request and
   extension_data of PathValidation.  Severs that send the
   PathValidation extension data MUST have received a validation_request
   in the extended client hello.

   Servers that send the PathValidation extension SHOULD only include
   the end-entity authentication certificate in the Certificate message.
   The server MAY include supporting certificates.  The client MAY
   ignore supporting certificates if the PathValidation is found to be
   satisfactory.

   Clients that receive a PathValidation extension without sending a
   validation_request extension MUST abort the connection.

   Servers that do not support (or are not configured to enable the use
   of) this extension SHOULD NOT include the validation_request
   extension in the Certificate message.

   A server MAY also choose not to send a PathValidation extension, even
   if has received a validation_request extension in the client hello
   message.





Segers & Kopman         Expires 30 December 2022                [Page 4]


Internet-Draft        Validation Request Extension             June 2022


   If the client sent a validation_request in the client hello extension
   but did not receive a validation_request extension in the server
   Certificate message MAY choose to use alternative means to validate
   the server certificate or MAY choose to abort the connection.

   Clients requesting a certificate path validation and receiving
   validation_request Certificate extension MUST check the
   PathValidation message and abort the handshake if the response is not
   satisfactory with bad_certificate_validation_response (TBD) alert.
   This alert is always fatal.

   The PathValidationRequest and PathValidation types are further
   defined in Section 3 and Section 4 of this document.

3.  Path Validation Request

   Deployment of Public Key Infrastructure (PKI) enabled applications
   can be simplified by delegating path validation processing to a
   server.  Additionally, for organizations wishing to centralize
   administration of validation policies, delegation to a server ensures
   consistent policy validation across clients in an ecosystem.

   Constrained clients wishing to delegate path validation also face
   challenges such as bandwidth and latency limitations.  This extension
   allows for such information to be sent in the TLS handshake, saving
   roundtrips and resources.

   To indicate their desire to receive certificate validation
   information, TLS clients MAY include an extension of type
   validation_request in the extended client hello.  ClientHello
   handshake messages containing the validation_request extension SHALL
   contain a PathValidationRequest in the extension_data field of this
   extension.  The PathValidationRequest is defined as follows:

   struct {
        PathValidationType path_validation_type;
        select (path_validation_type) {
             case scvp: SCVPValidationRequest;
        } request;
   } PathValidationRequest;

   enum { scvp(1), (255) } PathValidationType;

   The PathValidationRequest is defined for type Server-based
   Certificate Validation Protocol (SCVP) however is designed to be
   extendable to other protocols.





Segers & Kopman         Expires 30 December 2022                [Page 5]


Internet-Draft        Validation Request Extension             June 2022


3.1.  SCVP Validation Request

   SCVP provides a standards-based client-server protocol for delegated
   path validation defined in RFC 5055 [RFC5055].  Clients wishing to
   request the use of SCVP path validation MAY include the
   path_validation extension in the client hello handshake with the
   PathValidationType of scvp (1) in the PathValidationRequest.  If the
   PathValidationType is set to scvp, the Request SHALL be an
   SCVPValidationRequest.

   The SCVPValidationRequest consists of three optional lists: a list of
   SCVP responder URIs, a list of trust anchors, and a list of
   validation extensions.

   struct {
        ResponderURIs responder_uri_list<0..2^16-1>;
        TrustAnchors trust_anchor_list<0..2^16-1>;
        ValidationExtensions validation_extensions_list<0..2^16-1>;
   } SCVPValidationRequest;

3.1.1.  Responder URIs

   The ResponderURIs provides a list of SCVP responders that the client
   trusts.  A zero-length responder_uri_list sequence has special
   meaning that the responders are implicitly known to the server, e.g.
   by prior arrangement.  The ResponderURIs list is in the client's
   preferred order.  The TLS server SHOULD process the responder URI
   list in order and return a response from the first reachable URI with
   an acceptable response.  What constitutes an acceptable response is
   discussed in Section 4.1.1.  The ResponderURIs list is represented as
   a DER encoded SEQUENCE OF ASN.1 IA5String objects.

3.1.2.  Trust Anchors

   Zero or more trust anchors MAY be provided in the
   SCVPValidationRequest to specify the trust anchors at which the
   certification path must terminate if the path is to be considered
   valid.  The TrustAnchors type is an ASN.1 SEQUENCE OF PKCReference.
   The SCVP Server usage is defined in Section 3.2.4.7 of RFC 5055
   [RFC5055].  If a TLS server receives a SCVPValidationRequest which
   contains TrustAnchors it SHOULD include the TrustAnchors in the SCVP
   Request Validation Policy.  A non-zero length TrustAnchors sequence
   combined with a zero length Responder URI sequence indicates that the
   TLS client wishes to use the TLS server's default SCVP Responder to
   construct a certification path which terminates at a specified
   certificate.  If a non-zero length TrustAnchors is provided and the
   TLS Client includes the validation_policy validation extension as
   defined in Section 3.1.3, the ValidationPolicy TrustAnchors MUST be



Segers & Kopman         Expires 30 December 2022                [Page 6]


Internet-Draft        Validation Request Extension             June 2022


   equivalent to the SCVPValidationRequest TrustAnchors.

   As defined in RFC 5055, the trust anchor PKCReference MAY be either
   an SCVPCertID or a Certificate.  To minimize the size of the
   SCVPValidationRequest, TrustAnchors SHOULD be included by SCVPCertID.

3.1.3.  Validation Extensions

   This document defines nine optional ValidationExtensionTypes.  These
   validation extensions allow the client to specify values in the CV
   Request as described in Section 3.1.4.  Inclusion of the validation
   extensions will increase the size of the request and response.
   Therefore, the extensions should be included only when necessary.

   The validation_extension_data values are DER-encoded ASN.1 types that
   can be directly mapped to the SCVP CVRequest as defined by RFC 5055
   [RFC5055].

   struct {
        ValidationExtensionType validation_extension_type;
        select (validation_extension_type {
             case want_back: WantBack;
             case validation_policy: ValidationPolicy;
             case cached_response: BOOLEAN;
             case query_extensions: Extensions;
             case request_nonce: OCTET STRING;
             case request_extensions: Extensions;
             case signature_algorithm: AlgorithmIdentifier;
             case hash_algorithm: OBJECT IDENTIFIER;
             case requestor_text: UTF8String (SIZE (1..256));
        } validation_extension_data;
   } ValidationExtension

3.1.4.  TLS Server CVRequest

   Servers that receive a client hello containing the validation_request
   extension MAY return a suitable path validation response to the
   client along with their certificate.  If SCVP is requested, the TLS
   Server SHOULD use the information contained in the extension when
   selecting an SCVP responder and Trust Anchor.  The TLS server SHOULD
   map the validation extension types to the SCVP request as follows.










Segers & Kopman         Expires 30 December 2022                [Page 7]


Internet-Draft        Validation Request Extension             June 2022


   want_back : CVRequest.query.wantBack
   validation_policy : CVRequest.query.validationPolicy
   cached_response : CVRequest.query.responseFlags.cachedResponse
   query_extensions : CVRequest.query.queryExtensions
   request_nonce : CVRequest.requestNonce
   request_extensions : CVRequest.requestExtensions
   signature_algorithm : CVRequest.signatureAlgorithm
   hash_algorithm : CVRequest.hashAlgorithm
   requestor_text : CVRequest.requestorText

   Conforming TLS Servers MUST construct a CVRequest with a
   cvRequestVersion and query.

3.1.4.1.  cvRequestVersion

   TLS Servers conforming to RFC 5055 [RFC5055] MUST set the value of
   the cvRequestVersion item to one (1).

3.1.4.2.  Query

   The query item is defined in Section 3.2 of RFC 5055 [RFC5055]

   TLS Servers conforming to RFC 5055 [RFC5055] SHALL include the query
   item.  For processing the TLS Validation Request the TLS server SHALL
   include the queriedCerts, certChecks and validationPolicy fields, MAY
   include wantBack, responseFlags, intermediateCerts, revInfos, and
   queryExtension fields, SHOULD NOT include producedAt and
   serverContextInfo fields, and MUST NOT include the validationTime
   field.

   The TLS Server MUST populate the CertReferences item.  The
   CertReferences sequence MUST be of length one and specify the
   server's X.509v3 TLS Certificate.  This certificate MUST correspond
   to the TLS Certificate sent by the TLS server to the TLS client in
   the Certificate handshake message.

   The TLS server MUST populate the CertChecks item.  The item MUST be
   set to id-stc-build-status-checked-pkc-path (id-stc 3).

   The TLS Server SHOULD NOT include want back unless specified by the
   TLS Client in the validation extension want_back item.  If the TLS
   Server receives a SCVPValidationRequest with a want_back validation
   extension, the TLS Server MAY set the wantBack item in the CVRequest
   to the value of the want_back.  Want backs can significantly increase
   the size of the CVResponse and should be used only when specifically
   required.





Segers & Kopman         Expires 30 December 2022                [Page 8]


Internet-Draft        Validation Request Extension             June 2022


   The TLS Server MUST include the ValidationPolicy item in the
   CVRequest query item as follows:

   If the TLS Client specified a validation_policy in the validation
   extensions:

   *  The TLS Server SHOULD include that ValidationPolicy in the
      CVRequest.

   If the TLS Client did not specify a validation_policy

   *  If the ResponderURIs is a zero-length list, indicating that the
      TLS server should query a pre-configured SCVP responder, the TLS
      Server SHOULD set the ValidationPolicy validationPolRef to either
      a pre-configured ValidationPolicy or the default validation policy
      OID id-svp-defaultValPolicy (id-svp 1).

   *  If the ResponderURIs is a non-zero-length list, indicating that
      the TLS server should query a client specified SCVP responder, the
      TLS Server SHOULD set the ValidationPolicy validationPolRef item
      to the default validation policy OID id-svp-defaultValPolicy (id-
      svp 1).

   *  If the TrustAnchors is a non-zero length list the TLS Server MUST
      include the TLS Client provided TrustAnchors in the
      ValidationPolicy TrustAnchors.

   The TLS Server MAY only include the ResponseFlags item in the
   CVRequest if requesting non-default values.  If default values are
   used for all flags, the responseFlags item MUST NOT be included in
   the request.  To enable to TLS client to trust the CVResponse, the
   TLS Server MUST use the default value for the protectResponse flag
   (TRUE).  To minimize the size of the CVResponse, the TLS Server
   SHOULD use the default values for the response flags
   fullRequestInResponse (FALSE) and responseValidationPolicyByRef
   (TRUE).  If the TLS Client included the cached_response validation
   extension with a value of FALSE, the TLS Server SHOULD NOT use its
   cache as described in Section 4.1.2 and MAY include the
   cachedResponse set to FALSE in the CVRequest responseFlags item.  If
   the TLS Server sets the cachedResponse flag to FALSE the
   request_nonce MUST be set.  If the TLS Server received the
   request_nonce validation extension, the requestNonce in the CVRequest
   MAY be set to the value of the request_nonce extension.  Otherwise,
   the TLS Server MUST generate and set a requestNonce in the CVRequest.

   The TLS Server SHOULD NOT include the serverContextInfo item in the
   CVRequest.




Segers & Kopman         Expires 30 December 2022                [Page 9]


Internet-Draft        Validation Request Extension             June 2022


   The TLS Server MUST NOT include the validationTime item in the
   CVRequest.

   The TLS Server MAY include the intermediateCerts item in the CVRequst
   to help the SCVP server create a valid certification path as defined
   in Section 3.2.8 of RFC 5055 [RFC5055].

   The TLS Server MAY include the revInfos item in the CV Request which
   MAY be used by the SCVP Server when validating certification paths as
   defined in Section 3.2.9 of RFC 5055 [RFC5055].

   The TLS Server SHOULD NOT include the producedAt item in the
   CVRequest.

   The TLS Server MAY include the queryExtensions item in the CVRequest
   to extend the query.  If the TLS Server receives a
   SCVPValidationRequest with a query_extensions validation extension,
   the TLS Server MAY set the queryExtensions item in the CVRequest to
   the value of the query_extension.

3.1.4.3.  requestorRef

   The TLS Server SHOULD NOT set the requestorRef item in the CVRequest.

3.1.4.4.  requestNonce

   The TLS Server MAY include the requestNonce item in the CVRequest to
   indicate a preference for a non-cached response.  If the TLS Server
   receives a SCVPValidationRequest with a request_nonce validation
   extension, the TLS Server MAY set the requestNonce item in the
   CVRequest to the value of the request_nonce validation extension.  If
   the TLS Server sets the cachedResponse response flag to FALSE but did
   not receive the request_nonce validation extension the TLS Server
   MUST generate and set a requestNonce in the CVRequest.

3.1.4.5.  requestorName

   The TLS Server SHOULD NOT include the requestorName item in the
   CVRequest.

3.1.4.6.  responderName

   The TLS Server SHOULD NOT include the responderName item in the
   CVRequest.







Segers & Kopman         Expires 30 December 2022               [Page 10]


Internet-Draft        Validation Request Extension             June 2022


3.1.4.7.  requestExtensions

   The TLS Server MAY include the requestExtensions item in the
   CVRequest to extend the request.  If the TLS Server receives a
   SCVPValidationRequest with a request_extensions validation extension,
   the TLS Server MAY set the requestExtensions item in the CVRequest to
   the value of the request_extension.

3.1.4.8.  signatureAlgorithm

   The TLS Server SHOULD NOT include the signatureAlgorithm item in the
   CVRequest unless specified by the TLS Client in the
   signature_algorithm validation extension.  If the TLS Server receives
   a SCVPValidationRequest with a signature_algorithm validation
   extension, the TLS server MAY set the signatureAlgorithm item in the
   CVRequest to the value of the signature_algorithm.

   To keep the size of the request and response small, it is recommended
   that community define the signature algorithm rather than using the
   signature_algorithm extension.

3.1.4.9.  hashAlgorithm

   The TLS Server SHOULD NOT include the hashAlgorithm item in the
   CVRequest unless specified by the TLS Client in the hash_algorithm
   validation extension.  If the TLS Server receives a
   SCVPValidationRequest with a hash_algorithm validation extension, the
   TLS Server MAY set the hashAlgorithm item in the CVRequest to the
   value of the hash_algorithm.

   To keep the size of the request and response small, it is recommended
   that community define the hash algorithm rather than using the
   hash_algorithm extension.

3.1.4.10.  requestorText

   The TLS Server SHOULD NOT include the requestorText item in the
   CVRequest unless specified by the TLS Client in the requestor_text
   validation extension.  If the TLS Server receives a
   SCVPValidationRequest with a requestor_text validation extension, the
   TLS Server MAY set the requestorText item in the CVRequest to the
   value of the requestor_text.

   To keep the size of the request and response small, it is recommended
   that the requestor text be used only for debugging purposes.






Segers & Kopman         Expires 30 December 2022               [Page 11]


Internet-Draft        Validation Request Extension             June 2022


4.  Path Validation Response

   Servers that receive a client hello containing the validation_request
   extension MAY return a suitable path validation response to the
   client along with their certificate by sending a PathValidation as an
   extension to the Certificate message.  Like the
   PathValidationRequest, the ValidationResponse is defined for type
   Server-Based Certificate Validation Protocol (SCVP) however is
   designed to be extendable to other protocols.

   The PathValidation response is defined as follows:

   struct {
        PathValidationType path_validation_type;
        select (path_validation_type) {
             case scvp: SCVPResponse;
        } response;
   } PathValidation;

   enum { scvp(1), (255) } PathValidationType;

   TLS Servers send the PathValidation response to the client in the
   extension_data of the validation_request extension to the TLS server
   end-entity certificate in the Certificate message.  The
   PathValidation data conveys whether the certificate path was
   successfully built and validated.  Therefore, in most cases, it is
   unnecessary for the TLS server to include supporting certificates in
   the Certificates message.

4.1.  SCVP Validation Response

   If a TLS server returns a PathValidation message in response to a
   PathValidationRequest of type scvp, that PathValidation message MUST
   be of type scvp and contain a SCVPResponse as follows.

   struct {
     opaque signed_cv_response
     ValidationExtensions validation_extensions_list<0..2^16-1>;
   } SCVPResponse;

   A signed_cv_response contains a complete, DER-encoded CMS SignedData
   object as defined in RFC 5652 [RFC5652] with an EncapsulatedContent
   of type CVResponse as defined in RFC 5055 [RFC5055].  Only one SCVP
   response may be sent.

   The TLS Server SHOULD include the list of validation extensions from
   the SCVPValidationRequest that were used in the CVRequest to indicate
   to the TLS Client which validation extensions were honored.  If the



Segers & Kopman         Expires 30 December 2022               [Page 12]


Internet-Draft        Validation Request Extension             June 2022


   TLS Server did not use a validation extension in the CVRequest, it
   MUST NOT be included in the SCVPResponse.  The SCVPResponse MUST NOT
   include validation extensions that were not present in the
   SCVPValidationRequest.

   Section 9 of RFC 5055 [RFC5055] asserts that clients MUST verify that
   the response matches their original request and outlines the steps
   necessary to perform this verification.  For this extension, the
   client responsibility of divided between the TLS server and the TLS
   client.  Certain values are only known by the TLS server whereas
   other values require verification at the final end-point, the TLS
   client.  The following two sections specify the verification of the
   SCVP response at the TLS server Section 4.1.1 and at the TLS client
   Section 4.1.2.

4.1.1.  SCVP Response Processing by TLS Server

   The TLS Server MUST verify the response from the SCVP server.  If the
   TLS Server finds the response unacceptable, it MAY query another SCVP
   server (from the ResponderURIs or a pre-configured list) or MAY send
   a bad_path_validation_response alert notifying to close the
   connection.

   The TLS server MUST verify that the response is a protected response
   consisting of a CVResponse encapsulated in CMS SignedData.

   The TLS server SHOULD verify that the SignedData Message Digest is a
   hash of the received CVResponse.

   The TLS server MAY verify the certificate of the SCVP responder used
   for signing the response.  In some environments, it may be left to
   the TLS client to validate.

   As an SCVP client, the TLS server MUST process the CVResponse as
   defined by RFC 5055 [RFC5055].

   The TLS server SHOULD verify the responseStatus code.  If the code
   does not indicate okay(0), the TLS server MAY choose to query another
   SCVP server from the Responder URIs.

   As stated in RFC 5055, the requestRef item allows the SCVP client to
   determine that the request was not maliciously altered.  The TLS
   Server creates the CVRequest and is therefore the only place where
   the full CVRequst is known.  The TLS Server SHOULD compare the
   returned requestRef to the CVRequest.

   If the TLS server generated a requestNonce it SHOULD verify that the
   requestNonce in the response matches the value in the request.



Segers & Kopman         Expires 30 December 2022               [Page 13]


Internet-Draft        Validation Request Extension             June 2022


4.1.2.  SCVP Response Processing by TLS Client

   On receipt of a SCVPResponse, the TLS client MUST verify that the
   response indicates a successful path validation and can be trusted.

   The TLS Client MUST verify that the CVResponse is encapsulated in a
   CMS SignedData object and validate the digital signature on the
   response to ensure that the expected SCVP server generated the
   response.  The TLS Client MUST verify that the SignedData Message
   Digest matches a hash of the received CVResponse.

   The CVResponse CertReply item MUST contain a single certificate
   matching the TLS Server certificate sent in the TLS Certificate
   Handshake message.  If the CertReply does not meet this requirement
   the TLS client MUST abort the connection with a
   bad_path_validation_response.

   The TLS Client MUST verify that the CVResponse indicates success.  A
   CVResponse is successful if: the responseStatus is CVStatusCode
   okay(0) and the CertReply item containing the TLS Server's
   certificate has a replyStatus of success (0).  If these conditions
   are not met the TLS client MUST abort the connection with a
   bad_path_validation_response.

   The TLS Client should check the SCVPResponse validation_extensions
   against the validation_extensions sent in the SCVPValidationRequest.
   If the SCVPResponse validation_extensions list does not match the
   list of sent validation_extensions, the TLS client MAY abort the
   connection.

   If the client set validation extensions in the SCVPValidationRequest,
   the TLS client SHOULD verify that the CVResponse appropriately
   reflects those validation extensions.  For example, if the
   request_nonce validation extension was set the client SHOULD verify
   that the CVResponse respNonce contains the same value.

4.2.  Path Validation Cache

   To improve performance and survive path validation service outages
   the TLS server MAY cache PathValidation responses.  On receipt of a
   client hello with a validation_request extension the TLS Server MAY
   check a local cache for a PathValidation response matching the TLS
   client's settings.  If a matching response is found the server MAY
   use this response rather than generating a fresh response.







Segers & Kopman         Expires 30 December 2022               [Page 14]


Internet-Draft        Validation Request Extension             June 2022


   If the validation_request is of type scvp, the server should check if
   the client has set validation extensions before returning a cached
   response.  If the cached_response validation extension is set to
   FALSE or the request_nonce validation extension is set.  The TLS
   server SHOULD NOT return a cached response.

   The TLS server SHOULD place a time limit on cached responses and
   generate a fresh PathValidation response after that time has elapsed.
   To improve performance, the TLS server MAY proactively refresh cached
   responses before the cache time limit has been reached.  Path
   validation servers may also perform caching to optimize response
   times.  Timestamps may be included in the path validation response
   that MAY be used by the TLS server to determine when a fresh response
   will be available from the path validation server.  In the case of
   SCVP, this information can optionally be communicated in the
   nextUpdate wantBack value.

5.  Error Alerts

   On receipt of a PathValidation response the TLS client MUST validate
   that the response indicates a successful path validation as described
   in Section 4.  If the PathValidation response does not indicate that
   the server certificate was successfully validated the TLS client MUST
   abort the connection with a bad_path_validation_response as follows.

   enum {
     bad_path_validation_response(TBD),
     (255)
   } AlertDescription;

6.  IANA Considerations

   IANA considerations for TLS extensions and the creation of a registry
   are covered in Section 11 of RFC 8446 [RFC8446].

6.1.  Reference for TLS Alerts and ExtensionTypes

   The following values in the TLS Alert Registry have been updated to
   reference this document:

      TBD bad_path_validation_response

   The following ExtensionType values have been updated to reference
   this document:

      TBD validation_request





Segers & Kopman         Expires 30 December 2022               [Page 15]


Internet-Draft        Validation Request Extension             June 2022


7.  Security Considerations

   General security considerations for TLS extensions are covered in TLS
   1.3 RFC 8446 [RFC8446].

   For security considerations specific to the Cryptographic Message
   Syntax message formats, see RFC 5652 [RFC5652].  For security
   considerations specific to the process of PKI certification path
   validation, see RFC 5280 [RFC5280].  For security considerations
   specific to SCVP, see RFC 5055 [RFC5055].

   This section summarizes some of the more important security aspects
   specific to the TLS validation_request extension, though there are
   many security-relevant details in the remainder of this document.

7.1.  Support for Extension

   If a client requests a path validation response, it must consider
   that an attacker's server could (and probably would) pretend not to
   support the extension.  In this case, a client that requires path
   validation of certificates SHOULD either contact the validation
   server directly or abort the handshake.

7.2.  Replay Attacks

   Use of the optional SCVP cached response flag and request nonce items
   by either the TLS client in the validation extensions or by the TLS
   server may improve security against attacks that attempt to replay
   SCVP responses.  However, use of these properties must be balanced
   with the performance impact of requiring generation of a fresh SCVP
   response.

7.3.  Extension Modifications

   Values in the client hello validation_request extension and
   PathValidationRequest are passed between the TLS client to the TLS
   server unprotected.  This makes the values vulnerable to
   modification.  An attacker might try to influence the handshake
   exchange in multiple ways including to increase latency, cause
   parties to abort the connection or to create trust in an untrusted
   server.

   The SCVP type of this extension is made further vulnerable by the
   inclusion of validation extensions in the SCVPValidationRequest.
   These validation extensions have been included to support
   flexibility.  However, to mitigate the vulnerability to modification,
   domains should consider limiting use of validation extensions and
   instead use preconfigured domain specific values.  TLS client and



Segers & Kopman         Expires 30 December 2022               [Page 16]


Internet-Draft        Validation Request Extension             June 2022


   server verification of values returned in the signed CVResponse as
   described in Section 4.1 should also be used to protect against these
   attacks and detect attempts to modify these values

7.4.  Unrelated Path Validation Response

   The received PathValidation response could contain information
   unrelated to the request.  A path for an end-entity certificate other
   than the TLS server certificate could be returned.  The first
   certificate in the certificate path could not match any of the client
   provided trust anchors.  Or the SCVP responder signing the response
   could be unknown to the client.  If any such unrelated PathValidation
   response is received, it MUST be discarded and the TLS client MAY
   choose to use alternative means to validate the server certificate or
   MAY choose to abort the connection.

7.5.  Trust Anchor Maintenance

   The TLS client relies on a locally known trust anchor to verify the
   signed PathValidation response.  The trust anchor may change or
   expire periodically.  TLS clients using this specification MUST
   implement a secure mechanism to keep their trust anchors up to date.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5055]  Freeman, T., Housley, R., Malpani, A., Cooper, D., and W.
              Polk, "Server-Based Certificate Validation Protocol
              (SCVP)", RFC 5055, DOI 10.17487/RFC5055, December 2007,
              <https://www.rfc-editor.org/info/rfc5055>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              RFC 5652, DOI 10.17487/RFC5652, September 2009,
              <https://www.rfc-editor.org/info/rfc5652>.





Segers & Kopman         Expires 30 December 2022               [Page 17]


Internet-Draft        Validation Request Extension             June 2022


   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC9147]  Rescorla, E., Tschofenig, H., and N. Modadugu, "The
              Datagram Transport Layer Security (DTLS) Protocol Version
              1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
              <https://www.rfc-editor.org/info/rfc9147>.

Authors' Addresses

   Robert Segers
   Federal Aviation Administration
   800 Independence Ave. SW
   Washington, DC 20591
   United States of America
   Email: Robert.Segers@faa.gov


   Ashley Kopman
   Concepts Beyond
   1155 F St NW
   Washington, DC 20004
   United States of America
   Email: akopman@conceptsbeyond.com


























Segers & Kopman         Expires 30 December 2022               [Page 18]