|
@@ -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://<hostname>/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.
|