Tech-invite   3GPPspecs   RFCs   Search in Tech-invite

in Index   Prev   Next

RFC 7671

The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance

Pages: 33
Group: DANE
Proposed STD
Updates:  6698
Part 1 of 2 – Pages 1 to 16
None   None   Next

Top   ToC   RFC7671 - Page 1
Internet Engineering Task Force (IETF)                       V. Dukhovni
Request for Comments: 7671                                     Two Sigma
Updates: 6698                                                W. Hardaker
Category: Standards Track                                        Parsons
ISSN: 2070-1721                                             October 2015

    The DNS-Based Authentication of Named Entities (DANE) Protocol:
                    Updates and Operational Guidance


   This document clarifies and updates the DNS-Based Authentication of
   Named Entities (DANE) TLSA specification (RFC 6698), based on
   subsequent implementation experience.  It also contains guidance for
   implementers, operators, and protocol developers who want to use DANE

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.
Top   ToC   RFC7671 - Page 2
Table of Contents

   1. Introduction ....................................................3
      1.1. Terminology ................................................4
   2. DANE TLSA Record Overview .......................................5
      2.1. Example TLSA Record ........................................6
   3. DANE TLS Requirements ...........................................6
   4. DANE Certificate Usage Selection Guidelines .....................7
      4.1. Opportunistic Security and PKIX Usages .....................7
      4.2. Interaction with Certificate Transparency ..................8
      4.3. Switching from/to PKIX-TA/EE to/from DANE-TA/EE ............9
   5. Certificate-Usage-Specific DANE Updates and Guidelines ..........9
      5.1. Certificate Usage DANE-EE(3) ...............................9
      5.2. Certificate Usage DANE-TA(2) ..............................11
      5.3. Certificate Usage PKIX-EE(1) ..............................15
      5.4. Certificate Usage PKIX-TA(0) ..............................15
   6. Service Provider and TLSA Publisher Synchronization ............16
   7. TLSA Base Domain and CNAMEs ....................................18
   8. TLSA Publisher Requirements ....................................19
      8.1. Key Rollover with Fixed TLSA Parameters ...................20
      8.2. Switching to DANE-TA(2) from DANE-EE(3) ...................21
      8.3. Switching to New TLSA Parameters ..........................22
      8.4. TLSA Publisher Requirements: Summary ......................23
   9. Digest Algorithm Agility .......................................23
   10. General DANE Guidelines .......................................25
      10.1. DANE DNS Record Size Guidelines ..........................25
      10.2. Certificate Name Check Conventions .......................26
      10.3. Design Considerations for Protocols Using DANE ...........27
   11. Note on DNSSEC Security .......................................28
   12. Summary of Updates to RFC 6698 ................................29
   13. Operational Considerations ....................................29
   14. Security Considerations .......................................30
   15. References ....................................................30
      15.1. Normative References .....................................30
      15.2. Informative References ...................................32
   Acknowledgements ..................................................33
   Authors' Addresses ................................................33
Top   ToC   RFC7671 - Page 3
1.  Introduction

   The DNS-Based Authentication of Named Entities (DANE) specification
   [RFC6698] introduces the DNS "TLSA" resource record (RR) type ("TLSA"
   is not an acronym).  TLSA records associate a certificate or a public
   key of an end-entity or a trusted issuing authority with the
   corresponding Transport Layer Security (TLS) [RFC5246] or Datagram
   Transport Layer Security (DTLS) [RFC6347] transport endpoint.  DANE
   relies on the DNS Security Extensions (DNSSEC) [RFC4033].  DANE TLSA
   records validated by DNSSEC can be used to augment or replace the use
   of trusted public Certification Authorities (CAs).

   The TLS and DTLS protocols provide secured TCP and UDP communication,
   respectively, over IP.  In the context of this document, channel
   security is assumed to be provided by TLS or DTLS.  By convention,
   "TLS" will be used throughout this document; unless otherwise
   specified, the text applies equally well to DTLS over UDP.  Used
   without authentication, TLS provides protection only against
   eavesdropping through its use of encryption.  With authentication,
   TLS also protects the transport against man-in-the-middle (MITM)

   [RFC6698] defines three TLSA record fields: the first with four
   possible values, the second with two, and the third with three.
   These yield 24 distinct combinations of TLSA record types.  This
   document recommends a smaller set of best-practice combinations of
   these fields to simplify protocol design, implementation, and

   This document explains and recommends DANE-specific strategies to
   simplify "virtual hosting", where a single Service Provider transport
   endpoint simultaneously supports multiple hosted Customer Domains.

   Other related documents that build on [RFC6698] are [RFC7673] and

   Section 12 summarizes the normative updates this document makes to
