Subject: Re: Trust Packets

From: [email-masked] (Peter Gutmann)
Date: Sat, 31 Jan 2004 15:37:05 +1300

Lutz Donnerhacke <[email-masked]> writes:

>Furthermore it's easy to implement a keyserver, because you notice how many
>new keys/signatures/userid etc. pp. occured. So merging keys is very simple.

Yup, and real-time status queries are also incredibly trivial, the user
submits a request (e.g. via HTTP, http://......?keyID=abcd), you translate it
into "SELECT COUNT(*) FROM validKeys WHERE keyID=abcd" and return the output
to the user (there's an RFC draft on this floating around somehere on
ietf.org).

>>You forgot:
>> - Maintaining 10 tables at once is entertaining for the software developer.
>
>Yep. Obtaining standard query strings from you local DB developer (it's fun
>for him) and using them as black box is plain recovery. ;-)

While we're rhapsodising about the joys of SQL keyservers, it also makes
debugging incredibly easy, you just drop your favourite SQL browse tool onto
the database and you can check everything that happens, arranged/filtered by
whatever criteria you want.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 31 Jan 2004 18:16:41 +1300

"Richard Laager" <[email-masked]> writes:

>Hmm. I just tested this with IE. Highlight the first certificate, hold shift,
>click the last, hit Delete. Any browser which requires you to individually
>delete certificates has a broken UI that's beyond the scope of this
>discussion. So much for your 700 mouse clicks.

Oh, they must have fixed it in recent versions.

>Exercising trust in the entity Reg.E/Reg.Z (which I'm assuming are sites as
>this is the most logical example given this discussion) is NOT the same as
>trusting the certificate alleging to be from Reg.E/Reg.Z. 

Regulation E and Regulation Z are US consumer-protection legislation covering
use of credit and ATM cards.  I trust Reg.E/Reg.Z to keep me from harm.  I
don't trust a CA-issued to cert to do this (although it can't hurt, for
reasons given in my previous post).

>The only way this would work is if one of the VeriSign certificates in the
>certification path was signed by another CA. Furthermore, it would only work
>if the server sending its SSL certificate included the VeriSign intermediate
>certificate signed by the other root authority. 

Yup.

>Who would explicitly configure a server this way when the VeriSign
>certificates are in basically every product that uses SSL? 

Who would explicitly configure a server to pretend to be Paypal when it isn't?
The answer is the same in both cases.

>In any case, none of this is "implicit" or "universal".

In a browser, every CA is trusted equally, and can usurp every other CA.  The
technical term for this is "implicit universal cross-certification".

Peter.