Add DANE RFC (6698) for reference

1 files changed, 2075 insertions, 0 deletions

diff --git a/doc/doc-txt/rfc6698-dane.txt b/doc/doc-txt/rfc6698-dane.txt
new file mode 100644
index 000000000..95e7cf4f5
--- /dev/null
+++ b/doc/doc-txt/rfc6698-dane.txt
@@ -0,0 +1,2075 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        P. Hoffman
+Request for Comments: 6698                                VPN Consortium
+Category: Standards Track                                    J. Schlyter
+ISSN: 2070-1721                                                 Kirei AB
+                                                             August 2012
+
+
+         The DNS-Based Authentication of Named Entities (DANE)
+             Transport Layer Security (TLS) Protocol: TLSA
+
+Abstract
+
+   Encrypted communication on the Internet often uses Transport Layer
+   Security (TLS), which depends on third parties to certify the keys
+   used.  This document improves on that situation by enabling the
+   administrators of domain names to specify the keys used in that
+   domain's TLS servers.  This requires matching improvements in TLS
+   client software, but no change in TLS server software.
+
+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
+   http://www.rfc-editor.org/info/rfc6698.
+
+Copyright Notice
+
+   Copyright (c) 2012 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
+   (http://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 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.
+
+
+
+
+Hoffman & Schlyter           Standards Track                    [Page 1]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Background and Motivation ..................................3
+      1.2. Securing the Association of a Domain Name with a
+           Server's Certificate .......................................4
+      1.3. Method for Securing Certificate Associations ...............5
+      1.4. Terminology ................................................6
+   2. The TLSA Resource Record ........................................7
+      2.1. TLSA RDATA Wire Format .....................................7
+           2.1.1. The Certificate Usage Field .........................7
+           2.1.2. The Selector Field ..................................8
+           2.1.3. The Matching Type Field .............................9
+           2.1.4. The Certificate Association Data Field ..............9
+      2.2. TLSA RR Presentation Format ................................9
+      2.3. TLSA RR Examples ..........................................10
+   3. Domain Names for TLSA Certificate Associations .................10
+   4. Use of TLSA Records in TLS .....................................11
+      4.1. Usable Certificate Associations ...........................11
+   5. TLSA and DANE Use Cases and Requirements .......................13
+   6. Mandatory-to-Implement Features ................................15
+   7. IANA Considerations ............................................15
+      7.1. TLSA RRtype ...............................................15
+      7.2. TLSA Certificate Usages ...................................15
+      7.3. TLSA Selectors ............................................16
+      7.4. TLSA Matching Types .......................................16
+   8. Security Considerations ........................................16
+      8.1. Comparing DANE to Public CAs ..............................18
+           8.1.1. Risk of Key Compromise .............................19
+           8.1.2. Impact of Key Compromise ...........................20
+           8.1.3. Detection of Key Compromise ........................20
+           8.1.4. Spoofing Hostnames .................................20
+      8.2. DNS Caching ...............................................21
+      8.3. External DNSSEC Validators ................................21
+   9. Acknowledgements ...............................................22
+   10. References ....................................................22
+      10.1. Normative References .....................................22
+      10.2. Informative References ...................................23
+   Appendix A. Operational Considerations for Deploying TLSA
+               Records ...............................................25
+     A.1. Creating TLSA Records ......................................25
+       A.1.1. Ambiguities and Corner Cases When TLS Clients
+              Build Trust Chains .....................................26
+       A.1.2. Choosing a Selector Type ...............................26
+     A.2. Provisioning TLSA Records in DNS ...........................28
+       A.2.1. Provisioning TLSA Records with Aliases .................28
+     A.3. Securing the Last Hop ......................................30
+     A.4. Handling Certificate Rollover ..............................31
+
+
+
+Hoffman & Schlyter           Standards Track                    [Page 2]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   Appendix B. Pseudocode for Using TLSA .............................32
+     B.1. Helper Functions ...........................................32
+     B.2. Main TLSA Pseudocode .......................................33
+   Appendix C. Examples ..............................................35
+
+1.  Introduction
+
+1.1.  Background and Motivation
+
+   Applications that communicate over the Internet often need to prevent
+   eavesdropping, tampering, or forgery of their communications.  The
+   Transport Layer Security (TLS) protocol provides this kind of
+   communications security over the Internet, using channel encryption.
+
+   The security properties of encryption systems depend strongly on the
+   keys that they use.  If secret keys are revealed, or if public keys
+   can be replaced by fake keys (that is, a key not corresponding to the
+   entity identified in the certificate), these systems provide little
+   or no security.
+
+   TLS uses certificates to bind keys and names.  A certificate combines
+   a published key with other information such as the name of the
+   service that uses the key, and this combination is digitally signed
+   by another key.  Having a key in a certificate is only helpful if one
+   trusts the other key that signed the certificate.  If that other key
+   was itself revealed or substituted, then its signature is worthless
+   in proving anything about the first key.
+
+   On the Internet, this problem has been solved for years by entities
+   called "Certification Authorities" (CAs).  CAs protect their secret
+   key vigorously, while supplying their public key to the software
+   vendors who build TLS clients.  They then sign certificates, and
+   supply those to TLS servers.  TLS client software uses a set of these
+   CA keys as "trust anchors" to validate the signatures on certificates
+   that the client receives from TLS servers.  Client software typically
+   allows any CA to usefully sign any other certificate.
+
+   The public CA model upon which TLS has depended is fundamentally
+   vulnerable because it allows any of these CAs to issue a certificate
+   for any domain name.  A single trusted CA that betrays its trust,
+   either voluntarily or by providing less-than-vigorous protection for
+   its secrets and capabilities, can undermine the security offered by
+   any certificates employed with TLS.  This problem arises because a
+   compromised CA can issue a replacement certificate that contains a
+   fake key.  Recent experiences with compromises of CAs or their
+   trusted partners have led to very serious security problems, such as
+   the governments of multiple countries attempting to wiretap and/or
+   subvert major TLS-protected web sites trusted by millions of users.
+
+
+
+Hoffman & Schlyter           Standards Track                    [Page 3]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   The DNS Security Extensions (DNSSEC) provide a similar model that
+   involves trusted keys signing the information for untrusted keys.
+   However, DNSSEC provides three significant improvements.  Keys are
+   tied to names in the Domain Name System (DNS), rather than to
+   arbitrary identifying strings; this is more convenient for Internet
+   protocols.  Signed keys for any domain are accessible online through
+   a straightforward query using the standard DNSSEC protocol, so there
+   is no problem distributing the signed keys.  Most significantly, the
+   keys associated with a domain name can only be signed by a key
+   associated with the parent of that domain name; for example, the keys
+   for "example.com" can only be signed by the keys for "com", and the
+   keys for "com" can only be signed by the DNS root.  This prevents an
+   untrustworthy signer from compromising anyone's keys except those in
+   their own subdomains.  Like TLS, DNSSEC relies on public keys that
+   come built into the DNSSEC client software, but these keys come only
+   from a single root domain rather than from a multiplicity of CAs.
+
+   DNS-Based Authentication of Named Entities (DANE) offers the option
+   to use the DNSSEC infrastructure to store and sign keys and
+   certificates that are used by TLS.  DANE is envisioned as a
+   preferable basis for binding public keys to DNS names, because the
+   entities that vouch for the binding of public key data to DNS names
+   are the same entities responsible for managing the DNS names in
+   question.  While the resulting system still has residual security
+   vulnerabilities, it restricts the scope of assertions that can be
+   made by any entity, consistent with the naming scope imposed by the
+   DNS hierarchy.  As a result, DANE embodies the security "principle of
+   least privilege" that is lacking in the current public CA model.
+
+1.2.  Securing the Association of a Domain Name with a Server's
+      Certificate
+
+   A TLS client begins a connection by exchanging messages with a TLS
+   server.  For many application protocols, it looks up the server's
+   name using the DNS to get an Internet Protocol (IP) address
+   associated with the name.  It then begins a connection to a
+   particular port at that address, and sends an initial message there.
+   However, the client does not yet know whether an adversary is
+   intercepting and/or altering its communication before it reaches the
+   TLS server.  It does not even know whether the real TLS server
+   associated with that domain name has ever received its initial
+   messages.
+
+   The first response from the server in TLS may contain a certificate.
+   In order for the TLS client to authenticate that it is talking to the
+   expected TLS server, the client must validate that this certificate
+   is associated with the domain name used by the client to get to the
+   server.  Currently, the client must extract the domain name from the
+
+
+
+Hoffman & Schlyter           Standards Track                    [Page 4]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   certificate and must successfully validate the certificate, including
+   chaining to a trust anchor.
+
+   There is a different way to authenticate the association of the
+   server's certificate with the intended domain name without trusting
+   an external CA.  Given that the DNS administrator for a domain name
+   is authorized to give identifying information about the zone, it
+   makes sense to allow that administrator to also make an authoritative
+   binding between the domain name and a certificate that might be used
+   by a host at that domain name.  The easiest way to do this is to use
+   the DNS, securing the binding with DNSSEC.
+
+   There are many use cases for such functionality.  [RFC6394] lists the
+   ones to which the DNS RRtype in this document apply.  [RFC6394] also
+   lists many requirements, most of which this document is believed to
+   meet.  Section 5 covers the applicability of this document to the use
+   cases in detail.  The protocol in this document can generally be
+   referred to as the "DANE TLSA" protocol.  ("TLSA" does not stand for
+   anything; it is just the name of the RRtype.)
+
+   This document applies to both TLS [RFC5246] and Datagram TLS (DTLS)
+   [RFC6347].  In order to make the document more readable, it mostly
+   only talks about "TLS", but in all cases, it means "TLS or DTLS".
+   Although the references in this paragraph are to TLS and DTLS
+   version 1.2, the DANE TLSA protocol can also be used with earlier
+   versions of TLS and DTLS.
+
+   This document only relates to securely associating certificates for
+   TLS and DTLS with host names; retrieving certificates from DNS for
+   other protocols is handled in other documents.  For example, keys for
+   IPsec are covered in [RFC4025], and keys for Secure SHell (SSH) are
+   covered in [RFC4255].
+
+1.3.  Method for Securing Certificate Associations
+
+   A certificate association is formed from a piece of information
+   identifying a certificate and the domain name where the server
+   application runs.  The combination of a trust anchor and a domain
+   name can also be a certificate association.
+
+   A DNS query can return multiple certificate associations, such as in
+   the case of a server that is changing from one certificate to another
+   (described in more detail in Appendix A.4).
+
+   This document only applies to PKIX [RFC5280] certificates, not
+   certificates of other formats.
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                    [Page 5]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   This document defines a secure method to associate the certificate
+   that is obtained from the TLS server with a domain name using DNS;
+   the DNS information needs to be protected by DNSSEC.  Because the
+   certificate association was retrieved based on a DNS query, the
+   domain name in the query is by definition associated with the
+   certificate.  Note that this document does not cover how to associate
+   certificates with domain names for application protocols that depend
+   on SRV, NAPTR, and similar DNS resource records.  It is expected that
+   future documents will cover methods for making those associations,
+   and those documents may or may not need to update this one.
+
+   DNSSEC, which is defined in [RFC4033], [RFC4034], and [RFC4035], uses
+   cryptographic keys and digital signatures to provide authentication
+   of DNS data.  Information that is retrieved from the DNS and that is
+   validated using DNSSEC is thereby proved to be the authoritative
+   data.  The DNSSEC signature needs to be validated on all responses
+   that use DNSSEC in order to assure the proof of origin of the data.
+
+   This document does not specify how DNSSEC validation occurs because
+   there are many different proposals for how a client might get
+   validated DNSSEC results, such as from a DNSSEC-aware resolver that
+   is coded in the application, from a trusted DNSSEC resolver on the
+   machine on which the application is running, or from a trusted DNSSEC
+   resolver with which the application is communicating over an
+   authenticated and integrity-protected channel or network.  This is
+   described in more detail in Section 7 of [RFC4033].
+
+   This document only relates to getting the DNS information for the
+   certificate association securely using DNSSEC; other secure DNS
+   mechanisms are out of scope.
+
+1.4.  Terminology
+
+   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].
+
+   This document also makes use of standard PKIX, DNSSEC, TLS, and DNS
+   terminology.  See [RFC5280], [RFC4033], [RFC5246], and STD 13
+   [RFC1034] [RFC1035], respectively, for these terms.  In addition,
+   terms related to TLS-protected application services and DNS names are
+   taken from [RFC6125].
+
+
+
+
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                    [Page 6]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+2.  The TLSA Resource Record
+
+   The TLSA DNS resource record (RR) is used to associate a TLS server
+   certificate or public key with the domain name where the record is
+   found, thus forming a "TLSA certificate association".  The semantics
+   of how the TLSA RR is interpreted are given later in this document.
+
+   The type value for the TLSA RR type is defined in Section 7.1.
+
+   The TLSA RR is class independent.
+
+   The TLSA RR has no special Time to Live (TTL) requirements.
+
+2.1.  TLSA RDATA Wire Format
+
+   The RDATA for a TLSA RR consists of a one-octet certificate usage
+   field, a one-octet selector field, a one-octet matching type field,
+   and the certificate association data field.
+
+                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Cert. Usage  |   Selector    | Matching Type |               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               /
+   /                                                               /
+   /                 Certificate Association Data                  /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+2.1.1.  The Certificate Usage Field
+
+   A one-octet value, called "certificate usage", specifies the provided
+   association that will be used to match the certificate presented in
+   the TLS handshake.  This value is defined in a new IANA registry (see
+   Section 7.2) in order to make it easier to add additional certificate
+   usages in the future.  The certificate usages defined in this
+   document are:
+
+      0 -- Certificate usage 0 is used to specify a CA certificate, or
+      the public key of such a certificate, that MUST be found in any of
+      the PKIX certification paths for the end entity certificate given
+      by the server in TLS.  This certificate usage is sometimes
+      referred to as "CA constraint" because it limits which CA can be
+      used to issue certificates for a given service on a host.  The
+      presented certificate MUST pass PKIX certification path
+      validation, and a CA certificate that matches the TLSA record MUST
+      be included as part of a valid certification path.  Because this
+      certificate usage allows both trust anchors and CA certificates,
+
+
+
+Hoffman & Schlyter           Standards Track                    [Page 7]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+      the certificate might or might not have the basicConstraints
+      extension present.
+
+      1 -- Certificate usage 1 is used to specify an end entity
+      certificate, or the public key of such a certificate, that MUST be
+      matched with the end entity certificate given by the server in
+      TLS.  This certificate usage is sometimes referred to as "service
+      certificate constraint" because it limits which end entity
+      certificate can be used by a given service on a host.  The target
+      certificate MUST pass PKIX certification path validation and MUST
+      match the TLSA record.
+
+      2 -- Certificate usage 2 is used to specify a certificate, or the
+      public key of such a certificate, that MUST be used as the trust
+      anchor when validating the end entity certificate given by the
+      server in TLS.  This certificate usage is sometimes referred to as
+      "trust anchor assertion" and allows a domain name administrator to
+      specify a new trust anchor -- for example, if the domain issues
+      its own certificates under its own CA that is not expected to be
+      in the end users' collection of trust anchors.  The target
+      certificate MUST pass PKIX certification path validation, with any
+      certificate matching the TLSA record considered to be a trust
+      anchor for this certification path validation.
+
+      3 -- Certificate usage 3 is used to specify a certificate, or the
+      public key of such a certificate, that MUST match the end entity
+      certificate given by the server in TLS.  This certificate usage is
+      sometimes referred to as "domain-issued certificate" because it
+      allows for a domain name administrator to issue certificates for a
+      domain without involving a third-party CA.  The target certificate
+      MUST match the TLSA record.  The difference between certificate
+      usage 1 and certificate usage 3 is that certificate usage 1
+      requires that the certificate pass PKIX validation, but PKIX
+      validation is not tested for certificate usage 3.
+
+   The certificate usages defined in this document explicitly only apply
+   to PKIX-formatted certificates in DER encoding [X.690].  If TLS
+   allows other formats later, or if extensions to this RRtype are made
+   that accept other formats for certificates, those certificates will
+   need their own certificate usage values.
+
+2.1.2.  The Selector Field
+
+   A one-octet value, called "selector", specifies which part of the TLS
+   certificate presented by the server will be matched against the
+   association data.  This value is defined in a new IANA registry (see
+   Section 7.3).  The selectors defined in this document are:
+
+
+
+
+Hoffman & Schlyter           Standards Track                    [Page 8]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+      0 -- Full certificate: the Certificate binary structure as defined
+      in [RFC5280]
+
+      1 -- SubjectPublicKeyInfo: DER-encoded binary structure as defined
+      in [RFC5280]
+
+   (Note that the use of "selector" in this document is completely
+   unrelated to the use of "selector" in DomainKeys Identified Mail
+   (DKIM) [RFC6376].)
+
+2.1.3.  The Matching Type Field
+
+   A one-octet value, called "matching type", specifies how the
+   certificate association is presented.  This value is defined in a new
+   IANA registry (see Section 7.4).  The types defined in this document
+   are:
+
+      0 -- Exact match on selected content
+
+      1 -- SHA-256 hash of selected content [RFC6234]
+
+      2 -- SHA-512 hash of selected content [RFC6234]
+
+   If the TLSA record's matching type is a hash, having the record use
+   the same hash algorithm that was used in the signature in the
+   certificate (if possible) will assist clients that support a small
+   number of hash algorithms.
+
+2.1.4.  The Certificate Association Data Field
+
+   This field specifies the "certificate association data" to be
+   matched.  These bytes are either raw data (that is, the full
+   certificate or its SubjectPublicKeyInfo, depending on the selector)
+   for matching type 0, or the hash of the raw data for matching types 1
+   and 2.  The data refers to the certificate in the association, not to
+   the TLS ASN.1 Certificate object.
+
+2.2.  TLSA RR Presentation Format
+
+   The presentation format of the RDATA portion (as defined in
+   [RFC1035]) is as follows:
+
+   o  The certificate usage field MUST be represented as an 8-bit
+      unsigned integer.
+
+   o  The selector field MUST be represented as an 8-bit unsigned
+      integer.
+
+
+
+
+Hoffman & Schlyter           Standards Track                    [Page 9]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   o  The matching type field MUST be represented as an 8-bit unsigned
+      integer.
+
+   o  The certificate association data field MUST be represented as a
+      string of hexadecimal characters.  Whitespace is allowed within
+      the string of hexadecimal characters, as described in [RFC1035].
+
+2.3.  TLSA RR Examples
+
+   In the following examples, the domain name is formed using the rules
+   in Section 3.
+
+   An example of a hashed (SHA-256) association of a PKIX CA
+   certificate:
+
+   _443._tcp.www.example.com. IN TLSA (
+      0 0 1 d2abde240d7cd3ee6b4b28c54df034b9
+            7983a1d16e8a410e4561cb106618e971 )
+
+   An example of a hashed (SHA-512) subject public key association of a
+   PKIX end entity certificate:
+
+   _443._tcp.www.example.com. IN TLSA (
+      1 1 2 92003ba34942dc74152e2f2c408d29ec
+            a5a520e7f2e06bb944f4dca346baf63c
+            1b177615d466f6c4b71c216a50292bd5
+            8c9ebdd2f74e38fe51ffd48c43326cbc )
+
+   An example of a full certificate association of a PKIX end entity
+   certificate:
+
+   _443._tcp.www.example.com. IN TLSA (
+      3 0 0 30820307308201efa003020102020... )
+
+3.  Domain Names for TLSA Certificate Associations
+
+   Unless there is a protocol-specific specification that is different
+   than this one, TLSA resource records are stored at a prefixed DNS
+   domain name.  The prefix is prepared in the following manner:
+
+   1.  The decimal representation of the port number on which a TLS-
+       based service is assumed to exist is prepended with an underscore
+       character ("_") to become the left-most label in the prepared
+       domain name.  This number has no leading zeros.
+
+
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 10]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   2.  The protocol name of the transport on which a TLS-based service
+       is assumed to exist is prepended with an underscore character
+       ("_") to become the second left-most label in the prepared domain
+       name.  The transport names defined for this protocol are "tcp",
+       "udp", and "sctp".
+
+   3.  The base domain name is appended to the result of step 2 to
+       complete the prepared domain name.  The base domain name is the
+       fully qualified DNS domain name [RFC1035] of the TLS server, with
+       the additional restriction that every label MUST meet the rules
+       of [RFC0952].  The latter restriction means that, if the query is
+       for an internationalized domain name, it MUST use the A-label
+       form as defined in [RFC5890].
+
+   For example, to request a TLSA resource record for an HTTP server
+   running TLS on port 443 at "www.example.com",
+   "_443._tcp.www.example.com" is used in the request.  To request a
+   TLSA resource record for an SMTP server running the STARTTLS protocol
+   on port 25 at "mail.example.com", "_25._tcp.mail.example.com" is
+   used.
+
+4.  Use of TLSA Records in TLS
+
+   Section 2.1 of this document defines the mandatory matching rules for
+   the data from the TLSA certificate associations and the certificates
+   received from the TLS server.
+
+   The TLS session that is to be set up MUST be for the specific port
+   number and transport name that was given in the TLSA query.
+
+   Some specifications for applications that run over TLS, such as
+   [RFC2818] for HTTP, require that the server's certificate have a
+   domain name that matches the host name expected by the client.  Some
+   specifications, such as [RFC6125], detail how to match the identity
+   given in a PKIX certificate with those expected by the user.
+
+   If a TLSA record has certificate usage 2, the corresponding TLS
+   server SHOULD send the certificate that is referenced just like it
+   currently sends intermediate certificates.
+
+4.1.  Usable Certificate Associations
+
+   An implementation of this protocol makes a DNS query for TLSA
+   records, validates these records using DNSSEC, and uses the resulting
+   TLSA records and validation status to modify its responses to the TLS
+   server.
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 11]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   Determining whether a TLSA RRSet can be used MUST be based on the
+   DNSSEC validation state (as defined in [RFC4033]).
+
+   o  A TLSA RRSet whose DNSSEC validation state is secure MUST be used
+      as a certificate association for TLS unless a local policy would
+      prohibit the use of the specific certificate association in the
+      secure TLSA RRSet.
+
+   o  If the DNSSEC validation state on the response to the request for
+      the TLSA RRSet is bogus, this MUST cause TLS not to be started or,
+      if the TLS negotiation is already in progress, MUST cause the
+      connection to be aborted.
+
+   o  A TLSA RRSet whose DNSSEC validation state is indeterminate or
+      insecure cannot be used for TLS and MUST be considered unusable.
+
+   Clients that validate the DNSSEC signatures themselves MUST use
+   standard DNSSEC validation procedures.  Clients that rely on another
+   entity to perform the DNSSEC signature validation MUST use a secure
+   mechanism between themselves and the validator.  Examples of secure
+   transports to other hosts include TSIG [RFC2845], SIG(0) [RFC2931],
+   and IPsec [RFC6071].  Note that it is not sufficient to use secure
+   transport to a DNS resolver that does not do DNSSEC signature
+   validation.  See Section 8.3 for more security considerations related
+   to external validators.
+
+   If a certificate association contains a certificate usage, selector,
+   or matching type that is not understood by the TLS client, that
+   certificate association MUST be considered unusable.  If the
+   comparison data for a certificate is malformed, the certificate
+   association MUST be considered unusable.
+
+   If a certificate association contains a matching type or certificate
+   association data that uses a cryptographic algorithm that is
+   considered too weak for the TLS client's policy, the certificate
+   association MUST be considered unusable.
+
+   If an application receives zero usable certificate associations from
+   a DNS request or from its cache, it processes TLS in the normal
+   fashion without any input from the TLSA records.  If an application
+   receives one or more usable certificate associations, it attempts to
+   match each certificate association with the TLS server's end entity
+   certificate until a successful match is found.  During the TLS
+   handshake, if none of the certificate associations matches the
+   certificate given by the TLS server, the TLS client MUST abort the
+   handshake.
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 12]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   An attacker who is able to divert a user to a server under his
+   control is also likely to be able to block DNS requests from the user
+   or DNS responses being sent to the user.  Thus, in order to achieve
+   any security benefit from certificate usage 0 or 1, an application
+   that sends a request for TLSA records needs to get either a valid
+   signed response containing TLSA records or verification that the
+   domain is insecure or indeterminate.  If a request for a TLSA record
+   does not meet one of those two criteria but the application continues
+   with the TLS handshake anyway, the application has gotten no benefit
+   from TLSA and SHOULD NOT make any internal or external indication
+   that TLSA was applied.  If an application has a configuration setting
+   that has turned on TLSA use, or has any indication that TLSA is in
+   use (regardless of whether or not this is configurable), that
+   application either MUST NOT start a TLS connection or it MUST abort a
+   TLS handshake if both of the two criteria above are not met.
+
+   The application can perform the TLSA lookup before initiating the TLS
+   handshake, or do it during the TLS handshake: the choice is up to the
+   client.
+
+5.  TLSA and DANE Use Cases and Requirements
+
+   The different types of certificate associations defined in TLSA are
+   matched with various sections of [RFC6394].  The use cases from
+   Section 3 of [RFC6394] are covered in this document as follows:
+
+   3.1 CA Constraints -- Implemented using certificate usage 0.
+
+   3.2 Certificate Constraints -- Implemented using certificate usage 1.
+
+   3.3 Trust Anchor Assertion and Domain-Issued Certificates --
+      Implemented using certificate usages 2 and 3, respectively.
+
+   The requirements from Section 4 of [RFC6394] are covered in this
+   document as follows:
+
+   Multiple Ports -- The TLSA records for different application services
+      running on a single host can be distinguished through the service
+      name and port number prefixed to the host name (see Section 3).
+
+   No Downgrade -- Section 4 specifies the conditions under which a
+      client can process and act upon TLSA records.  Specifically, if
+      the DNSSEC status for the TLSA resource record set is determined
+      to be bogus, the TLS connection (if started) will fail.
+
+   Encapsulation -- Encapsulation is covered in the TLSA response
+      semantics.
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 13]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   Predictability -- The appendices of this specification provide
+      operational considerations and implementation guidance in order to
+      enable application developers to form a consistent interpretation
+      of the recommended client behavior.
+
+   Opportunistic Security -- If a client conformant to this
+      specification can reliably determine the presence of a TLSA
+      record, it will attempt to use this information.  Conversely, if a
+      client can reliably determine the absence of any TLSA record, it
+      will fall back to processing TLS in the normal fashion.  This is
+      discussed in Section 4.
+
+   Combination -- Multiple TLSA records can be published for a given
+      host name, thus enabling the client to construct multiple TLSA
+      certificate associations that reflect different assertions.  No
+      support is provided to combine two TLSA certificate associations
+      in a single operation.
+
+   Roll-over -- TLSA records are processed in the normal manner within
+      the scope of the DNS protocol, including the TTL expiration of the
+      records.  This ensures that clients will not latch onto assertions
+      made by expired TLSA records, and will be able to transition from
+      using one public key or certificate usage to another.
+
+   Simple Key Management -- The SubjectPublicKeyInfo selector in the
+      TLSA record provides a mode that enables a domain holder to only
+      have to maintain a single long-lived public/private key pair
+      without the need to manage certificates.  Appendix A outlines the
+      usefulness and the potential downsides to using this mode.
+
+   Minimal Dependencies -- This specification relies on DNSSEC to
+      protect the origin authenticity and integrity of the TLSA resource
+      record set.  Additionally, if DNSSEC validation is not performed
+      on the system that wishes to use TLSA certificate bindings, this
+      specification requires that the "last mile" be over a secure
+      transport.  There are no other deployment dependencies for this
+      approach.
+
+   Minimal Options -- The operating modes map precisely to the DANE use
+      cases and requirements.  DNSSEC use is mandatory in that this
+      specification encourages applications to use only those TLSA
+      records that are shown to be validated.
+
+   Wildcards -- Wildcards are covered in a limited manner in the TLSA
+      request syntax; see Appendix A.
+
+   Redirection -- Redirection is covered in the TLSA request syntax; see
+      Appendix A.
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 14]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+6.  Mandatory-to-Implement Features
+
+   TLS clients conforming to this specification MUST be able to
+   correctly interpret TLSA records with certificate usages 0, 1, 2,
+   and 3.  TLS clients conforming to this specification MUST be able to
+   compare a certificate association with a certificate from the TLS
+   handshake using selector types 0 and 1, and matching type 0 (no hash
+   used) and matching type 1 (SHA-256), and SHOULD be able to make such
+   comparisons with matching type 2 (SHA-512).
+
+7.  IANA Considerations
+
+   IANA has made the assignments in this section.
+
+   In the following sections, "RFC Required" was chosen for TLSA
+   certificate usages and "Specification Required" for selectors and
+   matching types because of the amount of detail that is likely to be
+   needed for implementers to correctly implement new certificate usages
+   as compared to new selectors and matching types.
+
+7.1.  TLSA RRtype
+
+   This document uses a new DNS RR type, TLSA, whose value (52) was
+   allocated by IANA from the Resource Record (RR) TYPEs subregistry of
+   the Domain Name System (DNS) Parameters registry.
+
+7.2.  TLSA Certificate Usages
+
+   This document creates a new registry, "TLSA Certificate Usages".  The
+   registry policy is "RFC Required".  The initial entries in the
+   registry are:
+
+   Value    Short description                       Reference
+   ----------------------------------------------------------
+   0        CA constraint                           RFC 6698
+   1        Service certificate constraint          RFC 6698
+   2        Trust anchor assertion                  RFC 6698
+   3        Domain-issued certificate               RFC 6698
+   4-254    Unassigned
+   255      Private use
+
+   Applications to the registry can request specific values that have
+   yet to be assigned.
+
+
+
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 15]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+7.3.  TLSA Selectors
+
+   This document creates a new registry, "TLSA Selectors".  The registry
+   policy is "Specification Required".  The initial entries in the
+   registry are:
+
+   Value    Short description                       Reference
+   ----------------------------------------------------------
+   0        Full certificate                        RFC 6698
+   1        SubjectPublicKeyInfo                    RFC 6698
+   2-254    Unassigned
+   255      Private use
+
+   Applications to the registry can request specific values that have
+   yet to be assigned.
+
+7.4.  TLSA Matching Types
+
+   This document creates a new registry, "TLSA Matching Types".  The
+   registry policy is "Specification Required".  The initial entries in
+   the registry are:
+
+   Value    Short description                       Reference
+   ----------------------------------------------------------
+   0        No hash used                            RFC 6698
+   1        SHA-256                                 RFC 6234
+   2        SHA-512                                 RFC 6234
+   3-254    Unassigned
+   255      Private use
+
+   Applications to the registry can request specific values that have
+   yet to be assigned.
+
+8.  Security Considerations
+
+   The security of the DNS RRtype described in this document relies on
+   the security of DNSSEC to verify that the TLSA record has not been
+   altered.
+
+   A rogue DNS administrator who changes the A, AAAA, and/or TLSA
+   records for a domain name can cause the client to go to an
+   unauthorized server that will appear authorized, unless the client
+   performs PKIX certification path validation and rejects the
+   certificate.  That administrator could probably get a certificate
+   issued by some CA anyway, so this is not an additional threat.
+
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 16]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   If the authentication mechanism for adding or changing TLSA data in a
+   zone is weaker than the authentication mechanism for changing the A
+   and/or AAAA records, a man-in-the-middle who can redirect traffic to
+   his site may be able to impersonate the attacked host in TLS if he
+   can use the weaker authentication mechanism.  A better design for
+   authenticating DNS would be to have the same level of authentication
+   used for all DNS additions and changes for a particular domain name.
+
+   Secure Socket Layer (SSL) proxies can sometimes act as a man-in-the-
+   middle for TLS clients.  In these scenarios, the clients add a new
+   trust anchor whose private key is kept on the SSL proxy; the proxy
+   intercepts TLS requests, creates a new TLS session with the intended
+   host, and sets up a TLS session with the client using a certificate
+   that chains to the trust anchor installed in the client by the proxy.
+   In such environments, using TLSA records will prevent the SSL proxy
+   from functioning as expected because the TLS client will get a
+   certificate association from the DNS that will not match the
+   certificate that the SSL proxy uses with the client.  The client,
+   seeing the proxy's new certificate for the supposed destination, will
+   not set up a TLS session.
+
+   Client treatment of any information included in the trust anchor is a
+   matter of local policy.  This specification does not mandate that
+   such information be inspected or validated by the server's domain
+   name administrator.
+
+   If a server's certificate is revoked, or if an intermediate CA in a
+   chain between the server and a trust anchor has its certificate
+   revoked, a TLSA record with a certificate usage of 2 that matches the
+   revoked certificate would in essence override the revocation because
+   the client would treat that revoked certificate as a trust anchor and
+   thus not check its revocation status.  Because of this, domain
+   administrators need to be responsible for being sure that the keys or
+   certificates used in TLSA records with a certificate usage of 2 are
+   in fact able to be used as reliable trust anchors.
+
+   Certificates that are delivered in TLSA with certificate usage 2
+   fundamentally change the way the TLS server's end entity certificate
+   is evaluated.  For example, the server's certificate might chain to
+   an existing CA through an intermediate CA that has certain policy
+   restrictions, and the certificate would not pass those restrictions
+   and thus normally be rejected.  That intermediate CA could issue
+   itself a new certificate without the policy restrictions and tell its
+   customers to use that certificate with certificate usage 2.  This in
+   essence allows an intermediate CA to become a trust anchor for
+   certificates that the end user might have expected to chain to an
+   existing trust anchor.
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 17]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   If an administrator wishes to stop using a TLSA record, the
+   administrator can simply remove it from the DNS.  Normal clients will
+   stop using the TLSA record after the TTL has expired.  Replay attacks
+   against the TLSA record are not possible after the expiration date on
+   the RRsig of the TLSA record that was removed.
+
+   Generators of TLSA records should be aware that the client's full
+   trust of a certificate association retrieved from a TLSA record may
+   be a matter of local policy.  While such trust is limited to the
+   specific domain name, protocol, and port for which the TLSA query was
+   made, local policy may decline to accept the certificate (for reasons
+   such as weak cryptography), as is also the case with PKIX trust
+   anchors.
+
+8.1.  Comparing DANE to Public CAs
+
+   As stated above, the security of the DNS RRtype described in this
+   document relies on the security of DNSSEC to verify that the TLSA
+   record has not been altered.  This section describes where the
+   security of public CAs and the security of TLSA are similar and
+   different.  This section applies equally to other security-related
+   DNS RRtypes such as keys for IPsec and SSH.
+
+   DNSSEC forms certificates (the binding of an identity to a key) by
+   combining a DNSKEY, DS, or DLV resource record with an associated
+   RRSIG record.  These records then form a signing chain extending from
+   the client's trust anchors to the RR of interest.
+
+   Although the DNSSEC protocol does not enforce it, DNSKEYs are often
+   marked with a SEP flag indicating whether the key is a Zone Signing
+   Key (ZSK) or a Key Signing Key (KSK).  ZSKs protect records in the
+   zone (including DS and DLV records), and KSKs protect ZSK DNSKEY
+   records.  This allows KSKs to be stored offline.
+
+   The TLSA RRtype allows keys from the DNSSEC PKI hierarchy to
+   authenticate keys wrapped in PKIX certificates for a particular host
+   name, protocol, and port.
+
+   With the exception of the DLV RRtype, all of these certificates
+   constrain the keys they identify to names that are within the zone
+   signing the certificate.  In order for a domain's DLV resource
+   records to be honored, the domain must be configured as a DLV domain,
+   and the domain's DNSKEYs must be configured as trust anchors or be
+   authentic [RFC5074].
+
+
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 18]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+8.1.1.  Risk of Key Compromise
+
+   The risk that a given certificate that has a valid signing chain is
+   fake is related to the number of keys that can contribute to the
+   validation of the certificate, the quality of protection each private
+   key receives, the value of each key to an attacker, and the value of
+   falsifying the certificate.
+
+   DNSSEC allows any set of domains to be configured as trust anchors
+   and/or DLVs, but most clients are likely to use the root zone as
+   their only trust anchor.  Also, because a given DNSKEY can only sign
+   resource records for that zone, the number of private keys capable of
+   compromising a given TLSA resource record is limited to the number of
+   zones between the TLSA resource record and the nearest trust anchor,
+   plus any configured DLV domains.  Typically, this will be six keys,
+   half of which will be KSKs.
+
+   PKIX only describes how to validate a certificate based on a client-
+   chosen set of trust anchors, but says nothing about how many trust
+   anchors to use or how they should be constrained.  As currently
+   deployed, most PKIX clients use a large number of trust anchors
+   provided with the client or operating system software.  These trust
+   anchors are selected carefully, but with a desire for broad
+   interoperability.  The trust anchors and CA certificates for public
+   CAs rarely have name constraints applied.
+
+   A combination of technical protections, process controls, and
+   personnel experience contribute to the quality of security that keys
+   receive.
+
+   o  The security surrounding DNSSEC DNSKEYs varies significantly.  The
+      KSK/ZSK split allows the KSK to be stored offline and protected
+      more carefully than the ZSK, but not all domains do so.  The
+      security applied to a zone's DNSKEYs should be proportional to the
+      value of the domain, but that is difficult to estimate.  For
+      example, the root DNSKEY has protections and controls comparable
+      to or exceeding those of public CAs.  On the other end of the
+      spectrum, small domains might provide no more protection to their
+      keys than they do to their other data.
+
+   o  The security surrounding public CAs also varies.  However, due to
+      financial incentives and standards imposed by clients for
+      acceptance into their trust anchor stores, CAs generally employ
+      security experts and protect their keys carefully, though highly
+      public compromises have occurred.
+
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 19]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+8.1.2.  Impact of Key Compromise
+
+   The impact of a key compromise differs significantly between the two
+   models.
+
+   o  DNSKEYs are inherently limited in what they can sign, so a
+      compromise of the DNSKEY for "example.com" provides no avenue of
+      attack against "example.org".  Even the impact of a compromise of
+      .com's DNSKEY, while considerable, would be limited to .com
+      domains.  Only the compromise of the root DNSKEY would have the
+      equivalent impact of an unconstrained public CA.
+
+   o  Public CAs are not typically constrained in what names they can
+      sign, and therefore a compromise of even one CA allows the
+      attacker to generate a certificate for any name in the DNS.  A
+      domain holder can get a certificate from any willing CA, or even
+      multiple CAs simultaneously, making it impossible for a client to
+      determine whether the certificate it is validating is legitimate
+      or fraudulent.
+
+   Because a TLSA certificate association is constrained to its
+   associated name, protocol, and port, the PKIX certificate is
+   similarly constrained, even if its public CAs signing the certificate
+   (if any) are not.
+
+8.1.3.  Detection of Key Compromise
+
+   If a key is compromised, rapid and reliable detection is important in
+   order to limit the impact of the compromise.  In this regard, neither
+   model prevents an attacker from near-invisibly attacking their
+   victim, provided that the necessary keys are compromised.
+
+   If a public CA is compromised, only the victim will see the
+   fraudulent certificate, as there is typically no publicly accessible
+   directory of all the certificates issued by a CA that can be
+   inspected.  DNS resource records are typically published publicly.
+   However, the attacker could also allow the uncompromised records to
+   be published to the Internet as usual but provide a compromised DNS
+   view to the victim to achieve the same effect.
+
+8.1.4.  Spoofing Hostnames
+
+   Some CAs implement technical controls to ensure that certificates are
+   not issued to domains with names similar to domains that are popular
+   and prone to attack.  Of course, an attacker can attempt to
+   circumvent this restriction by finding a CA willing to issue the
+   certificate anyway.  However, by using DNSSEC and TLSA, the attacker
+   can circumvent this check completely.
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 20]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+8.2.  DNS Caching
+
+   Implementations of this protocol rely heavily on the DNS, and are
+   thus prone to security attacks based on the deliberate
+   mis-association of TLSA records and DNS names.  Implementations need
+   to be cautious in assuming the continuing validity of an association
+   between a TLSA record and a DNS name.
+
+   In particular, implementations SHOULD rely on their DNS resolver for
+   confirmation of an association between a TLSA record and a DNS name,
+   rather than caching the result of previous domain name lookups.  Many
+   platforms already can cache domain name lookups locally when
+   appropriate, and they SHOULD be configured to do so.  It is proper
+   for these lookups to be cached, however, only when the TTL (Time To
+   Live) information reported by the DNS makes it likely that the cached
+   information will remain useful.
+
+   If implementations cache the results of domain name lookups in order
+   to achieve a performance improvement, they MUST observe the TTL
+   information reported by DNS.  Implementations that fail to follow
+   this rule could be spoofed or have access denied when a previously
+   accessed server's TLSA record changes, such as during a certificate
+   rollover.
+
+8.3.  External DNSSEC Validators
+
+   Due to a lack of DNSSEC support in the most commonly deployed stub
+   resolvers today, some ISPs have begun checking DNSSEC in the
+   recursive resolvers they provide to their customers, setting the
+   Authentic Data (AD) flag as appropriate.  DNSSEC-aware clients could
+   use that data, ignoring the fact that the DNSSEC data has been
+   validated externally.  Because there is typically no authentication
+   of the recursive resolver or integrity protection of the data and AD
+   flag between the client and the recursive resolver, this can be
+   trivially spoofed by an attacker.
+
+   However, even with secure communications between a host and the
+   external validating resolver, there is a risk that the external
+   validator could become compromised.  Nothing prevents a compromised
+   external DNSSEC validator from claiming that all the records it
+   provides are secure, even if the data is falsified, unless the client
+   checks the DNSSEC data itself (rendering the external validator
+   unnecessary).
+
+   For this reason, DNSSEC validation is best performed on-host, even
+   when a secure path to an external validator is available.
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 21]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+9.  Acknowledgements
+
+   Many of the ideas in this document have been discussed over many
+   years.  More recently, the ideas have been discussed by the authors
+   and others in a more focused fashion.  In particular, some of the
+   ideas and words here originated with Paul Vixie, Dan Kaminsky, Jeff
+   Hodges, Phillip Hallam-Baker, Simon Josefsson, Warren Kumari, Adam
+   Langley, Ben Laurie, Ilari Liusvaara, Ondrej Mikle, Scott Schmit,
+   Ondrej Sury, Richard Barnes, Jim Schaad, Stephen Farrell, Suresh
+   Krishnaswamy, Peter Palfrader, Pieter Lexis, Wouter Wijngaards, John
+   Gilmore, and Murray Kucherawy.
+
+   This document has also been greatly helped by many active
+   participants of the DANE Working Group.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
+
+   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Resource Records for the DNS Security Extensions",
+              RFC 4034, March 2005.
+
+   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, March 2005.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+   [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, May 2008.
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 22]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
+              Verification of Domain-Based Application Service Identity
+              within Internet Public Key Infrastructure Using X.509
+              (PKIX) Certificates in the Context of Transport Layer
+              Security (TLS)", RFC 6125, March 2011.
+
+   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+              Security Version 1.2", RFC 6347, January 2012.
+
+10.2.  Informative References
+
+   [RFC0952]  Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
+              host table specification", RFC 952, October 1985.
+
+   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+              specifying the location of services (DNS SRV)", RFC 2782,
+              February 2000.
+
+   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
+              Wellington, "Secret Key Transaction Authentication for DNS
+              (TSIG)", RFC 2845, May 2000.
+
+   [RFC2931]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
+              ( SIG(0)s)", RFC 2931, September 2000.
+
+   [RFC4025]  Richardson, M., "A Method for Storing IPsec Keying
+              Material in DNS", RFC 4025, March 2005.
+
+   [RFC4255]  Schlyter, J. and W. Griffin, "Using DNS to Securely
+              Publish Secure Shell (SSH) Key Fingerprints", RFC 4255,
+              January 2006.
+
+   [RFC4641]  Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
+              RFC 4641, September 2006.
+
+   [RFC5074]  Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074,
+              November 2007.
+
+   [RFC5890]  Klensin, J., "Internationalized Domain Names for
+              Applications (IDNA): Definitions and Document Framework",
+              RFC 5890, August 2010.
+
+   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
+              Extensions: Extension Definitions", RFC 6066,
+              January 2011.
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 23]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   [RFC6071]  Frankel, S. and S. Krishnan, "IP Security (IPsec) and
+              Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
+              February 2011.
+
+   [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
+              (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
+
+   [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
+              "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376,
+              September 2011.
+
+   [RFC6394]  Barnes, R., "Use Cases and Requirements for DNS-Based
+              Authentication of Named Entities (DANE)", RFC 6394,
+              October 2011.
+
+   [X.690]    "Recommendation ITU-T X.690 (2002) | ISO/IEC 8825-1:2002,
+              Information technology - ASN.1 encoding rules:
+              Specification of Basic Encoding Rules (BER), Canonical
+              Encoding Rules (CER) and Distinguished Encoding Rules
+              (DER)", July 2002.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 24]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+Appendix A.  Operational Considerations for Deploying TLSA Records
+
+A.1.  Creating TLSA Records
+
+   When creating TLSA records, care must be taken to avoid
+   misconfigurations.  Section 4 of this document states that a TLSA
+   RRSet whose validation state is secure MUST be used.  This means that
+   the existence of such a RRSet effectively disables other forms of
+   name and path validation.  A misconfigured TLSA RRSet will
+   effectively disable access to the TLS server for all conforming
+   clients, and this document does not provide any means of making a
+   gradual transition to using TLSA.
+
+   When creating TLSA records with certificate usage 0 (CA certificate)
+   or usage 2 (trust anchor), one needs to understand the implications
+   when choosing between selector type 0 (Full certificate) and 1
+   (SubjectPublicKeyInfo).  A careful choice is required because
+   different methods for building trust chains are used by different TLS
+   clients.  The following outlines the cases that one ought to be aware
+   of and discusses the implications of the choice of selector type.
+
+   Certificate usage 2 is not affected by the different types of chain
+   building when the end entity certificate is the same as the trust
+   anchor certificate.
+
+A.1.1.  Ambiguities and Corner Cases When TLS Clients Build Trust Chains
+
+   TLS clients can implement their own chain-building code rather than
+   rely on the chain presented by the TLS server.  This means that,
+   except for the end entity certificate, any certificate presented in
+   the suggested chain might or might not be present in the final chain
+   built by the client.
+
+   Certificates that the client can use to replace certificates from the
+   original chain include:
+
+   o  Client's trust anchors
+
+   o  Certificates cached locally
+
+   o  Certificates retrieved from a URI listed in an Authority
+      Information Access X.509v3 extension
+
+   CAs frequently reissue certificates with different validity periods,
+   signature algorithms (such as a different hash algorithm in the
+   signature algorithm), CA key pairs (such as for a cross-certificate),
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 25]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   or PKIX extensions where the public key and subject remain the same.
+   These reissued certificates are the certificates that the TLS client
+   can use in place of an original certificate.
+
+   Clients are known to exchange or remove certificates that could cause
+   TLSA certificate associations that rely on the full certificate to
+   fail.  For example:
+
+   o  The client considers the signature algorithm of a certificate to
+      no longer be sufficiently secure.
+
+   o  The client might not have an associated root certificate in its
+      trust store and instead uses a cross-certificate with an identical
+      subject and public key.
+
+A.1.2.  Choosing a Selector Type
+
+   In this section, "false-negative failure" means that a client will
+   not accept the TLSA certificate association for a certificate
+   designated by the DNS administrator.  Also, "false-positive
+   acceptance" means that the client accepts a TLSA association for a
+   certificate that is not designated by the DNS administrator.
+
+A.1.2.1.  Selector Type 0 (Full Certificate)
+
+   The "Full certificate" selector provides the most precise
+   specification of a TLSA certificate association, capturing all
+   fields of the PKIX certificate.  For a DNS administrator, the best
+   course to avoid false-negative failures in the client when using this
+   selector is:
+
+   1.  If a CA issued a replacement certificate, don't associate to CA
+       certificates that have a signature algorithm with a hash that is
+       considered weak by local policy.
+
+   2.  Determine how common client applications process the TLSA
+       certificate association using a fresh client installation -- that
+       is, with the local certificate cache empty.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 26]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+A.1.2.2.  Selector Type 1 (SubjectPublicKeyInfo)
+
+   A SubjectPublicKeyInfo selector gives greater flexibility in avoiding
+   some false-negative failures caused by trust-chain-building
+   algorithms used in clients.
+
+   One specific use case ought to be noted: creating a TLSA certificate
+   association to CA certificate I1 that directly signed end entity
+   certificate S1 of the server.  The case can be illustrated by the
+   following graph:
+
+           +----+                      +----+
+           | I1 |                      | I2 |
+           +----+                      +----+
+              |                           |
+              v                           v
+           +----+                      +----+
+           | S1 |                      | S1 |
+           +----+                      +----+
+   Certificate chain sent by    A different validation path
+   server in TLS handshake      built by the TLS client
+
+   I2 is a reissued version of CA certificate I1 (that is, it has a
+   different hash in its signature algorithm).
+
+   In the above scenario, both certificates I1 and I2 that sign S1 need
+   to have identical SubjectPublicKeyInfo fields because the key used to
+   sign S1 is fixed.  An association to SubjectPublicKeyInfo (selector
+   type 1) will always succeed in such a case, but an association with a
+   full certificate (selector type 0) might not work due to a false-
+   negative failure.
+
+   The attack surface is a bit broader compared to the "Full
+   certificate" selector: the DNS administrator might unintentionally
+   specify an association that would lead to false-positive acceptance.
+
+   o  The administrator must know or trust that the CA does not engage
+      in bad practices, such as not sharing the key of I1 for unrelated
+      CA certificates (which would lead to trust-chain redirection).  If
+      possible, the administrator ought to review all CA certificates
+      that have the same SubjectPublicKeyInfo field.
+
+   o  The administrator ought to understand whether some PKIX extension
+      may adversely affect security of the association.  If possible,
+      administrators ought to review all CA certificates that share the
+      SubjectPublicKeyInfo.
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 27]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   o  The administrator ought to understand that any CA could, in the
+      future, issue a certificate that contains the same
+      SubjectPublicKeyInfo.  Therefore, new chains can crop up in the
+      future without any warning.
+
+   Using the SubjectPublicKeyInfo selector for association with a
+   certificate in a chain above I1 needs to be decided on a case-by-case
+   basis: there are too many possibilities based on the issuing CA's
+   practices.  Unless the full implications of such an association are
+   understood by the administrator, using selector type 0 is a better
+   option from a security perspective.
+
+A.2.  Provisioning TLSA Records in DNS
+
+A.2.1.  Provisioning TLSA Records with Aliases
+
+   The TLSA resource record is not special in the DNS; it acts exactly
+   like any other RRtype where the queried name has one or more labels
+   prefixed to the base name, such as the SRV RRtype [RFC2782].  This
+   affects the way that the TLSA resource record is used when aliasing
+   in the DNS.
+
+   Note that the IETF sometimes adds new types of aliasing in the DNS.
+   If that happens in the future, those aliases might affect TLSA
+   records, hopefully in a good way.
+
+A.2.1.1.  Provisioning TLSA Records with CNAME Records
+
+   Using CNAME to alias in DNS only aliases from the exact name given,
+   not any zones below the given name.  For example, assume that a zone
+   file has only the following:
+
+   sub1.example.com.          IN CNAME sub2.example.com.
+
+   In this case, a request for the A record at "bottom.sub1.example.com"
+   would not return any records because the CNAME given only aliases the
+   name given.  Assume, instead, the zone file has the following:
+
+   sub3.example.com.          IN CNAME sub4.example.com.
+   bottom.sub3.example.com.   IN CNAME bottom.sub4.example.com.
+
+   In this case, a request for the A record at bottom.sub3.example.com
+   would in fact return whatever value for the A record exists at
+   bottom.sub4.example.com.
+
+
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 28]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   Application implementations and full-service resolvers request DNS
+   records using libraries that automatically follow CNAME (and DNAME)
+   aliasing.  This allows hosts to put TLSA records in their own zones
+   or to use CNAME to do redirection.
+
+   If the owner of the original domain wants a TLSA record for the same,
+   they simply enter it under the defined prefix:
+
+   ; No TLSA record in target domain
+   ;
+   sub5.example.com.            IN CNAME sub6.example.com.
+   _443._tcp.sub5.example.com.  IN TLSA 1 1 1 308202c5308201ab...
+   sub6.example.com.            IN A 192.0.2.1
+   sub6.example.com.            IN AAAA 2001:db8::1
+
+   If the owner of the original domain wants to have the target domain
+   host the TLSA record, the original domain uses a CNAME record:
+
+   ; TLSA record for original domain has CNAME to target domain
+   ;
+   sub5.example.com.            IN CNAME sub6.example.com.
+   _443._tcp.sub5.example.com.  IN CNAME _443._tcp.sub6.example.com.
+   sub6.example.com.            IN A 192.0.2.1
+   sub6.example.com.            IN AAAA 2001:db8::1
+   _443._tcp.sub6.example.com.  IN TLSA 1 1 1 536a570ac49d9ba4...
+
+   Note that it is acceptable for both the original domain and the
+   target domain to have TLSA records, but the two records are
+   unrelated.  Consider the following:
+
+   ; TLSA record in both the original and target domain
+   ;
+   sub5.example.com.            IN CNAME sub6.example.com.
+   _443._tcp.sub5.example.com.  IN TLSA 1 1 1 308202c5308201ab...
+   sub6.example.com.            IN A 192.0.2.1
+   sub6.example.com.            IN AAAA 2001:db8::1
+   _443._tcp.sub6.example.com.  IN TLSA 1 1 1 ac49d9ba4570ac49...
+
+   In this example, someone looking for the TLSA record for
+   sub5.example.com would always get the record whose value starts with
+   "308202c5308201ab"; the TLSA record whose value starts with
+   "ac49d9ba4570ac49" would only be sought by someone who is looking for
+   the TLSA record for sub6.example.com, and never for sub5.example.com.
+   Note that deploying different certificates for multiple services
+   located at a shared TLS listener often requires the use of TLS SNI
+   (Server Name Indication) [RFC6066].
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 29]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   Note that these methods use the normal method for DNS aliasing using
+   CNAME: the DNS client requests the record type that they actually
+   want.
+
+A.2.1.2.  Provisioning TLSA Records with DNAME Records
+
+   Using DNAME records allows a zone owner to alias an entire subtree of
+   names below the name that has the DNAME.  This allows the wholesale
+   aliasing of prefixed records such as those used by TLSA, SRV, and so
+   on without aliasing the name itself.  However, because DNAME can only
+   be used for subtrees of a base name, it is rarely used to alias
+   individual hosts that might also be running TLS.
+
+   ; TLSA record in target domain, visible in original domain via DNAME
+   ;
+   sub5.example.com.            IN CNAME sub6.example.com.
+   _tcp.sub5.example.com.       IN DNAME _tcp.sub6.example.com.
+   sub6.example.com.            IN A 192.0.2.1
+   sub6.example.com.            IN AAAA 2001:db8::1
+   _443._tcp.sub6.example.com.  IN TLSA 1 1 1 536a570ac49d9ba4...
+
+A.2.1.3.  Provisioning TLSA Records with Wildcards
+
+   Wildcards are generally not terribly useful for RRtypes that require
+   prefixing because one can only wildcard at a layer below the host
+   name.  For example, if one wants to have the same TLSA record for
+   every TCP port for www.example.com, the result might be:
+
+   *._tcp.www.example.com.    IN TLSA 1 1 1 5c1502a6549c423b...
+
+   This is possibly useful in some scenarios where the same service is
+   offered on many ports or the same certificate and/or key is used for
+   all services on a host.  Note that the domain being searched for is
+   not necessarily related to the domain name found in the certificate,
+   so a certificate with a wildcard in it is not searched for using a
+   wildcard in the search request.
+
+A.3.  Securing the Last Hop
+
+   As described in Section 4, an application processing TLSA records
+   must know the DNSSEC validity of those records.  There are many ways
+   for the application to determine this securely, and this
+   specification does not mandate any single method.
+
+
+
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 30]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   Some common methods for an application to know the DNSSEC validity of
+   TLSA records include:
+
+   o  The application can have its own DNS resolver and DNSSEC
+      validation stack.
+
+   o  The application can communicate through a trusted channel (such as
+      requests to the operating system under which the application is
+      running) to a local DNS resolver that does DNSSEC validation.
+
+   o  The application can communicate through a secured channel (such as
+      requests running over TLS, IPsec, TSIG, or SIG(0)) to a non-local
+      DNS resolver that does DNSSEC validation.
+
+   o  The application can communicate through a secured channel (such as
+      requests running over TLS, IPsec, TSIG, or SIG(0)) to a non-local
+      DNS resolver that does not do DNSSEC validation, but gets
+      responses through a secured channel from a different DNS resolver
+      that does DNSSEC validation.
+
+A.4.  Handling Certificate Rollover
+
+   Certificate rollover is handled in much the same way as for rolling
+   DNSSEC zone signing keys using the pre-publish key rollover method
+   [RFC4641].  Suppose example.com has a single TLSA record for a TLS
+   service on TCP port 990:
+
+   _990._tcp.example.com IN TLSA 1 1 1 1CFC98A706BCF3683015...
+
+   To start the rollover process, obtain or generate the new certificate
+   or SubjectPublicKeyInfo to be used after the rollover and generate
+   the new TLSA record.  Add that record alongside the old one:
+
+   _990._tcp.example.com IN TLSA 1 1 1 1CFC98A706BCF3683015...
+   _990._tcp.example.com IN TLSA 1 1 1 62D5414CD1CC657E3D30...
+
+   After the new records have propagated to the authoritative
+   nameservers and the TTL of the old record has expired, switch to the
+   new certificate on the TLS server.  Once this has occurred, the old
+   TLSA record can be removed:
+
+   _990._tcp.example.com IN TLSA 1 1 1 62D5414CD1CC657E3D30...
+
+   This completes the certificate rollover.
+
+
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 31]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+Appendix B.  Pseudocode for Using TLSA
+
+   This appendix describes, in pseudocode format, the interactions given
+   earlier in this specification.  If the steps below disagree with the
+   text earlier in the document, the steps earlier in the document ought
+   to be considered correct and this text incorrect.
+
+   Note that this pseudocode is more strict than the normative text.
+   For instance, it forces an order on the evaluation of criteria, which
+   is not mandatory from the normative text.
+
+B.1.  Helper Functions
+
+   // implement the function for exiting
+   function Finish (F) = {
+     if (F == ABORT_TLS) {
+       abort the TLS handshake or prevent TLS from starting
+       exit
+     }
+
+     if (F == NO_TLSA) {
+       fall back to non-TLSA certificate validation
+       exit
+     }
+
+     if (F == ACCEPT) {
+       accept the TLS connection
+       exit
+     }
+
+     // unreachable
+   }
+
+   // implement the selector function
+   function Select (S, X) = {
+     // Full certificate
+     if (S == 0) {
+       return X in DER encoding
+     }
+
+     // SubjectPublicKeyInfo
+     if (S == 1) {
+       return X.SubjectPublicKeyInfo in DER encoding
+     }
+
+     // unreachable
+   }
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 32]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   // implement the matching function
+   function Match (M, X, Y) {
+     // Exact match on selected content
+     if (M == 0) {
+       return (X == Y)
+     }
+
+     // SHA-256 hash of selected content
+     if (M == 1) {
+       return (SHA-256(X) == Y)
+     }
+
+     // SHA-512 hash of selected content
+     if (M == 2) {
+       return (SHA-512(X) == Y)
+     }
+
+     // unreachable
+   }
+
+B.2.  Main TLSA Pseudocode
+
+   TLS connect using [transport] to [name] on [port] and receiving end
+   entity cert C for the TLS server:
+
+   (TLSArecords, ValState) = DNSSECValidatedLookup(
+     domainname=_[port]._[transport].[name], RRtype=TLSA)
+
+   // check for states that would change processing
+   if (ValState == BOGUS) {
+     Finish(ABORT_TLS)
+   }
+   if ((ValState == INDETERMINATE) or (ValState == INSECURE)) {
+     Finish(NO_TLSA)
+   }
+   // if here, ValState must be SECURE
+
+   for each R in TLSArecords {
+     // unusable records include unknown certUsage, unknown
+     // selectorType, unknown matchingType, erroneous RDATA, and
+     // prohibited by local policy
+     if (R is unusable) {
+       remove R from TLSArecords
+     }
+   }
+   if (length(TLSArecords) == 0) {
+     Finish(NO_TLSA)
+   }
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 33]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   // A TLS client might have multiple trust anchors that it might use
+   //    when validating the TLS server's end entity (EE) certificate.
+   //    Also, there can be multiple PKIX certification paths for the
+   //    certificates given by the server in TLS.  Thus, there are
+   //    possibly many chains that might need to be tested during
+   //    PKIX path validation.
+
+   for each R in TLSArecords {
+
+     // pass PKIX certificate validation and chain through a CA cert
+     //    that comes from TLSA
+     if (R.certUsage == 0) {
+       for each PKIX certification path H {
+         if (C passes PKIX certification path validation in H) {
+           for each D in H {
+             if ((D is a CA certificate) and
+                 Match(R.matchingType, Select(R.selectorType, D),
+                       R.cert)) {
+               Finish(ACCEPT)
+             }
+           }
+         }
+       }
+     }
+
+     // pass PKIX certificate validation and match EE cert from TLSA
+     if (R.certUsage == 1) {
+       for each PKIX certification path H {
+         if ((C passes PKIX certificate validation in H) and
+                 Match(R.matchingType, Select(R.selectorType, C),
+                 R.cert)) {
+             Finish(ACCEPT)
+         }
+       }
+     }
+
+     // pass PKIX certification validation using TLSA record as the
+     //    trust anchor
+     if (R.certUsage == 2) {
+       // the following assert() is merely a formalization of the
+       // "trust anchor" condition for a certificate D matching R
+       assert(Match(R.matchingType, Select(R.selectorType, D), R.cert))
+
+
+
+
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 34]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+       for each PKIX certification path H that has certificate D
+           matching R as the trust anchor {
+         if (C passes PKIX validation in H) {
+           Finish(ACCEPT);
+         }
+       }
+     }
+
+     // match the TLSA record and the TLS certificate
+     if (R.certUsage == 3) {
+       if Match(R.matchingType, Select(R.selectorType, C), R.cert)
+         Finish(ACCEPT)
+       }
+     }
+
+   }
+
+   // if here, then none of the TLSA records ended in "Finish(ACCEPT)"
+   //   so abort TLS
+   Finish(ABORT_TLS)
+
+Appendix C.  Examples
+
+   The following are examples of self-signed certificates that have been
+   generated with various selectors and matching types.  They were
+   generated with one piece of software, and validated by an individual
+   using other tools.
+
+   S = Selector
+   M = Matching Type
+
+   S M Association Data
+   0 0 30820454308202BC020900AB58D24E77AD2AF6300D06092A86
+       4886F70D0101050500306C310B3009060355040613024E4C31163014
+       0603550408130D4E6F6F72642D486F6C6C616E643112301006035504
+       071309416D7374657264616D310C300A060355040A13034F53333123
+       30210603550403131A64616E652E6B6965762E70726163746963756D
+       2E6F73332E6E6C301E170D3132303131363136353730335A170D3232
+       303131333136353730335A306C310B3009060355040613024E4C3116
+       30140603550408130D4E6F6F72642D486F6C6C616E64311230100603
+       5504071309416D7374657264616D310C300A060355040A13034F5333
+       312330210603550403131A64616E652E6B6965762E70726163746963
+       756D2E6F73332E6E6C308201A2300D06092A864886F70D0101010500
+       0382018F003082018A0282018100E62C84A5AFE59F0A2A6B250DEE68
+       7AC8C5C604F57D26CEB2119140FFAC38C4B9CBBE8923082E7F81626B
+       6AD5DEA0C8771C74E3CAA7F613054AEFA3673E48FFE47B3F7AF987DE
+       281A68230B24B9DA1A98DCBE51195B60E42FD7517C328D983E26A827
+       C877AB914EE4C1BFDEAD48BD25BE5F2C473BA9C1CBBDDDA0C374D0D5
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 35]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+       8C389CC3D6D8C20662E19CF768F32441B7F7D14AEA8966CE7C32A172
+       2AB38623D008029A9E4702883F8B977A1A1E5292BF8AD72239D40393
+       37B86A3AC60FA001290452177BF1798609A05A130F033457A5212629
+       FBDDB8E70E2A9E6556873C4F7CA46AE4A8B178F05FB319005E1C1C7D
+       4BD77DFA34035563C126AA2C3328B900E7990AC9787F01DA82F74C3D
+       4B6674CCECE1FD4C6EF9E6644F4635EDEDA39D8B0E2F7C8E06DAE775
+       6213BD3D60831175BE290442B4AFC5AE6F46B769855A067C1097E617
+       962529E166F22AEE10DDB981B8CD6FF17D3D70723169038DBFBC1A44
+       9C8D0D31BC683C5F3CE26148E42EC9BBD4D9F261569B25B53C1D7FC2
+       DDFF6B4CAC050203010001300D06092A864886F70D01010505000382
+       0181002B2ABE063E9C86AC4A1F7835372091079C8276A9C2C5D1EC57
+       64DE523FDDABDEAB3FD34E6FE6CBA054580A6785A663595D90132B93
+       D473929E81FA0887D2FFF78A81C7D014B97778AB6AC9E5E690F6F5A9
+       E92BB5FBAB71B857AE69B6E18BDCCB0BA6FCD9D4B084A34F3635148C
+       495D48FE635903B888EC1DEB2610548EDD48D63F86513A4562469831
+       48C0D5DB82D73A4C350A42BB661D763430FC6C8E5F9D13EA1B76AA52
+       A4C358E5EA04000F794618303AB6CEEA4E9A8E9C74D73C1B0B7BAF16
+       DEDE7696B5E2F206F777100F5727E1684D4132F5E692F47AF6756EA8
+       B421000BE031B5D8F0220E436B51FB154FE9595333C13A2403F9DE08
+       E5DDC5A22FD6182E339593E26374450220BC14F3E40FF33F084526B0
+       9C34250702E8A352B332CCCB0F9DE2CF2B338823B92AFC61C0B6B8AB
+       DB5AF718ED8DDA97C298E46B82A01B14814868CFA4F2C36268BFFF4A
+       591F42658BF75918902D3E426DFE1D5FF0FC6A212071F6DA8BD833FE
+       2E560D87775E8EE9333C05B6FB8EB56589D910DB5EA903
+
+   0 1 EFDDF0D915C7BDC5782C0881E1B2A95AD099FBDD06D7B1F779
+       82D9364338D955
+
+   0 2 81EE7F6C0ECC6B09B7785A9418F54432DE630DD54DC6EE9E3C
+       49DE547708D236D4C413C3E97E44F969E635958AA410495844127C04
+       883503E5B024CF7A8F6A94
+
+   1 0 308201A2300D06092A864886F70D01010105000382018F0030
+       82018A0282018100E62C84A5AFE59F0A2A6B250DEE687AC8C5C604F5
+       7D26CEB2119140FFAC38C4B9CBBE8923082E7F81626B6AD5DEA0C877
+       1C74E3CAA7F613054AEFA3673E48FFE47B3F7AF987DE281A68230B24
+       B9DA1A98DCBE51195B60E42FD7517C328D983E26A827C877AB914EE4
+       C1BFDEAD48BD25BE5F2C473BA9C1CBBDDDA0C374D0D58C389CC3D6D8
+       C20662E19CF768F32441B7F7D14AEA8966CE7C32A1722AB38623D008
+       029A9E4702883F8B977A1A1E5292BF8AD72239D4039337B86A3AC60F
+       A001290452177BF1798609A05A130F033457A5212629FBDDB8E70E2A
+       9E6556873C4F7CA46AE4A8B178F05FB319005E1C1C7D4BD77DFA3403
+       5563C126AA2C3328B900E7990AC9787F01DA82F74C3D4B6674CCECE1
+       FD4C6EF9E6644F4635EDEDA39D8B0E2F7C8E06DAE7756213BD3D6083
+       1175BE290442B4AFC5AE6F46B769855A067C1097E617962529E166F2
+       2AEE10DDB981B8CD6FF17D3D70723169038DBFBC1A449C8D0D31BC68
+       3C5F3CE26148E42EC9BBD4D9F261569B25B53C1D7FC2DDFF6B4CAC05
+       0203010001
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 36]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   1 1 8755CDAA8FE24EF16CC0F2C918063185E433FAAF1415664911
+       D9E30A924138C4
+
+   1 2 D43165B4CDF8F8660AECCCC5344D9D9AE45FFD7E6AAB7AB9EE
+       C169B58E11F227ED90C17330CC17B5CCEF0390066008C720CEC6AAE5
+       33A934B3A2D7E232C94AB4
+
+Authors' Addresses
+
+   Paul Hoffman
+   VPN Consortium
+
+   EMail: paul.hoffman@vpnc.org
+
+
+   Jakob Schlyter
+   Kirei AB
+
+   EMail: jakob@kirei.se
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 37]
+