From 001d8f3d64311b7f6d35a361097eac97884abcce Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Mon, 30 Apr 2007 17:16:40 +0000 Subject: r12576@catbus: nickm | 2007-04-30 13:16:31 -0400 Changes to 103 based on or-dev mail from arma. svn:r10065 --- proposals/103-multilevel-keys.txt | 105 ++++++++++++++++++++++++++++---------- 1 file changed, 77 insertions(+), 28 deletions(-) (limited to 'proposals/103-multilevel-keys.txt') diff --git a/proposals/103-multilevel-keys.txt b/proposals/103-multilevel-keys.txt index 02946ac..39814b8 100644 --- a/proposals/103-multilevel-keys.txt +++ b/proposals/103-multilevel-keys.txt @@ -108,41 +108,54 @@ A possible solution: Extensions to Proposal 101. - Add the following elements to vote documents: - - "dir-identity-key": The long-term identity key for this authority. - "dir-key-published": The time when this directory's signing key was last - changed. - "dir-key-certification": A signature of the fields "fingerprint", - "dir-key-published", "dir-signing-key", and "dir-identity-key", - concatenated, in that order. The signed material extends from the - beginning of "fingerprint" through the newline after - "dir-key-certification". The identity key is used to generate this - signature. - - The elements "fingerprint", "dir-key-published", "dir-signing-key", - "dir-identity-key", and "dir-key-certification" together constitute a - "key certificate". These are generated offline when starting a v3 - authority. - - The elements "dir-signing-key", "dir-key-published", and - "dir-identity-key", "dir-key-certification" and MUST NOT appear in - consensus documents. - - The "fingerprint" field is generated based on the identity key, not - the signing key. + Define a new document type, "Key certificate". It contains the + following fields, in order: + + "dir-key-certificate-version": As network-status-version. Must be + "3". + "fingerprint": Hex fingerprint, with spaces, based on the directory + authority's identity key. + "dir-identity-key": The long-term identity key for this authority. + "dir-key-published": The time when this directory's signing key was + last changed. + "dir-signing-key": As in proposal 101. + "dir-key-certification": A signature of the above fields, in order. + The signed material extends from the beginning of + "dir-key-certicate-version" through the newline after + "dir-key-certification". The identity key is used to generate + this signature. + + These elements together constitute a "key certificate". These are + generated offline when starting a v3 authority. Private identity + keys SHOULD be stored offline, encrypted, or both. A running + authority only needs access to the signing key. + + Unlike other keys currently used by Tor, the authority identity + keys and directory signing keys MAY be longer than 1024 bits. + (They SHOULD be 2048 bits or longer; they MUST NOT be shorter than + 1024.) + + Vote documents change as follows: + + A key certificate MUST be included in-line in every vote document. With + the exception of "fingerprint", its elements MUST NOT appear in consensus + documents. Consensus network statuses change as follows: Remove dir-signing-key. Change "directory-signature" to take a fingerprint of the authority's - identity key rather than the authority's nickname. + identity key and a fingerprint of the authority's current signing key + rather than the authority's nickname. + + Change "dir-source" to take the a fingerprint of the authority's + identity key rather than the authority's nickname or hostname. Add a new document type: - A "keys" document contains all currently known key certification - certificates. All authorities serve it at + A "keys" document contains all currently known key certificates. + All authorities serve it at http:///tor/status/keys.z @@ -150,6 +163,42 @@ Extensions to Proposal 101. consensus vote that uses a key they do not recognize. Caches download from authorities; clients download from caches. - Verification: + Processing votes: + + When receiving a vote, authorities check to see if the key + certificate for the voter is different from the one they have. If + the key certificate _is_ different, and its dir-key-published is + more recent than the most recently known one, and it is + well-formed and correctly signed with the correct identity key, + then authorities remember it as the new canonical key certificate + for that voter. + + A key certificate is invalid if any of the following hold: + * The version is unrecognized + * The fingerprint does not match the identity key. + * The identity key or the signing key is ill-formed. + * The published date is very far in the past or future. + + * The signature is not a valid signature of the key certificate + generated with the identity key. + + When processing the signatures on consensus, clients and caches act as + follows: + + 1. Only consider the directory-signature entries whose identity + key hashes match trusted authorities. + + 2. If any such entries have signing key hashes that match unknown + signing keys, download a new keys document. + + 3. For every entry with a known (identity key,signing key) pair, + check the signature on the document. + + 4. If the document has been signed by more than half of the + authorities the client recognizes, treat the consensus as + correctly signed. - [XXXX write me] + If not, but the number entries with known identity keys but + unknown signing keys might be enough to make the consensus + correctly signed, do not use the consensus, but do not discard + it until we have a new keys document. -- cgit v1.2.3-54-g00ecf