-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter S. May Cryptographic Key Policy This is my current policy for dealing with cryptographic keys as of 2006 Oct 12. Location Public key data and cross-signatures should be available from . PGP key signatures Except for the specific exceptions listed in the next section, you may expect me to have followed this policy for all keys I have signed. My current PGP key signing policy is to meet in person and check at least one photo ID against the bearer and the name on the UID before signing. As such, a user requesting a key signature from me must have on hand at least one but preferably two or more photo IDs (a driver's license *and* passport would be preferred) and a hard copy of his PGP key fingerprints and the attached UIDs. I would prefer that anyone who requests my signature on his key sign mine in return. Unless the circumstance is an event where key signings are an obvious part of the agenda, please give me advance notice so that I can have the appropriate materials on hand. In general it is considered poor etiquette to upload keys you sign (or any keys you do not own) to public key servers without the owner's permission. I will state here that if I've requested a signature from you, unless I have instructed you otherwise, you have my permission to upload the signed public key to a keyserver of your choice *as long as* you also send a copy of the signed key directly to me. I shall not make the same assumption without your permission, and, unless instructed to do otherwise, I will send your signed key back to you, encrypted by your public key. Specific exceptions Unfortunately, I started signing keys about a day before I understood the exact implications of signing a key. I tried to revoke the signatures I made, but apparently the software I was using to sign these keys set them to unrevocable. The most secure thing to do would be to revoke my own key pair and start anew, but that would make things difficult. Instead, I've listed below the keys I was unable to revoke, and how I arrived at them. From that, you may decide whether or not to trust my key as an introducer. I believe, despite my ignorance in deciding to sign them, that they are fairly safe bets. I plan to allow my keys to expire on their current expiration date of 2011 July 24, at which point these exceptions should no longer apply. I don't presently intend to sign any other keys with my personal signing key based on such minimal verification; however, I may at some point allocate a separate key for these. US-CERT pub 4096R/D01508CC 2003-09-16 [expires: 2008-09-14] Key fingerprint = CF03 0DC0 2D86 FA86 D4F6 7D6D 9265 B029 D015 08CC uid US-CERT Master Key-signing Key (signing only) I actually verified this key about as much as humanly possible; I called their call center by telephone to check the fingerprint. Patrick Brunschwig (author of Enigmail) pub 1024D/9369CDF3 2004-01-23 Key fingerprint = 10B2 E4A0 E718 BB1B 2791 DAC4 F040 E41B 9369 CDF3 uid Patrick Brunschwig (Enigmail sig) Patrick Brunschwig is the author and signer of Enigmail, the Mozilla and Thunderbird extension for GnuPG. This is the key listed on its website, . I Googled the name, found the same fingerprint several other places, and spotted no news posts to the effect that the key had been compromised. Werner Koch (author of GNU Privacy Guard) pub 1024R/1CE0C630 2006-01-01 [expires: 2008-12-31] Key fingerprint = 7B96 D396 E647 1601 754B E4DB 53B6 20D0 1CE0 C630 uid Werner Koch (dist sig) Werner Koch is the author and signer of the GNU Privacy Guard, the GNU implementation of OpenPGP (among other security protocols). This is the key listed on its website at . I Googled the name, found the same fingerprint several other places, and spotted no news posts to the effect that the key had been compromised. Cross-verification of PGP public keys and X.509 certificates GNU Privacy Guard, an implementation of OpenPGP, is my preferred mode of cryptographic communication, and for all practical purposes you may consider my PGP key my canonical key. However, in certain applications where X.509 certificates are required, including S/MIME and SSL/TLS, I may have one or more X.509 certificates. I am not limited to a single certificate authority, but at this point I have only had keys which were either self-signed or certified by Thawte () or CAcert (). Until further notice, treat certificates from other authorities but bearing my name as suspect. What these cross-signatures confirm The fact that my PGP key has signed my X.509 certificate or vice versa does not inherently imply that they're both from the same owner. Instead, my PGP signature on an X.509 certificate is an affirmation by me that the certificate is indeed controlled by the person whose name and address is on it; in this case, it would just happen to be my own name and address. Similarly, my S/MIME signature on a PGP public key is an affirmation that the UIDs attached to that key are legitimate; in this case, said UIDs would bear my own name and address. The importance of this distinction is that I may choose to use signatures to affirm the X.509 certificates or PGP keys of others. Provided that the following specifications have been adhered to, my valid signature on another's keys or certificates may be considered legitimate. Signing X.509 certificates with PGP keys When I sign X.509 certificates with my PGP key, it is my policy to only sign the DER form of the certificate itself; that is, the file that results from the command openssl pkcs12 -clcerts -nokeys -in cert.p12 | \ openssl x509 -outform DER -out cert.der The reasoning for this is twofold: One, the DER form is a canonical binary representation of the certificate. The PEM form, which is simply the DER form rendered into ASCII armor, is far too flexible to be properly used as signable material. Two, the MD5 and SHA-1 digests of the DER form match the certificate fingerprints displayed by your browser when the certificate is displayed, which can help you to verify that what you see in the browser is the same thing I have signed. Signing PGP keys with X.509 certificates While a certificate from a CA is no real basis for trust in a PGP key, it may serve as a reasonable substitute when no other options are available. As with the X.509 certificates, I will not sign any ASCII-armored form of my public key. In general, what will be signed is the file that results from the command # Admittedly some of these options may be redundant gpg --output publickey.pub --export MYKEYID \ --export-options no-export-local-sigs export-attributes \ no-export-sensitive-revkeys export-clean-uids \ export-clean-sigs no-export-reset-subkey-passwd \ export-minimal where *MYKEYID* is replaced with my key ID, currently 7885DAFC. The signature itself will be a detached S/MIME signature (in PEM format, which in this case is not subject to tampering problems). Verifying it would be a matter of acquiring the separate files for the public key and the signature, and running the command openssl smime -verify -inform PEM \ -in smimesig.pem -content publickey.pub -out /dev/null Of course, I realize that not all S/MIME users run OpenSSL, so if necessary I may send a signed copy of the same file by e-mail, upon request. A discussion of the CA-based pseudo web of trust Thawte and CAcert both employ a system they refer to as "Web of Trust", but their version is a variant that removes the most distinctive feature: Flexibility in level of trust. Technically speaking, a web of trust system may be used voluntarily as a certificate authority based system, but it doesn't work in reverse; the web of trust system is strictly a superset of the CA system's functionality. This specialized "web of trust" is a system for allowing the CA to utilize volunteers to verify the identities of users, but in the end anyone installing their root certificates has to trust their decisions unilaterally, no matter which volunteer did the checking. I agree with the motivations of CAcert.org insofar as I believe that certificates vetted by interested volunteers are no less trustworthy than (some of) the CAs pre-installed in the typical web browser. I also believe that it's far more likely that CAcert will eventually be smiled upon by the big browsers than it is for my self-signature to be accepted without question. I enrolled with Thawte's equivalent program precisely because its certificates *are* already installed most places; unfortunately, Thawte's free certificates only apply to e-mail. However, while pre-installation of root certificates is a convenient thing, it seems probable that it's also one of the factors that leaves the general public in the dark about how much security they are actually getting out of all this. Author PGP: pub 1024D/7885DAFC 2006-07-25 [expires: 2011-07-24] Key fingerprint = A0E6 3851 9ABB 112E 7303 DD91 7A2E 91FB 7885 DAFC uid Peter S. May uid Peter S. May Notice Do not accept this document without a valid cryptographic signature from the author! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkolfvkACgkQei6R+3iF2vyQFwCfdU8NOKnzvHOlltjnn2CjTRa9 E58AnivZeK392TvECU5wwsnPDUOrN3B1 =pnck -----END PGP SIGNATURE-----