Skip to main content

DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP
draft-ietf-dane-openpgpkey-12

Revision differences

Document history

Date Rev. By Action
2016-08-02
12 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2016-07-14
12 Jean Mahoney Closed request for Telechat review by GENART with state 'No Response'
2016-07-07
12 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2016-07-05
12 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2016-05-17
12 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2016-05-16
12 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2016-05-09
12 (System) RFC Editor state changed to EDIT
2016-05-09
12 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2016-05-09
12 (System) Announcement was received by RFC Editor
2016-05-09
12 (System) IANA Action state changed to Waiting on Authors from In Progress
2016-05-09
12 (System) IANA Action state changed to In Progress
2016-05-09
12 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2016-05-09
12 Amy Vezza IESG has approved the document
2016-05-09
12 Amy Vezza Closed "Approve" ballot
2016-05-09
12 Amy Vezza Ballot approval text was generated
2016-05-09
12 Amy Vezza IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2016-05-09
12 Amy Vezza Ballot writeup was changed
2016-05-03
12 Alexey Melnikov
[Ballot comment]
NOTE to editors: Thank you for addressing my earlier comments in -09, -10 and -12.

Despite many objections to publishing this specification I …
[Ballot comment]
NOTE to editors: Thank you for addressing my earlier comments in -09, -10 and -12.

Despite many objections to publishing this specification I believe we should run the experiment. I will vote "Yes" once DISCUSS-points are addressed. I would rather see this experiment being done and fail (or better - succeed), than to block publication of this document because it is not perfect.

Some (edited) comments from Ned Freed that I (mostly) agree with:

1) In Section 3:

When describing unquoting and unescaping, I think it would be useful to give an example, for example all of the following are equivalent and must result in the same hashed value:

(1) first.last@example.com
(2) first . last @example.com
(3) "first.last"@example.com
(4) "\f\i\r\s\t.last"@example.com

2)

5.1.  Obtaining an OpenPGP key for a specific email address

  If no OpenPGP public keys are known for an email address, an
  OPENPGPKEY DNS lookup MAY be performed to seek the OpenPGP public key
  that corresponds to that email address.  This public key can then be
  used to verify a received signed message or can be used to send out
  an encrypted email message.  An application whose attempt fails to
  retrieve a DNSSEC verified OPENPGPKEY RR from the DNS should remember
  that failure for some time to avoid sending out a DNS request for
  each email message the application is sending out; such DNS requests
  constitute a privacy leak

Should the document give a specific recommendation about "remember for some time"? Is it tied to TTL for the corresponding RR?
If you can provide some additional text explaining what is reasonable (or not) here, that would improve the specification.
2016-05-03
12 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to Yes from Discuss
2016-05-02
12 Paul Wouters New version available: draft-ietf-dane-openpgpkey-12.txt
2016-04-29
11 Paul Wouters IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2016-04-29
11 Paul Wouters New version available: draft-ietf-dane-openpgpkey-11.txt
2016-04-28
10 Tero Kivinen Closed request for Last Call review by SECDIR with state 'No Response'
2016-04-27
10 Alexey Melnikov
[Ballot discuss]
NOTE to editors: Thank you for addressing my earlier comments in -09 and -10.

Despite many objections to publishing this specification I believe …
[Ballot discuss]
NOTE to editors: Thank you for addressing my earlier comments in -09 and -10.

Despite many objections to publishing this specification I believe we should run the experiment. I will vote "Yes" once DISCUSS-points are addressed. I would rather see this experiment being done and fail (or better - succeed), than to block publication of this document because it is not perfect.

Ned Freed wrote:

> So when a domain owner publishes such records in the DNS, a reasonable way to
> look at it is that they are effectively saying, "Everyone is allowed to
> interpret the local-parts of our addresses as specified in this document in
> this one narrow context." I'm pretty confident there's nothing in any standard
> that forbids such a delegation of authority.
>
> And once you realize this is what is going on, not only does it become clear
> that this draft is *not* violating the longstanding rules about local-part
> interpretation, it casts the decision not to normalize the local-parts to lower
> (or upper) case in an entirely different light. By choosing not to normalize
> this specification is effectively restricting its own applicability to domains
> with case-sensitive local parts. That is, IMO, a highly suboptimal choice - the
> overwhelming majority of domains treat the local part in a case-insensitive
> fashion, and so should the mechanism specified in this draft.
>
> Or, to put this another way, the inherent limitations of using the DNS to
> provide the mapping from address to PGP key restricts the domain of
> applicability of this specification to domains with particular local-part
> policies, and the way in which the local-part to DNS mapping is specified
> determines which policies the specification supports. And while it seems
> logical to support a policy that's known to be in wide use, the specification
> also needs to be very clear that domains that employ case-sensitive local-parts
> MUST NOT avail themselves of this mechanism.

I don't think I agree on "MUST NOT" here, because I think an email owner can publish the preferred form (which can be lowercased) or even multiple common forms of the email address. E.g. I can publish DNS records for alexey.melnikov@isode.com, Alexey.Melnikov@isode.com and ALEXEY.MELNIKOV@isode.com, but not others.

> What needs to happen here is that the specification be revised to make it clear
> that this is what is going on: That by publishing such records a domain is
> granting a limited right to interpret the local parts of its addresses.

On a second thought, there is no obvious place to put this text. Besides, the document disallows mangling of local-parts, so "granting a limited right to interpret" doesn't mean much other than "this email address might exist".
I agree with this. A sentence or two on this would suffice.
2016-04-27
10 Alexey Melnikov Ballot discuss text updated for Alexey Melnikov
2016-04-23
10 Alexey Melnikov
[Ballot discuss]
NOTE to editors: Thank you for addressing my earlier comments in -09 and -10.

