On Apr 1, 2015, at 2:13 PM, Nico Williams <[email protected]> wrote:
> On Wed, Apr 01, 2015 at 01:17:15AM -0000, John Levine wrote: >>> An alternative is to go back to the original base32 encoding, which >>> is lossless, and thus can allow the remote DNS server (a special-purpose >>> DNS lookup engine serving a zone with per-user information) to >>> decode the local-part and perform whatever fuzzy matching may be >>> appropriate. >>> >>> The lossless encoding can support longer names by breaking them up >>> into multiple labels. >>> >>> This allows static DNS to be published where desired, and custom >>> code to produce dynamic results when appropriate. >> >> I wrote up a draft summarizing the ways one might do mailbox >> name lookups in the DNS with something close to the local-part >> rules that MTAs have: >> >> http://datatracker.ietf.org/doc/draft-levine-dns-mailbox/ > > The All Names Valid approach has a problem: we're looking for S/MIME or > OPENPGP public keys, so that's what needs to be found. For any public > key algorithms where not every possible bit string is a possible public > key, and where clients can figure that out, the server would have to > generate distinct plausible public keys, otherwise clients could still > enumerate the set of plausible mailboxes. > > I would still prefer to require MUAs to implement the DNS > (base32-encoded) LHS lookup and the pointer-to-HTTPS-server lookup. > Whether mail domains choose to implement static or dynamic DNS lookups, > or the pointer-to-HTTPS-server, should be up to them. Following up on an earlier comment: by adding a URI field to the SMIMEA RR (and keeping the CAD for verification on the other end), zone admin/operators can add an RR at the apex of their zone, that points to another service, secure the delegation with the CAD material, and then (optionally) add per-inbox RRs (also possibly using URI pointers) in their zone. This would also let domains experiment with oracle-like-services in a compatible way with direct key learning from mailboxes, me thinks. :) <snip> Eric _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
