PGP Key Signing Policy of Patrick Näf Moser

v1.1.0, 14 December 2009

Content

  1. Preamble
  2. Key information
  3. Location
  4. The Protocol
  5. Requirements for acceptable identity documents
  6. Requirements for acceptable UIDs
  7. Levels of signatures
  8. Links
  9. Changelog
  10. Credits
  11. License

Preamble

I am willing to sign PGP keys at keysigning parties and conferences, as well as in informal personal meetings with one or more people, as long as these meetings have been arranged beforehand for the explicit purpose of keysigning. In other words: I do not sign PGP keys in spontaneus or rushed environments.

This document specifies the protocol that has to be followed and the requirements I have for natural persons to get my PGP key signature. I usually do not sign corporate or organizational keys because I have no idea about a proper procedure that would satisfy my need for proof of identity in such a circumstance.

This policy was originally written on 2009-09-02 and will be followed from this date on, but it may be replaced with a new version at any time.

Key information

pub   1024D/3FF38573 2009-08-26
      Key fingerprint = A8B7 3C5A DF93 8EA4 2E3C  ADF0 1319 CD4F 3FF3 8573
uid                  Patrick Näf Moser (dev) <herzbube@herzbube.ch>
uid                  Patrick Näf Moser <patrick@moser-naef.ch>

Please refer to a keyserver if you need to fetch the key. For instance, you could try wwwkeys.pgp.net to get the ASCII armored key, or a verbose index with all the key's details.

Location

I live in Kriens, near Lucerne (Switzerland). The easiest way for signing keys would be to meet me in Kriens or Lucerne, but I can also be persuaded to travel to Zug, Zurich or other reasonably nearby places for a meeting. Just contact me and we will work something out.

The Protocol

Personal meeting

If I am going to sign your PGP key in a personal meeting, then the protocol to follow looks like this:

Before the meeting:

  1. You prepare a piece of paper that lists your PGP key's fingerprint and the UIDs you want me to sign. Preferrably the paper is a print-out of a command such as "gpg --fingerprint 0x12345678" (if you use GnuPG), but I will also accept clear and legible handwriting. Please use at least an A5-sized paper because space for writing notes and our signatures will be necessary.
  2. If you intend to bring identity documents that are not issued by the Swiss government, you must advise me beforehand about the type of documents and the issuing government. I request this because I am familiar with identity documents from Switzerland only, and your notification will give me the opportunity to familiarize myself with how the documents you bring are supposed to look before the meeting. If when we meet you show me a document that I am not familiar with, I will be unable to verify your identity in good conscience, which will make keysigning impossible for me.
  3. If you are willing to cross-sign with me and you point me to your own PGP Key Signing Policy, I will prepare myself for the meeting according to that policy.

At the meeting:

  1. We meet in person under reasonable circumstances (i.e. ourselves not being in a hurry, exchanging key data at a calm place and so on).
  2. You prove your identity to me by showing me at least one acceptable identity document. Further down I have listed my "requirements for acceptable identity documents".
  3. I check the photo in your identity document(s) as well as I can against your appearance.
  4. You give me the piece of paper with your PGP key's fingerprint and the UIDs you want me to sign.
  5. I check the name in your identity document(s) against the name of the UIDs you want me to sign. I refuse to sign UIDs whose name does not match (e.g. pseudonymous UIDs) or are otherwise not acceptable to me. Further down I have listed my "requirements for acceptable UIDs".
  6. I add notes to the paper about the types (not the serial numbers) of identity documents you have shown to me, and where and when (the date) we have met.
  7. Both you and me sign the piece of paper. This prevents fraud and emphasizes the serious nature of keysigning.
  8. I take the piece of paper with me for filing at home. I guarantee to keep the paper filed for at least 5 years.
  9. You tell me where I can download your PGP public key once I get back home (e.g. from a public keyserver, from your website, etc.).
  10. If none of your UIDs includes an email address, you also provide me with an address that I can use to send you the signatures.

