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 |