Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic to the Top
- Bookmark
- Subscribe
- Printer Friendly Page
0
Interopera bility with non-PGP keys....
Options
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
12-21-2005 04:27 PM
I was under the impression that this product supported non-PGP keys, specifically X.509v3 certificates (at least the literature says that).
However, I cannot seem to import the public keys for external users that do not use PGP, i.e. users using VeriSign (for example). PGP desktop appears to only want to import PEM, PFX, or P12 extensions. These are extensions used when users export their private keys - not something they would do when exchanging public keys. The extensions for public keys when exported are typically CER or P7B. In any case, exporting keys is not the best way to do it - simply having a user send you a signed message is an easy way of capturing their public key, which you can then use for encrypting mail to them (once you add them to your Outlook contacts).
It also appears that PGP does not recognize non-PGP keys in inbound e-mail that is signed with a non-PGP key. Without PGP installed, when you receive a signed e-mail you simply add that user to your contacts, and then you can send them encrypted mail (obviously signing as well, using your own private key).
It does not seem like there is great interoperability with non-PGP users - if anyone has some useful information to offer (based on actual experience), that would be great….
If not I will most likely return the product …..
However, I cannot seem to import the public keys for external users that do not use PGP, i.e. users using VeriSign (for example). PGP desktop appears to only want to import PEM, PFX, or P12 extensions. These are extensions used when users export their private keys - not something they would do when exchanging public keys. The extensions for public keys when exported are typically CER or P7B. In any case, exporting keys is not the best way to do it - simply having a user send you a signed message is an easy way of capturing their public key, which you can then use for encrypting mail to them (once you add them to your Outlook contacts).
It also appears that PGP does not recognize non-PGP keys in inbound e-mail that is signed with a non-PGP key. Without PGP installed, when you receive a signed e-mail you simply add that user to your contacts, and then you can send them encrypted mail (obviously signing as well, using your own private key).
It does not seem like there is great interoperability with non-PGP users - if anyone has some useful information to offer (based on actual experience), that would be great….
If not I will most likely return the product …..
0
No Subject
Options
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
12-22-2005 12:48 PM
You are correct that PGP does not automatically grab X509 certificates from incoming email at this time.
It also does not import binary CER files.
You are somewhat incorrect in that PEM format is a very well used format for exchanging public keys. PEM is base-64 encoded, while CER is binary encoded, unless you are microsoft in which case CER is either.
You can use the MS certificate export wizard to convert to PEM by selecting the Base-64 Encoded option. You will then need to change the extension to PEM because MS puts .cer on everything, even things that are really PEM.
It also does not import binary CER files.
You are somewhat incorrect in that PEM format is a very well used format for exchanging public keys. PEM is base-64 encoded, while CER is binary encoded, unless you are microsoft in which case CER is either.
You can use the MS certificate export wizard to convert to PEM by selecting the Base-64 Encoded option. You will then need to change the extension to PEM because MS puts .cer on everything, even things that are really PEM.
0
Continuati on.....
Options
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
12-22-2005 02:05 PM
Earle,
Thanks for the reply, information, and clarification - it is much appreciated.
Recognizing that PGP does not currently automatically grab X.509 certificates from incoming mail at this time, it means a manual import of an external users key, i.e., by having that user export their key as a base-64 encoded cert, obtaining that cert file from them, renaming the CER extension to PEM and then importing it. After completing this, one should be able to successfully send encrypted mail to the external user - I assume I am correct in this regard (please correct me if I have made an incorrect assumption).
Slightly more tedious than simply having them send a sign e-mail, but workable nevertheless.
Let me continue the discussion for another question…
One of the principal reasons I purchased PGP was for supporting disk encryption, specifically with the use of the Token. As a result I may decide to keep PGP, and simply disable the PGP e-mail proxying.
However, should I have the need to use PGP e-mail proxying, i.e. to do secure mail with users that can only support PGP, are there any interoperability issues that you are aware of.
In other words, if I have PGP Desktop Professional v9 installed, can I still continue to do signed and encrypted mail as I currently do (as I do without PGP installed), as well as PGP mail (I assume I would obviously have to edit the policies to avoid conflicts - i.e. create a policy that I would specifically use when I want PGP to handle the encryption).
Thanks, Neil
Thanks for the reply, information, and clarification - it is much appreciated.
Recognizing that PGP does not currently automatically grab X.509 certificates from incoming mail at this time, it means a manual import of an external users key, i.e., by having that user export their key as a base-64 encoded cert, obtaining that cert file from them, renaming the CER extension to PEM and then importing it. After completing this, one should be able to successfully send encrypted mail to the external user - I assume I am correct in this regard (please correct me if I have made an incorrect assumption).
Slightly more tedious than simply having them send a sign e-mail, but workable nevertheless.
Let me continue the discussion for another question…
One of the principal reasons I purchased PGP was for supporting disk encryption, specifically with the use of the Token. As a result I may decide to keep PGP, and simply disable the PGP e-mail proxying.
However, should I have the need to use PGP e-mail proxying, i.e. to do secure mail with users that can only support PGP, are there any interoperability issues that you are aware of.
In other words, if I have PGP Desktop Professional v9 installed, can I still continue to do signed and encrypted mail as I currently do (as I do without PGP installed), as well as PGP mail (I assume I would obviously have to edit the policies to avoid conflicts - i.e. create a policy that I would specifically use when I want PGP to handle the encryption).
Thanks, Neil
0
No Subject
Options
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
12-22-2005 05:19 PM
Yes, if you manually import the certificate as you describe you should be able to send S/MIME mail to recipients (unless you are using Outlook w/ Exchange or Lotus Notes, in which case PGP cannot send S/MIME). Using Outlook as an POP/IMAP/SMTP mailer should work fine.
I am not aware of any conflicts with using Outlook's S/MIME implementation together with PGP. Since one would expect that the S/MIME users do not have PGP keys, if you do not import them into PGP, PGP won't find keys for those users and as such would not attempt to encrypt the mail in any fashion.
I am not aware of any conflicts with using Outlook's S/MIME implementation together with PGP. Since one would expect that the S/MIME users do not have PGP keys, if you do not import them into PGP, PGP won't find keys for those users and as such would not attempt to encrypt the mail in any fashion.
0
No Subject
Options
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
12-22-2005 06:14 PM
Earle,
Thanks for the reply - as we use Outlook with Exchange, it looks like we will have to stick with non-PGP for the vast majority of our secure e-mail requirements.
We may keep a copy of PGP to further investigate it's interoperability, as we recommend security products to our clients. Probably worthwhile to look at PGP as it matures, as we have never really been PGP users – we have always been in the more corporate stream, full fledged PKI, Entrust, etc.
Thanks for all your info….
Thanks for the reply - as we use Outlook with Exchange, it looks like we will have to stick with non-PGP for the vast majority of our secure e-mail requirements.
We may keep a copy of PGP to further investigate it's interoperability, as we recommend security products to our clients. Probably worthwhile to look at PGP as it matures, as we have never really been PGP users – we have always been in the more corporate stream, full fledged PKI, Entrust, etc.
Thanks for all your info….
