From bf4c6cf24ae0a64645c129edf534e00647a1efae Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Tue, 2 Dec 2008 22:20:47 +0000 Subject: [PATCH] Add proposal 157: "Make certificate downloads specific" svn:r17448 --- doc/spec/proposals/000-index.txt | 2 + .../proposals/157-specific-cert-download.txt | 91 +++++++++++++++++++ 2 files changed, 93 insertions(+) create mode 100644 doc/spec/proposals/157-specific-cert-download.txt diff --git a/doc/spec/proposals/000-index.txt b/doc/spec/proposals/000-index.txt index dddc4ff0e6..85e404437c 100644 --- a/doc/spec/proposals/000-index.txt +++ b/doc/spec/proposals/000-index.txt @@ -79,6 +79,7 @@ Proposals by number: 154 Automatic Software Update Protocol [OPEN] 155 Four Improvements of Hidden Service Performance [OPEN] 156 Tracking blocked ports on the client side [OPEN] +157 Make certificate downloads specific [OPEN] Proposals by status: @@ -101,6 +102,7 @@ Proposals by status: 154 Automatic Software Update Protocol 155 Four Improvements of Hidden Service Performance 156 Tracking blocked ports on the client side + 157 Make certificate downloads specific NEEDS-REVISION: 131 Help users to verify they are using Tor NEEDS-RESEARCH: diff --git a/doc/spec/proposals/157-specific-cert-download.txt b/doc/spec/proposals/157-specific-cert-download.txt new file mode 100644 index 0000000000..d389c26fd6 --- /dev/null +++ b/doc/spec/proposals/157-specific-cert-download.txt @@ -0,0 +1,91 @@ +Filename: 157-specific-cert-download.txt +Title: Make certificate downloads specific +Version: $Revision$ +Last-Modified: $Date$ +Author: Nick Mathewson +Created: 2-Dec-2008 +Status: Open +Target: 0.2.1.x + +Overview: + + Tor's directory specification gives two ways to download a certificate: + by its identity fingerprint, or by the digest of its secret key. Both + are error-prone. We propose a new download mechanism to make sure that + clients get the certificates they want. + +Motivation: + + When a client wants a certificate to verify a consensus, it has two choices + currently: + - Download by identity key fingerprint. In this case, the client risks + getting a certificate for the same authority, but with a different + signing key than the one used to sign the consensus. + + - Download by signing key fingerprint. In this case, the client risks + getting a forged certificate that contains the right signing key + signed with the wrong identity key. (Since caches are willing to + cache certs from authorities they do not themselves recognize, the + attacker wouldn't need to compromise an authority's key to do this.) + +Current solution: + + Clients fetch by identity keys, and re-fetch with backoff if they don't get + certs with the signing key they want. + +Proposed solution: + + Phase 1: Add a URL type for clients to download certs by identity _and_ + signing key fingerprint. Unless both fields match, the client doesn't + accept the certificate(s). Clients begin using this method when their + randomly chosen directory cache supports it. + + Phase 1A: Simultaneously, add a cross-certification element to + certificates. + + Phase 2: Once many directory caches support phase 1, clients should prefer + to fetch certificates using that protocol when available. + + Phase 2A: Once all authorities are generating cross-certified certificates + as in phase 1A, require cross-certification. + +Specification additions: + + The key certificate whose identity key fingerprint is and whose signing + key fingerprint is should be available at: + + http:///tor/keys/fp-sk/-.z + + As usual, clients may request multiple certificates using: + + http:///tor/keys/fp-sk/-+-.z + + Clients SHOULD use this format whenever they know both key fingerprints for + a desired certificate. + + + Certificates SHOULD contain the following field (at most once): + + "cross-cert" NL CrossSignature NL + + where CrossSignature is a signature, made using the certificate's signing + key, of the digest of the PKCS1-padded hash of the certificate's identity + key. For backward compatibility with broken versions of the parser, we + wrap the base64-encoded signature in -----BEGIN ID SIGNATURE---- and + -----END ID SIGNATURE----- tags. (See bug 880.) Implementations MUST allow + the "ID " portion to be omitted, however. + + When encountering a certificate with a cross-cert entry, implementations + MUST verify that the + + (In a future version of this specification, cross-cert entries will be + required.) + +Why cross-certify too? + + Cross-certification protects clients who haven't updated yet, by reducing + the number of caches that are willing to hold and serve bogus certificates. + +References: + + This is related to part 2 of bug 854.