OpenPGP Key Signing Policy for Andrew Broekman

This policy is signed using GPG. To verify its authenticity, run the following commands:

$ gpg --recv-keys 0x218411E7135D12A9
$ gpg curl | gpg --verify -


EFFECTIVE DATE : 16 December 2017


  1. Definitions
  2. Abstract
  3. OpenPGP Keys
  4. Key Signing Protocol
  5. Cross Signing Policy
  6. Challenge–response Authentication Procedure
  7. Requirements
  8. Signature Types and Requirements
  9. Changelog
  10. Credits
  11. License

0. Definitions

EFFECTIVE DATE This is the policy used for all signatures made on or after the date in question.

JURISTIC PERSON A group of people, such as companies, Certificate Authorities, Non-Profit Organisations, etc.

NATURAL PERSON A real individual human being.

OPENPGP The OpenPGP standard as defined by the Internet Engineering Task Force (IETF) proposed standard RFC4880, RFC5581 and RFC6637.

SIGNATURE TYPE As defined in RFC4880 Section 5.2.1.

SIGNEE The key holder who wishes to obtain a signature from the signer.

SIGNEE KEYS OpenPGP keys and associated UIDs of the signee.

SIGNER Andrew Broekman

UID An OpenPGP User IDentity (UID) of the following format: “ ”.

1. Abstract

I am willing to sign OpenPGP keys, at keysigning parties, conferences and informal meetings arranged for the explicit purpose of keysigning, i.e. I will not sign keys on spontaneous requests or under a stressful environment.

This framework outlines my keysigning policy as well as the procedure and requirements which must be followed to obtain my OpenPGP signature.

I reserve the right to change this document at any point in time, by publishing a later revision here. Please note that I will not actively notify anybody.

GUIDING PRINCIPLE: Maintain a high-level of security and trust while keeping paranoia at an acceptable level.

2. OpenPGP Keys

This OpenPGP Key Signing Framework applies from the effective date stated above for all signatures made by the OpenPGP/GnuPG key

pub   rsa4096/0x218411E7135D12A9 2017-12-16 [C]
      Key fingerprint = 1FD3 7495 969C CDAE 9122  CFB2 2184 11E7 135D 12A9
uid                   [ultimate] Andrew Broekman <>
sub   rsa4096/0x75098FF6B743AE5D 2017-12-16 [S] [expires: 2018-12-16]
      Key fingerprint = 6DC9 D918 2BB4 9EFF F8C9  F288 7509 8FF6 B743 AE5D
sub   rsa4096/0xD262C64CB5B1D325 2017-12-16 [E] [expires: 2018-12-16]
      Key fingerprint = B9A0 3D42 BC96 A214 E7E7  484C D262 C64C B5B1 D325
sub   rsa4096/0xE8F465765A62E931 2017-12-16 [A] [expires: 2018-12-16]
      Key fingerprint = 2B27 A6DC FFEB E173 0E21  9B44 E8F4 6576 5A62 E931

3. Key Signing Protocol

3.1 Natural Person

3.1.1 Before the Meeting
  1. The signee prepares a printed note that lists the relevant fingerprints and UIDs by using a command such as “gpg –fingerprint 0x12345678” where 0x12345678 is the key ID of the key to be signed. The signee can also prepare a handwritten note given that the handwriting is clear and legible.
  2. If the signee wishes to obtain my signature on a photographic ID, then the printout should also contain the image of the photographic ID. I will also accept a printout or copy of a photograph clearly showing and match the signee.
  3. Please use at least an A5 piece of paper to prepare the note on.
