RFC 7673: Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records
In plain English — editorial summary, not part of the RFC
The DNS-Based Authentication of Named Entities (DANE) specification (RFC 6698) describes how to use TLSA resource records secured by DNSSEC (RFC 4033) to associate a server's connection endpoint with its Transport Layer Security (TLS) certificate (thus enabling administrators of domain names to specify the keys used in that domain's TLS servers). However, application protocols that use SRV records (RFC 2782) to indirectly name the target server connection endpoints for a service domain name cannot apply the rules from RFC 6698. Therefore, this document provides guidelines that enable such protocols to locate and use TLSA records.
Document record
- Document ID
- RFC7673
- Published
- October 2015
- Authors
- T. Finch; M. Miller; P. Saint-Andre
- Status
- PROPOSED STANDARD
- Stream
- IETF
- Area
- sec
- Pages
- 16
- Also known as
- —
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 7672SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)Current
October 2015
- RFC 7671The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational GuidanceCurrent
October 2015
- RFC 7662OAuth 2.0 Token IntrospectionCurrent
October 2015
- RFC 7685A Transport Layer Security (TLS) ClientHello Padding ExtensionCurrent
October 2015
- RFC 7644System for Cross-domain Identity Management: ProtocolUpdated
September 2015
- RFC 7643System for Cross-domain Identity Management: Core SchemaUpdated
September 2015
- RFC 7642System for Cross-domain Identity Management: Definitions, Overview, Concepts, and RequirementsCurrent
September 2015
- RFC 7638JSON Web Key (JWK) ThumbprintCurrent
September 2015
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?