OpenPGP Key Signing Policy

This document about my OpenPGP key signing policy is intended to help you decide whether you want to trust my signatures on other people's keys.

Key Used for Signatures

When I sign another person's key, I use my Master Key as described in my OpenPGP Key Policy.

Terminology

The owner of a key who wishes to obtain a signature from me is called the "signee" in this document. I am the "signer".

Signature Notes

For all keys I have signed since 2026, I document where I met the signee and how I verified their identity. These notes are privately kept, but I might publish them if needed.

The (private) documentation also contains explanations if I have deviated from my own policy while signing a key. This might, for example, happen if I signed a key at a public key signing event where following my policy to the letter would have disturbed the event.

Prerequisites for Signing

Proof of Identity

The signee must prove their identity to me using a valid identity card or passport. These documents must contain a photograph of the signee. No other types of documents will be accepted.

Please note that I require proof of identity even for people whom I know personally. This verification step is called "proof of identity".

For people whose identity documents originate from countries outside Central Europe, I may, at my discretion, request a second official photo ID, such as a driver's license, because I may not be sufficiently familiar with the documents and associated fraud risks. I can decide to make an exception and will document if I made an exception.

Hardcopy Fingerprint

The signee should prepare a hardcopy of their "OpenPGP Slip", as is common when obtaining key signatures. The slip should contain:

• the UID(s) they want signed,
• the full key fingerprint,
• the type and length of the key,
• a reachable email address without an overzealous spam filter,
• information about where to obtain the full public key on the Internet,
• their real name.

A handwritten piece of paper containing this information will also be accepted.

I may take a picture of the information using my mobile phone or camera instead of keeping the physical paper slip.

Storage of the Secret Key

I might ask the signee how their secret key is protected. I appreciate people publishing their key policy on the World Wide Web, like I do, but I also accept an explanation of how the key is protected.

Please note that I will might publish my notes, including a short description of the protection scheme, at a later time.

How to Hand Over Proof of Identity and Fingerprint

The procedure must take place under reasonable circumstances: neither of us should be in a hurry, and key data should be exchanged in a calm environment.

I reserve the right to refuse signing under inappropriate, hectic, or chaotic circumstances.

caff

I will use a procedure similar to the one implemented by the caff(1) program. After verifying the signee's identity and fingerprint, I will create signatures for each email UID on the key individually, encrypt those signatures to the key being signed, and send them to the corresponding email address.

By being able to receive the message, the signee demonstrates control over the mailbox associated with the UID. By being able to decrypt the message, the signee demonstrates control over the corresponding private key.

This additional exchange does not replace the identity verification described above; it only verifies control of the email address and the private key.

Signatures for UIDs that do not have an associated email address will be sent together with the signature for the first email UID or redundantly for all email UIDs.

I still need to decide how to handle keys that cannot encrypt, do not have an encryption subkey, and/or are not associated with an email address.

Some technical terms and common knowledge that needs explit mentioning

I find the terminology introduced by the Sequoia PGP Project easily understandable, albeit it using some of the definitions differ from what GnuPG users and readers of the OpenPGP standards might be used to. I am therefore trying to stick with the Sequoia kind of naming things. I do, however, continue to call the Certification of a key signing or more exactly putting my signature on a key since that's what literally everybody says.

I generally say that technicaly, each UID belongs to a key. In sequoia, this relationship between UID and key is explicitly made locally by the sq pki link add command. Optioinally, in this step, an --amount of trust is added to the link which can range from Zero (unauthenticated) to 120 (fully auhenticated).

There is also a key certification --depth that expresses who many levels of indirect certifications my system will honor to add trust to a signature.

Trust Amount and Depth

When I certify a key, I primarily certify that I vouch for the fact that a person who has presented identification has claimed that the key with the given fingerprint belongs to them. In addition, I certify that this person has claimed to use the UIDs associated with the key fingerprint. The caff process used by my does some degree of technical verification of the claims, see the caff chapter in this policy for more explanation.

At this moment in time, I do not have a clear opinion about whether to use the --depth option. I will therefore use the default depth of 255 in my internal links.

If a user says that they keep their primary key offline at all times, I add a bonus to my trust amount, when they keep their primary key in a HSM, I add another bonus. Be aware that I have to believe the people what they say, I have no power to actually verify that.

How to Meet Me

I live in Leimen, Baden-Württemberg, Germany, Europe. I am available for key signing at reasonable times.

The easiest way to verify keys is to meet me in Leimen after contacting me via email: mh+gpg-keysigning2026@zugschlus.de.

I rarely leave my incoming mailbox unattended for longer than a day, so this is a suitable communication method.

I am also a frequent visitor of Debian, Networking, and Open Source Meetups and Conferences, so if you visit one of those and want to meet me there, get in touch wiht me in due time and this may be a reason to come to that place for a first time.

Spam

Spam is a significant problem. I am quite sure that this web page will sooner or later be harvested by spam robots.

To combat this problem, all email addresses mentioned on this web page are heavily filtered using MTA policies. Please try to make your messages look like legitimate correspondence when using these addresses. Feel free to reach out to me via other methods of contact if I don't reply to your e-mail in due time.

Credits

Creating this document required building knowledge about the Web of Trust, which itself is very much based on mutual trust. It is therefore important to understand the unwritten regulations and etiquette rules.

Many de.comp.security.misc regulars, including Carsten Eilers, Florian Weimer, and Markus Schaaf, helped me build that knowledge since 2002. I also appreciate all the documentation I had to read to keep my knowledge current during the 24 years it took for this document to finally be put into use.

This document was strongly inspired by Bastian Blank, Hanno Wagner, Bjoern Buerger and Marcus Frings. Thank you very much!

Revision History

A new revision of this policy may replace this one at any time.