On Thu, Jun 11, 2015 at 10:48:20AM -0400, Paul Wouters wrote:
> The base32 split up actually gains you nothing.
>
> Upon review by the WG, we did determine that any translations other than
> case are too dangerous because they are not universal, and there is no
> way you can query a domain for those policies. So any rewriting with +
> or . or - substituation should not be done and the draft does not tell
> you to.
I agree with all of that. If it is to be DNS, then hashing works
no worse than most other encodings. Since IIRC we're not at liberty
to require case-insensitive matching, we can't just use the literal
localpart unencoded, and all encodings suffer most of the same
limitations. Hashing is in many ways the least bad of the available
choices.
So the choices are:
A. Use DNS (with hashed lookup keys)
B. Use some other lookup protocol, with a secure service
endpoint specified via DANE, but a service other than
DNS handling the database lookups.
There are some advantages to each approach. The main disadvantage
of not using DNS (B), is that no such service is readily available,
so new code would be required to implement it.
An argument for (B) would be much more effective if there were
running code for such a service that could be readily integrated
into various environments with pluggable database backends, extensible
canonicalization rules, ...
IIRC it was also pointed out that PGP public keys or SMIME certificaets
obtained for something other than the literal requested address
are not necessarily usable when the identity embedded in the PGP
key or SMIME certificate is different from the one requested.
In particular, trust-anchor certificate usages would run into
significant problems since name matching must still be performed
against the actual certificate or PGP key.
So it is not unreasonable to adopt the view that secure email
requires non-fuzzy peer identities, and that variant addresses
(more than case difference) can't leverage end-to-end encrypted
email without additional keys for each variant (or multiple
names in PGP or SMIME keys when possible).
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
