In message <[email protected]>, Paul Wouters wr ites: > On Tue, 7 Jan 2014, Mark Andrews wrote: > > Thanks for the review Mark. > > > Section 3.1 has lots of factually incorrect rationals for > > encoding using base32. The DNS is capable of encoding > > binary data in labels up to 63 octets. I've got no problem > > with encoding, but if one intends to include rationalisations > > please make them factually correct. > > I took those from draft-hoffman-dane-smime-01, Paul Hoffman and > Jacob Schlyter believe these to be right as well? Can you explain > what's wrong or perhaps write a replacement paragraph that would > agree with you more? It's mostly there to explain why we did not > end up using username._openpgpkey.domain.com and require base32 encoding. > > > There is no mention of how to encode LHS which exceed 63 octets > > when encoded using base32. Pack the left most labels or the > > right most labels? > > Is that really a use-case we need to cover?
Yes. Lots of mail systems use real names and some people have long names. > How many _real_ +- 50+ LHS character email addresses do people use? The fact that you can't answer that is the reason you need to support them. > I'm happy to document the > limitation, a little more reserved for specifying tricks to go beyond. > For example, http://tools.ietf.org/html/rfc6763 mentions this limit too > in context of UTF8,unicode,Kanji without defining anything to extend > this limit. > > > There is no mention of how to normalise LHS prior to base32 encoding. > > That was discussed offline, but you are right in that the result of > that discussion is missing. Since there seems to be great variety in > how SMTP servers normalise the LHS, we did not want to enforce our > one normalisation. I didn't say enforce one normalisation, though you should specify how to handle all the forms of Postmaster as that is required to be treated as a case insensitive value. > > Are "Hugh" and "hugh" the same? > > That really depends on the SMTP server implementation, the OS it runs > on, the email client used by the sender, etc. > > > Should "hugh" and "hugh+xxx" be treated the same? > > I don't think so? The "+" sign as magic "this is the same user as" > is also not a feature supported by all SMTP servers or specified in > a standard, correct? And people might want to use different keys for > paul+personal versus paul+ietf. And this is not a decision that needs to made by us. This is a decision that should be made by the publisher of the data. One could even have a rule which says "if *+* try as is and on nxdomain try /\(*\)+*/\1/" > > It should be possible to specify normalisation > > rules and store them at _openpgpkey. > > But those rules could change if the SMTP implementation changes? So you update the rules. > So, this document is leaving these as unclear as whether your email > will arrive at all or not based on the presence or absence of > normalisation rules of the SMTP server. This is about how to discover the pgp key stored in the DNSN for a user given a email address. I know that my email address is in various databases as "[email protected]" and "[email protected]" despite me entering it as "[email protected]" in all cases. I still want those who have stored the address as "[email protected]" to be able to find my PGP key. I do not want to have to add 31 CNAME records to the DNS to account for all the permutations of MaRkA. > > It might be useful to suppress the padding at the end of base32 > > encoded strings. We already do similar suppression with NSEC3 > > records. > > Unlike NSEC3 we will see some interaction with userland tools and humans > that will use stock base32 that produces the padding. So I have a slight > preference to stick with the output generated by standard base32 code in > the hope that it will be less confusing to users and developers. s/=*// > Paul -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
