Merge remote branch 'mjgoins/master'

Conflicts:
	doc/george/changelog

1 files changed, 0 insertions, 203 deletions

diff --git a/website/trust-models.mdwn b/website/trust-models.mdwn
deleted file mode 100644
index 37928eb..0000000
--- a/website/trust-models.mdwn
+++ /dev/null
@@ -1,203 +0,0 @@
-[[!meta title="OpenPGP Trust Models"]]
-
-# OpenPGP Trust Models #
-
-Monkeysphere relies on GPG's definition of the OpenPGP web of trust,
-so it's important to understand how GPG calculates User ID validity
-for a key.
-
-The basic question that a trust model tries to answer is: For a given
-User ID on a specific key, given some set of valid certifications
-(signatures), and some explicit statements about whose certifications
-you think are trustworthy (ownertrust), should we consider this User
-ID to be legitimately attached to this key (a "valid" User ID)?
-
-It's worth noting that there are two integral parts in this
-calculation:
-
- *  the certifications themselves -- this is the objective part: the
-    correctness of these signatures can be calculated with a known
-    algorithm which everyone knows and agrees on, based on the public
-    keys involved.
-
- *  the ownertrust -- this is the subjective part: Who do you trust to
-    identify other entities on the network?  And *how much* do you
-    trust them to make these identifications correctly?  Everyone could
-    (and should!) answer this question differently, based on their
-    values and their relationships to the entities in question.
-
-    I might trust my sister's certifications because we've talked about
-    what sorts of certifications we feel comfortable making, and i
-    agree with her choices ("full" or "complete" ownertrust).  You
-    might not know her at all, and have no reason to treat her
-    certifications as valid (no ownertrust).
-
-    I might decide that the local municipality's procedures for
-    obtaining identity documents are a joke, and not trust their
-    certifications at all (no ownertrust), while you might feel that
-    their certifications are helpful as corroboration, but not to be
-    trusted on their own ("marginal" or "partial" ownertrust).  (Note:
-    I wish my municipality actually made cryptographic certifications
-    of identity, regardless of the ownertrust i'd put in them!)
-
-## What does "validity" mean anyway? ##
-
-You see the term "validity" a lot in this context, but it has several
-subtly different meanings:
-
-First of all, someone might speak of the validity of a key itself,
-which could mean two things:
-
- *  The key is cryptographically well-formed, not revoked, not expired,
-    and has reasonable self-signatures on its User ID packets.
-
- *  It is *also* sometimes used to mean something like "the maximum
-    validity of any associated User ID or [User
-    Attribute](http://tools.ietf.org/html/rfc4880#section-5.12)".  This
-    definition is often not very useful; because if you care about User
-    IDs at all, you usually care about a *specific* User ID.
-
-So the more useful definition of validity is actually *User ID
-validity*:
-
- *  Given that:
-
-    * the key itself is valid, in the first narrow sense used above, and
-    * given the UserID's set of cryptographically-correct certifications, and
-    * given your personal subjective declarations about who you trust to make certifications (and *how much* you trust them to do this), 
-
-    is this User ID bound to its key with an acceptable trust path?
-
-## Examining your GPG trust database ##
-
-You can see your trust database parameters like this:
-
-	gpg --with-colons --list-key bogusgarbagehere 2>/dev/null | head -n1
-
-for me, it looks like this:
-
-	tru::1:1220401097:1220465006:3:1:5
-
-These colon-delimited records say (in order):
-
- * `tru`: this is a trust database record
- * `<empty>`: the trust database is not stale (might be 'o' for old, or 't' for "built with different trust model and not yet updated")
- * `1`: uses new "PGP" trust model (0 would be the "Classic trust model") -- see below
- * `1220401097`: seconds since the epoch that I created the trust db.
- * `1220465006`: seconds after the epoch that the trustdb will need to be rechecked (usually due to the closest pending expiration, etc)
- * `3`: Either 3 certifications from keys with marginal ownertrust ...
- * `1`: Or 1 certification from a key with full ownertrust is needed for full User ID+Key validity
- * `5`: `max_cert_depth` (i'm not sure exactly how this is used, though the name is certainly suggestive)
-
-
-## Classic trust model ##
-
-As far as i can tell, the basic trust model is just the `3` and `1`
-from the above description:
-
- *  how many certifications from keys with marginal ownertrust are
-    needed to grant full validity to a User ID on a key?
-
- *  how many certifications from keys with full ownertrust are needed
-    to grant full validity for a User ID on a key?
-
-If either of these are satisfied, the User ID is considered to be
-legitimately attached to its key (it is "fully" valid).
-
-If there are no certifications from anyone you trust, the User ID is
-considered to have unknown validity, which basically means "not
-valid".
-
-If there are *some* certifications from people who you trust, but not
-enough to satisfy either condition above, the User ID has "marginal
-validity".
-
-## PGP trust model (Classic trust model + trust signatures) ##
-
-Note that so far, your ability to express ownertrust is relatively
-clumsy.  You can say "i trust the certifications made by this
-keyholder completely", or "a little bit", or "not at all".  And these
-decisions about ownertrust are an entirely private matter.  You have
-no formal way to declare it, or to automatically interpret and act on
-others' declarations.  There is also no way to limit the scope of this
-ownertrust (e.g. "I trust my co-worker to properly identify anyone in
-our company, but would prefer not to trust him to identify my bank").
-
-[Trust
-signatures](http://tools.ietf.org/html/rfc4880#section-5.2.3.13) are a
-way to address these concerns.  With a trust signature, I can announce
-to the world that i think my sister's certifications are legitimate.
-She is a "trusted introducer".  If i use "trust level 1", this is
-equivalent to my ownertrust declaration, except that i can now make it
-formally public by publishing the trust signature to any keyserver.
-
-If you trust my judgement in this area ([the
-spec](http://tools.ietf.org/html/rfc4880#section-5.2.3.13) calls my
-role in this scenario a "!meta introducer"), then you should be able to
-automatically accept certifications made by my sister by creating a
-level 2 trust signature on my key.  You can choose whether to publish
-this trust signature or not, but as long as your `gpg` instance knows
-about it, my sister's certifications will be treated as legitimate.
-
-Combining trust signatures with [regular
-expressions](http://tools.ietf.org/html/rfc4880#section-5.2.3.14)
-allows you to scope your trust declarations.  So, for example, if you
-work at ExampleCo, you might indicate in a standard level 1 trust
-signature on your co-worker's key that you trust them to identify any
-User ID within the `example.com` domain.
-
-### Problems and Questions with Chained Trust ###
-
-How do partial/marginal ownertrust and chained trust connections
-interact?  That is, if:
-
- * `A` privately grants "marginal" ownertrust for `B`, and
- * `B` issues a "marginal" trust signature at level 1 for `C`, and
- * `C` certifies `D`'s User ID and key, 
-
-Then what should `A` see as the calculated validity for `D`'s User ID?
-Surely nothing more than "marginal", but if `A` marginally trusts two
-other certifications on `D`, should that add up to full validity?
-
-What if the chain goes out more levels than above?  Does "marginal"
-get more attenuated somehow as a chain of marginals gets deeper?  And
-how exactly does `max_cert_depth` play into all this?  
-
-What about regex-scoped trust signatures of level > 1?  Does the
-scoping apply to all dependent trust signatures?  Has this sort of
-thing been tested?
-
-
-## "ultimate" ownertrust in GnuPG ##
-
-Note that for a key under your sole control, which you expect to use
-to certify other people's User IDs, you would typically give that key
-"ultimate" ownertrust, which for the purposes of the calculations
-described here is very similar to "full".
-
-The difference appears to be this: If a key with "full" ownertrust
-*but with no valid User IDs* makes a certification, that certification
-will not be considered.  But if the certifying key has "ultimate"
-ownertrust, then its certifications *are* considered.
-
-So "full" ownertrust on a key is only meaningful as long as there is a
-trust path to some User ID on that key already.  "ultimate" ownertrust
-is meaningful anyway, because presumably you control that key.
-
-## Other references ##
-
- * Much of this was gathered from experimenting with
-   [GnuPG](http://gnupg.org/), and reading [gpg's
-   `DETAILS`](http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/trunk/doc/DETAILS?root=GnuPG&view=markup).
-   Unfortunately, `DETAILS` seems to often conflate the ideas of trust
-   and validity, which can make it confusing to read.
-
- * [RFC 4880](http://tools.ietf.org/html/rfc4880) is the canonical
-   modern OpenPGP reference.  If you want to understand the pieces to
-   this puzzle in detail, this is the place to go.  However, it
-   doesn't describe the trust model calculations discussed here
-   directly, but only points at them obliquely, through [the
-   definition of trust
-   signatures](http://tools.ietf.org/html/rfc4880#section-5.2.3.13).
-   How your particular OpenPGP client chooses to calculate User ID
-   validity is therefore implementation-specific.