MD5 Checksum 74e7ef4620b7eeae4d7223de7ab3b8bb

SHA1 Checksum 4a7160895617f7eb7ef43a7f1ca8eb5cd42faa8b

SHA256 Checksum bd35f5ce24e2976afd9ce1e8bbac30346263b5ccae172e7b1f38f2d1c92ab918

	Jeremy T. Bouse OpenPGP Key Usage Policy

Issued: April 9, 2014


Preamble

This document is valid from Apr  8, 2014 and establishes the usage and security
policy, along with all key certifications, for the following keys:

pub   4096R/4FADF197 2011-12-23
      Key fingerprint = 09C5 AB71 078F 4ACD 235B  28E5 FFCE 1C9A 4FAD F197
uid                  Jeremy T. Bouse (Debian Developer) <jbouse@debian.org>

pub   4096R/D01E190C 2011-12-23
      Key fingerprint = 653C 947B 2C05 481E 8A0A  9927 15D0 A62E D01E 190C
uid                  Jeremy T. Bouse <jeremy.bouse@undergrid.net>

pub   4096R/4114CAC1 2014-04-08
      Key fingerprint = 6604 903B 408F 9F96 B082  21E4 7404 106F 4114 CAC1
uid                  Jeremy T. Bouse (Cox Media Group) <jeremy.bouse@coxinc.com>

This policy conforms to generally accepted security principles and practices of
the OpenPGP users community.


Key Components

- The primary ("Master") keys:

The master keys are high-security sign-and-certify 4096 bit RSA key, on a clean
GNU/Linux system using the current gnupg version available.

The secret part of the master keys are stored on an encrypted removable media.
A backup copy is made using Shamir Secret Sharing and stored in several secure
locations both on-line and off-line. The main copy is kept secure in a fire safe
along with a copy of the revocation certificate stored on WORM media and a hard
copy print-out. Both copies are protected with a strong passphrase.

The master keys have no expiration and are only used for:

1. collect other people's certifications;
2. certify other people's keys, following the policy established in my key
   certification policy;
3. sign usage and certification policies, certification notes and other key
   management related documents;
4. generate, renew, revoke and self-certify User IDs and subkeys bound to the
   master keys.

The master keys are, of course, immediately revoked in the case of loss, theft
or suspected compromise of the secret key.

- The subkeys:

Two or more subkeys (at least one signing key, one encryption key) are bound to
the master key. These subkeys are used for signature and encryption operations
in everyday communications. Authentication keys are used with SSH communications.

Subkeys are no less than 2048 bits and have an expiration period of two years,
renewed every two years if the secrecy and integrity of the subkey is not suspected
to be compromised. The subkeys are stored on OpenPGP v2 smartcards.

Subkeys are, of course, immediately revoked in case of loss, theft or suspected
compomise of the secret key.

- The User IDs:

The keys are currently bound to these User IDs:

Jeremy T. Bouse <jeremy.bouse(%)undergrid.net>

    This e-mail address is used for regular communication.

Jeremy T. Bouse (Debian Developer) <jbouse(%)debian.org>

    This e-mail address is used for formal communications with the Debian Project

Jeremy T. Bouse (Cox Media Group) <jeremy.bouse(%)coxinc.com>

    This e-mail address is used for formal communications with my employment with Cox Media Group


Key preferences

- Preferred keyservers:

My preferred keyserver is pool.sks-keyservers.net. If you use the
'no-honor-keyserver-url' GnuPG option (or equivalent option in other OpenPGP
software), please make sure to use an up-to-date keyserver. Many keyservers are
still using very old and buggy releases of PKS software and do not correctly
handle keys with multiple subkeys. The keyservers that can handle multiple subkeys
are summarized on sks-keyservers.net. Consider setting pool.sks-keyservers.net
as your default keyserver and add the 'repair-pks-subkey-bug' option to your
GnuPG configuration.

- Preferred algorithms:

    Cipher: AES256, AES192, AES, CAST5, 3DES

    Digest: SHA512, SHA384, SHA256, SHA224, SHA1

    Compression: ZLIB, BZIP2, ZIP, Uncompressed


Key certifications

- Prerequisites for certification:

The applicant (the key holder who wishes to obtain a key certification from me)
must make his/her OpenPGP public key available on a publically accessible
keyserver.

The application should have prepared a strip of paper with a print-out of the
output from:

    gpg --fingerprint KEY-ID

(or equivalent command if not using GnuPG), where KEY-ID is the key ID of the
key that is to be certified. A hand-written sheet featuring all user IDs the
applicant wants me to certify and the fingerprint will also be accepted, if
clearly readable.

By requesting the key certification, the applicant declares to know and approve
this policy and generally accepted principles and practices of the OpenPGP users
community and obliges himself/herself to take all reasonable precautions to
prevent loss, disclosure or unauthorized use of his/her secret key(s) and to
immediately revoke his/her public key in any case of loss or compromise of the
secret key.

The entire process of identity verification and certificate issuing is run on a
voluntary, free of charge and best effort basis. Although I take all reasonable
measures in verifying the applicant's identity and preventing compromise or
misuse of my secret certification keys, I cannot grant any legal warranty nor
guarantees.

The OpenPGP Web of Trust follows he principle of reciprocity, so the applicant
should be willing to cross-certify with me.

- Identity verification:

I never certify someone’s key without having met him or her in person.

The applicant must prove his/her identity to me by way of a government ID card,
a driver's licence, a passport or a similar document. The document must feature
a photographic picture of the applicant.

- The act of certification:

At home, I will:

1. import the applicant's key from a publically accessible keyserver;
2. check if the key fingerprint matches the one I received from the applicant;
3. include a cert-policy-url to this policy document with certification;
4. certify the key using the caff utility. caff certifies each user ID separately
   and sends the certified key in an encrypted email to each of them. Certificates
   will not be sent to the keyservers, it's an applicant's responsibility to
   update his/her key on the public keyservers.

- Certification levels

I will certify keys using these certification levels:

Level 3 (key ownership has been carefully verified)
    Used for sign-and-encrypt keys which successfully pass all the checks: I
    have met the applicant in person and I have verified his/her identity card
    and fingerprint and the applicant has successfully received and deciphered
    the challenge/response test and sent the certified key to public keyservers.
    These certifications are the strongest in the Web of Trust.

Level 2 (key ownership has been casually verified)
    Used when the applicant has only signing-keys and no encryption keys, where
    the challenge/response test with caff was not possible. I reserve use this
    certification level also when I'm not familiar with the kind of presented
    document (i.e. foreign driver's licences, exotic countries passports or
    documents with very old photo).

Level 0 (Undefined)
    Used to certify keys belonging not to persons but to groups or organisations.

Signature of this document

    This document will have detached signatures for all master keys covered
under this policy.
			

Related links