On Sun, 14 Jun 2015, Viktor Dukhovni wrote:
I think this assumption is part of the miscommunication in this
thread. I don't think that's what being suggested. Rather, users
may have lots of valid addresses, known to the receiving system as
being the same user and in fact too many to create a separate DNS
record for each one (as with user+<anything> address extensions).
So the question is whether it should be possible for the key server
server (DNS or otherwise) to recognize address *variants* (not
fuzzy matching). There's nothing fuzzy here, server's domain,
server's matching rules.
Currently there is no mechanism where the server can advertise their
rewriting rules. So a client implementation _could_ query for the
key of [email protected] and if that fails try [email protected]
for those well known domains we know the rewriting happens, then
check within the pgp key data for some confirmation or prompt the
user.
However, I was told I could not even suggest this in the draft.
Then somehow, the crypto key lookup is can be enhanced by using base32
lookups so the server can return crypto keys?
Well with base32, the original input string is recoverable as-is,
and so the server can apply no rules and use the lookup key verbatime,
or it might canonicalize the key in some manner that makes for localparts
in the domain in question.
The problem is that for those who use offline DNSSEC signing, this is
not an workable solution. And since the lowercase()ing would be removed,
it means those with offline signing now have to stuff their zone with
all possible lower/upper casing they think their users virtual keyboards
might slip by, and the only way out there is to basically do the same
thing as above, if you can't find split(base32([email protected])) try
split(base32([email protected])). Which I was told I could not even suggest
in the draft.
We're talking about "v.dukhovni" and "vdukhovni" being equivalent
localparts for my Gmail mailbox and Google unequivocally knows this
is the case, but user agents composing email do not (or at least
should/must not).
Yes, the + and the . use cases are very wel understood and easilly
handled by the mail client doing the DNS lookup.
The draft as currently proposd works with offline and online signing.
And with the simple universally known rewrite rules can be made to
work to support the + and . alias rewriting.
The base32/split solution does not work with offline signing. And can
be made to work to support offline signing and Casing by allowing the
client to issue hash(original), then hash(lowercase) queries.
So pick one.
Paul
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
