CryptoRights Foundation our mission contact us
 

 

 

 

 

  
The CryptoRights PKI

Revision: 0.0.2 — PRELIMIARY DRAFT
Updated: 2002-02-14
Location: <cryptorights.org/keys/info/crf-pki.html>

The sections below in [square brackets] are either yet to be written or are under revision and we always need volunteers to help us improve this and other documents.
Please contact us if you can contribute!

NOTE: These policies may be superceded for an individual CRF project by the "44_KeyGenGuide" file in that Project's "ProjectBook" documentation.

Editor:
 Dave Del Torto <ddt@cryptorights.org> (editor)
Contributors:
 Jorgen Ottosson <otto@cryptorights.org>
 Richard Outerbridge <outer@cryptorights.org>
 Len Sassaman <rabbi@cryptorights.org>
 Rodney Thayer <rodney@tillerman.to>
 Ruediger Weis <ruedi@cryptorights.org>

Table of Contents:

What is a PKI?

A PKI (Public Key Infrastructure) is a collection of related public keys which bind the identities of their owners to the individuals keys and to other keys within the infratrusture in order to create reliable trust relationships when using the keys to secure and authenticate the communications between any of the participants in the PKI.

The principal challenges of maintaining a PKI are registering keys which are generated using the correct parameters, binding the keys to the human beings who claim to own them and making sure each key is available appropriately to other PKI participants (and often not to others) and makign sure to remove (or revoke) keys which are no longer useful or which represent a security threat (e.g. keys introduced by counterfeiters).

[Generalized description of CRF Web of Trust principles]

The CryptoRights PKI

CRF uses a combination of "hierarchical" and "web" trust models, this combination being possible because of the highly flexible OpenPGP certificate structure defined in RFCs 1991 and 2440. We have internal and external Public Key Infrastructures (PKIs) and use the "hierarchical" model internally only, in order to enforce various critical security policy mechanisms that help us ensure that we never handle our human rights clients' actual data.

These policies include encryption of ALL internal email to and from CRF addresses ONLY and using ONLY CRF keys, and keyserver storage and certification policies. Externally, for user services personnel and with clients, we use the "web" validity (trust) model to validate keying material after proofing people's identities. This allows for flexibility under rigorous field conditions. Where the external "web" model touches the boundaries of our more strict internal trust model, we provide alternative communications security mechanisms to either interoperate with, convert or translate the necessary keying material and data encryption formats, making sure to leave an auditable logging trail wherever possible.

xxxxxxxxxxxxxxxxxxxxxxxxxxx

Root/Hierarchical PKI

[staff]

[volunteers]

The CRF Root Key(s)

CryptoRights uses a 'Root Key' (much like your own key) for the certification of other important role keys (keymaster, postmaster, hostmaster, webmaster, etc), signatures on important documents. This key is generated in a public ceremony which is witnessed by many other people (unlike some root keys, which are created in secret, which we do not believe in). It is specially modified so that it may only be used to sign/certify other data (i.e. it cannot be used for encryption, and therefore you cannot encrypt email to it). The keying material is very carefully and securely maintained by CRF's President and Board of Directors, and we also have a special software development project now underway (Project PEASOUP) to create an open source mechanism for cryptographically splitting such critical keys (and other data) into secure shares that enable us to require multiple people to consent to the purpose in order to use them for signing/certifying anything.

Obtaining the Current CRF Root Key

You can obtain the current CRF Root Key from <cryptorights.org/keys/crf-root-00.html>]

[why you need this key: see policy statement on above page]

[obtaining CRF Root Key(s): [internal keyserver: protocol: PGP Keyserver LDAPS, server: keys.cryptorights.org, port: 636]

[webserver: staff-key page, HTTP Keyserver UI]

[by hand: floppy disk, compact flash, etc.]

[by email to crf-rootkey-request@cryptorights.org]

[pda-beaming: note size limitation on beamed documents]

[on paper]

[other]

Making the CRF Root into a Meta-Introducer

[making "Meta-Introducer" signature on CRF Root key]

[Set key to expire on same date that CRF Root expires]

[GPG: alternate GPG users procedure involving
(A) direct signature on verified Root key,
(B) manual no-export policy]

The CRF Keymaster Key

[use of Keymaster Key for key submissions]

[why you need this key: see policy statement on above page]

[you need: [Keymaster key from <cryptorights.org/keys/crf-keymaster.html>]

[obtaining Keymaster Key]

[internal keyserver]

[webserver]

[by email]

[pda-beaming (from CRF officers only?)]

[size limits on beamed PalmOS address-note and memo files]

[how to check signatures by Keymaster Key]

[PGP: making "Trusted Introducer" signature on Keymaster key]

[GPG: alternate GPG users procedure]

Postmaster Key

[use of for email-related requests/updates: see Keymaster page description]

[you need:]

[Postmaster key from <cryptorights.org/keys/crf-postmaster.html>]

[obtaining Postmaster key:]

[internal keyserver]

[webserver]

[by email]

[pda-beaming (from CRF officers only?)]

[size limits on beamed PalmOS address-note and memo files]

[making "Non-Exportable" signature on Postmaster]

[GPG: alternate GPG users procedure]

CRF Staff Keys

[obtaining; internal keyserver, webserver, by hand, by email, pda-beaming, paper, other]

[restrictions on signing of other CRF keys]

Special Root Keys

[obtaining; internal keyserver, by hand, by email, pda-beaming, paper, other]

[regional CRF roots]

[external client roots]

Project Keys

[obtaining from Project Manager]

[use of for validating project data]

Key-Splitting

[Why CRF splits keys: root/signature keys, ADKs]
[Describe and link to PEASOUP Project]

[why Staff/Volunteers might split a key: before going on field mission, splitting a KRC, etc.]

[why you might receive shares of a split keypair: before going on field mission]

Current Limitations on Key Splitting:

[inability of GPG to do keysplitting, reference PEASOUP project]

[see rabbi@cryptorights.org for version non-interoperability limitations on PGP key-splitting/reconstitution]

Key Revocation

[obtaining; internal keyserver, by hand, by email, pda-beaming, paper, other]

[approved methods for use of revocations]

[setting Designated Revoker to Keymaster key]

[self revocation: KRCs]

[detecting fraudulent revocations]

Destruction of Keying Material
[secure deletion of keying material]
Verifying CRF Key Validity

[Checking Validity of CRF Keys]

[Checking Validity of Signatures from CRF Keys]

[Obtain required keys: see ****]

[where to obtain keys for CRF staff/volunteers]

[How to check the validity of those keys: see ****]

[what to do when signatures fail: common signature failure troubleshooting]

[Who to notify]

[Where to send failed signatures for further investigation. Note on presence of ADK]

CRF Keys in the Field Field Registration of Keys

[procedures for Registering client-generated keys in the field]

[tutorial/guided keygen]

[use of special field root keys]

[returning client keys to CRF: see "Key Submission"]

[via Keyserver: protocol: PGP Keyserver LDAPS, server: keys.cryptorights.org, port: 636]

[via Email to Keymaster]

[via CRF remailer]

[via FTP <ftp://key:submit@cryptorights.org/> for anonymous FTP submissions]

[other]