KEY-SIGNING POLICY

  1. I will sign User IDs only if I can verify the whole User ID string.
  2. If the UID contains an e-mail then an encrypted certification will be sent to the e-mail address in this UID. This proves that you control both the private key and have access to the e-mail.
  3. All parts of name in the UID must be present in the identification document (e.g. a passport).
  4. I will not certify UIDs containing comments as comments are often redundant and it is not clear how to verify them. There is one exception to this rule: if we are mutually signing keys and your key contains only UIDs with comments I will sign one of these with sig1 (persona) certification.
  5. I will not certify User Attributes, that includes photos.

NEW UIDS

If you add a new UID to a key that I have already signed I can sign it too (using the rules above) upon e-mail request.

If you had comments in all your UIDs and I issued only a sig1 certification you can add a new UID without a comment and ask me for a generic certification (sig).

TRUST LEVELS

I use generic certifications (sig) almost exclusively. The only exception is described in point 4 above.

The rationale behind using only generic certifications is described in gpg --ask-cert-level considered harmful.

CHANGES

This document will change only in backwards-compatible way.

[2018-01-30]
Initial version.