3.1.2 At the Meeting
  1. We meet in person under reasonable circumstances.
  2. The signee proves their identity to the signer by presenting at least one acceptable identity document as found in the section 6.1 titled “Requirements for Acceptable Identity Documents”.
  3. If applicable, I will also verify that the printout/copy of the photograph presented to me, matches the signee in question.
  4. I add notes about the types of identification used, not the serial numbers, as well as the date, time and place where verification took place.
  5. Both parties sign the prepared note.
  6. The note will be filled for a minimum period of 5 years.
  7. The signee informs me where to obtain their public key as well as providing me with an email address that I can use to send the signatures in encrypted format.
  8. The process to verify the signers identity using the keysigning policy of the signee is then initiated.
3.1.3 After the Meeting
  1. I download the public key of the signee and verify the fingerprint of the downloaded key with the fingerprint obtained in the meeting.
  2. I check the UIDs and for each UID that matches I initiate the challange-repsonse authentication procedure as outlined in section 5 titled “Challenge–response Authentication Procedure”.
  3. I also check that the photographic ID matches the images presented at the meeting.
  4. Important note: I will not upload signatures to any keyserver.
3.1.4 Delivery of Signatures

Signatures will be encrypted with an associated encryption key of the signee keys and delivered in the following manner:

  1. Any non-UIDs will be sent along with all emails.
  2. If no email UIDs are to be signed or exist, then an alternate email address will be used.
  3. If I receive a bounce message from a associated email UID, I will send the signee a warning email to all associated UIDs expecting. the signee to rectify the associated problem, and responding as soon as the problem is fixed.
  4. I will try a maximum of three times to send the signatures, either until no bounce message is received or the keysigning process is cancelled by the signee.

3.2 Juristic Person

I regret to inform the internet community, that I currently don’t sign juristic persons’ OpenPGP keys, as I am not aware of a proper procedure which can be used to proof identity.

3.3 Keysigning Party (KSP)

During keysigning parties I will allow the following deviations from the above protocol:

  • Signee’s are not expected to sign any paperwork, however I will still be signing any paperwork which must return home, in order to reduce the risk of fraud.
  • If the KSP organizer doesn’t provide a list with keys for all attendees, and if the signee is unable to provide a download location for their respective keys, I will try to locate the keys to the best of my ability, with no guarantees.
  • If no specific UIDs where given to be signed, I will sign all UIDs which satisfies the “Requirements for Acceptable UIDs” as outlined in section 6.2.

4. Cross Signing Policy

I expect that the signee will sign my OpenPGP keys according to their key signing policy, and hence I request that the signee will send me their keysigning policy details well in advance to allow me to prepare.

5. Challenge–response Authentication Procedure

Note that I use the following challange-response procedure:

  1. Generate approximately 256 bytes of random data:
    dd if=/dev/random bs=1 count=256 | hexdump
  2. Keep randomly generated hexdump data on file, send an encrypted and signed plain text email using the key in question.
  3. Signee sends back signed copy of encrypted data.
  4. If the signed data matches the local copy kept on file of the generated random data then authentication succeeds.

Note that the above procedure is used to test that the signee is in control of the UIDs in question, and controls the private key.

6. Requirements

6.1 Requirements for Acceptable Identity Documents

An identity document is considered acceptable if:

  1. It contains a photo of the signee.
  2. It is valid at the date of the keysigning party, conferences or informal meeting.
  3. It is issued by an official government.
6.1.1 Examples of Identity Documents Acceptable Documentation
  • National identity cards
  • Passport
  • Driver’s License Non-acceptable Documentation
  • Credit cards
  • Debit cards
  • Student/Union/Club/Society/Social cards
  • Corporate security cards

