Hello,
On 14 Jun 2015, at 18:10, Paul Wouters wrote:
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 let’s do this!
Allow the client to lowercase (initially, or as a fallback) - I think
everybody agrees there is no harm in this *in practice*, then encode
with split base32. This works for offline signing exactly as well as
lowercase+hashing, but anybody who wants more (support for dot
stripping, variant addresses, etc.) can *choose to* switch to online
signing and get these benefits.
As for the argument “a key is no use if it does not exactly match the
email address”:
(1) keep in mind that whatever lookup mechanism we agree on will be
copied for SMIMEA and, with any luck, other future protocols as well
(2) with split base32, one *could* run a mail server that automatically
issues keys/certs for variant addresses, broadening the scope of
‘opportunistic encryption’ to variant addresses without requiring
client changes
(3) clients *could* decide to trust the DNS server on the variant
mapping
2 and 3 are not required, but it would be good to keep room for them.
With split base32, we get this flexibility. With hashing, we lose it.
Note that this requires very little changed text in the draft. Replace
hashing with split base32, leave section 3.1 (variants) as is (with MUST
NOT). Maybe add some text there about server-side (online signing)
variant mapping.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
