Copyright statement

This document is inspired on Daniel Roethlisberger's PGP Certification Practice Statement. The following content is licensed under the Creative Commons Attribution 3.0 license.

Introduction

This document describes the certification practice of Geoffroy GRAMAIZE and specifies requirements for certification. The term «certification» is used as a synonym for verifying an individual’s identity and signing the respective public PGP key, also commonly referred to as «PGP key signing». Is refered as «the applicant» any natural or legal person that seeks certification.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Requirements for Persons

I only certify applicants from countries with a stable government able to issue trustable ID documents. Meeting an applicant in person, face to face, is strictly required for certification, but can be made more agreeable by choosing a nice place with an appropriate supply of beverages.

Proof of Identity

The applicant has to identify himself with at least 1 (one) valid government-issued ID document with a photograph that matches the applicant's face (e.g Passport, driving license, national ID card). Expired ID Documents will systematically be rejected, even if the photograph is matching the applicant's face. I reserve myself the right to deny a document if I don't have the means to check its authenticity, if it has significant tampering evidences or if is unusually worn.

Level of Certification

When signing a key, PGP offers 3 (three) different levels of trust. I will use these certification levels to rate the applicant ability to prove his identity as described below:

• Level 1 (a.k.a. «marginal»): The user has successfully submitted 1 (one) valid government-issued ID documents.
• Level 2 (a.k.a. «full»): The user has successfully submitted 2 (two) valid government-issued ID documents.
• Level 3 (a.k.a. «ultimate»): The user has successfully submitted 3 (three) or more valid government-issued ID documents.

An electronic passport (also known as «biometric passport», «e-passport», «ePassport» or «digital») which has passed the electronic chip content check process is equivalent to 2 (two) valid government-issued IDs. I will neither store nor send to anyone any information that is read during the electronic chip content check process. The electronic chip content check process consists in reading and displaying the data stored in the passport chip and checking its consistency digitally (execution of «Passive Authentication» and of «Active Authentication»), and against the informations on the passport's page 2.

Proof of Key Authenticity

The applicant MUST confirm its key fingerprint at the meeting using an accepted method such as exchange of printed fingerprints or manually comparing fingerprints. The applicant MUST prove that he is in possession of the private part of the key. Since the private key possession verification process is cumbersome, this step MAY be performed after the meeting. The private key possession verification is performed by sending a signed and encrypted e-mail, or by exchanging a signed and encrypted file with a key which fingerprint has previously been confirmed.

Requirements for Keys

I only sign keys using cryptographically strong algorithms with sufficient key length. At the time of writing, sufficient key length for this purpose is 2048 bits for non-elliptic-curves algorithms such as RSA, DSA and ElGamal.

Keys to be signed are required to have a valid self-signature. I sign keys no matter whether the self-signature has an expiry date set or not, but the self-signature must not have expired yet. In no case will my signature carry an expiry date.

I only sign UIDs which conform to the requirements for UIDs below.

Requirements for UIDs

I will only sign UIDs carrying a full name as shown on the official ID document. I accept UIDs with middle name(s) missing. I also accept UIDs with i18n differences (non-English characters encoded or replaced with some language-dependent ASCII equivalents, such as «oe» for «ö»). I do not sign picture UIDs. I do not require an e-mail address in the UID, but if an e-mail address is supplied, it MUST conform to the requirements for e-mail addresses below.

I reserve the right to only sign a subset of eligible UIDs on keys with an excessive amount of UIDs (more than ten), with a clear preference for personal e-mail addresses to unpersonal ones such as «info@».

Requirements for E-Mail Addresses

I do not verify that the owner of the key can receive e-mail and that the e-mail address actually belongs to the owner of the key. I consider e-mail to be inherently insecure and e-mail addresses to change owner frequently, therefore verification of e-mail addresses would only provide a false sense of security where there is none.

I will not sign UIDs with syntactically bogus e-mail addresses. I will not sign UIDs with e-mail addresses carrying a person’s name obviously different from the name of the individual to be certified. I will not sign UIDs with X.400, LDAP/X.500/AD, FidoNet or other non-Internet/SMTP e-mail addresses.

Mutual Certification

I expect the applicant to also sign my keys within a reasonable timeframe. I reserve the right to revoke my signatures on keys of individuals which do not sign my keys in return.

Implicit certification renewal

The implicit certification renewal is the operation of signing a new key without a face-to-face encounter.

The applicant MUST meet ALL the following requirements to be eligible to implicit certification renewal:

1. The applicant MUST have already been certified.
2. The certified key MUST be valid (neither expired nor revoked) when I perform the renewal procedure.
3. The certified key MUST still be cryptographically strong. Refer to «Requirements for Keys» for further informations.
4. The UIDs of the new certificate MUST match the UIDs of the current certificate.
5. The certification request MUST include the public part of the certified key signed by the new key.
6. The certification request MUST include the public part of the new key AND the new key's full fingerprint signed by the certified key.
7. The certification request MUST be either a signed and encrypted e-mail or a signed and encrypted archive. Signature MUST be performed with the certified key.

Any renewal request that does not meet ALL the aforementionned requirements will be processed as a new application and will need a face to face meeting.

Transmission of Signature and Signed Key

By default, I will upload my signature (and consequently, the signed key) to a public key server. Furthermore, I reserve the right to include certified individuals and their keys in key signing analysis documents such as trust relationship graphs or matrices.

Individuals wishing to opt out of such use of their already publicly available data may request so by e-mail.

Proper key management

Once the applicant's key has been certified, the applicant MUST properly secure the private key part of the certified key (e.g. use a strong password, or a PIN protected smart-card storage). The applicant MUST revoke the key as soon as he knows that the certified key has been compromised.

I reserve the right to revoke the signature if I have strong evidences of blatant negligence or of the certified key compromission. In the last case, I MAY warn the corresponding applicant.

The applicant is hereby informed that he SHOULD regularly renew his key with cryptographically strong algorithms at least every 5 (five) years.

Revisions of this Document

I reserve the right to change this document at any point in time by publishing a later release here. I will not actively notify anybody about the change. This document replaces the previous version and is valid beginning at the time and date of the last revision.