[Cryptography] "Trust in digital certificate ecosystem eroding"

[Guido Witmond]

On 05/04/15 15:16, Ben Laurie wrote:
> On 3 May 2015 at 23:45, Christian Huitema <huitema at huitema.net>
>> On Sunday, May 3, 2015, at 11:02 AM, Guido Witmond wrote:
>>> ... With DNSSEC and DANE, the site-owner *specifies* which CA is 
>>> the correct one *for their own site*.
>> 
>> Yes. And this is indeed the right way to look at the problem. Not 
>> "does this certificate chain verifies according to the rules of 
>> WebPKI" but "can we verify that this is the certificate that the 
>> server domain intended to use." DNSSEC could be a great tool for 
>> that.
> 
> Why? DNSSEC has its equivalent of CAs/RAs: registries and registrars.
> Why do you think they'll do any better a job of verifying ownership
> than CAs do?

I believe there is a difference between CA/RA's and the DNS(SEC) registrars:

In the CA/RA world, *every* CA can create valid (looking) certificates
for your site and it's up to the receiver (the end user who gets
MitM'ed) to detect it before trusting the connection with their private
data. This is the responsibility of the end user.

In the DNS(SEC) registrar world, there's only a small subset that can
manipulate your certificates: the ones on the chain from the root (*)
towards your chosen registrar. This is something that the domain owner
can hold the registrar responsible for. If the registrar gets it wrong
(or coerced), shame them, drop them, claim your money back for breach of
contract and go to another. This is the responsibility of the site
operator/domain owner.

That's a huge difference to me, shifting the responsibility *from the
end users to the site operators*.

If these coercions happen just a few times too many, we create a global
monitoring system that permanently checks for coercions and register
these in a CT-like log for posterity.

Regards, Guido.

* (And only if they also replaced your ICANN-Root (pinned in your
browser) beforehand).





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150504/34e6901a/attachment.sig>