Despite many objections to publishing this specification I believe …
[Ballot discuss]
NOTE to editors: Thank you for addressing my earlier comments in -09 and -10.

Despite many objections to publishing this specification I believe we should run the experiment. I will vote "Yes" once DISCUSS-points are addressed. I would rather see this experiment being done and fail (or better - succeed), than to block publication of this document because it is not perfect.

Ned Freed wrote:

> So when a domain owner publishes such records in the DNS, a reasonable way to
> look at it is that they are effectively saying, "Everyone is allowed to
> interpret the local-parts of our addresses as specified in this document in
> this one narrow context." I'm pretty confident there's nothing in any standard
> that forbids such a delegation of authority.
>
> And once you realize this is what is going on, not only does it become clear
> that this draft is *not* violating the longstanding rules about local-part
> interpretation, it casts the decision not to normalize the local-parts to lower
> (or upper) case in an entirely different light. By choosing not to normalize
> this specification is effectively restricting its own applicability to domains
> with case-sensitive local parts. That is, IMO, a highly suboptimal choice - the
> overwhelming majority of domains treat the local part in a case-insensitive
> fashion, and so should the mechanism specified in this draft.
>
> Or, to put this another way, the inherent limitations of using the DNS to
> provide the mapping from address to PGP key restricts the domain of
> applicability of this specification to domains with particular local-part
> policies, and the way in which the local-part to DNS mapping is specified
> determines which policies the specification supports. And while it seems
> logical to support a policy that's known to be in wide use, the specification
> also needs to be very clear that domains that employ case-sensitive local-parts
> MUST NOT avail themselves of this mechanism.

I don't think I agree on "MUST NOT" here, because I think an email owner can publish the preferred form (which can be lowercased) or even multiple common forms of the email address. E.g. I can publish DNS records for alexey.melnikov@isode.com, Alexey.Melnikov@isode.com and ALEXEY.MELNIKOV@isode.com, but not others.

> What needs to happen here is that the specification be revised to make it clear
> that this is what is going on: That by publishing such records a domain is
> granting a limited right to interpret the local parts of its addresses.

I agree with this. A sentence or two on this would suffice.
2016-04-23
10 Alexey Melnikov
[Ballot comment]
Some (edited) comments from Ned Freed that I (mostly) agree with:

1) In Section 3:

When describing unquoting and unescaping, I think it …
[Ballot comment]
Some (edited) comments from Ned Freed that I (mostly) agree with:

1) In Section 3:

When describing unquoting and unescaping, I think it would be useful to give an example, for example all of the following are equivalent and must result in the same hashed value:

(1) first.last@example.com
(2) first . last @example.com
(3) "first.last"@example.com
(4) "\f\i\r\s\t.last"@example.com

2)

5.1.  Obtaining an OpenPGP key for a specific email address

  If no OpenPGP public keys are known for an email address, an
  OPENPGPKEY DNS lookup MAY be performed to seek the OpenPGP public key
  that corresponds to that email address.  This public key can then be
  used to verify a received signed message or can be used to send out
  an encrypted email message.  An application whose attempt fails to
  retrieve a DNSSEC verified OPENPGPKEY RR from the DNS should remember
  that failure for some time to avoid sending out a DNS request for
  each email message the application is sending out; such DNS requests
  constitute a privacy leak

Should the document give a specific recommendation about "remember for some time"? Is it tied to TTL for the corresponding RR?
If you can provide some additional text explaining what is reasonable (or not) here, that would improve the specification.
2016-04-23
10 Alexey Melnikov Ballot comment and discuss text updated for Alexey Melnikov
2016-04-23
10 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'No Response'
2016-04-21
10 Matthew Miller Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Matthew Miller.
2016-04-21
10 Cindy Morgan IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation
2016-04-21
10 Stephen Farrell
Document Writeup for Working Group Documents

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up.

Changes are expected …
Document Writeup for Working Group Documents

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

Experimental RFC is requested, and indicated in the header.
Note: see item (6) ***

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

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.


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,

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

DS has read every version of the document, and worked with the editor
in addressing isuses. A extensive working group last call was
conducted, along with with a session at a DANE meeting where people
from the email community had a frank discussion about the issues and
scope of the document. This document has advanced as far as it can
inside the WG and pubishing as Proposed Standard is the the desire of
the WG.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

Not really.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

More review from email community will not hurt, but unless they have
an sudden insight as how to "cannonize" email address this is the best
we can do.


