On Wed, 1 Apr 2015, Olafur Gudmundsson wrote:
<chair-hat off>
I have been thinking about the issues in finding right email address format for
a user.
IMHO we need to take a step back and think about responsibilities, and
expectations as well as goals.
The goal is to create a simple way to find <email key> for a known
correspondent.
Can we assume that the email encryptor knows the address of recipients in a
format emitted by the recipients email system, and is that good enough?
I believe so.
Can we expect a User mail agent to look up many different form of an email address
just to find an <email key> ?
Whatever we say in the document, some User mail agents will probably
perform multiple lookups, especially for the [email protected] case.
Can we expect a Email provider to publish users email key for number of
variants of the users email address?
That is very unlikely. See the VRFY command in SMTP.
There have been mentions of EMAIL oracle, and other methods to find “canonical
address” for user.
Are there simple rules we can apply to email addresses that decrease the number
of combinations?
For example we can apply lower case rule to the left hand side before hashing?
I do think that lowercasing is a valid option that would reduce the
number one case of requiring CNAME's for the hash("Firstcaps") use case.
Even John wrote in his draft that:
The most common variants are upper and lower case, which are now
invariably treated as equivalent.
<char-hat on>
I think we can publish OPENPGPKEY draft as is tagging it as Opportunistic key
lookup, if it has to be labeled EXPERIMENTAL that is fine.
I would prefer it not be labeled EXPERIMENTAL. This draft isn't rocket science.
We push the issues of canonical email discovery and techniques to improve
finding keys for random email addresses into the OPENPGPKEY-usage document as
there are things that email receivers can do as well as what senders can do.
As long as it is not decided to hold up this document over the -usage
document, or else we are just moving and re-opening this same discussion
again.
As for Stephen's comment regarding sha224. I honestly don't care that
much, but lean towards not manually cutting down hash lengths and let
cryptographers make those calls. Hence the use of sha224.
Paul
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