Top   ToC   RFC7671 - Page 4
1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "OPTIONAL" in this document are to be interpreted as described in

   The following terms are used throughout this document:

   Web PKI:  The Public Key Infrastructure (PKI) model employed by
      browsers to authenticate web servers.  This employs a set of
      trusted public CAs to vouch for the authenticity of public keys
      associated with a particular party (the subject).

   Service Provider:  A company or organization that offers to host a
      service on behalf of the owner of a Customer Domain.  The original
      domain name associated with the service often remains under the
      control of the customer.  Connecting applications may be directed
      to the Service Provider via a redirection RR.  Example redirection
      records include MX, SRV, and CNAME.  The Service Provider
      frequently provides services for many customers and needs to
      ensure that the TLS credentials presented to connecting
      applications authenticate it as a valid server for the requested

   Customer Domain:  As described above, a TLS client may be interacting
      with a service that is hosted by a third party.  This document
      refers to the domain name used to locate the service (prior to any
      redirection) as the "Customer Domain".

   TLSA Publisher:  The entity responsible for publishing a TLSA record
      within a DNS zone.  This zone will be assumed DNSSEC-signed and
      validatable to a trust anchor (TA), unless otherwise specified.
      If the Customer Domain is not outsourcing its DNS service, the
      TLSA Publisher will be the customer itself.  Otherwise, the TLSA
      Publisher may be the operator of the outsourced DNS service.

   Public key:  The term "public key" is shorthand for the
      subjectPublicKeyInfo component of a PKIX [RFC5280] certificate.

   SNI:  The Server Name Indication (SNI) TLS protocol extension allows
      a TLS client to request a connection to a particular service name
      of a TLS server ([RFC6066], Section 3).  Without this TLS
      extension, a TLS server has no choice but to offer a certificate
      with a default list of server names, making it difficult to host
      multiple Customer Domains at the same IP-address-based TLS service
      endpoint (i.e., provide "secure virtual hosting").
Top   ToC   RFC7671 - Page 5
   TLSA parameters:  In [RFC6698], the TLSA record is defined to consist
      of four fields.  The first three of these are numeric parameters
      that specify the meaning of the data in the fourth and final
      field.  This document refers to the first three fields as "TLSA
      parameters", or sometimes just "parameters" when obvious from

   TLSA base domain:  Per Section 3 of [RFC6698], TLSA records are
      stored at a DNS domain name that is a combination of a port and
      protocol prefix and a "base domain".  In [RFC6698], the "base
      domain" is the fully qualified domain name of the TLS server.
      This document modifies the TLSA record lookup strategy to prefer
      the fully CNAME-expanded name of the TLS server, provided that
      expansion is "secure" (DNSSEC validated) at each stage of the
      expansion, and TLSA records are published for this fully expanded
      name.  Thus, the "TLSA base domain" is either the fully
      CNAME-expanded TLS server name or otherwise the initial fully
      qualified TLS server name, whichever is used in combination with a
      port and protocol prefix to obtain the TLSA RRset.