6.2 Requirements for Acceptable UIDs

  1. I will only sign UIDs carrying a full name as shown on the identity document offered for proof of identity.
  2. I will accept UIDs with abbreviated or missing middle names.
  3. I will also accept UIDs with differences due to i18n issues.
  4. I will not accept UIDs that are pseudonymous.
  5. I don’t require and email address in the UID , but if an email address is supplied, I will only sign the UID if it appears to be a valid Internet/SMTP email address.
  6. I will only sign photographic UIDs if the key signing protocol for natural persons in section 3.1 have been followed.
  7. If a situation arises which is not covered by the above statements then CACert Practice on Names ( will be used to make a decision.

6.3 Requirements for Keys

  1. OpenPGP key is a version 4 or later key.
  2. Key length for non-elliptic-curves algorithms such as RSA, DSA, DH and ElGamal are at least 1024 bits.
  3. Key length for elliptic curve algorithms such as ECDSA and ECDH are at least 160 bits.
  4. Keys have a valid self-signature.
  5. The key or self-signature should not have expired at the time of signing.

7. Signature Types and Requirements

7.1 Definition

RFC4880 “OpenPGP Message Format” defines the following signature types in Section 5.2.1: 0x10: Generic certification of a User ID and Public-Key packet. The issuer of this certification does not make any particular assertion as to how well the certifier has checked that the owner of the key is in fact the person described by the User ID. 0x11: Persona certification of a User ID and Public-Key packet. The issuer of this certification has not done any verification of the claim that the owner of this key is the User ID specified. 0x12: Casual certification of a User ID and Public-Key packet. The issuer of this certification has done some casual verification of the claim of identity. 0x13: Positive certification of a User ID and Public-Key packet. The issuer of this certification has done substantial verification of the claim of identity.

7.2 Interpretation and Implementation

7.2.1 0x10 (Level 0): Currently not used

May be used in future to sign keys of Certificates Authorities and/or juristic persons, i.e. companies, NPO, etc.

7.2.2 0x11 (Level 1): Currently not used

In my opinion, this level of security weakens the whole web of trust model and hence will not be used by me to sign any OpenPGP keys.

7.2.3 0x12 (Level 2):Sign-only Keys

In order to obtain a level 2 signature, the signee had to satisfy the following criteria:

  1. Personal meeting with the signer.
  2. Presented at least one acceptable identity document as outlined in section 6.1 “Requirements for acceptable identity documents”.
  3. Followed the Key Signing Protocol as outlined in Section 3.1.
7.2.4 0x13 (Level 3):Sign-and-encrypt Keys

In order to obtain a level 3 signature, the signee had to satisfy the following criteria:

  1. Satisfied Level 2 requirements.
  2. Challange-Response Authentication was successfully completed for the specific UID in question.

8. Changelog

Version 1.0 - 16 December 2017 Initial Release.

9. Credits

This document was inspired mainly by a HantsLUG Wiki Keysigning page, and the PGP Key Signing Policies of various people (Marc Haber, Patrick Näf Mosera and Daniel Roethlisberger).

10. License

Copyright (c) 2017 Andrew Broekman.

This work is licensed under a Creative Commons Attribution 4.0 International License.

Key Signing Policy for Andrew Broekman Version 2017-12-10


This policy is valid for all signature made by the following GnuPG keys

which can be downloaded from or from the SKS Keyserver pool network.

Any future version of this policy will supersede this one (the signatures that were already made before the update will, of course, continue to be governed by the versions in effect at the time they were made).


I live in Pretoria, South Africa and am open to sign keys at any time. The easiest way for verifying keys would be to write me an e-mail and arrange a meeting in the area around Pretoria or Johannesburg.

Signature Levels

Here are the levels of trust that I can give to my signatures:

sig (0x10 - Generic Certification)

A level of 0 is given to keys of Certification Authorities since in most cases the key owner is a whole organization and not a single person. Usually the fingerprints of those keys have to be verified by getting them from the corresponding website of the CA and cannot be checked by exchange with a member of the CA who is in charge. These signatures are the weakest in my web of trust.

sig1 (0x11 - Persona Certification)

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 never do so in the future.

sig2 (0x12 - Casual Certification)

A level of 2 is given to sign-only keys. It is not clear to determine if the owner of the mail account is the same as the key owner because encryption cannot be used, hence the signatures only receive a lower level of 2.

sig3 (0x13 - Positive Certification)

A level of 3 is given to sign-and-encrypt keys: I have met the signee, I have verified his/her identity card and fingerprint and I was able to send my signatures encrypted with the corresponding key of the signee. These signatures are the strongest in my web of trust. Photographic UIDs are also going to be signed with a level of 3 if I can still remember the signee’s face when I will be back at home.


Whenever possible, the meeting should take place in a quiet public setting and there should be enough time (at least 10/15 minutes) to allow the procedure to be completed without any rush.

When meeting (either at a keysigning party or one on one), you will need to bring:

  • the output of gpg --fingerprint 0x12345678
  • if the key to be cetified includes photo UIDs and I do not know you personally, a printout of the photo
  • at least two government-issued photo ID’s

At the meeting I will: * check the details and security features of your documents; * check that the photo on your documents matches your appearance (note that the photo UID embedded in the key does not necessarily need to match the one on your documents, although they must represent the same person); * note down your name, as written in your documents; * ask you to confirm the fingerprint of your GPG key and note it (or just take the piece of paper where you noted the output of gpg --fingerprint 0x12345678); * take the printout of the photos (if that printout is required under this policy).

I will typically ask for a reciprocal key signing in return (as long as your key signing policy can be followed).

In order for a identification document to be used for identification it must: * Be either a Passport, Identification Card, or Driving Licence (in that order). * Be issued by a government. * Must not be expired. * Have a recognisable picture of the key holder. * Show the legal full name of the key holder. * Have the nationality of the holder listed. * Have anti-forging features (such as holograms, raised print, watermarks, etc). * Be in good condition with no signs of tampering.

Signing Procedure

After meeting in person, I will: * retrieve your public key from a public key server or a well-known public location; * check that the fingerprint you confirmed at the meeting matches the one of the public key. * I will make a list of all UIDs carrying a name matching your name as listed in the documents shown during the meetings (in some cases, minor variations are accepted; I follow the CACert “Practice on Names” interpretation to determine whether a name variation is acceptable or not). If the UID has a comment, it must not raise any doubts about the identity of the user, meaning that I will independently verify any affiliation/nickname listed in them; * if a UID carries an e-mail address, I will generate a random token, include it in a message, encrypt it with the key to be certified, sign it with my own key and send it. You will need to send me the random token back to confirm that you have control over the address; If a key has multiple uids, then these proofs must be obtained for each of the non-revoked uids in the key. I will never sign a uid that does not have these proofs provided. * if a UID is a photo UID, I will check that the photo represents the same person depicted in the printout.

I will sign locally UIDs which pass all those checks, embedding a reference to this certification policy in my signature, and then send your signed public key to you via e-mail. Unless explicitly requested by you or by the rules of the attended keysigning party (if any), I will not publish my signature to a public key server; however, I reserve the right to do so (and to publish a signature revocation) in case I need to revoke my signature in the future.

I reserve the right to not sign a key at my own discretion.

What I do not certify

By signing a key, I certify certain things about it. Most of this document deals with this. However it worth noting some of the things that I do not certify about any key that I sign. The list is not exhaustive:

  • I do not certify that the email addresses listed in the key go directly to the person named.
  • I do not certify that the email addresses will always reach the person in control of the key and further more that the owner of the will revoke uids that they no lnoger can access.
  • I do not certify anything about the character or trustworthiness of the owner of the key.
  • I do not certify anything about the security measures the owner of the key uses to protect the key from compromise. I do not query the owner of the key whether a revocation certificate has been generated as I have no way to verify this fact.
  • I do not certify anything about how well the owner of the key will check other keys before signing them.


This key signing policy has been strongly influenced by the following key signing policies.


2017-12-10, Version 1.0: Intial version.

This policy is copyrighted by Andrew Broekman, 2017.

Structure and contents may be used under the conditions of the Creative Commons Attribution-Noncommercial-Share Alike 3.0 license.