(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

There are are two issues that have been raised over and over again.
A. Do not publish email addresses in the DNS.
B. You are not guaranteed to find the key of the actual person you
want to send signed/encrypted email to.

Both of these issues have been refuted and as publication is optional
A. does not realy apply. For B. there conversion techique is has got
extensive input and improved based on that. There is not much more we
can do at this point to address it.

Some people have said that they would be more comfortable with the
document published as Experimental. The working group requests
publication as Standards Track but can live with Experimental status.
(Update: we changed to experimental.)


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78
and BCP 79 have already been filed. If not, explain why?

No IPR filed

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR filed

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

Strong


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

None

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Yes the document was reviewed by DNS RRtype Registry experts.


(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

No


(15) Are there downward normative references references (see RFC
3967
)? If so, list these downward references to support the Area
Director in the Last Call procedure.

No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

No


(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226
).

Only IANA action requested is to updat a reference upon publication of
this document.

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

Done

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

ID-nits

None.

2016-04-21
10 Jari Arkko [Ballot comment]
There are some editorial comments from Matt's Gen-ART review, probably worthwhile to address these.
2016-04-21
10 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2016-04-20
10 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2016-04-20
10 Amanda Baber IANA Review state changed to IANA - Not OK from Version Changed - Review Needed
2016-04-20
10 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2016-04-20
10 Alissa Cooper
[Ballot comment]
I know there has been a lot of list discussion of this draft so I apologize if these issues have already been discussed …
[Ballot comment]
I know there has been a lot of list discussion of this draft so I apologize if these issues have already been discussed before.

I think if this sees any sizable deployment, it will be trivial for attackers to use it to harvest email addresses from the DNS. Section 7.4 therefore seems to be quite misleading. I don't see why a zone walk is necessary to do this kind of harvesting when an attacker could just send one query per entry in its dictionary. I think it would be more accurate to say that by using this mechanism, people are effectively making their email addresses public.

I also think the mechanism could facilitate pervasive monitoring as described in RFC 7258, as it potentially makes a whole class of entities (resolvers) into repositories of detailed data about who has communicated with whom via email. To the extent that large DNS providers keep logs about individual queries, it seems like those logs could become prime attack targets. The mechanism specified here can obviously help mitigate pervasive monitoring in other ways, but I think the draft needs to be up front about the trade-offs between potentially exposing metadata to a wider pool of entities and attackers in exchange for more easily being able to protect content.
2016-04-20
10 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2016-04-20
10 Ben Campbell [Ballot comment]
I agree with Mirja that it would be nice if the shepherd's writeup were updated to reflect the experimental status.
2016-04-20
10 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2016-04-20
10 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2016-04-20
10 Mirja Kühlewind
[Ballot comment]
[Please update shepherd write-up, it still says: Some people have said that they would be more comfortable with the document published as Experimental. …
[Ballot comment]
[Please update shepherd write-up, it still says: Some people have said that they would be more comfortable with the document published as Experimental. The working group requests publication as Standards Track but can live with Experimental status. ]
2016-04-20
10 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2016-04-20
10 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2016-04-19
10 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2016-04-19
10 Paul Wouters New version available: draft-ietf-dane-openpgpkey-10.txt
2016-04-19
09 Alexey Melnikov
[Ballot discuss]
NOTE to editors: Thank you for addressing my earlier comments in -09.
If you need any more specific suggestions about text being added/deleted/updated, …
[Ballot discuss]
NOTE to editors: Thank you for addressing my earlier comments in -09.
If you need any more specific suggestions about text being added/deleted/updated, please let me know.

Despite many objections to publishing this specification I believe we should run the experiment. I will vote "Yes" once DISCUSS-points are addressed. I would rather see this experiment being done and fail (or better - succeed), than to block publication of this document because it is not perfect.

1). As per Sean Leonard/Ned Freed:

There's also - as noted by Sean Leonard - a technical glitch in the current
specification: The local-part is not the correct input to the hash function. A
canonicalization step is needed because all of these addresses are
equivalent:

(1) first.last@example.com
(2) first . last @example.com
(3) "first.last"@example.com
(4) "\f\i\r\s\t.last"@example.com

(2) is equivalent to (1) because CWS has no semantics, (3) is equivalent to
(1) because the enclosing quotes are not properly part of the address, and (4)
is equivalent to (1) because quoted-pairs are semantically equivalent to
just the quoted character.

I believe this is the entire list, so the obvious canonicalization to use
on the local-part portion of an address prior to hashing is:

(a) If the local-part is unquoted remove any whitespace (CFWS) around "."s.
(b) Remove any enclosing double quotes.
(c) Remove any literal quoting.

2). Ned Freed wrote:

> First, there's no way to define a mapping of local-parts to a new set of
> identifiers *without* effectively interpreting the local-part! If you define
> the mapping as the draft currently does, implicit in that definition is that
> local-parts are case-sensitive. And similarly, if you convert the local-part to
> lower (or upper) case, you're now assuming the local-part is case-insensitive.
>
> And in the case of EAI, without some sort of normalization you're assuming that
> different UTF-8 representations of the same string of characters correspond to
> different recipients. (Which, as Harald Alvestrand and I both pointed out on
> the IETF list, is technically untenable and needs to be addressed. My
> suggestion was and is to specify that the same case-folding and normalization
> algorithm used for IDNs also be employed here.)

RFC 6532 and Section 10.1 of RFC 6530 recommend using NFC Unicode Normalization Form. (This is similar to what IDN recommends, although there is no standard mapping there.) I think it would be reasonable for this document to say SHOULD apply NFC before hashing.
2016-04-19
09 Alexey Melnikov
[Ballot comment]
Some (edited) comments from Ned Freed that I (mostly) agree with:

1) In Section 3:

Finally, a couple of observations about terminology are …
[Ballot comment]
Some (edited) comments from Ned Freed that I (mostly) agree with:

1) In Section 3:

Finally, a couple of observations about terminology are in order. The current
text covering the hashing of local-parts begins with:

      The user name (the "left-hand side" of the email address, called
      the "local-part" in the mail message format definition [RFC5322]
      and the local-part in the specification for internationalized
      email [RFC6530]) is encoded in UTF-8 (or its subset ASCII).  If
      the local-part is written in another encoding it MUST be converted
      to UTF-8.

First, the left hand side of an email address is not a "user name" and should
not be referred to as such. (The entire address is in some cases a "user name"
of sorts, and in some cases the local-part is identical to some kind of login
credential. But neither of these are universally true, and more to the point,
none of this is relevant to the matter at hand.)

Second, it probably makes sense to note that local-part is an ABNF
production contained in a broader syntax, not just a name.

Third, the term "encoding" here is inaccurate; it should be "charset".

2) Ned Freed wrote:

