PGP Certification Practice Statement
Version 1.5
Abstract
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 People
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 a recently expired ID at my discretion.
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 generally 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 adds little if anything to the security of the web of trust.
Requirements for Keys
I only sign v4 or later PGP keys. I only sign keys using strong algorithms with sufficient key length.
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 matching the official ID document. Missing middle names or i18n differences are acceptable. 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 do not sign picture UIDs, instant messaging UIDs or other exotic UIDs.
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 info@.
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. Domains and e-mail addresses change ownership frequently. Therefore verification of e-mail addresses would only provide a false sense of security. I consider it a design flaw in OpenPGP that e-mail addresses are covered by signatures from other key.
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 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.
Mutual Certification
I expect people who 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.
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.