-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Date: Wed, 29 Dec 2010 01:45:03 +0000 (ISO 8601 Basic: 20101229014503Z) Copyright: Copyright (C) 2009,2010 Ben Love Title: Key Signing Policy Author: Ben Love Policy URL: http://www.kylimar.com/cryptography/certification-policy/[LONGKEYID]/current Permanent URL: http://www.kylimar.com/cryptography/certification-policy/[LONGKEYID]/[YYYYMMDDhhmmssZ]?[HASHTYPE]=[HASHVALUE] Public Key URL: http://www.kylimar.com/cryptography/keys/[LONGKEYID]/public.asc Acceptable Hash Types: SHA512 Acceptable Primary Key Types: RSA (preferred), DSA Minimum Primary Key Length: 1024 bits Acceptable Encryption Key Types: RSA (preferred), ELG Minimum Encryption Key Length: 2048 bits UIDs: - ----------------------------- 1) Ben Love (Primary) Effective: 20 JUL 2009 Expired: (active) 2) Ben Love Effective: 20 JUL 2009 Expired: (active) 3) Ben Love Effective: 20 JUL 2009 Expired: (active) Applicable Key: - ----------------------------- 1) pub 4096R/0x0E9CF26FDAE3284F 2009-07-20 [expires: 2011-07-20] Key fingerprint = 2936 EE16 025B CFEB E043 41E9 0E9C F26F DAE3 284F Effective: 20 JUL 2009 ======================================================================== About Policy: - ----------------------------- This document establishes, presents, and certifies the key certification policy for OpenPGP keys under the sole control of the Author ("SIGNER"). This document is only valid if it is signed by a non-revoked, unexpired Applicable Key. It is effective as of the Date above. It applies to all key certification signatures made with the Applicable Key since their creation by the Author, as the sole person authorised and capable of making such signatures. The most recent version of this policy will be found at Policy URL. A specific version may be found at the Permanent URL. The public key of the Applicable Key can be found at the Public Key URL. The Author hopes, but cannot guarantee, that signatures made on the Applicable Key by other persons follow a similar Policy. In particular, the Author will attempt to ensure as much as possible that such signatures are made with a process at least as rigorous as the Key Signing Procedure specified herein. This policy was inspired by Martin Krafft's policy at: http://martin-krafft.net/gpg/cert-policy/55c9882d999bbcc4/current Policy Validity Requirements: - ----------------------------- This policy is only considered valid if all of the following requirements are met: 1) The Date must match the timestamp of the various signatures on this document to the nearest second. 2) The various signatures on this policy must use a hash algorithm that is on the list of Acceptable Hash Types specified in this policy. 3) The various signatures on this policy must contain the Permanent URL of the version of this policy being signed, though without the normal hash. Unfortunately, the hash is not feasible in this instance because the signatures themselves are used in computing the hash. This will be in the Policy URL field defined in RFC 2440. URL Information: - ----------------------------- The "[YYYYMMDDhhmmssZ]" represents a template for specifying a Coordinated Universal Time (UTC) timestamp in ISO 8601 Basic Format. For this version, the timestamp is: 20101229014503Z. The "[HASHTYPE]" represents a string that specifies one of the hash types in the comma-separated Acceptable Hash Types list of this policy. The "[HASHVALUE]" represents a capitalized hexadecimal string that is a hash value of the specified hash type and will match the hash value of this complete Policy, including the various signatures. The "[LONGKEYID]" represents a 16 character capitalized hexadecimal string that is the long form (without a leading '0x') of the key ID. It also represents the last 16 hexadecimal characters of the key's fingerprint. Certification Principles: - ----------------------------- a) Certification verifies identity and ownership equally. b) There is a Minimum Primary Key Length required to be eligible for certification by this Policy. c) Only Acceptable Primary Key Types are eligible for certification by this Policy. d) Certification signatures will never be non-revocable or trust types. e) Certification signatures will be set to never expire, unless the SIGNEE specifically requests a shorter interval. f) Certification signatures will use one of the Acceptable Hash Types. g) Certification signatures must contain the Permanent URL of the version of this policy in force at the time of signing, along with a hash verifying the contents. This will be in the Policy URL field defined in RFC 2440. h) For UIDs with e-mail addresses, the SIGNEE confirmed the validity of the e-mail via the Key Signing Procedure. This requires that the key contain a Primary Key or Subkey with a type from the Acceptable Encryption Key Types list having at least Minimum Encryption Key Length. i) For UIDs that establish an affiliation, e.g. to a project, a company, or an institution (as through a Comment, username, domain name, Real Name, etc.), the SIGNER had no doubt at the time of signing that SIGNEE was affiliated with the identified group. The identification itself must be a reasonable form. j) For UIDs with photos, the SIGNER is able to recognize the SIGNEE in the photo. k) Certifications of UIDs that do not contain an e-mail address will be transmitted to an e-mail address on another UID of the same primary key that the SIGNER also certifies. If no UID with an e-mail address exists, the certification signature will be transmitted electronically and securely to the SIGNEE in a manner SIGNER and SIGNEE agree upon in advance. l) All transmissions of certification signatures to SIGNEE will be encrypted by the SIGNEE's key and signed by the Applicable Key. In particular, SIGNER __NEVER__ uploads certifications of keys belonging to SIGNEE directly to any key server, whether public or private. Signature Levels: - ----------------------------- a) Signature Level 0 is worthless for verifying identity or ownership and therefore never used. b) Signature Level 1 indicates that no reliable verification could be performed. This is only possible with certifications give to keys belonging to roles, certification authorities, or organizations. Personal keys never receive level 1. Other keys never receive anything other than level 1. c) Signature Levels 2 and 3 indicates that the SIGNEE and key meet all other requirements of this certification policy. d) Signature Level 2 requires at least one form, preferably two, of recognizable, original, government-issued, valid photo id, with recognizable photo (such as driver's license or passport). The document(s) must have no obvious signs of tampering. The fingerprint of the key to be signed must be delivered in full, in person. e) Signature Level 3 requires the SIGNEE to be well-known by SIGNER in a personal or professional capacity for at least two years. Key Signing Procedure: (Method 1) - ----------------------------- This procedure is very similar to Manoj's Protocol, which may be found at: http://people.debian.org/~jaqque/keysign.html 1) SIGNER and SIGNEE meet in person to exchange the following: * SIGNEE's public key (if not obtainable elsewhere). * SIGNEE's public key fingerprint. * SIGNEE's UID(s) to be signed. * SIGNER's random secret number. * SIGNEE's random secret word. 2) At that same meeting, SIGNER verifies SIGNEE's identity with photo identification. 3) At home, SIGNER verifies: * SIGNEE's public key fingerprint matches SIGNEE's public key. * UID(s) to be signed on SIGNEE's public key match UID(s) provided in meeting. 4) SIGNER creates a new random secret number for each UID with an address to be signed. 5) SIGNER sends a separate message to each UID with an address, encrypted by the SIGNEE's public key, containing: * SIGNEE's random secret word. * The new random secret number for that UID. 6) SIGNER receives an encrypted reply from each UID with an address, signed by SIGNEE's public key, containing: * SIGNER's original random secret number. * SIGNER's new random secret number for that UID. 7) SIGNER signs each verified UID and delivers the signed public key directly to SIGNEE in a secure manner (preferably a message encrypted with SIGNEE's public key sent to a verified UID with an address). Key Signing Procedure: (Method 2) - ----------------------------- This alternate Key Signing Procedure method is not as complex as Method 1. At first glance it seems less rigorous, as the SIGNER does not actually know the validity of the UID(s) at the time of signing. However, it is believed to be sufficient in that the certifications are only published if and when the recipient receives them at the proper e-mail address and decrypts them using the private key. While it appears easier to deceive the SIGNER using this method, the attack surface is very similar between the two methods, requiring the SIGNEE and the attacker to be working together, since the fingerprint and UID(s) are verified in the face-to-face meeting. 1) SIGNER and SIGNEE meet in person to exchange the following: * SIGNEE's public key (if not obtainable elsewhere). * SIGNEE's public key fingerprint. * SIGNEE's UID(s) to be signed. 2) At that same meeting, SIGNER verifies SIGNEE's identity with photo identification. 3) At home, SIGNER verifies: * SIGNEE's public key fingerprint matches SIGNEE's public key. * UID(s) to be signed on SIGNEE's public key match UID(s) provided in meeting. 4) SIGNER signs each UID (separately and independently). Each signature is separately encrypted with SIGNEE's public key and sent to the associated e-mail address. Any UID without an associated address is sent to every e-mail address with a UID. If no UID has an associated address, the encrypted signature(s) are delivered using some other manner arranged with the SIGNEE. Revisions: - ----------------------------- A new revision of this policy supersedes all earlier revisions. The most recent version can always be found at the Policy URL. Specific revisions may be found at their respective Permanent URLs in perpetuity. ======================================================================== Changelog: - ----------------------------- [20101229014503Z] Removed uid blove@chathamfinancial.com entirely. Added the alternate Key Signing Procedure (Method 2). Dropped Minimum Private Key Length from 2048 to 1024 bits, since many people still use keys of that length. [20101202010805Z] Marked uid blove@chathamfinancial.com as expired. It hasn't been valid for several months now. [20100412032527Z] Added Changelog section. Added link to Manoj's Protocol. Adjusted some formatting. Added policy inspiration link. Added cert expiration principle. [20100109054432Z] Initial revision. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: http://www.kylimar.com/cryptography/keys/blove.public.asc iQJ3BAEBCgBhBQJNGpKfWhpodHRwOi8vd3d3Lmt5bGltYXIuY29tL2NyeXB0b2dy YXBoeS9jZXJ0aWZpY2F0aW9uLXBvbGljeS8wRTlDRjI2RkRBRTMyODRGLzIwMTAx MjI5MDE0NTAzWgAKCRAOnPJv2uMoT1XbD/0bZ05ULcD2JmOSE96rBVvI4e0UMX/n k6EUL7cz/MkN18tjO27tXjWgu4Oes3BlmHhLIDP6+7QpZiEUPolU4B6MM62EIapp EKV6t5fPAPxVAYDnmokYlCEEnCxZ8qtT/TmqwbOpkYDUcmfNboVpMBG1ZzI8p0Ob Qm27NEt1lzPkzl6VRGzMvwcnxnFZrJiMsaZ/Ivvt2G+Q9pXM9lB7Ij6Gp6BL103H Lx8R71DJgodXHWai2CbEatR3y+H9Ct9hUg2uWwSl2DwJ27S0b678aLWilKOyHTSs fPPeCTZv8h9HmVF9DcK1qz6s57fxZmTmvx1ClBZSkyRk9uK/iNKeXNLJDgrngXKc h5ewO2zrFhcpK1ggFbd2IjdgFaNx6amt7JI9fY2dDFILVlYOomzCpnTacUewaOny FL6eCS0/vj/TNPxZAqe8ITXPosqDULAnbnsYlEEA2khd4i9bhR1Qtu4JOiKH7JmX ve/MZT2liPU1tjWuuDpmJhxTHl1iyCO8VOr1Ha54goqh6SCevlcoTiw9/R/XmpTN htucR5OM/ypi0Fcj4O6LkvUaSpNweQjqsb+mqU/Xpqa5v7S58C8U9bA3gP52vgKa 0LD7aG+T9r9v1/aOSfdwsKVyLTi+A8R6lMcLteanNyiN2u9RS/KuwPOyjrooRHtv fcB0EtLfYDh9Tw== =yF2Q -----END PGP SIGNATURE-----