> So when a domain owner publishes such records in the DNS, a reasonable way to
> look at it is that they are effectively saying, "Everyone is allowed to
> interpret the local-parts of our addresses as specified in this document in
> this one narrow context." I'm pretty confident there's nothing in any standard
> that forbids such a delegation of authority.
>
> And once you realize this is what is going on, not only does it become clear
> that this draft is *not* violating the longstanding rules about local-part
> interpretation, it casts the decision not to normalize the local-parts to lower
> (or upper) case in an entirely different light. By choosing not to normalize
> this specification is effectively restricting its own applicability to domains
> with case-sensitive local parts. That is, IMO, a highly suboptimal choice - the
> overwhelming majority of domains treat the local part in a case-insensitive
> fashion, and so should the mechanism specified in this draft.
>
> Or, to put this another way, the inherent limitations of using the DNS to
> provide the mapping from address to PGP key restricts the domain of
> applicability of this specification to domains with particular local-part
> policies, and the way in which the local-part to DNS mapping is specified
> determines which policies the specification supports. And while it seems
> logical to support a policy that's known to be in wide use, the specification
> also needs to be very clear that domains that employ case-sensitive local-parts
> MUST NOT avail themselves of this mechanism.

I don't think I agree on "MUST NOT" here, because I think an email owner can publish the preferred form (which can be lowercased) or even multiple common forms of the email address. E.g. I can publish DNS records for alexey.melnikov@isode.com, Alexey.Melnikov@isode.com and ALEXEY.MELNIKOV@isode.com, but not others.

> What needs to happen here is that the specification be revised to make it clear
> that this is what is going on: That by publishing such records a domain is
> granting a limited right to interpret the local parts of its addresses.

I agree with this. A sentence or two on this would suffice.

---------------

3) The following issues/comments/questions were reported earlier:

5.1.  Obtaining an OpenPGP key for a specific email address

  If no OpenPGP public keys are known for an email address, an
  OPENPGPKEY DNS lookup MAY be performed to seek the OpenPGP public key
  that corresponds to that email address.  This public key can then be
  used to verify a received signed message or can be used to send out
  an encrypted email message.  An application whose attempt fails to
  retrieve a DNSSEC verified OPENPGPKEY RR from the DNS should remember
  that failure for some time to avoid sending out a DNS request for
  each email message the application is sending out; such DNS requests
  constitute a privacy leak

Should the document give a specific recommendation about "remember for some time"? Is it tied to TTL for the corresponding RR?
If you can provide some additional text explaining what is reasonable (or not) here, that would improve the specification.
2016-04-19
09 Alexey Melnikov Ballot comment and discuss text updated for Alexey Melnikov
2016-04-19
09 Alexey Melnikov
[Ballot comment]
I might have more comments/questions before the telechat. Some (edited) comments from Ned Freed that I agree with:

1) In Section 3:

Finally, …
[Ballot comment]
I might have more comments/questions before the telechat. Some (edited) comments from Ned Freed that I agree with:

1) In Section 3:

Finally, a couple of observations about terminology are in order. The current
text covering the hashing of local-parts begins with:

      The user name (the "left-hand side" of the email address, called
      the "local-part" in the mail message format definition [RFC5322]
      and the local-part in the specification for internationalized
      email [RFC6530]) is encoded in UTF-8 (or its subset ASCII).  If
      the local-part is written in another encoding it MUST be converted
      to UTF-8.

First, the left hand side of an email address is not a "user name" and should
not be referred to as such. (The entire address is in some cases a "user name"
of sorts, and in some cases the local-part is identical to some kind of login
credential. But neither of these are universally true, and more to the point,
none of this is relevant to the matter at hand.)

Second, it probably makes sense to note that local-part is an ABNF
production contained in a broader syntax, not just a name.

Third, the term "encoding" here is inaccurate; it should be "charset".

2) Ned Freed wrote:

> So when a domain owner publishes such records in the DNS, a reasonable way to
> look at it is that they are effectively saying, "Everyone is allowed to
> interpret the local-parts of our addresses as specified in this document in
> this one narrow context." I'm pretty confident there's nothing in any standard
> that forbids such a delegation of authority.
>
> And once you realize this is what is going on, not only does it become clear
> that this draft is *not* violating the longstanding rules about local-part
> interpretation, it casts the decision not to normalize the local-parts to lower
> (or upper) case in an entirely different light. By choosing not to normalize
> this specification is effectively restricting its own applicability to domains
> with case-sensitive local parts. That is, IMO, a highly suboptimal choice - the
> overwhelming majority of domains treat the local part in a case-insensitive
> fashion, and so should the mechanism specified in this draft.
>
> Or, to put this another way, the inherent limitations of using the DNS to
> provide the mapping from address to PGP key restricts the domain of
> applicability of this specification to domains with particular local-part
> policies, and the way in which the local-part to DNS mapping is specified
> determines which policies the specification supports. And while it seems
> logical to support a policy that's known to be in wide use, the specification
> also needs to be very clear that domains that employ case-sensitive local-parts
> MUST NOT avail themselves of this mechanism.

I don't think I agree on "MUST NOT" here, because I think an email owner can publish the preferred form (which can be lowercased) or even multiple common forms of the email address. E.g. I can publish DNS records for alexey.melnikov@isode.com, Alexey.Melnikov@isode.com and ALEXEY.MELNIKOV@isode.com, but not others.

> What needs to happen here is that the specification be revised to make it clear
> that this is what is going on: That by publishing such records a domain is
> granting a limited right to interpret the local parts of its addresses.

I agree with this. A sentence or two on this would suffice.

---------------

3) The following issues/comments/questions were reported earlier:

5.1.  Obtaining an OpenPGP key for a specific email address

  If no OpenPGP public keys are known for an email address, an
  OPENPGPKEY DNS lookup MAY be performed to seek the OpenPGP public key
  that corresponds to that email address.  This public key can then be
  used to verify a received signed message or can be used to send out
  an encrypted email message.  An application whose attempt fails to
  retrieve a DNSSEC verified OPENPGPKEY RR from the DNS should remember
  that failure for some time to avoid sending out a DNS request for
  each email message the application is sending out; such DNS requests
  constitute a privacy leak

Should the document give a specific recommendation about "remember for some time"? Is it tied to TTL for the corresponding RR?
If you can provide some additional text explaining what is reasonable (or not) here, that would improve the specification.
2016-04-19
09 Alexey Melnikov Ballot comment text updated for Alexey Melnikov
2016-04-15
09 Alexey Melnikov
[Ballot discuss]
NOTE to editors: I am in the process of editing this text. There might be a couple of extra DISCUSS points that I …
[Ballot discuss]
NOTE to editors: I am in the process of editing this text. There might be a couple of extra DISCUSS points that I will add. I will send the updated version once done.
And thank you for addressing my earlier comments in -09.

Despite many objections to publishing this specification I believe we should run the experiment. I will vote "Yes" once DISCUSS-points are addressed. I would rather see this experiment being done and fail (or better - succeed), than to block publication of this document because it is not perfect.

As per Sean Leonard/Ned Freed:

There's also - as noted by Sean Leonard - a technical glitch in the current
specification: The local-part is not the correct input to the hash function. A
canonicalization step is needed because all of these addresses are
equivalent:

(1) first.last@example.com
(2) first . last @example.com
(3) "first.last"@example.com
(4) "\f\i\r\s\t.last"@example.com

(2) is equivalent to (1) because CWS has no semantics, (3) is equivalent to
(1) because the enclosing quotes are not properly part of the address, and (4)
is equivalent to (1) because quoted-pairs are semantically equivalent to
just the quoted character.

I believe this is the entire list, so the obvious canonicalization to use
on the local-part portion of an address prior to hashing is:

(a) If the local-part is unquoted remove any whitespace (CFWS) around "."s.
(b) Remove any enclosing double quotes.
(c) Remove any literal quoting.
2016-04-15
09 Alexey Melnikov Ballot discuss text updated for Alexey Melnikov
2016-04-13
09 Alexey Melnikov
[Ballot comment]
I might have more comments/questions before the telechat. Some (edited) comments from Ned Freed that I agree with:

In Section 3:

Finally, a …
[Ballot comment]
I might have more comments/questions before the telechat. Some (edited) comments from Ned Freed that I agree with:

In Section 3:

Finally, a couple of observations about terminology are in order. The current
text covering the hashing of local-parts begins with:

      The user name (the "left-hand side" of the email address, called
      the "local-part" in the mail message format definition [RFC5322]
      and the local-part in the specification for internationalized
      email [RFC6530]) is encoded in UTF-8 (or its subset ASCII).  If
      the local-part is written in another encoding it MUST be converted
      to UTF-8.

First, the left hand side of an email address is not a "user name" and should
not be referred to as such. (The entire address is in some cases a "user name"
of sorts, and in some cases the local-part is identical to some kind of login
credential. But neither of these are universally true, and more to the point,
none of this is relevant to the matter at hand.)

Second, it probably makes sense to note that local-part is an ABNF
production contained in a broader syntax, not just a name.

Third, the term "encoding" here is inaccurate; it should be "charset".

---------------

The following issues/comments/questions were reported earlier:

5.1.  Obtaining an OpenPGP key for a specific email address

  If no OpenPGP public keys are known for an email address, an
  OPENPGPKEY DNS lookup MAY be performed to seek the OpenPGP public key
  that corresponds to that email address.  This public key can then be
  used to verify a received signed message or can be used to send out
  an encrypted email message.  An application whose attempt fails to
  retrieve a DNSSEC verified OPENPGPKEY RR from the DNS should remember
  that failure for some time to avoid sending out a DNS request for
  each email message the application is sending out; such DNS requests
  constitute a privacy leak

Should the document give a specific recommendation about "remember for some time"?
TTL for the corresponding RR?
If you can provide some additional text explaining what is reasonable (or not) here, that would improve the specification.
2016-04-13
09 Alexey Melnikov Ballot comment text updated for Alexey Melnikov
2016-04-13
09 Paul Wouters IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2016-04-13
09 Paul Wouters New version available: draft-ietf-dane-openpgpkey-09.txt
2016-04-13
08 Kathleen Moriarty
[Ballot comment]
This sounds like a worth while experiment and with Alexey's discuss & comments addressed, it will be well specified.  I'll be interested to …
[Ballot comment]
This sounds like a worth while experiment and with Alexey's discuss & comments addressed, it will be well specified.  I'll be interested to see the results and findings on space considerations for DNSSec.
2016-04-13
08 Kathleen Moriarty [Ballot Position Update] New position, Yes, has been recorded for Kathleen Moriarty
2016-04-13
08 Alexey Melnikov
[Ballot discuss]
Despite many objections to publishing this specification I believe we should run the experiment. I will vote "Yes" once DISCUSS-points are addressed. I …
[Ballot discuss]
Despite many objections to publishing this specification I believe we should run the experiment. I will vote "Yes" once DISCUSS-points are addressed. I would rather see this experiment being done and fail (or better - succeed), than to block publication of this document because it is not perfect.

As per Sean Leonard/Ned Freed:

There's also - as noted by Sean Leonard - a technical glitch in the current
specification: The local-part is not the correct input to the hash function. A
canonicalization step is needed because all of these addresses are
equivalent:

(1) first.last@example.com
(2) first . last @example.com
(3) "first.last"@example.com
(4) "\f\i\r\s\t.last"@example.com

(2) is equivalent to (1) because CWS has no semantics, (3) is equivalent to
(1) because the enclosing quotes are not properly part of the address, and (4)
is equivalent to (1) because quoted-pairs are semantically equivalent to
just the quoted character.

