<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 27, 2013 at 10:18 PM, Perry E. Metzger <span dir="ltr"><<a href="mailto:perry@piermont.com" target="_blank">perry@piermont.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On Tue, 27 Aug 2013 19:57:30 -0600 Peter Saint-Andre<br>
<<a href="mailto:stpeter@stpeter.im">stpeter@stpeter.im</a>> wrote:<br>
<div class="im">> On 8/27/13 7:47 PM, Jonathan Thornburg wrote:<br>
> > On Tue, 27 Aug 2013, Perry E. Metzger wrote:<br>
> >> Say that you want to distribute a database table consisting of<br>
> >> human readable IDs, cryptographic keys and network endpoints for<br>
> >> some reason. Say you want it to scale to hundreds of millions of<br>
> >> users.<br>
> ><br>
> > This sounds remarkably like a description of DNSSEC.<br>
> ><br>
> > Assuming it were widely deployed, would<br>
> > DNSSEC-for-key-distribution be a reasonable way to store<br>
> >   email_address --> public_key<br>
> > mappings?<br>
><br>
</div>> You mean something like this (email address --> OTR key)?<br>
><br>
> <a href="https://datatracker.ietf.org/doc/draft-wouters-dane-otrfp/" target="_blank">https://datatracker.ietf.org/doc/draft-wouters-dane-otrfp/</a><br>
<br>
My problem with the use of DNSSEC for such things is the barrier to<br>
entry. It requires that a systems administrator for the domain your<br>
email address is in cooperate with you. This has even slowed DNSSEC<br>
deployment itself.<br></blockquote><div><br></div><div>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?<br></div><div><br></div>
<div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
It is, of course, clearly the "correct" way to do such things, but<br>
trying to do things architecturally correctly sometimes results in<br>
solutions that don't deploy.<br>
<br>
I prefer solutions that require little or no buy in from anyone other<br>
than yourself. One reason SSH deployed so quickly was it needed no<br>
infrastructure -- if you controlled a single server, you could log in<br>
to it with SSH and no one needed to give you permission.<br>
<br>
This is a guiding principle in the architectures I'm now considering.</blockquote><div><br></div><div> I very much agree that deployment is all. </div></div><div><br></div><div>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.</div>
<div><br></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br>
</div></div>