ietf-openpgp
[Top] [All Lists]

RE: Trust Packets

2004-01-30 21:48:37

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Gutmann wrote:

I could disable the 100+ certs in my browser (a mere 700 
mouse clicks, only a
day or so's work) but then I'd constantly have warning 
dialogs popping up and
annoying me while I'm exercising my trust in Reg.E/Reg.Z.

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.

As for the warning dialogs: These can be disabled in IE. Again, if
the browser doesn't let you disable them, that's a UI issue.

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. Their certificates could easily have been swapped out by
a MITM attack. Now, if you have a trusted out-of-band channel where
you obtained the certificate or its fingerprint, then add the
certificate to your browser's trusted store. Otherwise, exercising
trust in the certificate is pointless because you're not sure of its
origin. As I said before, in this scenario, HTTPS is effectively
reduced in security to HTTP.

The trust in a normal HTTPS situation flows like this:
User -> Computer Vendor -> OS Vendor -> Bundled Browser (optionally
- -> signed browser upgrades from [Alternate] Browser Vendor) -> Root
CAs (optionally -> intermediate CAs) -> Site Operator & Site
Certificate -> HTTPS Session

If you add an alternate certificate that you've verified some other
way:
User -> Site Operator & Site Certificate -> HTTPS Session

                                                           In
addition disabling only the Verisign roots won't prevent Verisign 
certs from being
accepted, because of the implicit universal 
cross-certification in browsers
any other CA could issue Verisign certs and they'd be treated 
no diferently
from the real thing.

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. Who would explicitly configure a server this way when the
VeriSign certificates are in basically every product that uses SSL?
And, in this example then, the certificate ceases to be a VeriSign
certificate and is by definition a certificate which inherits its
trust through the other root. So, if you don't trust that root,
delete it. In any case, none of this is "implicit" or "universal".

Stop making excuses. Commercial certification authorities and the
X.509 hierarchical structure make it easy for the non-technical
masses to use HTTPS. Not everyone has the desire to participate in a
fragile web of trust just to order the latest gadget off a website.
Due to capitalism, the CAs make money providing their service. While
I share your distrust of VeriSign in some ways, especially in the CA
business after the Microsoft fiasco, this is not a protocol or
implementation detail. The system is designed and can be used to
prevent 

This thread is off-topic so I will refrain from any further response.

Richard Laager

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.2

iQA/AwUBQBszmW31OrleHxvOEQJLegCgnHZ9kcAoECb7cW+bLujLm7kjSckAn1zl
u39jLDIps3NXQj9lfUFknPzU
=f3+0
-----END PGP SIGNATURE-----


<Prev in Thread] Current Thread [Next in Thread>