OpenPGP Key Signing Policy for Matthew Wakeling

This web page describes the OpenPGP key signing policy for the following OpenPGP key:

ID	Name	Fingerprint	Signature
409AC31C	Matthew Wakeling (Home address)	AF2B 176C CF52 CC74 8F46 02BC F786 A9F1 409A C31C	signature

This web page is signed by the key mentioned above with a detached signature, linked above. To verify the signature on this document, download this page and the signature, and run (assuming you are using GnuPG):
gpg --verify <signature file> <html file>
This document should only be trusted as the key signing policy of the above key if there exists a valid signature for this document produced by the key in question.

Comments on keys I have already signed

To view comments on OpenPGP keys that I have already signed, look in this directory.

Requirements of proof for key signing

I require that two things are proven to me in order for me to sign a key:

The person named in the key has certified that they generated and own the key, rather than someone else.
Mail sent to email addresses mentioned in the key reach someone capable of using the key.

If a key has multiple uids, then these proofs must be obtained for each of the non-revoked uids in the key, or a very good explanation provided as to why this is not the case. In any case, I will never sign a uid that does not have these proofs provided.

Proof of identity

To satisfy the first requirement of proof, the person named in the key must meet me in person, and provide sufficient proof that they are that person. Sufficient proof requires one item from each of the following two lists. The first list comprises of supposedly "strong" proofs of identity.

Official photographic id
- Passport
- Driving license
- Well-known reputable photographic id (eg. Access card used where I work)
Personal recognition, based on an extended period of time (read: years) during which such person continuously acts as the person named and nobody claims otherwise. (Translation: I have known them for a while and recognise them)

The second list comprises of sanity checks, to back up the "strong" proofs of identity.

Personal recognition based on a reasonable certainty that the person is who they say they are, has been acting as such for a reasonable amount of time, without contradiction
Recognition by a well-known reasonably-trusted third party, where that third party performed some checking of their own.
- Person has a key to a room marked by the trusted official owner of the room as belonging to the person.
- Person is employed by a reputable company as the person named.
Named Credit/debit card.
Unopened mail addressed to the named person and marked as delivered by the post office.

The purpose of the sanity check is to extend the amount of effort required to fool the system to silly amounts.

Identifying the key to be signed

To satisfy the first requirement of proof, the person named in the key must certify to me in person that they generated and now own the key in question. They must identify the key by its full fingerprint, which they must provide. It is not sufficient for them to glance their eyes over a copy of the fingerprint that I brought along and say "that's fine". In fact, I will usually not bring a copy of their key's fingerprint to the meeting. I highly recommend bringing pieces of paper (or business cards) with your own key fingerprint to hand out to people at a meeting.

Proof of ownership of email addresses

To satisfy the second requirement of proof, I will send an email to each of the email addresses of uids that I am to sign, encrypted to the key that I am to sign. In the encrypted email, I will quote some fairly unguessable text (suggestions have been made to make use of RFC 1760, but that is not a requirement). I will expect the owner of the key to quote back to me that text, to prove that the email reached someone capable of using the key.

In the case of a signing-only key, I will send some random text in the clear to each of the email addresses, and expect the text to be sent back as part of a message that makes clear that the text is included in the message for the purpose of verifying the email address. The message MUST be signed by the key in question.

None of the random/unguessable text I use in this procedure will be of a form that one could object to signing, but even so, it is recommended that if you choose to sign text that someone else has provided, you specify that as part of the signed message.

Signature trust levels

If all the procedures above are followed fully, then I will sign the key with a trust level of 3.

However, sometimes it may not be possible to follow the procedure completely properly. This may happen for example at a keysigning party, where I may not be able to inspect all the identification I wish to. In these circumstances, I will sign keys with a trust level of 2. I will not sign keys without a reasonable level of checking - if it isn't good enough for level 2, it will not happen.

What I do not certify

By signing a key, I certify certain things about it. Most of this document deals with this. However, it is worth listing some of the things that I do not certify about any key that I sign. This list is not exhaustive.

I do not certify that the email addresses listed in the key go directly to the person named, rather than going to someone who "passes on" the message. There is nothing in my checking that verifies this. Emails sent to the email addresses should only be deemed secure if the message is encrypted for the key specified.
I do not certify that the email addresses will always reach the person in control of the key. I do not even certify that the owner of the key will revoke uids that they can no longer access.
I do not certify anything about the character or trustworthiness of the owner of the key.
I do not certify anything about the security measures the owner of the key uses to protect the key from compromise. I do not even ask if the owner of the key has prepared a revocation certificate stored in a safe place.
I do not certify anything about how well the owner of the key will check other keys before signing them, although I may comment about it.

Most of these points are because I will only certify facts that can be verified by myself. I do not certify anything that I would have to merely trust someone about.

Signing keys

I will expect all the keys that I sign to be present in the main PGP keyservers. If there is a really good reason why not, then I may accept a key that is emailed to me in ASCII-armoured format to sign.

To sign an OpenPGP key, first import it into your main public keyring, by running a command like:
gpg --recv-keys <key id>
You may need to set up your GnuPG configuration to access a keyserver. Then, enter the interactive shell, by running something like:
gpg --edit-key <key id>
In this shell, typing "help" will give you a list of the commands you can run. Use the "uid" command to select the uids that you wish to sign, and then use the "sign" command to sign the key. Finally, to save your changes and exit, use the "save" command.

When I sign keys, I will send updated versions of the key to the keyservers unless you tell me not to. I will also send you a copy of the ASCII-armoured representation of the newly-signed key.

To produce such an ASCII-armoured text representation, use a command like:
gpg --armor --export <key id>

To send an updated key to the keyservers, use a command like:
gpg --send-keys <key id>