Second Serie | Part 14 : Publish a signing policy
Have you read all the articles ?
- Part 8 : Sign files
- Part 9 : Encrypt files
- Part 10 : GPG Conf’
- Part 11 : Some details about keys and maths
- Part 12 : Export and import public and private keys
- Part 13 : Various security aspects
- Part 14 : Publish a signing policy
- Part 15 : Using gpg in command line
- Part 16 : Going to a gpg signing party
You have now a gpg key and you sign other people ? Maybe time to do it seriously no ? Writing a signing policy helps you to figure out your own level of GPG mastership.
It is a form of commitment as “digital citizen”. A sort of legal document, even though not
Il s’agit d’une forme d’engagement en temps que «citoyen numérique». It is a form of legal document, although hardly recognizable in court. It must be public and accessible through a permanent URL, and signed - preferably with the key you plan to use in the future when you sign.
It allows also others to assess your level of proficiency with gpg.
Form and details
You can get inspired by my own signing policy. A web search with «key signing policy» will also give you good examples.
Introduction
You have to write on top of the document what I would call the “metadata” :
- author
- publication and/or validity date
- version
- GPG key used to sign the document
- public url where the signed document is available
Policy
Then your policy itself.
You must mention the circumstances in which you agree to sign someone’s key, the various levels of trust granted and the default trust.
It’s also a good idea to justify the selected opinions and options. This way the reader and potential signer will know why you will sign his key with a marginal trust rather than total (for example). A well-written signature policy should be such that several months after its writing, you still feel fine and confident about it and have no desire to change.
It is imperative that you understand what “sign a key.” I suggest you read again the article about key signing while writing the policy.
You must specify the key used in the while signing other keys if it is different from the one previously indicated (signing the document itself).
Publication
The signing policy should be made public on the web (I’m not aware of printed signing policies, and it looks absurd to me anyway).
The most common is to publish the document on your own website or blog, with a link to a text file - can be abbreviated, but always with the most important elements. This text file will then, be signed.
What did I do
As I generate my blog with Pelican, everything works with plain text files. The easiest way for me was to copy the original Markdown in the download folder, tear off the extension and sign the raw file.
This forced me to write right at the start, the definitive url of the two versions (English and French) of the policy, and their signatures’ url, since all this was to be found frozen from the outset in the raw file to sign!
Remember, if you change the text (so the file), its signature is no longer valid!
You can also place your signature policy on github. There is in this case an advantage: you can sign the commit itself, which then signs the signing policy. Github is also used by keybase.io (one of the following articles is about the use of this service).