Marble Horse
Project overview
Team members
Cryptography


[Marble Horse]


Documentation
Software
Patch repository
Advocacy


About this site
Privacy policy





Hosted by:
[SourceForge]

Marble Horse Free Software Group
Policies on the Practice of Digital Keysigning

I. Introduction

The Marble Horse Free Software Group (which may be further referenced within this document as "MHFSG") seeks to promote the use of security- and privacy-enhancing protocols, methods and mechanisms throughout the world, not only for the experienced developer, but also the layman. This document provides a set of draft [ratified] guidelines to be followed by members of the MHFSG in all of their keysigning endeavors.

Digital keysigning is the process of associating a public key with a person or group of proven (verified) identity. Through this process, identity theft (which may result in data theft) may be prevented and the continuity of secure communications is preserved.

By their own choices, not everyone who currently holds a set of digital keys participates in keysigning. Due to the severe repercussions involved with not having a strong web of trust, the members of the MHFSG feel it is their duty to provide keysigning services, and to do so in a consistent and fair manner.

II. General Principles

1. Supported key types

MHFSG is capable of signing DSA keys that are compatible with the GNU Privacy Guard system. At this time, we are unable to provide signature services for RSA keys, due to legal issues surrounding the unlicensed use of RSA algorithm in the US as well as incompatibilities in the older PGP products (which don't know about DSA/ElGamal).

2. Requirement for in-person meeting

In order for a MHFSG member to participate in the keysigning process, an in-person meeting with the keyholder is required, without exception. This meeting serves two purposes: exchange/receipt of the key fingerprint information and opportunity to perform identity validation. Key and identity validation are crucial to successful, secure development of a strong web-of-trust.

3. Official Language of Correspondence

Unless otherwise requested (and we are able to comply), all correspondence related to keysigning will be done in the English language. Provided that trusted translation resources exist, we may be able to communicate in a language other than English, though this may only occur at our discretion.

4. Reciprocal Keysigning

Members of the MHFSG have no requirement for recipricol keysigning; that is, we are perfectly willing to sign a key even if the keyholder is not willing to sign our key.

5. Policy on Signing of MHFSG Member Keys

The MHFSG and its members do not seek to limit your keysigning practices including your possible intentions in signing our keys. We do request that you require at least a basic level of in-person identity validation and a standard level of key validity checks prior to signing keys represented as belonging to MHFSG members. All MHFSG member keys contain the name and citizenship of the keyholder as well as the four characters '[MH]'. No MHFSG keys contain ADKs (Additional Decryption Keys, used in key recovery). Please notify us immediately in the event that you find a copy of a MHFSG member key which does contain an ADK.

6. Free Service

Members of the MHFSG have no financial requirement for providing keysigning services; we do not accept money for these services (they are provided without charge and without warranty).

7. Limitations of liability

Keysigning is a free service we provide, without discrimination against race, creed, nationality, religion or sexual preference. Neither the Marble Horse Free Software Group nor its members act as, operate, or have any affiliation with licensed or unlicensed Certification Authorities; we sign keys to strengthen our personal webs of trust and to make our own communications and interactions more secure. Our keys were not issued by Certification Authorities. These services are provided without warranty. Keysigning by MHFSG members permits the keyholder no special rights nor benefits and does not provide them with membership or membership rights to the MHFSG. Keysigning by MHFSG members does not attest to the character, trustworthiness or any other property related to the keyholder nor does it validate conclusively the true identity of the keyholder. The MHFSG and its members may not agree with the keyholder's political beliefs, ideals, lifestyle, or purposes for using the key. Keysigning by MHFSG members does not permit the keyholder to make any statements regarding the MHFSG in terms of agreement with beliefs nor actions nor to act on the behalf of the MHFSG or its members. Keysigning by MHFSG members shall have sole meaning of identity validity and key consistency as entailed by this document. The MHFSG and its members make no statement, warranty nor guarantee related to their provision of keysigning services; these services are provided at the sole discretion of the MHFSG and its members. The MHFSG and its members shall not be held liable or otherwise accountable for keyholder costs in use, storage or maintenance of their key, keysigning processes, travel and living expenses nor any other expenses connected with the keyholder unless otherwise stated by a signed contract. The MHFSG and its members shall not be held liable or otherwise accountable for any costs or damages related to keysigning or refusal to sign a key. We are not lawyers, but we believe our intent is clear.

III. Basic Requirements

1. Validation of keys

During an in-person meeting, the keyholder shall provide the potential signer with the fingerprint of their secret key (not public key). After the in-person meeting, the signer will validate the secret key fingerprint against the public key fingerprint for the same key. In the event that the supplied fingerprint of the secret key matches the determined fingerprint of the public key, the key is decided to be valid.

2. Supply of public key to key signer

It is the responsibility of the keyholder, not the key signer, to verify that the key signer receives a copy of the public key to be signed. In lieu of direct communication of the key, the keyholder may direct the key signer to obtain the key from a keyserver. Key information must, under normal circumstance, be supplied in digital form. The key signer will not accept copies of the public key during the in-person meeting; this data transfer must occur either before or after the meeting.

3. Validation of keyholder identity

During an in-person meeting, the keyholder shall provide a suitable set of official identity documents, such as drivers license, passport, etc. as needed to verify the identity of the document holder. The keyholder may be asked to produce additional identity documentation in the event that the supplied materials are insufficient. At least one document must contain a recent color photograph of the keyholder. Notes will be taken by the key signer as to which forms of identification were supplied, as well as the legal name listed on this documentation. Keys which do not belong to a "real" individual shall be treated in a special manner and thus will be exempt from this style of validation (an alternate method of identity validation will occur). The preferred method of identity validation is through examination of an identification card issued by a state, federal, or tribal government that contains the individual's photo, signature, and written physical description. The written physical description should contain, at a minimum, the individual's height, weight, color of hair, and color of eyes. The identification card must be current.

4. Requirement of keyholder for responsible use

The primary controls in place to prevent misuse of the public key infrastructure lie in the hands of the keyholder. To help prevent misuse of the key and weakening of the web-of-trust, the MHFSG employs a set of requirements beyond those normally required by a key signer.

First, a query is sent to the keyholder related to their e-mail address holdings. If any of the e-mail addresses listed on a key are not held by the keyholder or e-mail address information on the key is incorrect, the MHFSG member may be unable to sign the key. No requirement is made to have an e-mail address associated with a key; those keys not listing e-mail addresses will have this requirement waived. Through this means, we help to prevent data theft or denial-of-service.

Second, the keyholder is queried during the in-person meeting as to whether or not they have generated a key revocation certificate. Key revocation certificates should be generated prior to need, to prevent weakness in the infrastructure in the case of lost password or other inability to access key data. If the keyholder has not generated a key revocation certificate, the MHFSG member may be unable to sign the key. Through this means, we promote responsible key management.

Third, only keys which have been self-signed by the keyholder may be signed by MHFSG members. Self-signing of keys helps to prevent placement of phony address information on the key (and thus prevents diversion of mail to an unwanted destination). MHFSG members will be unable to sign keys which are not self-signed.

5. Post-meeting Correspondence

Subsequent to a meeting where all key signing requirements have been met (including identity validation and key fingerprint exchange), it is within the sole discression of the MHFSG member to sign, or decline signing, a key. In the event that key signing has for some reason been declined, the member in question or a member of the administrative support team will provide written notice of this declination.

If the member determines they will sign a key, a notice will be sent to the keyholder notifying them of this signature addition. This notice will be sent to the e-mail addresses associated with the key, or alternatively, a different e-mail address designated during the meeting. The notice will include the following properties:

  • Name of the party identified as keyholder
  • Date and location of previous meeting (where identity validation occurred)
  • Name of the key signator (notice sender)
  • Supplied secret key fingerprint of the key signed
  • Determined public key fingerprint of the key signed
  • Fingerprint of the key used for signing
  • List of keyservers signed key has been posted to
  • Date and time of key signing (and keyserver posting, if different)
  • ASCII armored copy of signed key
  • ASCII armored copy of the key used for signing
  • Method employed for identity validation
  • Note on whether a level of citizenship validation occurred

6. Posting of keys and signatures to keyservers

Unless otherwise requested, MHFSG members will post all signed keys (including newly affixed signatures) to the wwwkeys.pgp.net and www.keyserver.net keyservers.

IV. Special Cases

1. Shared or Group Keys

Members of the MHFSG shall provide signatures to shared or group keys only when they have been able to conclusively validate proper ownership and right exists by the keyholder to use these keys. Shared and group keys constitute a grey area in identity validation; it may be necessary for the keyholder to provide statement of key ownership on official group letterhead via FAX or postal mail OR to having a high-level administrative contact for the group vouch for the validity of the key. Members of the MHFSG will make reasonable effort to verify a key is held by a duly authorized individual prior to signing.

2. Reference or Utility Keys

Reference and utility keys, much like shared or group keys, fall into a grey area in terms of identity validation. Unlike shared or group keys, it is much more difficult to verify proper right to use a key, due to common practice of not having an official contact associated with such keys. MHFSG members will sign reference or utility keys only of projects of which they have direct knowledge or involvement. Exception to this rule may be granted by a MHFSG member on a per case basis, pending their ability to successfully validate the right of a keyholder to use the designated key identity.

3. Anonymous Keyholders

Many people use pseudonyms in dealing with electronic mail so as to prevent their true identities from being determined. Due to the incredible difficulty involved with proving truth in ownership of anonymous identities (pseudonyms), it shall be the sole discretion of the MHFSG member as to whether or not they wish to trust the key of an anonymous keyholder. The sole remedy in trust is the validity of an associated e-mail address; if the keyholder receives mail sent to the listed address which is encrypted with the listed key, the member may choose to trust this pseudonym. Keysigning records kept regarding anonymous keyholders will be purposefully vague, but will not be omitted.

4. Keysigning Parties

Members of the MHFSG are willing to participate in organized keysigning parties. We will make every attempt to meet the rules and guidelines set out by the organizer, however in cases where MHFSG policy has more stringent guidelines, we will use these instead. Please contact MHFSG administrative staff if you have a particular set of unique needs which you need the MHFSG to consider.

5. Keyholders Younger than age of Majority

Due to the variation of laws (from state-to-state and country-to-country) related to the rights of persons who have not yet reached the age of majority ("minors"), the MHFSG and its members may decline activities of an official nature (such as identity validation) with minors unless they are accompanied by a parent or guardian. It shall be the sole discretion of the MHFSG member whether or not to participate in keysigning activities with an unaccompanied minor.

V. Enhancements to the Keysigning Process

1. Citizenship Validation

Members of the MHFSG do not hold knowledge of citizenship requirements for various countries not have the skill to validate the claims of citizenship of a keyholder. We are able to "eyeball" US passports, US official birth certificates (which have an embossed seal), Canadian birth certificates, Canadian citizenship cards and Canadian passports, making presumption that (in addition to examination of matching photo ID, if document does not contain a photograph), the individual holding these documents is a citizen of either the US or Canada. It should be noted that social security cards and drivers licenses are not considered proof of citizenship. This validation provides us only with a reasonable level of knowledge of the citizenship of a person such that we feel comfortable stating a person has a particular citizenship. This statement is, of course, not legally binding or meaningful, but does help us to ascertain a persons right to receive cryptographic materials from us.

2. Recordskeeping of Keysigning Practices

A set of signed electronic records will be retained of all keysigning performed by MHFSG members as well as any failed keysigning attempts. These records may be provided in a public manner via the Internet, telephone or other communications method.

Each success record will include the following information:

  • The date the keysigning was performed
  • The form and type of identification materials displayed to the MHFSG member
  • The name or pseudonym of the keyholder
  • One or more valid e-mail addresses for the keyholder
  • The name and key ID of the key signer
  • A signed copy of the public key
  • Date and location of in-person meeting
  • Additional notes as needed
Each failure record will include the following information:
  • Date and location of in-person meeting, if applicable
  • The name or pseudonym of the keyholder
  • The reason keysigning was declined
  • Additional notes as needed

VI. Administrative Contact

Questions or concerns regarding this document should be addressed to Jacob Moorman via e-mail at [email protected]

VII. Additional Resources

The following resources are provided by persons and groups other than the MHFSG and its members. The MHFSG and its members are not responsible for the content of these sites, but feel that the content may be beneficial as background information to use in gaining a complete understanding of this policy document.

  • GNU Privacy Guard
  • GNU Privacy Guard mini-HOWTO (chapters 1 and 5 are of particular use)
  • GNU Privacy Handbook on the web of trust
  • GNU Privacy Handbook on keysigning
  • PGP FAQ (which mostly still applies)
  • The now-defunct USENIX keysigning service
  • A paper on the dangers of Key Recovery and ADKs

Revision 2000AUG24JM01
This document is Copyright (C) 2000 Jacob Moorman and Erik Peterson. All rights reserved.



Content Copyright (c) 1999-2001 Marble Horse Free Software Group.
All trademarks are property of their respective owners.