Filename: 157-specific-cert-download.txt Title: Make certificate downloads specific Author: Nick Mathewson Created: 2-Dec-2008 Status: Accepted Target: 0.2.1.x History: 2008 Dec 2, 22:34 Changed name of cross certification field to match the other authority certificate fields. Status: As of 0.2.1.9-alpha: Cross-certification is implemented for new certificates, but not yet required. Directories support the tor/keys/fp-sk urls. Overview: Tor's directory specification gives two ways to download a certificate: by its identity fingerprint, or by the digest of its signing 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): "dir-key-crosscert" 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 dir-key-crosscert entry, implementations MUST verify that the signature is a correct signature of the hash of the identity key using the signing key. (In a future version of this specification, dir-key-crosscert 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.