After the meeting:

  1. When I get back home, I download your PGP public key from wherever you told me.
  2. I check the fingerprint of the downloaded key against the fingerprint on the piece of paper that I have signed.
  3. I check the UIDs of the downloaded key against those UIDs on the piece of paper that I have marked as acceptable during our meeting. For each UID that matches:
    1. I generate a signature. If the PGP key I am supposed to sign is capable of encryption, the signature will be level 3. Otherwise the signature will be level 2.
    2. If the UID has an email address, I send an email to that address with the signature as an attachment. The email is signed with my own PGP key, and encrypted using the PGP key I am supposed to sign (if that key is capable of encryption).
    3. The purpose of this procedure is that you demonstrate your control over both the UID's email address and the private part of the key that I am supposed to sign.
    4. If the UID has no email address, but there are other UIDs with an email address, I attach the signature to emails sent to those other UIDs.
    5. If none of your UIDs includes an email address, I collect all signatures and send them as a single message to the email address you have previously provided me with.
    6. If I receive a bounce email I send a warning email to the remaining UIDs' email addresses, expecting you to fix the problem and notify me so that I can retry. I will retry at most three times, until either the email could be sent, or you cancel the procedure for the UID (in which case it will receive no signature).
  4. Important note: I will not upload signatures to any keyserver.

Keysigning party (KSP)

During keysigning parties I will allow some deviations from the protocol detailed above. It all depends on how the KSP has been organized.

For efficiency reasons, I will probably not ask signees to sign any paperwork during keysigning parties. I myself will always sign the paperwork that I am going to take home. Obviously, the nature of that paperwork will be determined by how the keysigning party was organized (e.g. list of fingerprints vs. individual paper per fingerprint).

If the KSP organizer does not provide a list with keys of all attendees, and if the signee is unable to provide me with a download location for his or her key, I will look for the key on common keyservers.

If it was not possible for the signee to indicate any specific UIDs that I should sign, I will sign all of them (provided they are acceptable).

Requirements for acceptable identity documents

I accept an identity documents if, and only if

Examples of accepted identity documents are passports, identity cards, or driver's licenses.

Examples of documents that I do not accept are credit cards, public transport passes (e.g. GA) or corporate security cards.

Requirements for acceptable UIDs

I will only sign UIDs carrying a full name as shown on the identity document offered for proof of identity. I accept UIDs with middle name(s) abbreviated or missing. I also accept UIDs with differences due to i18n issues (e.g. non-English characters encoded or replaced with some language-dependent ASCII equivalents, such as "oe" for "ö"). I might accept other differences in name if the signee can come up with a satisfying explanation for the difference (e.g. marriage), but I definitely do not accept UIDs that are pseudonymous.

I do not require an email address in the UID, but if an email address is supplied I will only sign the UID if it appears to be the a valid Internet/SMTP email address.

I will sign photographic UIDs if I can still remember the signee's face when I am back at home.

Levels of signatures

I use the following levels of signatures:

Level 3
A level of 3 is given to UIDs if their key is capable of encryption: I have met the signee, I have verified his or her identity and key fingerprint, and the signee has demonstrated sufficient control over both the UID's email address (if there is one) and the private part of the key I have signed. These signatures are the strongest in my web of trust.
Level 2
A level of 2 is given to UIDs if their key is not capable of encryption. Everything is the same as with level-3 signatures, except that the signee was not able to demonstrate sufficient control over the private part of the key I have signed.
Level 1
A level of 1 will never be used by me for it weakens the web of trust in my opinion. I have never signed keys without appropriate verification and I will probably never do so in the future.
Level 0
A level of 0 is given only in exceptional circumstances to keys where the key owner is a whole organization and not a single person (e.g. a Certification Authority). Usually the fingerprints of those keys have to be verified by getting them from the organization's website and cannot be checked by exchange with a member of the organization who is in charge. These signatures are the weakest in my web of trust, and I usually do not sign organizational keys at all.

Links

Here are some links which you may find useful or interesting:

Key signing policies of other people:
Marc Mutz
Daniel Röthlisberger
Marcus Frings
Jörgen Cederlöf
V. Alex Brennen
Background information
A non-personalized protocol for PGP key signing
PGP Key Signing Observations - Overlooked Social and Technical Considerations

Changelog

Version 1.1.0, 2009-12-14:
No longer use a challenge/response protocol.
Version 1.0.2, 2009-12-14:
Revoked willingness to sign corporate or organizational keys.
Version 1.0.1, 2009-11-23:
Fixed my last name (I sometimes forget that I am married :-O and that I am supposed to use my combined name [Näf Moser] instead of my "maiden" name [Näf]).
Version 1.0.0, 2009-09-02:
Initial Release.

Credits

This document was inspired mainly by a non-personalized protocol for PGP key signing, and the PGP Key Signing Policies of various people (Marc Mutz, Daniel Röthlisberger and Marcus Frings).

License

Copyright (c) 2009 Patrick Näf Moser.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation.