OpenSSL Team Keys
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all I recently noticed a GPG key on the public key servers supposedly for my name and email address that I did not create or control (key id 9708D9A2). As I sometimes sign OpenSSL releases I thought it was worth reminding everyone that the only keys that should be trusted when verifying an OpenSSL release are those linked to from the website: https://www.openssl.org/about/ Matt -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUWKq1AAoJENnE0m0OYESR+yUH/irTjzn6PUooKHL760y/UTgB 65/R16Ap2n6LfmBGg3acBjaTodZRMSzHM5nkL8ya3fxI89KYP7/F5fQDqfwpjQHx K7s4EImchoRirYmfhKrQzNYfo42gq76EDCIsOvtRAtcvU3ojC5gxTPj+1F61Azdb e4AQCgG1BvfYNslED4IAAtv9qAZB9sPHUpj1ZIMEyh+mquHkYFzNYGDL1dIwlOx2 dZZ9ddWBHdsHyPqKcFsvAbn43C+DGxYm/ZJXE4NP/yQe6UMAPFXCZcTuyNgIgmw0 kzoNbPvlg9t/CrhzDnHhy3umUysKjTWBFVRLuU68a0uJb2VSqZqM8k6TuQPs/E8= =x8a5 -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Team Keys
On 04/11/2014 11:30, Matt Caswell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all I recently noticed a GPG key on the public key servers supposedly for my name and email address that I did not create or control (key id 9708D9A2). As I sometimes sign OpenSSL releases I thought it was worth reminding everyone that the only keys that should be trusted when verifying an OpenSSL release are those linked to from the website: https://www.openssl.org/about/ Matt -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUWKq1AAoJENnE0m0OYESR+yUH/irTjzn6PUooKHL760y/UTgB 65/R16Ap2n6LfmBGg3acBjaTodZRMSzHM5nkL8ya3fxI89KYP7/F5fQDqfwpjQHx K7s4EImchoRirYmfhKrQzNYfo42gq76EDCIsOvtRAtcvU3ojC5gxTPj+1F61Azdb e4AQCgG1BvfYNslED4IAAtv9qAZB9sPHUpj1ZIMEyh+mquHkYFzNYGDL1dIwlOx2 dZZ9ddWBHdsHyPqKcFsvAbn43C+DGxYm/ZJXE4NP/yQe6UMAPFXCZcTuyNgIgmw0 kzoNbPvlg9t/CrhzDnHhy3umUysKjTWBFVRLuU68a0uJb2VSqZqM8k6TuQPs/E8= =x8a5 -END PGP SIGNATURE- I feared something like that was going to happen ever since I noticed howsloppy you were getting with the choice of signing keys. Noted weaknessesin current signing procedures: 1. The list of applicable signing keys included in the tarballs and elsewhereonly lists the fingerprints, not the full key blobs, making it a lot trickier to getand check the keys without getting random other keys from the keyservers. 2. The list seems kind of long, are all these people really authorized to decidewhich release tarballs are real? 3. The list contains a lot of old MD5 fingerprints and seemingly no fingerprintwith modern algorithms, such as whirlpool or SHA-2. The list on the about page doesn't even provide full fingerprints for most keys and the links point to key server searches, not actual local key blobs. 4. Some releases are signed with keys not on the list in the previous tarball,breaking the chain of trust. 5. As an SSL/X.509/SMIME library, you have a strange preference for PGP/GPG keys. 6. The SSL certificate for www.openssl.org is of the lowest trust grade available (domain validated only). Surely you are in a position to get a certificate backed by much more thorough identity checks, given your position in the SSL pecking order. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
RE: OpenSSL Team Keys
Thanks for the detailed feedback! 1. The list of applicable signing keys included in the tarballs and elsewhere only lists the fingerprints We'll fix that. 2. The list seems kind of long, are all these people really authorized to decide which release tarballs are real? Yes any member of the dev team can put out a release. Our goal is that, eventually, everyone be experienced in doing so. There used to be a shared release key, but individual keys provides better identification. (Putting out a release does require another team member to review it, by the way.) 3. The list contains a lot of old MD5 fingerprints and seemingly To be fixed as part of #1 4. Some releases are signed with keys not on the list in the previous tarball, breaking the chain of trust. We had a key-signing ceremony at the recent F2F, so this should be better addressed now. 5. As an SSL/X.509/SMIME library, you have a strange preference for PGP/GPG keys. :) PGP has market dominance for software distributions. 6. The SSL certificate for www.openssl.org is of the lowest trust grade available (domain validated only). That's an interesting idea, and something we'll pursue after a couple of other changes happen. -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.me Twitter: RichSalz
Re: OpenSSL Team Keys
On Tue, Nov 04, 2014 at 02:39:41PM -0500, Salz, Rich wrote: Thanks for the detailed feedback! 1. The list of applicable signing keys included in the tarballs and elsewhere only lists the fingerprints We'll fix that. I don't think their is anything wrong with fingerprints. However I would like to get rid of the v3 keys. And at least several mentioned in the tarball can be removed and/or replaced I think. 4. Some releases are signed with keys not on the list in the previous tarball, breaking the chain of trust. We had a key-signing ceremony at the recent F2F, so this should be better addressed now. I think the point is that he would like to see the fingerprint in a previous tarball and not suddenly someone doing an upload with a key not mentioned in it before. Kurt __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
