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

Reply via email to