Skip to main content

TLS Client Authentication via DANE TLSA records
draft-ietf-dance-client-auth-17

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, dance-chairs@ietf.org, dance@ietf.org, debcooley1@gmail.com, draft-ietf-dance-client-auth@ietf.org, mcr+ietf@sandelman.ca, rfc-editor@rfc-editor.org
Subject: Protocol Action: 'TLS Client Authentication via DANE TLSA records' to Proposed Standard (draft-ietf-dance-client-auth-17.txt)

The IESG has approved the following document:
- 'TLS Client Authentication via DANE TLSA records'
  (draft-ietf-dance-client-auth-17.txt) as Proposed Standard

This document is the product of the DANE Authentication for Network Clients
Everywhere Working Group.

The IESG contact persons are Christopher Inacio and Deb Cooley.

A URL of this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dance-client-auth/


Ballot Text

Technical Summary

   The DANE TLSA protocol describes how to publish Transport Layer
   Security (TLS) server certificates or public keys in the DNS.  This
   document describes how to use the TLSA record to publish client
   certificates or public keys, and also the rules and considerations
   for using them with TLS.  In addition, it defines a new TLS
   extension, DANE Client Identity, to convey the client's domain name
   identity to the server.

Working Group Summary

In the early days of this working group, there were many people involved in reviews.  
By the time it reached working group last call the first time, there were a few 
hardy souls who agreed it was ready. 

After the first IETF Last Call, it was recognized that changes were required (changing to (D)TLS1.3 
for example).  Once this work was finished there was a second wglc.

Document Quality

  There has been a DNSOP review, where the guidance has been incorporated.
  No YANG, ASN.1, MIB, Media Types or other types of encodings.

  There are claims that various enterprises want this protocol.  But no
  specific implementations have been listed. 

Personnel

   The Document Shepherd for this document is Michael Richardson. The
   Responsible Area Director is Deb Cooley

RFC Editor Note