GnuPG Key Signing Policy of Stephane Clodic

v1.0.1, Aug 08 2005


  1. Preamble
  2. Location
  3. Prerequisites for signing
  4. The act of signing
  5. Levels of signatures
  6. Infos about signatures
  7. Trace the path to my keys
  8. Links
  9. Changelog
  10. License


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

pub   1024D/0xC007255B 2001-10-29
uid                    Stephane Clodic (/SClo) <sclo!rapsody.com>
uid                    Stephane Clodic (France-Teaser) <sclo!teaser.fr>
uid                    Stephane Clodic (Retiaire) <sclo!retiaire.org>
uid                    Stephane Clodic (France-Teaser) <sclodic!teaser.fr>
sub   1024g/0x25934D76 2001-10-29
sub   4096g/0x3122EC26 2005-07-21
sub   4096R/0x2C5FE03F 2005-07-21

pub   1024D/0x2D733A3E 2005-02-06
uid                    Stephane Clodic (Retiaire) <sclo!retiaire.org>
sub   4096g/0xA3A50BC8 2005-02-06
sub   4096R/0xC2CCF3DF 2005-07-17

Please note that the key 0xC007255B contains the revoked UIDs <sclodic!sky.fr>, <stephane.clodic!cegetel.fr> and <stephane.clodic!cegetel.net> which are no longer valid.

To prevent spam the mail addresses in the UIDs from above are obfuscated on this web page (replace "!" with "@"). In the keys the real addresses are used.

These two keys will always be available on this page but the most current versions can usually be fetched from keyservers like pgpkeys.telering.at. You can get 0xC007255B here and 0x2D733A3E here.

This policy was originally written on 2005-05-17 and will be followed from this date on but it may be replaced with a new version at any time. Content and structure of this document are strongly based on the OpenPGP Key Signing Policy of Marc Mutz and Jörgen Cederlöf but have been slightly modified from the original sources.


I live in Paris (France) and I am open to sign keys at any time. The easiest way for verifying keys would be to meet me here in Paris. Another opportunity to get in personal contact would be to address me at certain computer related fairs. I am also listed at Biglumber.com, a webpage about key signing coordination.

Prerequisites for signing

The signee (the key owner who wishes to obtain a signature to his/her key from me, the signer) must make his/her OpenPGP key available on a publicly accessible keyserver (see above for example keyservers).

The signee must prove his/her identity to me by way of a valid identity card or a valid driving licence or passport. These documents must feature a photographic picture of the signee. No other kind of documents will be accepted. This also implies that the signee's key must feature his/her real name in order to be checked up on his/her identity card. A key which only contains a pseudonym will not be signed.

The signee should have prepared a strip of paper with a printout of the output

gpg --fingerprint 0x12345678

(or an equivalent command if the signee does not use GnuPG) where 0x12345678 is the key ID of the key which is to be signed.

A handwritten piece of paper featuring the fingerprint and all UIDs the signee wants me to sign will also be accepted.

The above must take place under reasonable circumstances (i.e. ourselves not being in a hurry, exchanging key data at a calm place and so on).

I prefer to have keys cross-signed so it does not make sense to ask me for signing keys if the signee is not willing to sign mine in return. Therefore I may use Biglumber's Key Exchange Service to ensure both parties get their keys exchanged simultaneously.

The act of signing

After having received (or exchanged) the proof detailed in the above I will sign the signee's piece of paper myself to avoid fraud.

At home I will send one e-mail to each of the mail addresses which are listed in the UIDs which I was asked to sign. These verification mails contain random strings and will be signed by me and encrypted to the public key whose fingerprint is printed on the sheet.

Upon reception of encrypted and signed replies I will check the returned random string for equality with what I sent.

UIDs which pass the above test are going to be signed. If one of the UIDs fails the test a warning will be sent to one of the other mail addresses and the procedure will be halted until a satisfactory explanation has been received or the procedure has been cancelled by the signee.

The signed keyblock will then be uploaded to a randomly chosen set of keyservers after I have received my signed keys at first. The signee can get it from there or choose to receive it through mail instead. It should be obvious that I expect the signee to sign my keys without any avoidable delay. The signee can either upload my keys to a keyserver or send it back to me by e-mail.

Levels of signatures

Depending on the character of the key which is to be signed by me I will use different levels of signatures:

Level 3
A level of 3 is given to sign-and-encrypt keys which successfully pass all the checks: I have met the signee, I have verified his/her identity card and fingerprint and his/her reply to my verification mails (being sent to the UIDs) has been correct. These signatures are the strongest in my web of trust. Photographic UIDs are also going to be signed with a level of 3.
Level 2
A level of 2 is given to sign-only keys. Usually their UIDs are of the type "Firstname Lastname" and not "Firstname Lastname <user@mailaddress.invalid>" which means that I can't (automatically) send verification mails to them. Besides encryption can't be used for these keys as they are sign-only. Please note that although these keys only get a level of 2 I have met the signee in real life and successfully verified his/her fingerprint and identity card.
Level 1
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 but I have signed some keys in the past at level 1 and I will never do so in the future.
Level 0
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 can't be checked by exchange with a member of the CA who is in charge. These signatures are the weakest in my web of trust.

Infos about signatures

Expiration date
A key with an expiration date will be signed with a signature which expire at the same time.
Policy URL
One to one meeting for GPG keysigning exchange will result by signing the signee's key whith a policy URL like this :
Each url will describe the checks before the act of signing.

Trace the path to my keys

You can use the pathfinder of http://skylane.kjsl.com/~jharris/ which gives you a simple text printout:

from to my key 0xC007255B
from to my key 0x2D733A3E

If you like graphics you surely want to try out Jörgen's Wotsap:

from to my key 0xC007255B
from to my key 0x2D733A3E


Here are some links which you may find useful or interesting:

Keyanalyze report:
Search for my name/keys in the current keyanalyze report
The current analysis of my key 0xC007255B (from http://keyserver.kjsl.com/~jharris/ka/)
The current analysis of my key 0x2D733A3E (from http://keyserver.kjsl.com/~jharris/ka/)
The current analysis of my key 0xC007255B (from http://www.lysator.liu.se/~jc/wotsap/)
The current analysis of my key 0x2D733A3E (from http://www.lysator.liu.se/~jc/wotsap/)


Version 1.0.2, 2007-10-24:
Correct typo and change url
Version 1.0.1, 2005-08-08:
Add sub-keys and self signed web page.
Version 1.0.0, 2005-05-17:
Initial Release.


Copyright (c) 2005 - present Stephane Clodic.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.

Stephane Clodic <sclo (at) rapsody (dot) com>
Last modified:
Valid HTML 4.01!Valid CSS!