Subject: Re: [xmpp] Commonality of proof types

From: Matt Miller <[email-masked]>
Date: Wed, 4 Apr 2012 15:05:11 -0600

On Mar 28, 2012, at 09:47, Richard L. Barnes wrote:

>>> Just musing on what proof types look like...
>> 
>> That smells like it's somewhat combining the proof types.
>> 
>> That is, you're saying we'd use DNSSEC if possible, but to maximize the
>> potential of it working, we'd serialize the chain and stick it somewhere
>> well-known, secured by HTTPS as a final fallback.
>> 
>> The serialization of the chain is basically a potted set of the DNS
>> answers (and their signatures) that you'd have got if you'd gone through
>> the DNS anyway. If you can (only) trust the HTTPS cert used to secure
>> the blob, you use that.
>> 
>> Does that sounds roughly right?
> 
> Yep, you got it.
> 
> 
>> My only concern is that the "bare" certificate in .well-known (as
>> exemplified by TurboHalibut) has a very low implementation threshold[1],
>> whereas this would invoke DNSSEC quite heavily.
>> 
>> Dave.
>> 
>> [1] - This means it's easy to code.
> 
> Appreciate the concern.  It does help that there are already tools, as in:
> <http://www.imperialviolet.org/2011/06/16/dnssecchrome.html>
> 

Using a "bare" certificate isn't just easy to code against, it's also easy to obtain and deploy (there's already lots of tools for that, certain doctors notwithstanding). This makes it a lot easier for me to explain to ops how to deploy it, and without requiring me to provide more utilities outside of my core product/service.

As DANE gains wider acceptance, I expect DNS hosts to provide nice web tools that let that same ops person take that same cert and drop it into a web form.

- - m&m

Matt Miller - <[email-masked]>
Cisco Systems, Inc.