> 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 ;)
I can fully agree with every word that you said. Please see „real“-world and make a difference between SMTP and PGP (or for me interesting: SMIMEA). PRO: lowercase Concerning different things like user@ or user+foo@, CNAME is an option that works. I have done some tests on the SMIMEA thing and I use several CNAMES for different email addresses that point to the same address and therefor to the same RR. Sincerely Christian
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