I believe this is the entire list, so the obvious canonicalization to use
on the local-part portion of an address prior to hashing is:

(a) If the local-part is unquoted remove any whitespace (CFWS) around "."s.
(b) Remove any enclosing double quotes.
(c) Remove any literal quoting.
2016-04-13
08 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to Discuss from No Record
2016-04-13
08 Alexey Melnikov
[Ballot comment]
I might have more comments/questions before the telechat. Some (edited) comments from Ned Freed that I agree with:

In Section 3:

Finally, a …
[Ballot comment]
I might have more comments/questions before the telechat. Some (edited) comments from Ned Freed that I agree with:

In Section 3:

Finally, a couple of observations about terminology are in order. The current
text covering the hashing of local-parts begins with:

      The user name (the "left-hand side" of the email address, called
      the "local-part" in the mail message format definition [RFC5322]
      and the local-part in the specification for internationalized
      email [RFC6530]) is encoded in UTF-8 (or its subset ASCII).  If
      the local-part is written in another encoding it MUST be converted
      to UTF-8.

First, the left hand side of an email address is not a "user name" and should
not be referred to as such. (The entire address is in some cases a "user name"
of sorts, and in some cases the local-part is identical to some kind of login
credential. But neither of these are universally true, and more to the point,
none of this is relevant to the matter at hand.)

Second, it probably makes sense to note that local-part is an ABNF
production contained in a broader syntax, not just a name.

Third, the term "encoding" here is inaccurate; it should be "charset".

---------------

The following issues/comments/questions were reported earlier:

5.1.  Obtaining an OpenPGP key for a specific email address

  If no OpenPGP public keys are known for an email address, an
  OPENPGPKEY DNS lookup MAY be performed to seek the OpenPGP public key
  that corresponds to that email address.  This public key can then be
  used to verify a received signed message or can be used to send out
  an encrypted email message.  An application whose attempt fails to
  retrieve a DNSSEC verified OPENPGPKEY RR from the DNS should remember
  that failure for some time to avoid sending out a DNS request for
  each email message the application is sending out; such DNS requests
  constitute a privacy leak

Should the document give a specific recommendation about "remember for some time"?
TTL for the corresponding RR?
If you can provide some additional text explaining what is reasonable (or not) here, that would improve the specification.

In section 7:

What is the difference between "an email client" and MUA?

In 7.1:

  If the DNS request for an OPENPGPKEY record returned an Indeterminate
  or Bogus answer as specified in [RFC4035], the MTA MUST NOT send the
  message and queue the plaintext message for encrypted delivery at a
  later time.  If the problem persists, the email should be returned
  via the regular bounce methods.

Is this behaviour only specific to encrypting gateways? I want to make sure that this is not applied uncondionally to general MTAs, which don't need to understand this specification.

In 7.2:
  If the public key for a recipient obtained from the locally stored
  sender’s public keyring differs from the recipient’s OPENPGPKEY RR,
  the MUA MUST NOT accept the message for delivery.

Minor terminology issue: It is better to say here "accept the message for submission", because "delivery" is a recipient side operation which is not done my MUAs, it is performed by MDAs.

In 7.5:

  The hashing of the user name in this document is not a security
  feature.

Please use "local part" instead of username here, email addresses are not user names.
2016-04-13
08 Alexey Melnikov Ballot comment text updated for Alexey Melnikov
2016-04-12
08 Jean Mahoney Request for Telechat review by GENART is assigned to Matthew Miller
2016-04-12
08 Jean Mahoney Request for Telechat review by GENART is assigned to Matthew Miller
2016-04-10
08 Alexey Melnikov
[Ballot comment]
I might have more comments/questions before the telechat. Here is my initial batch:

5.1.  Obtaining an OpenPGP key for a specific email address …
[Ballot comment]
I might have more comments/questions before the telechat. Here is my initial batch:

5.1.  Obtaining an OpenPGP key for a specific email address

  If no OpenPGP public keys are known for an email address, an
  OPENPGPKEY DNS lookup MAY be performed to seek the OpenPGP public key
  that corresponds to that email address.  This public key can then be
  used to verify a received signed message or can be used to send out
  an encrypted email message.  An application whose attempt fails to
  retrieve a DNSSEC verified OPENPGPKEY RR from the DNS should remember
  that failure for some time to avoid sending out a DNS request for
  each email message the application is sending out; such DNS requests
  constitute a privacy leak

Should the document give a specific recommendation about "remember for some time"?
TTL for the corresponding RR?

In section 7:

What is the difference between "an email client" and MUA?

In 7.1:

  If the DNS request for an OPENPGPKEY record returned an Indeterminate
  or Bogus answer as specified in [RFC4035], the MTA MUST NOT send the
  message and queue the plaintext message for encrypted delivery at a
  later time.  If the problem persists, the email should be returned
  via the regular bounce methods.

Is this behaviour only specific to encrypting gateways? I want to make sure that this is not applied uncondionally to general MTAs, which don't need to understand this specification.

In 7.2:
  If the public key for a recipient obtained from the locally stored
  sender’s public keyring differs from the recipient’s OPENPGPKEY RR,
  the MUA MUST NOT accept the message for delivery.

Minor terminology issue: It is better to say here "accept the message for submission", because "delivery" is a recipient side operation which is not done my MUAs, it is performed by MDAs.

In 7.5:

  The hashing of the user name in this document is not a security
  feature.

