+1 Until somebody else solves the matching problem it should be acknowledged and ignored.
Jim > -----Original Message----- > From: dane [mailto:[email protected]] On Behalf Of Paul Hoffman > Sent: Sunday, April 05, 2015 6:23 PM > To: [email protected] > Subject: [dane] Proposed design for draft-ietf-dane-openpgpkey (and then for > draft-ietf-dane-smime) > > Greetings again. The discussion about exact-match and discovery in draft-ietf- > dane-openpgpkey has been useful for finding out what the use cases are, and > it's time to settle on a design that works for most people (we're never going to > make everyone happy). My motivation for this message is that Jakob and I will > match whatever the WG comes up with for draft-ietf-dane-openpgpkey in our > draft-ietf-dane-smime draft. > > Proposal: > > - Lookup of OpenPGP and S/MIME keys and certs in the DNS are exact-match, > following the DNS's database model. This is known to possibly fail when the > party looking up the address has a copy of the email address different than > what might be entered in the zone, such as with different casing. There is no > expectation in this design that all variants that might be delivered to for a > particular address will have key records. This design keeps the security model > understandable: it's all authenticated just by DNSSEC. > > - Discovery of delivery variants is better handled by a more flexible protocol, > such as WebFinger. In fact, instead of just looking for variants and then coming > back to the DNS to get the key, that protocol can instead hand back the keys > and certs directly in a single response. The security model for that protocol > would also be simple: it's all authenticated by the TLS cert of the server. This > new protocol should probably be designed somewhere in the Applications > Area, not here, even though some of what is being delivered are objects > similar to what we are delivering here. > > If folks agree with this proposal, we can move forwards with draft-ietf-dane- > openpgpkey pretty much as it is. (PaulW: you threw in downcasing before > hashing, which is definitely not what people agreed to at the meeting.) For > draft-ietf-dane-smime, we can then use the same format and semantics, and > add in the LDAP access model proposed by Eric and Scott, which historically > has never applied to OpenPGP. > > Thoughts? > > --Paul Hoffman > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
