RFC 6394: Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE)
In plain English — editorial summary, not part of the RFC
Many current applications use the certificate-based authentication features in Transport Layer Security (TLS) to allow clients to verify that a connected server properly represents a desired domain name. Typically, this authentication has been based on PKIX certificate chains rooted in well-known certificate authorities (CAs), but additional information can be provided via the DNS itself. This document describes a set of use cases in which the DNS and DNS Security Extensions (DNSSEC) could be used to make assertions that support the TLS authentication process. The main focus of this document is TLS server authentication, but it also covers TLS client authentication for applications where TLS clients are identified by domain names. [STANDARDS-TRACK]
Document record
- Document ID
- RFC6394
- Published
- October 2011
- Authors
- R. Barnes
- Status
- INFORMATIONAL
- Stream
- IETF
- Area
- sec
- Pages
- 12
- Also known as
- —
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 9162Certificate Transparency Version 2.0Current
December 2021
- RFC 5922Domain Certificates in the Session Initiation Protocol (SIP)Current
June 2010
- RFC 6251Using Kerberos Version 5 over the Transport Layer Security (TLS) ProtocolCurrent
May 2011
- RFC 6025ASN.1 TranslationCurrent
October 2010
- RFC 6012Datagram Transport Layer Security (DTLS) Transport Mapping for SyslogUpdated
October 2010
- RFC 6844DNS Certification Authority Authorization (CAA) Resource RecordObsoleted
January 2013
- RFC 5912New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)Updated
June 2010
- RFC 5911New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIMEUpdated
June 2010
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?