Please use "local part" instead of username here, email addresses are not user names.
2016-04-10
08 Alexey Melnikov Ballot comment text updated for Alexey Melnikov
2016-03-24
08 Jean Mahoney Request for Telechat review by GENART is assigned to Suresh Krishnan
2016-03-24
08 Jean Mahoney Request for Telechat review by GENART is assigned to Suresh Krishnan
2016-03-23
08 Amanda Baber IANA Review state changed to IANA - Not OK from Version Changed - Review Needed
2016-03-19
08 Stephen Farrell Placed on agenda for telechat - 2016-04-21
2016-03-19
08 Stephen Farrell Changed consensus to Yes from Unknown
2016-03-19
08 Stephen Farrell IESG state changed to IESG Evaluation from Waiting for Writeup
2016-03-19
08 Stephen Farrell Ballot has been issued
2016-03-19
08 Stephen Farrell [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell
2016-03-19
08 Stephen Farrell Created "Approve" ballot
2016-03-19
08 Stephen Farrell Ballot writeup was changed
2016-03-09
08 Stephen Farrell
For posterity: as discussed on ietf@ietf.org [1] I
extended the IETF LC until March 15th to allow
folks a week to look over the -08 …
For posterity: as discussed on ietf@ietf.org [1] I
extended the IETF LC until March 15th to allow
folks a week to look over the -08 version.

[1]  https://www.ietf.org/mail-archive/web/ietf/current/msg96959.html
2016-03-08
08 Paul Wouters IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2016-03-08
08 Paul Wouters New version available: draft-ietf-dane-openpgpkey-08.txt
2016-02-22
07 (System) IESG state changed to Waiting for Writeup from In Last Call
2016-02-18
07 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2016-02-18
07 Sabrina Tanamal
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-dane-openpgpkey-07.txt. If any part of this review is inaccurate, please let us know.

IANA …
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-dane-openpgpkey-07.txt. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the Resource Record (RR) TYPEs subregistry of the Domain Name System (DNS) Parameters registry located at:

https://www.iana.org/assignments/dns-parameters/

The existing registration for OPENPGPKEY will have its reference changed as follows:

TYPE: OPENPGPKEY
Value: 61
Meaning: OpenPGP Key
Reference: [ RFC-to-be ]

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 


Thank you,

Sabrina Tanamal
IANA Specialist
ICANN
2016-02-11
07 Jean Mahoney Request for Last Call review by GENART is assigned to Suresh Krishnan
2016-02-11
07 Jean Mahoney Request for Last Call review by GENART is assigned to Suresh Krishnan
2016-02-11
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Donald Eastlake
2016-02-11
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Donald Eastlake
2016-02-08
07 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-dane-openpgpkey@ietf.org, ogud@ogud.com, dane@ietf.org, dane-chairs@ietf.org, stephen.farrell@cs.tcd.ie
Reply-To: ietf@ietf.org …
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-dane-openpgpkey@ietf.org, ogud@ogud.com, dane@ietf.org, dane-chairs@ietf.org, stephen.farrell@cs.tcd.ie
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Using DANE to Associate OpenPGP public keys with email addresses) to Experimental RFC


The IESG has received a request from the DNS-based Authentication of
Named Entities WG (dane) to consider the following document:
- 'Using DANE to Associate OpenPGP public keys with email addresses'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-02-22. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  OpenPGP is a message format for email (and file) encryption that
  lacks a standardized lookup mechanism to securely obtain OpenPGP
  public keys.  DNS-Based Authentication of Named Entities ("DANE") is
  a method for publishing public keys in DNS.  This document specifies
  a DANE method for publishing and locating OpenPGP public keys in DNS
  for a specific email address using a new OPENPGPKEY DNS Resource
  Record.  Security is provided via Secure DNS, however the OPENPGPKEY
  record is not a replacement for verification of authenticity via the
  "Web of Trust" or manual verification.  The OPENPGPKEY record can be
  used to encrypt an email that would otherwise have to be send
  unencrypted.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ballot/


No IPR declarations have been submitted directly on this I-D.

This is a second IETF last call - the diff from version -05 which
was the subject of the previous IETF last call is at [1].

[1] https://www.ietf.org/rfcdiff?url1=draft-ietf-dane-openpgpkey-05&url2=draft-ietf-dane-openpgpkey-07

2016-02-08
07 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2016-02-08
07 Stephen Farrell Last call was requested
2016-02-08
07 Stephen Farrell IESG state changed to Last Call Requested from Waiting for Writeup::AD Followup
2016-02-08
07 Stephen Farrell Last call announcement was changed
2016-02-08
07 Stephen Farrell Last call announcement was generated
2016-01-29
07 Stephen Farrell Last call announcement was generated
2016-01-27
07 Paul Wouters New version available: draft-ietf-dane-openpgpkey-07.txt
2015-12-03
06 Tero Kivinen Request for Last Call review by SECDIR Completed: Not Ready. Reviewer: Donald Eastlake.
2015-10-19
06 (System) Sub state has been changed to AD Followup from Revised ID Needed
2015-10-19
06 Paul Wouters IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2015-10-19
06 Paul Wouters New version available: draft-ietf-dane-openpgpkey-06.txt
2015-10-14
05 (System) Notify list changed from draft-ietf-dane-openpgpkey.ad@ietf.org, dane-chairs@ietf.org, ogud@ogud.com, draft-ietf-dane-openpgpkey.shepherd@ietf.org, draft-ietf-dane-openpgpkey@ietf.org to (None)
2015-09-14
05 Stephen Farrell IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup
2015-09-11
05 (System) IESG state changed to Waiting for Writeup from In Last Call
2015-09-10
05 Stephen Farrell Intended Status changed to Experimental from Proposed Standard
2015-09-08
05 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2015-09-08
05 Michelle Cotton
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-dane-openpgpkey-05.txt. If any part of this review is inaccurate, please let us know.

IANA …
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-dane-openpgpkey-05.txt. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the Resource Record (RR) TYPEs sub-registry of the Domain Name System (DNS) Parameters registry located at:

https://www.iana.org/assignments/dns-parameters/

the existing, temporary assignment for the RRtype 61:

