Relevance of PGP?

Matthew Gillen me-5yx05kfkO/aqeI1yJSURBw at public.gmane.org
Tue Jun 14 10:13:14 EDT 2011


On 06/14/2011 09:37 AM, Edward Ned Harvey wrote:
>> From: Derek Martin [mailto:invalid-yPs96gJSFQo51KKgMmcfiw at public.gmane.org]
>> Sent: Monday, June 13, 2011 3:35 PM
>>
>> If you don't take the time to actually verify BOTH the identity of the
>> person sending you messages, and the secret they've given you, then
>> you're right, there's no difference.  Both are worthless, beyond
>> keeping casual prying eyes from seeing your conversation... you
>> never really know for sure that you're communicating with the person
>> you think you are at the time.
> 
> You're saying, that because the OS "trusts" a list of root CA's, then
> anybody who can infiltrate or circumvent security measures of any of those
> CA's can forge communications on behalf of anyone.
> 
> True.  You can only trust S/MIME signing/encryption as much as you trust the
> procedures of the root CA's.

Right, and there are two problems with that:
 1) the list of root CA's that are trusted by default (e.g. by firefox),
is quite long
 2) /Any/ root CA getting compromised leads to the potential for /all/
communications to be compromised via man-in-the-middle attacks.

#2 isn't a problem with the S/MIME methodology in general, it's a
problem with how applications do their CA checking.  No application that
I know of allows you to say "trust this CA only for these domains".
This IMHO would make a lot of sense for email certificates, but it would
be very problematic for normal webserver certificates (to much burden on
the end-user).

> For the KGB or CIA, certainly SSL CA trust would not be acceptable.

If you frame the problem a little differently, it isn't true that SSL
isn't good enough for the gov't. US DoD is a huge user of X509
certificates.  Here's the rub: they have their own CAs.  If you use your
own CAs and don't use the 'standard' root CAs that get distributed w/
firefox et al, then SSL and S/MIME can be as trustworthy as your own CAs.





More information about the Discuss mailing list