Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Yes most of the inquiry was because we have clients that will only send documents via PGP encryption. Then with all the hustle and bustle about PGP on this list I have been more and more interested. I didn't set the system up here so it has been a bit confusing. That said you have answered my questions and I think any further headaches are not on my end, but on the server that someone put together here to house certified public keys. I have been trying to look towards myself for things not working but it seems with testing of my coworkers, the issues are wide spread. I guess my next question would be, if I create a key through our system here, could I just continue to redistribute that to anyone? So the next time there is a key signing I could come with my key I got at my current position and register it with you all? On Tue, Oct 11, 2011 at 1:00 PM, John Abreau <abreauj at gmail.com> 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 > > > > _______________________________________________ > > Discuss mailing list > > Discuss at blu.org > > http://lists.blu.org/mailman/listinfo/discuss > > > > > > -- > John Abreau / Executive Director, Boston Linux & Unix > GnuPG KeyID: 0xD5C7B5D9 / Email: abreauj at gmail.com > GnuPG FP: 72 FB 39 4F 3C 3B D6 5B E0 C8 5A 6E F1 2C BE 99 > _______________________________________________ > Discuss mailing list > Discuss at blu.org > http://lists.blu.org/mailman/listinfo/discuss >
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |