On Tue, Aug 27, 2013 at 10:18 PM, Perry E. Metzger <pe...@piermont.com>wrote:
> On Tue, 27 Aug 2013 19:57:30 -0600 Peter Saint-Andre > <stpe...@stpeter.im> wrote: > > On 8/27/13 7:47 PM, Jonathan Thornburg wrote: > > > On Tue, 27 Aug 2013, Perry E. Metzger wrote: > > >> Say that you want to distribute a database table consisting of > > >> human readable IDs, cryptographic keys and network endpoints for > > >> some reason. Say you want it to scale to hundreds of millions of > > >> users. > > > > > > This sounds remarkably like a description of DNSSEC. > > > > > > Assuming it were widely deployed, would > > > DNSSEC-for-key-distribution be a reasonable way to store > > > email_address --> public_key > > > mappings? > > > > You mean something like this (email address --> OTR key)? > > > > https://datatracker.ietf.org/doc/draft-wouters-dane-otrfp/ > > My problem with the use of DNSSEC for such things is the barrier to > entry. It requires that a systems administrator for the domain your > email address is in cooperate with you. This has even slowed DNSSEC > deployment itself. > How about the fact that the US govt de facto controls the organization controlling the root key and it is a single rooted hierarchy of trust? But in general, the DNS is an infrastructure for making assertions about hosts and services. It is not a good place for assertions about users or accounts. So it is a good place to dump DANE records for your STARTTLS certs but not for S/MIME certs. > It is, of course, clearly the "correct" way to do such things, but > trying to do things architecturally correctly sometimes results in > solutions that don't deploy. > > I prefer solutions that require little or no buy in from anyone other > than yourself. One reason SSH deployed so quickly was it needed no > infrastructure -- if you controlled a single server, you could log in > to it with SSH and no one needed to give you permission. > > This is a guiding principle in the architectures I'm now considering. I very much agree that deployment is all. One thing I would like to do is to separate the email client from the crypto decision making even if this is just a temporary measure for testbed purposes. I don't want to hack plugs into a dozen email clients for a dozen experiments and have to re-hack them for every architectural tweak. -- Website: http://hallambaker.com/
_______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography