Re: PGP and S/MIME
From: Mailman (mailman_at_anonymous.org)
Date: 08/29/03
- Next message: Bryan Olson: "Re: Magic Flight: latest version of a public-key algorithm using max-plus algebra"
- Previous message: Jim Haynes: "Who manufactured the Enigma machines for WW-II Germany?"
- In reply to: Henrick Hellström: "Re: PGP and S/MIME"
- Next in thread: Neil W Rickert: "Re: PGP and S/MIME"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 29 Aug 2003 01:57:50 +0200
Henrick Hellström wrote:
> Mailman wrote:
>
>> Henrick Hellström wrote:
>>
>>><snip>
>>>Secondly, exactly how would PGP be better than S/MIME w.r.t. worries
>>>about CA competence?
>>
>>
>> Maybe because PGP/GPG, in using the partial trust model, chose to do away
>> with CA's altogether? Basically, instead of delegating the authentication
>> issue to a trusted third party (otherwise known as the CA) you decide on
>> your own level of trust in anyone's key. In a sense YOU are the CA
>> (though without the normally associated fees ;-)
>
> Nothing prevents you from doing more or less exactly the same thing with
> S/MIME /w X.509. I always check each certificate manually. I have even
> deleted some root certificates just so that the browser and the mail
> client will warn me when I encounter certificates issued by that CA.
Very true - but try expaining that to your users (not that I would expect
the average user to deal too well with PGP either)...
>From personal experience: the vast majority of users will click "OK" no
matter what the pop-up says AND won't ever read the message(s).
> It is also possible to build S/MIME frameworks that will add trust
> points to a certificate if it reaches you as the *.p7c contents with a
> *.p7s signature signed by someone you already put explicit trust in. I
> recommend my clients and customers to separate the root certificate
> stores for different applications, just to differentiate their explicit
> trust hierarchies from their implicit and make authentication simpler in
> the former case (i.e. use your own root certificate and issue
> certificates only to those whose identity you have verified).
Again - technically correct, but leaving quite a few things out: for
example the degrees of trust you get with PGP (do I trust keyA more than
keyB, but neither quite as much as keyC?).
> Looking at it from the other angle, you only really act as your own CA
> if you got the public key through personal contact with an individual
> whose physical identity you verified at the scene. If you do it any
> other way you are placing trust on one or more third parties to do that
> verification for you. And I find it very hard to believe that no PGP
> user has ever screwed up when vouching for the authenticity of someone
> elses public key.
For anyone who believes that we also have a special offer on some prime
beach-front property in northern Mali...
The point I was trying to make is that the trust model (full or partial, to
what degree, is it transitive - i.e. if I trust Bob and he trusts Alice,
then do I trust Alice - and if yes to what extent) is explicit with PGP/GPG
and allows for rather fine-grained user/admin control.In the case of S/MIME
you have by default some external trust-defining authority (good luck
explaining to your non-ITSec PHB why you would rather not get a certificate
from Verisign and why some root CA certificate should be removed from the
browsers), and their interests in strong key/entity authentication may not
coincide with yours.
-- Mailman -----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -----== Over 100,000 Newsgroups - 19 Different Servers! =-----
- Next message: Bryan Olson: "Re: Magic Flight: latest version of a public-key algorithm using max-plus algebra"
- Previous message: Jim Haynes: "Who manufactured the Enigma machines for WW-II Germany?"
- In reply to: Henrick Hellström: "Re: PGP and S/MIME"
- Next in thread: Neil W Rickert: "Re: PGP and S/MIME"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
