DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP
RFC 7929

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
Cc: dane-chairs@ietf.org, dane@ietf.org, rfc-editor@rfc-editor.org, "The IESG" <iesg@ietf.org>, draft-ietf-dane-openpgpkey@ietf.org, ogud@ogud.com, stephen.farrell@cs.tcd.ie
Subject: Document Action: 'Using DANE to Associate OpenPGP public keys with email addresses' to Experimental RFC (draft-ietf-dane-openpgpkey-12.txt)

The IESG has approved the following document:
- 'Using DANE to Associate OpenPGP public keys with email addresses'
  (draft-ietf-dane-openpgpkey-12.txt) as Experimental RFC

This document is the product of the DNS-based Authentication of Named
Entities Working Group.

The IESG contact persons are Stephen Farrell and Kathleen Moriarty.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/


Technical Summary:

This document proposes a method to publish and "locate" OPENPGP keys
inside the DNS. The goal of this approach is to make it easier to find
OPENPGP keys for email addresses.  The document defines a "method" to
convert email-addres into a special normal form. that is limited but
is expected to cover many cases. The OPENPGP DNS record specified has 
been allocated by an Expert Review.  

The method of mapping email addresses into the normal form has gone
through number of revisions based on feedback from WG participants and
email community. No one claims this is a perfect solution but good
solution for the particular problem space, where the sender to an
email has a "good" idea what an email address of the receipient
is. This protocol can be described as oppertunistic OPENPGP key
discovery. This is not a replacement service for PKGP servers but a
compliment. 

Working Group Summary:

The main issues that the WG has discused are 
a) is it a good idea to publish email addresses in DNSSEC signed zone? 
b) is the role of the nomalization from strictly a normalization or an
obfuscation as well? 
The consensus of the WG is that as the publicaion is by the zone owner
it is an opt-in policy, there is no requriement for adoption thus the
issue need to be addressed in the light of each organizations
polices, i.e this is not a protocol issue. 

The second issue there is a strong consenus that the purpose of the
normal for is only to map email addresses into a DNS label that is
valid in all implementations. 
The working group consensus is strong about advancing this document. 

We had two IETF last calls on this one. There were some good points
raised in those and changes resulted. There are however some email
folks who remain unhappy with this experiment so the IETF consensus
for this is rough. The responsible AD judges that we do however have
rough consensus for this experiment. (And will similarly have rough
consensus for some other experiments in this space.) I think though
that it'd be especially good here if the ART ADs give this one a
particularly close look in case I've erred in considering their objections.
(I of course don't think I did, but hey, I've been wrong before:-)
 
Document Quality:

Early version of this  document went through DNS expert review before
the DNS RR type was allocated. The editor has been real good at
working with people to address textual and techical issues. 
There are number of implemenations of this protocol and some
deoployment where organizations have placed over 1500 keys online. 

More review from email community is welcome but until the email
community proposes a better form of normalization rules for email
addresses this is the best we can do. 

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?
Document Sheperd is Olafur Gudmundsson 
Responsible AD is : Stephen Farrell,