PGP Certification Practice Statement
This document describes the certification practice of Daniel Roethlisberger and specifies requirements for certification. The term “certification” is used as a synonym for verifying an individual’s identity and signing the respective public PGP key, also commonly referred to as “key signing”.
As a rule of thumb, I try to maintain a high level of security while keeping paranoia at an acceptable level.
Requirements for Persons
I only certify individuals from countries with a stable government able to issue trustable ID documents. Meeting an individual in person, face to face, is strictly required for certification, but can be made more agreeable by choosing a nice place with an appropriate supply of beverages.
Proof of Identity
Individuals to be certified have to identify themselves with at least one fairly recent, government issued ID document with photograph (i.e. passport, ID card or drivers license, in that order of preference). I only accept a drivers license if it is of at least the same security quality as an ID card. I also accept an expired ID if it has expired not over ten years in the past and it is still possible to clearly identify the person on the photograph.
Proof of Key Authenticity
Individuals must confirm their key fingerprint at the personal meeting using an accepted method such as exchange of printed fingerprints or manually comparing fingerprints. E-mail or other digital communication is not an acceptable means of proofing a key’s authenticity.
I do not require individuals to proof that they are in possession of the private key beyond their reciprocal signature on my keys, since such a proof is cumbersome and adds little if anything to the security of the web of trust.
Requirements for Keys
I only sign v4 or later PGP keys because of the chosen key ID vulnerability in earlier versions. I only sign keys using strong algorithms with sufficient key length. At the time of writing, sufficient key length for this purpose is 1024 bits for non-elliptic-curves algorithms such as RSA, DSA, DH and ElGamal.
I do make exceptions to the above rules for well-known keys which have been around for many years.
Keys to be signed are required to have a valid self-signature. I sign keys no matter whether the self-signature has an expiry date set or not, but the self-signature must not have expired yet. In no case will my signature carry an expiry date.
I only sign UIDs which conform to the requirements for UIDs below.
Requirements for UIDs
I will only sign UIDs carrying a full name as shown on the official ID document. I accept UIDs with middle name(s) missing. I also accept UIDs with i18n differences (non-English characters encoded or replaced with some language-dependent ASCII equivalents, such as “oe” for “ö”). I do not sign picture UIDs. I do not require an e-mail address in the UID, but if an e-mail address is supplied, it must conform to the requirements for e-mail addresses below. I only sign instant messaging UIDs for XMPP/Jabber.
I reserve the right to only sign a subset of eligible UIDs on
keys with an excessive amount of UIDs, with a clear preference
for personal e-mail addresses to unpersonal ones such as
Requirements for E-Mail Addresses
I do not verify that the owner of the key can receive e-mail and that the e-mail address actually belongs to the owner of the key. I consider e-mail to be inherently insecure and e-mail addresses to change owner frequently, therefore verification of e-mail addresses would only provide a false sense of security where there is none.
I will not sign UIDs with syntactically bogus e-mail addresses. I will not sign UIDs with e-mail addresses carrying a person’s name obviously different from the name of the individual to be certified. I will not sign UIDs with X.400, LDAP/X.500/AD, FidoNet or other non-Internet/SMTP e-mail addresses.
I expect persons which have their key certified by me to also sign my keys within a reasonable timeframe. I reserve the right to revoke my signatures on keys of individuals which do not sign my keys in return.
Re-Certification, Key Replacement
I do not automatically re-certify new keys replacing old keys previously certified by me. I re-certify new keys only by face-to-face request. I do not re-certify new keys based on an e-mail message.
Transmission of Signature and Signed Key
I send signed keys containing my signatures to one of the certified individual’s e-mail addresses. I will also upload my signature (and consequently, the signed key) to a public key server. Furthermore, I might include certified individuals and their keys in key signing analysis documents such as trust relationship graphs or matrices.
Individuals wishing to opt out of such use of their already publicly available data may request so by e-mail.
Revisions of this Document
I reserve the right to change this document at any point in time by publishing a later release here. I will not notify anybody actively about the change. This document replaces the previous version and is valid beginning at the time and date of the last revision.