2.  DANE TLSA Record Overview

   DANE TLSA [RFC6698] specifies a protocol for publishing TLS server
   certificate associations via DNSSEC [RFC4033] [RFC4034] [RFC4035].
   DANE TLSA records consist of four fields.  The record type is
   determined by the values of the first three fields, which this
   document refers to as the "TLSA parameters" to distinguish them from
   the fourth and last field.  The numeric values of these parameters
   were given symbolic names in [RFC7218].  The four fields are as

   The Certificate Usage field:  Section 2.1.1 of [RFC6698] specifies
      four values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and DANE-EE(3).
      There is an additional private-use value: PrivCert(255), which,
      given its private scope, shall not be considered further in this
      document.  All other values are reserved for use by future

   The Selector field:  Section 2.1.2 of [RFC6698] specifies two values:
      Cert(0) and SPKI(1).  There is an additional private-use value:
      PrivSel(255).  All other values are reserved for use by future

   The Matching Type field:  Section 2.1.3 of [RFC6698] specifies three
      values: Full(0), SHA2-256(1), and SHA2-512(2).  There is an
      additional private-use value: PrivMatch(255).  All other values
      are reserved for use by future specifications.
Top   ToC   RFC7671 - Page 6
   The Certificate Association Data field:  See Section 2.1.4 of
      [RFC6698].  This field stores the full value or digest of the
      certificate or subject public key as determined by the matching
      type and selector, respectively.

   In the Matching Type field, of the two digest algorithms --
   SHA2-256(1) and SHA2-512(2) -- as of the time of this writing, only
   SHA2-256(1) is mandatory to implement.  Clients SHOULD implement
   SHA2-512(2), but servers SHOULD NOT exclusively publish SHA2-512(2)
   digests.  The digest algorithm agility protocol defined in Section 9
   SHOULD be used by clients to decide how to process TLSA RRsets that
   employ multiple digest algorithms.  Server operators MUST publish
   TLSA RRsets that are compatible (see Section 8) with digest algorithm
   agility (Section 9).

2.1.  Example TLSA Record

   In the example TLSA record below, the TLSA certificate usage is
   DANE-TA(2), the selector is Cert(0), and the matching type is
   SHA2-256(1).  The last field is the Certificate Association Data
   field, which in this case contains the SHA2-256 digest of the server
   certificate. IN TLSA 2 0 1 (
                              CF556ECCF9F5303EBFBB77D022F834C0 )

3.  DANE TLS Requirements

   [RFC6698] does not discuss what versions of TLS are required when
   using DANE records.  This document specifies that TLS clients that
   support DANE/TLSA MUST support at least TLS 1.0 and SHOULD support
   TLS 1.2 or later.

   TLS clients using DANE MUST support the SNI extension of TLS
   [RFC6066].  Servers MAY support SNI and respond with a matching
   certificate chain but MAY also ignore SNI and respond with a default
   certificate chain.  When a server supports SNI but is not configured
   with a certificate chain that exactly matches the client's SNI
   extension, the server SHOULD respond with another certificate chain
   (a default or closest match).  This is because clients might support
   more than one server name but can only put a single name in the SNI
Top   ToC   RFC7671 - Page 7
4.  DANE Certificate Usage Selection Guidelines

   As mentioned in Section 2, the TLSA Certificate Usage field takes one
   of four possible values.  With PKIX-TA(0) and PKIX-EE(1), the
   validation of peer certificate chains requires additional
   preconfigured CA TAs that are mutually trusted by the operators of
   the TLS server and client.  With DANE-TA(2) and DANE-EE(3), no
   preconfigured CA TAs are required and the published DANE TLSA records
   are sufficient to verify the peer's certificate chain.

   Standards for application protocols that employ DANE TLSA can specify
   more specific guidance than [RFC6698] or this document.  Such
   application-specific standards need to carefully consider which set
   of DANE certificate usages to support.  Simultaneous support for all
   four usages is NOT RECOMMENDED for DANE clients.  When all four
   usages are supported, an attacker capable of compromising the
   integrity of DNSSEC needs only to replace the server's TLSA RRset
   with one that lists suitable DANE-EE(3) or DANE-TA(2) records,
   effectively bypassing any added verification via public CAs.  In
   other words, when all four usages are supported, PKIX-TA(0) and
   PKIX-EE(1) offer only illusory incremental security over DANE-TA(2)
   and DANE-EE(3).

   Designs in which clients support just the DANE-TA(2) and DANE-EE(3)
   certificate usages are RECOMMENDED.  With DANE-TA(2) and DANE-EE(3),
   clients don't need to track a large changing list of X.509 TAs in
   order to successfully authenticate servers whose certificates are
   issued by a CA that is brand new or not widely trusted.

   The DNSSEC TLSA records for servers MAY include both sets of usages
   if the server needs to support a mixture of clients, some supporting
   one pair of usages and some the other.

4.1.  Opportunistic Security and PKIX Usages

   When the client's protocol design is based on "Opportunistic
   Security" (OS) [RFC7435] and the use of authentication is based on
   the presence of server TLSA records, it is especially important to
   avoid the PKIX-EE(1) and PKIX-TA(0) certificate usages.

   When authenticated TLS is used opportunistically based on the
   presence of DANE TLSA records and no secure TLSA records are present,
   unauthenticated TLS is used if possible, and if TLS is not possible,
   perhaps even cleartext.  However, if usable secure TLSA records are
   published, then authentication MUST succeed.  Also, outside the
   browser space, there is no preordained canon of trusted CAs, and in
   any case there is no security advantage in using PKIX-TA(0) or
Top   ToC   RFC7671 - Page 8
   PKIX-EE(1) when the DANE-TA(2) and DANE-EE(3) usages are also
   supported (as an attacker who can compromise DNS can replace the
   former with the latter).

   Authentication via the PKIX-TA(0) and PKIX-EE(1) certificate usages
   is more brittle; the client and server need to happen to agree on a
   mutually trusted CA, but with OS the client is just trying to protect
   the communication channel at the request of the server and would
   otherwise be willing to use cleartext or unauthenticated TLS.  The
   use of fragile mechanisms (like public CA authentication for some
   unspecified set of trusted CAs) is not sufficiently reliable for an
   OS client to honor the server's request for authentication.  OS needs
   to be non-intrusive and to require few, if any, workarounds for valid
   but mismatched peers.

   Because the PKIX-TA(0) and PKIX-EE(1) usages offer no more security
   and are more prone to failure, they are a poor fit for OS and
   SHOULD NOT be used in that context.

4.2.  Interaction with Certificate Transparency

   Certificate Transparency (CT) [RFC6962] defines an experimental
   approach that could be used to mitigate the risk of rogue or
   compromised public CAs issuing unauthorized certificates.  This
   section clarifies the interaction of the experimental CT and DANE.
   This section may need to be revised in light of any future Standards
   Track version of CT.

   When a server is authenticated via a DANE TLSA RR with TLSA
   certificate usage DANE-EE(3), the domain owner has directly specified
   the certificate associated with the given service without reference
   to any public CA.  Therefore, when a TLS client authenticates the TLS
   server via a TLSA record with usage DANE-EE(3), CT checks SHOULD NOT
   be performed.  Publication of the server certificate or public key
   (digest) in a TLSA record in a DNSSEC-signed zone by the domain owner
   assures the TLS client that the certificate is not an unauthorized
   certificate issued by a rogue CA without the domain owner's consent.

   When a server is authenticated via a DANE TLSA record with TLSA usage
   DANE-TA(2) and the server certificate does not chain to a known
   public root CA, CT cannot apply (CT logs only accept chains that
   start with a known public root).  Since TLSA certificate usage
   DANE-TA(2) is generally intended to support non-public TAs, TLS
   clients SHOULD NOT perform CT checks with usage DANE-TA(2).
Top   ToC   RFC7671 - Page 9
   With certificate usages PKIX-TA(0) and PKIX-EE(1), CT applies just as
   it would without DANE.  TLSA records of this type only constrain
   which CAs are acceptable in PKIX validation.  All checks used in the
   absence of DANE still apply when validating certificate chains with
   DANE PKIX-TA(0) and PKIX-EE(1) constraints.

4.3.  Switching from/to PKIX-TA/EE to/from DANE-TA/EE

   The choice of preferred certificate usages may need to change as an
   application protocol evolves.  When transitioning between PKIX-TA/
   PKIX-EE and DANE-TA/DANE-EE, clients begin to enable support for the
   new certificate usage values.  If the new preferred certificate
   usages are PKIX-TA/EE, this requires installing and managing the
   appropriate set of CA TAs.  During this time, servers will publish
   both types of TLSA records.  At some later time, when the vast
   majority of servers have published the new preferred TLSA records,
   clients can stop supporting the legacy certificate usages.
   Similarly, servers can stop publishing legacy TLSA records once the
   vast majority of clients support the new certificate usages.

5.  Certificate-Usage-Specific DANE Updates and Guidelines

   The four certificate usage values from the TLSA record -- DANE-EE(3),
   DANE-TA(2), PKIX-EE(1), and PKIX-TA(0) -- are discussed below.

5.1.  Certificate Usage DANE-EE(3)

   In this section, the meaning of DANE-EE(3) is updated from [RFC6698]
   to specify that peer identity matching and validity period
   enforcement are based solely on the TLSA RRset properties.  This
   document also extends [RFC6698] to cover the use of DANE
   authentication of raw public keys [RFC7250] via TLSA records with
   certificate usage DANE-EE(3) and selector SPKI(1).

   Authentication via certificate usage DANE-EE(3) TLSA records involves
   simply checking that the server's leaf certificate matches the TLSA
   record.  In particular, the binding of the server public key to its
   name is based entirely on the TLSA record association.  The server
   MUST be considered authenticated even if none of the names in the
   certificate match the client's reference identity for the server.
   This simplifies the operation of servers that host multiple Customer
   Domains, as a single certificate can be associated with multiple
   domains without having to match each of the corresponding reference
Top   ToC   RFC7671 - Page 10
   ; Multiple Customer Domains hosted by an
   ; Service Provider:
   ;              IN CNAME              IN CNAME
   ; In the provider's DNS zone, a single certificate and TLSA
   ; record support multiple Customer Domains, greatly simplifying
   ; "virtual hosting".
   ;           IN A           IN A IN CNAME IN CNAME       IN TLSA 3 1 1 e3b0c44298fc1c14...

   Also, with DANE-EE(3), the expiration date of the server certificate
   MUST be ignored.  The validity period of the TLSA record key binding
   is determined by the validity period of the TLSA record DNSSEC
   signatures.  Validity is reaffirmed on an ongoing basis by continuing
   to publish the TLSA record and signing the zone in which the record
   is contained, rather than via dates "set in stone" in the
   certificate.  The expiration becomes a reminder to the administrator
   that it is likely time to rotate the key, but missing the date no
   longer causes an outage.  When keys are rotated (for whatever
   reason), it is important to follow the procedures outlined in
   Section 8.

   If a server uses just DANE-EE(3) TLSA records and all its clients are
   DANE clients, the server need not employ SNI (i.e., it may ignore the
   client's SNI message) even when the server is known via multiple
   domain names that would otherwise require separate certificates.  It
   is instead sufficient for the TLSA RRsets for all the domain names in
   question to match the server's default certificate.  For application
   protocols where the server name is obtained indirectly via SRV
   records, MX records, or similar records, it is simplest to publish a
   single hostname as the target server name for all the hosted domains.

   In organizations where it is practical to make coordinated changes in
   DNS TLSA records before server key rotation, it is generally best to
   publish end-entity DANE-EE(3) certificate associations in preference
   to other choices of certificate usage.  DANE-EE(3) TLSA records
   support multiple server names without SNI, don't suddenly stop
   working when leaf or intermediate certificates expire, and don't fail
   when a server operator neglects to include all the required issuer
   certificates in the server certificate chain.
Top   ToC   RFC7671 - Page 11
   More specifically, it is RECOMMENDED that at most sites TLSA records
   published for DANE servers be "DANE-EE(3) SPKI(1) SHA2-256(1)"
   records.  Selector SPKI(1) is chosen because it is compatible with
   raw public keys [RFC7250] and the resulting TLSA record need not
   change across certificate renewals with the same key.  Matching type
   SHA2-256(1) is chosen because all DANE implementations are required
   to support SHA2-256.  This TLSA record type easily supports hosting
   arrangements with a single certificate matching all hosted domains.
   It is also the easiest to implement correctly in the client.

   Clients that support raw public keys can use DANE TLSA records with
   certificate usage DANE-EE(3) and selector SPKI(1) to authenticate
   servers that negotiate the use of raw public keys.  Provided the
   server adheres to the requirements of Section 8, the fact that raw
   public keys are not compatible with any other TLSA record types will
   not get in the way of successful authentication.  Clients that employ
   DANE to authenticate the peer server SHOULD NOT negotiate the use of
   raw public keys unless the server's TLSA RRset includes "DANE-EE(3)
   SPKI(1)" TLSA records.

   While it is, in principle, also possible to authenticate raw public
   keys via "DANE-EE(3) Cert(0) Full(0)" records by extracting the
   public key from the certificate in DNS, extracting just the public
   key from a "3 0 0" TLSA record requires extra logic on clients that
   not all implementations are expected to provide.  Servers that wish
   to support [RFC7250] raw public keys need to publish TLSA records
   with a certificate usage of DANE-EE(3) and a selector of SPKI(1).

   While DANE-EE(3) TLSA records are expected to be by far the most
   prevalent, as explained in Section 5.2, DANE-TA(2) records are a
   valid alternative for sites with many DANE services.  Note, however,
   that virtual hosting is more complex with DANE-TA(2).  Also, with
   DANE-TA(2), server operators MUST ensure that the server is
   configured with a sufficiently complete certificate chain and need to
   remember to replace certificates prior to their expiration dates.

5.2.  Certificate Usage DANE-TA(2)

   This section updates [RFC6698] by specifying a new operational
   requirement for servers publishing TLSA records with a usage of
   DANE-TA(2): such servers MUST include the TA certificate in their TLS
   server certificate message unless all such TLSA records are "2 0 0"
   records that publish the server certificate in full.

   Some domains may prefer to avoid the operational complexity of
   publishing unique TLSA RRs for each TLS service.  If the domain
   employs a common issuing CA to create certificates for multiple TLS
   services, it may be simpler to publish the issuing authority as a TA
Top   ToC   RFC7671 - Page 12
   for the certificate chains of all relevant services.  The TLSA query
   domain (TLSA base domain with port and protocol prefix labels) for
   each service issued by the same TA may then be set to a CNAME alias
   that points to a common TLSA RRset that matches the TA.  For example:

   ; Two servers, each with its own certificate, that share
   ; a common issuer (TA).
   ;            IN A            IN A  IN CNAME  IN CNAME      IN TLSA 2 0 1 e3b0c44298fc1c14...

   The above configuration simplifies server key rotation, because while
   the servers continue to receive new certificates from a CA matched by
   the shared (target of the CNAMEs) TLSA record, server certificates
   can be updated without making any DNS changes.  As the list of active
   issuing CAs changes, the shared TLSA record will be updated (much
   less frequently) by the administrators who manage the CAs.  Those
   administrators still need to perform TLSA record updates with care,
   as described in Section 8.

   With usage DANE-TA(2), the server certificates will need to have
   names that match one of the client's reference identifiers (see
   [RFC6125]).  When hosting multiple unrelated Customer Domains (that
   can't all appear in a single certificate), such a server SHOULD
   employ SNI to select the appropriate certificate to present to the

5.2.1.  Recommended Record Combinations

   TLSA records with a matching type of Full(0) are NOT RECOMMENDED.
   While these potentially obviate the need to transmit the TA
   certificate in the TLS server certificate message, client
   implementations may not be able to augment the server certificate
   chain with the data obtained from DNS, especially when the TLSA
   record supplies a bare key (selector SPKI(1)).  Since the server will
   need to transmit the TA certificate in any case, server operators
   SHOULD publish TLSA records with a matching type other than Full(0)
   and avoid potential DNS interoperability issues with large TLSA
   records containing full certificates or keys (see Section 10.1.1).
Top   ToC   RFC7671 - Page 13
   TLSA Publishers employing DANE-TA(2) records SHOULD publish records
   with a selector of Cert(0).  Such TLSA records are associated with
   the whole TA certificate, not just with the TA public key.  In
   particular, when authenticating the peer certificate chain via such a
   TLSA record, the client SHOULD apply any relevant constraints from
   the TA certificate, such as, for example, path length constraints.

   While a selector of SPKI(1) may also be employed, the resulting TLSA
   record will not specify the full TA certificate content, and elements
   of the TA certificate other than the public key become mutable.  This
   may, for example, enable a subsidiary CA to issue a chain that
   violates the TA's path length or name constraints.

5.2.2.  Trust Anchor Digests and Server Certificate Chain

   With DANE-TA(2), a complication arises when the TA certificate is
   omitted from the server's certificate chain, perhaps on the basis of
   Section 7.4.2 of [RFC5246]:

      The sender's certificate MUST come first in the list.  Each
      following certificate MUST directly certify the one preceding it.
      Because certificate validation requires that root keys be
      distributed independently, the self-signed certificate that
      specifies the root certificate authority MAY be omitted from the
      chain, under the assumption that the remote end must already
      possess it in order to validate it in any case.

   With TLSA certificate usage DANE-TA(2), there is no expectation that
   the client is preconfigured with the TA certificate.  In fact, client
   implementations are free to ignore all locally configured TAs when
   processing usage DANE-TA(2) TLSA records and may rely exclusively on
   the certificates provided in the server's certificate chain.  But,
   with a digest in the TLSA record, the TLSA record contains neither
   the full TA certificate nor the full public key.  If the TLS server's
   certificate chain does not contain the TA certificate, DANE clients
   will be unable to authenticate the server.

   TLSA Publishers that publish TLSA certificate usage DANE-TA(2)
   associations with a selector of SPKI(1) or with a digest-based
   matching type (not Full(0)) MUST ensure that the corresponding server
   is configured to also include the TA certificate in its TLS handshake
   certificate chain, even if that certificate is a self-signed root CA
   and would have been optional in the context of the existing public
   CA PKI.
Top   ToC   RFC7671 - Page 14
   Only when the server TLSA record includes a "DANE-TA(2) Cert(0)
   Full(0)" TLSA record containing a full TA certificate is the TA
   certificate optional in the server's TLS certificate message.  This
   is also the only type of DANE-TA(2) record for which the client MUST
   be able to verify the server's certificate chain even if the TA
   certificate appears only in DNS and is absent from the TLS handshake
   server certificate message.

5.2.3.  Trust Anchor Public Keys

   TLSA records with TLSA certificate usage DANE-TA(2), selector
   SPKI(1), and a matching type of Full(0) publish the full public key
   of a TA via DNS.  In Section 6.1.1 of [RFC5280], the definition of a
   TA consists of the following four parts:

   1.  the trusted issuer name,

   2.  the trusted public key algorithm,

   3.  the trusted public key, and

   4.  optionally, the trusted public key parameters associated with the
       public key.

   Items 2-4 are precisely the contents of the subjectPublicKeyInfo
   published in the TLSA record.  The issuer name is not included in the

   With TLSA certificate usage DANE-TA(2), the client may not have the
   associated TA certificate and cannot generally verify whether or not
   a particular certificate chain is "issued by" the TA described in the
   TLSA record.

   When the server certificate chain includes a CA certificate whose
   public key matches the TLSA record, the client can match that CA as
   the intended issuer.  Otherwise, the client can only check that the
   topmost certificate in the server's chain is "signed by" the TA's
   public key in the TLSA record.  Such a check may be difficult to
   implement and cannot be expected to be supported by all clients.

   Thus, servers cannot rely on "DANE-TA(2) SPKI(1) Full(0)" TLSA
   records to be sufficient to authenticate chains issued by the
   associated public key in the absence of a corresponding certificate
   in the server's TLS certificate message.  Servers employing "2 1 0"
   TLSA records MUST include the corresponding TA certificate in their
   certificate chain.
Top   ToC   RFC7671 - Page 15
   If none of the server's certificate chain elements match a public key
   specified in a TLSA record, and at least one "DANE-TA(2) SPKI(1)
   Full(0)" TLSA record is available, it is RECOMMENDED that clients
   check to see whether or not the topmost certificate in the chain is
   signed by the provided public key and has not expired, and in that
   case consider the server authenticated, provided the rest of the
   chain passes validation, including leaf certificate name checks.

5.3.  Certificate Usage PKIX-EE(1)

   This certificate usage is similar to DANE-EE(3); but, in addition,
   PKIX verification is required.  Therefore, name checks, certificate
   expiration, CT, etc. apply as they would without DANE.

5.4.  Certificate Usage PKIX-TA(0)

   This section updates [RFC6698] by specifying new client
   implementation requirements.  Clients that trust intermediate
   certificates MUST be prepared to construct longer PKIX chains than
   would be required for PKIX alone.

   TLSA certificate usage PKIX-TA(0) allows a domain to publish
   constraints on the set of PKIX CAs trusted to issue certificates for
   its TLS servers.  A PKIX-TA(0) TLSA record matches PKIX-verified
   trust chains that contain an issuer certificate (root or
   intermediate) that matches its Certificate Association Data field
   (typically a certificate or digest).

   PKIX-TA(0) requires more complex coordination (than with DANE-TA(2)
   or DANE-EE(3)) between the Customer Domain and the Service Provider
   in hosting arrangements.  Thus, this certificate usage is
   NOT RECOMMENDED when the Service Provider is not also the TLSA
   Publisher (at the TLSA base domain obtained via CNAMEs, SRV records,
   or MX records).

   TLSA Publishers who publish TLSA records for a particular public root
   CA will expect that clients will only accept chains anchored at that
   root.  It is possible, however, that the client's trusted certificate
   store includes some intermediate CAs, either with or without the
   corresponding root CA.  When a client constructs a trust chain
   leading from a trusted intermediate CA to the server leaf
   certificate, such a "truncated" chain might not contain the trusted
   root published in the server's TLSA record.

   If the omitted root is also trusted, the client may erroneously
   reject the server chain if it fails to determine that the shorter
   chain it constructed extends to a longer trusted chain that matches
   the TLSA record.  Thus, when matching a usage PKIX-TA(0) TLSA record,
Top   ToC   RFC7671 - Page 16
   so long as no matching certificate has yet been found, a client MUST
   continue extending the chain even after any locally trusted
   certificate is found.  If no TLSA records have matched any of the
   elements of the chain and the trusted certificate found is not
   self-issued, the client MUST attempt to build a longer chain in case
   a certificate closer to the root matches the server's TLSA record.

(page 16 continued on part 2)

Next Section