Hi guys, I've been silently following this whole process basically from the beginning and I (hope I) read all arguments and understood them. It's a difficult topic and most things can't be simply declared "right" or "wrong", so I understand why there still are so many disputing opinions.
But there are (mainly) two points, where I think the discussion has taken a wrong path, focussing too much on SMTP and too little on PGP. First is the CaSe topic: yes, the RFCs are clear, a SMTP server is not allowed to make assumptions about the interpretation of case on the receiving end. But: we are not describing a SMTP server here. We are describing a standard for PGP key LOOKUPS. I've been using PGP for 20 years (in 2 months my oldest used key reaches that age, it's 1248 Bit so I might have to revoke it some day though :) and I have never encountered a case sensitive lookup. GPG for example (and thus mutt's integration of it for lookup) ignores case completely when looking up a key. Also all key servers I use ignore case when you search for a email address. Both don't even offer an option for case sensitive lookup. And I really don't see and never have experienced a problem with it. As discussed, technically it is possible to have mail servers which route different cased addresses really to different people, but even though it is RFC compliant to do so, in the real world it should be avoided - setups where it happend were changed, as it is just too error prone. It's a theoretical corner case. On the other hand, people typing emails in "wrong" casing are more the default than the exception. If we build a lookup mechanism that ignores that, we make the same mistake again that has been made so many times in the history of email encryption: ignore the people supposed to use it. If we want more encryption to happen, the lookup has to work in real life cases (no pun intended ;). And it has to work BETTER than the existing key servers, not worse. So: a strong PRO lowercasing before lookup (as it's already in the current draft) from my side. If there still are security concerns: It would be possible to add a text telling domain operators, who know they route different cased addresses to different mailboxes, not to implement this standard for obvious reasons %) Won't affect real life deployments anyway. The second point is the often discussed "fuzzy matching". As John pointed out perfectly correct (that's why I chose to follow-up here): > When a mail server handles a locally addressed piece of mail, it maps > the local-part of the address into some sort of internal identifier. > The local identifier for FOO might be FOO or foo but it's as likely to > be user1234. But that's again the SMTP side! When we look at PGP and the OpenPGP standards, we find the term "email address" as part of the User ID. You create PGP Keys for your email addresses, not for your mail accounts! It is not totally uncommon for people to have user@ and user+private@ to be delivered into the same mailbox, but have different PGP keys for it. On the other hand, if I really want people to encrypt mails to my user+usenet199703@ address, I should also publish my key with that ID included. The same goes for username@gmail and user.name@gmail. If both are used in your email conversations, add both as User IDs to your key. It's the only way the sender can know the key is intended to be used for that address. It's also the reason, that in the web of trust you don't sign keys as many people think. You sign the individual user IDs with a key. Coming back to the real world: I hardly see people use encryption on such "modified" addresses, and if they do, then intentionally and with a key for it. That's a topic outside the scope of this draft, the important part is that we don't block such usage - and we don't. It's easy to publish the same key under many labels. So again: no objection to the current draft, we should not encourage implementors to do fuzzy matching stuff, but we also don't have to plan for it on the server side. It's the decission of a user which User IDs he adds to his PGP key and for those it will be used. I have some more thoughts on other topics of the current discussion, but that would be too much for this already too long to read post ;) Greetings, Florian -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstrasse 15, 81669 Muenchen Sitz der Gesellschaft: Muenchen, Amtsgericht Muenchen: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