TYPE Value Meaning Reference
OPENPGPKEY 61 OpenPGP Key [draft-ietf-dane-openpgpkey]

will be made permanent and the reference will be changed to [ RFC-to-be ].

IANA understands that this is the only action that needs to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 


Thank you,

Michelle Cotton
Protocol Parameters Engagement Manager
ICANN
2015-09-03
05 Jean Mahoney Request for Last Call review by GENART is assigned to Suresh Krishnan
2015-09-03
05 Jean Mahoney Request for Last Call review by GENART is assigned to Suresh Krishnan
2015-09-03
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Donald Eastlake
2015-09-03
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Donald Eastlake
2015-09-01
05 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Kiran Chittimaneni
2015-09-01
05 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Kiran Chittimaneni
2015-08-28
05 Cindy Morgan IANA Review state changed to IANA - Review Needed
2015-08-28
05 Cindy Morgan
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Using DANE to Associate OpenPGP …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Using DANE to Associate OpenPGP public keys with email addresses) to Proposed Standard


The IESG has received a request from the DNS-based Authentication of
Named Entities WG (dane) to consider the following document:
- 'Using DANE to Associate OpenPGP public keys with email addresses'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-09-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  OpenPGP is a message format for email (and file) encryption that
  lacks a standardized lookup mechanism to securely obtain OpenPGP
  public keys.  This document specifies a method for publishing and
  locating OpenPGP public keys in DNS for a specific email address
  using a new OPENPGPKEY DNS Resource Record.  Security is provided via
  DNSSEC.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ballot/


No IPR declarations have been submitted directly on this I-D.


2015-08-28
05 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2015-08-28
05 Stephen Farrell Last call was requested
2015-08-28
05 Stephen Farrell Last call announcement was generated
2015-08-28
05 Stephen Farrell Last call was requested
2015-08-28
05 Paul Wouters New version available: draft-ietf-dane-openpgpkey-05.txt
2015-08-28
04 Stephen Farrell Last call was requested
2015-08-28
04 Stephen Farrell Ballot approval text was generated
2015-08-28
04 Stephen Farrell Ballot writeup was generated
2015-08-28
04 Stephen Farrell IESG state changed to Last Call Requested from AD Evaluation
2015-08-28
04 Stephen Farrell Last call announcement was generated
2015-08-27
04 Paul Wouters New version available: draft-ietf-dane-openpgpkey-04.txt
2015-06-03
03 Stephen Farrell IESG state changed to AD Evaluation from Publication Requested
2015-05-26
03 Amy Vezza Notification list changed to draft-ietf-dane-openpgpkey.ad@ietf.org, dane-chairs@ietf.org, ogud@ogud.com, draft-ietf-dane-openpgpkey.shepherd@ietf.org, draft-ietf-dane-openpgpkey@ietf.org from "Olafur Gudmundsson" <ogud@ogud.com>
2015-05-23
03 Ólafur Guðmundsson
Document Writeup for Working Group Documents

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up.

Changes are expected …
Document Writeup for Working Group Documents

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

Proposed Standard is requested, and indicated in the header.
Note: see item (6) ***

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

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.


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,

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

DS has read every version of the document, and worked with the editor
in addressing isuses. A extensive working group last call was
conducted, along with with a session at a DANE meeting where people
from the email community had a frank discussion about the issues and
scope of the document. This document has advanced as far as it can
inside the WG and pubishing as Proposed Standard is the the desire of
the WG.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

Not really.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

More review from email community will not hurt, but unless they have
an sudden insight as how to "cannonize" email address this is the best
we can do.


(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

There are are two issues that have been raised over and over again.
A. Do not publish email addresses in the DNS.
B. You are not guaranteed to find the key of the actual person you
want to send signed/encrypted email to.

Both of these issues have been refuted and as publication is optional
A. does not realy apply. For B. there conversion techique is has got
extensive input and improved based on that. There is not much more we
can do at this point to address it.

Some people have said that they would be more comfortable with the
document published as Experimental. The working group requests
publication as Standards Track but can live with Experimental status.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78
and BCP 79 have already been filed. If not, explain why?

No IPR filed

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR filed

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

Strong


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

None

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Yes the document was reviewed by DNS RRtype Registry experts.


(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

No


(15) Are there downward normative references references (see RFC
3967
)? If so, list these downward references to support the Area
Director in the Last Call procedure.

No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

No


(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226
).

Only IANA action requested is to updat a reference upon publication of
this document.

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

Done

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

ID-nits

None.

2015-05-23
03 Ólafur Guðmundsson Responsible AD changed to Stephen Farrell
2015-05-23
03 Ólafur Guðmundsson IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2015-05-23
03 Ólafur Guðmundsson IESG state changed to Publication Requested
2015-05-23
03 Ólafur Guðmundsson IESG process started in state Publication Requested
2015-05-23
03 Ólafur Guðmundsson Changed document writeup
2015-05-23
03 Ólafur Guðmundsson Intended Status changed to Proposed Standard from None
2015-05-23
03 Ólafur Guðmundsson Notification list changed to "Olafur Gudmundsson" <ogud@ogud.com>
2015-05-23
03 Ólafur Guðmundsson Document shepherd changed to Ólafur Guðmundsson
2015-04-01
03 Paul Wouters New version available: draft-ietf-dane-openpgpkey-03.txt
2015-03-09
02 Paul Wouters New version available: draft-ietf-dane-openpgpkey-02.txt
2015-02-23
01 Warren Kumari IETF WG state changed to In WG Last Call from WG Document
2014-10-27
01 Paul Wouters New version available: draft-ietf-dane-openpgpkey-01.txt
2014-04-10
00 Paul Wouters New version available: draft-ietf-dane-openpgpkey-00.txt