just a quick core-dump here to build on my comments at the mic yesterday in
the DANE session regarding the "How to look up KEY’s for Email addresses"
topic..
i would restate the topic as "given an email address, lookup a public key(s)
that may be mapped to it"
some of us have been around this overall block before back in the
mid-to-late '90s.
note that formally, an email addr is an "addr-spec":
addr-spec = local-part "@" domain [RFC5322]
the values of local-parts are typically based on "natural names", eg of
people. Natural names are syntactically messy and they change over time,
thus so do typical email addr local-part values.
from my personal perspective, based on past experience, here's what I think
would be viable for standardization from a high-level non-DANE-specific
perspective..
###
1. given email addr of "[email protected]"
2. find a "local-part lookup service" at "example.org" [eg using SRV lookup
in DNS]
3. query example.org's local-part lookup service for info (eg public key)
mapped to "foobar"
4. this results in an answer (eg public key) or not [eg "not found" status code]
###
Thus, the Really Hard Parts -- which involve looking up info mapped to
local-parts (and all the backend support infrastructure) that are not
amenable to standardization (i.e. they are "site-specific") -- are buried
behind/below the "local-part lookup service" (this is where, classically,
when one is mapping 'natural names' to identifiers and other attributes,
registry and directory services are employed).
For a case-history example of the considerations, infrastructure, name &
attribute mapping, etc. of directory service deployment -- which supports a
local-part lookup service for a directory-enabled MTA, see..
Registry & Directory Infrastructure: A Case History
<http://kingsmountain.com/doc/StanfordRegistryAndDirectoryCaseHistory-1999-05-11.pdf>
the local-part lookup is described on slide 16.
names and identifiers characteristics are on slide 15.
backend support infrastructure: slides 12, 13, 14
overall themes/philosophies begin on slide 20
DANE wg might conceivably define how to place subject's public keys in
secure DNS mapped to some identifier, but to me it doesn't seem that any of
the other potentially-standardizable solution portions are appropriate for
the DANE wg.
there have been various approaches to step 2 (above) over the years and I'm
not up-to-speed on the attempts since about year 2000, so won't attempt
point to any, but suggest others who are interested to research it (and not
just within the RFC corpus)
HTH,
=JeffH
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
