[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[or-cvs] r10065: Changes to 103 based on or-dev mail from arma. (in tor/trunk: . doc/spec/proposals)
- To: or-cvs@xxxxxxxxxxxxx
- Subject: [or-cvs] r10065: Changes to 103 based on or-dev mail from arma. (in tor/trunk: . doc/spec/proposals)
- From: nickm@xxxxxxxx
- Date: Mon, 30 Apr 2007 13:16:48 -0400 (EDT)
- Delivered-to: firstname.lastname@example.org
- Delivered-to: email@example.com
- Delivered-to: firstname.lastname@example.org
- Delivery-date: Mon, 30 Apr 2007 13:17:05 -0400
- Reply-to: or-dev@xxxxxxxxxxxxx
- Sender: owner-or-cvs@xxxxxxxxxxxxx
Date: 2007-04-30 13:16:40 -0400 (Mon, 30 Apr 2007)
New Revision: 10065
r12576@catbus: nickm | 2007-04-30 13:16:31 -0400
Changes to 103 based on or-dev mail from arma.
Property changes on: tor/trunk
svk:merge ticket from /tor/trunk [r12576] on 8246c3cf-6607-4228-993b-4d95d33730f1
--- tor/trunk/doc/spec/proposals/103-multilevel-keys.txt 2007-04-30 15:05:51 UTC (rev 10064)
+++ tor/trunk/doc/spec/proposals/103-multilevel-keys.txt 2007-04-30 17:16:40 UTC (rev 10065)
@@ -108,41 +108,54 @@
Extensions to Proposal 101.
- Add the following elements to vote documents:
+ Define a new document type, "Key certificate". It contains the
+ following fields, in order:
- "dir-identity-key": The long-term identity key for this authority.
- "dir-key-published": The time when this directory's signing key was last
- "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
+ "dir-key-certificate-version": As network-status-version. Must be
+ "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.
- 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
+ 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.
- The elements "dir-signing-key", "dir-key-published", and
- "dir-identity-key", "dir-key-certification" and MUST NOT appear in
- consensus documents.
+ 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
- The "fingerprint" field is generated based on the identity key, not
- the signing key.
+ 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
Consensus network statuses change as follows:
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
@@ -150,6 +163,42 @@
consensus vote that uses a key they do not recognize. Caches download
from authorities; clients download from caches.
+ Processing votes:
- [XXXX write me]
+ 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
+ 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.
+ 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.