Thanks Paul for the really speedy response. I'll raise the outstanding points on the IESG telechat and respond after the IESG has discussed those. (Alexey and/or other ADs might choose to also respond in the meantime which is also fine.)
Cheers, S. On 19/04/16 21:05, Paul Wouters wrote: > On 04/19/2016 01:42 PM, Alexey Melnikov wrote: >> Alexey Melnikov has entered the following ballot position for >> draft-ietf-dane-openpgpkey-09: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ >> >> >> >> ---------------------------------------------------------------------- >> 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. > > I have addressed most issues and incorporated most suggestions. See below for > the two issues left. > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-dane-openpgpkey-10.txt > >> 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) [email protected] >> (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. > > I have added this to the document. > > >> 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. > > I have added this to the document. > > > >> >> >> ---------------------------------------------------------------------- >> 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.) > > This has been changed to use local-part instead of user name. > >> Second, it probably makes sense to note that local-part is an ABNF >> production contained in a broader syntax, not just a name. > > See above. text was changed. > >> Third, the term "encoding" here is inaccurate; it should be "charset". > > Fixed. > >> 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 on e 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 >> [email protected], [email protected] and >> [email protected], but not others. > > The problem with putting any text into the document regarding case is that a > few people in the working group > deemed that mentioning the case issue would only lead implementations to > "illegally" lowercase it. I was > explicitly prevented from adding any text about lowercase/uppercase. What you > are asking me to do here, > is exactly that - introduce text to mention the lowercase problem. > > I do believe it is only logical to lowercase and that case-sensitive > local-parts do not effectively exist on > the internet. This can further be seen by the references implemention section > that lists only software that > performs this "illegal" lowercase. > > I will need guidance from the IESG on how to proceed. If we do not add > lowercasing as a step before hashing, > please let me know what text should be added where, so that I do not run into > new objections within the working group. > >>> 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. > > Can the IESG please provide the text and location for this, as some in the > working group are loudly opposed to any such text. > > >> --------------- >> >> 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. > > I do not think the TTL should be used here for key management. The TTL > relates to the DNS transport and caching only. > > Paul > > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
