[Cryptography] Verisimilitrust

Ben Laurie ben at links.org
Tue Jan 12 05:15:11 EST 2016


On 12 January 2016 at 01:57, Peter Gutmann <pgut001 at cs.auckland.ac.nz> wrote:
> Ben Laurie <ben at links.org> writes:
>
>>Selective quoting for the win. It also says:
>>
>>"We maintain an internal list of crawled CRLs. The CRLs from that set go to
>>make up the published CRLSet. For size reasons, the list doesn't include all
>>CRLs - EV CRLs and CRLs with good reason codes are taken in preference. CRLs
>>which cover intermediates are typically small and valuable so we try to take
>>as many as possible."
>
> Which doesn't change in any way what I said:
>
>   Provide revocation info for certs - No, the browser vendor will.
>
> The browser vendor is providing revocation info via the CRLSet.  The CA's
> revocation information, CRLs and OCSP, are ignored ("Online (i.e. OCSP and
> CRL) checks are not, generally, performed by Chrome").  The browser is relying
> on the browser vendor, not the CA, to obtain its revocation information.
>
> I don't know how many more ways I can rephrase this, perhaps the following
> will help:
>
>   Browser downloads CRL from CA and checks it -> CA "provides revocation info
>   for certs"
>
>   Browser downloads CRLSet from browser vendor and checks it -> Browser vendor
>   "provides revocation info for certs".
>
> In this case it's clearly the browser vendor providing the revocation
> information.  To put it another way, if the CA goes away, the revocation info
> still gets to the browser.  If the browser vendor goes away, the revocation
> info doesn't get to the browser any more ("CRL/OCSP checks are not
> performed").

Revocations that are derived from CRLs are only "provided by the
browser vendor" in the same sense that CRLs are "provided by your home
router", as is the whole of the rest of the Internet.

Or, to put it another way: if CAs didn't do the majority of
revocations, who would do it instead? Not the browser vendors, that's
for sure.

Which is the core issue: how do you bind domain names (or identities
or whatever) to keys and deal with the inevitable errors in doing so
without introducing some kind of third party? What realistic system do
you propose to replace the CA gravy train with?


More information about the cryptography mailing list