[Discuss] PGP Basics

[gaf at blu.org (Jerry Feldman)]

There are a few ways you can mitigate this.
First is to sign your new key with the old key, then send the new key to 
your trust group signed by your old key.
So, if you send me your new key for me to sign, encrypted, and signed by 
your old key, I will then sign your new key. The main issue is to 
establish trust. If I can insure that it was you that sent me your key, 
I will gladly sign it. Another way that applies only to Dave Kramer and 
me is to upload the key to one of our servers possibly into your home 
directory.

On 10/11/2011 01:00 PM, John Abreau wrote:
> Hey, I created a new key the day after the keysigning! It's just that the
> next BLU keysigning party is still 11 months away...
>
>
>
> On Tue, Oct 11, 2011 at 12:38 PM, Jerry Feldman<gaf at blu.org>  wrote:
>> On 10/10/2011 09:28 PM, Edward Ned Harvey wrote:
>>>> From: discuss-bounces+blu=nedharvey.com at blu.org [mailto:discuss-
>>>> bounces+blu=nedharvey.com at blu.org] On Behalf Of Kyle Leslie
>>>>
>>>> Hola Everyone.  With the recent talk about PGP and the growing need for
>>> its
>>>> use at my company I have been trying to learn about it.
>>> I'll encourage you to look at S/MIME instead.  It's much easier.
>>>
>>> Surely some people on this list will say PGP is more secure, and as with
>>> anything, there's a grain of truth which is probably not represented
>>> entirely accurately.  The fundamental difference is this:  S/MIME is based
>>> on SSL, which means anything you send/receive is automatically checked for
>>> validity using the built-in SSL root Trusts.  These are the same
>>> organizations that are used to trust https traffic, or anything else based
>>> on SSL.
>>>
>>> So the grain of truth is like this:  As long as you're trusting a 3rd
>>> party
>>> such as verisign or thawte, then there's an attack vector which otherwise
>>> doesn't exist.  An attacker only needs to somehow compromise one of these
>>> root trusts, and then they can forge signatures.  Although rare, this has
>>> been known to happen.  When it happens, the compromised certificate
>>> authority promptly revokes any compromised certs (as soon as they discover
>>> they've been compromised)...  So it's important to keep current with
>>> system
>>> updates.
>>>
>>> On the flip side, with PGP you don't have automatic trusts.  You need to
>>> somehow decide you trust someone's cert based on some kind of out-of-band
>>> information.  Maybe because the person told you over the phone "I'm
>>> sending
>>> it now" and then it arrived a second later, or whatever.  The problem with
>>> something like this is...  Just like the "Are you sure?" prompts that you
>>> get everytime you try to do anything in windows...  People just make a
>>> habit
>>> of always clicking "Yes" without thinking about it.
>>>
>>> Everyone has their own opinions, about which is more trustworthy and which
>>> is more convenient.  My opinion is that if you're deploying one of these
>>> technologies for your company, IMHO your users would be more secure with
>>> S/MIME, and it's much more convenient.  If you were only deploying it for
>>> yourself, then you as an interested and technical user might actually get
>>> better security out of PGP.
>>>
>>> You can get free S/MIME certs from startssl.com, and probably a number of
>>> other locations.  If you're interested, I have an example here:
>>>
>>> http://dl.dropbox.com/u/543241/Digital%20ID%20Step%201%20-%20Create%20Cert%2
>>> 0IE9%20Win7.pdf
>>> and
>>>
>>> http://dl.dropbox.com/u/543241/Digital%20ID%20Step%202%20-%20Outlook%202010.
>>> pdf
>>>
>> It does come down to trust, but also a need. I can pretty well trust those
>> whose keys I have signed, and who have conversely signed mine. But, where is
>> my need? I don't have much need, and until JABR gets a new key I don't much
>> trust him :-). But, in a corporate environment when you are exchanging
>> email, both digital signatures as well as encryption are workable. So, in a
>> corporate environment, you might upload your public key to the corporate key
>> server (assuming PGP). By having only employees being allowed to upload, you
>> can establish trust as long as it is being properly managed. If an employee
>> leaves, then there should be a procedure to decertify his/her key. Same
>> would apply to ssl certs. I think in the original poster's situation, he is
>> in a corporate PGP environment,
>
>


-- 
Jerry Feldman<gaf at blu.org>
Boston Linux and Unix
PGP key id:3BC1EB90
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90