proposal 240: Early signing key revocation for directory authorities.
Filename: 240-auth-cert-revocation.txt Title: Early signing key revocation for directory authorities. Author: Nick Mathewson Created: 09-Jan-2015 Status: Draft 1. Overview This proposal describes a simple way for directory authorities to perform signing key revocation. 2. Specification We add the following lines to the authority signing certificate format: revoked-signing-key SP algname SP FINGERPRINT NL This line may appear zero or more times. It indicates that a particular not-yet-expired signing key should not be used. 3. Client and cache operation No client or cache should retain, use, or serve any certificate whose signing key is described in a revoked-signing-key line in a certificate with the same authority identity key. (If the signing key fingerprint appears in a cert with a different identity key, it has no effect: you aren't allowed to revoke other people's keys.) No Tor instance should download a certificate whose signing key,identity key combination is known to be revoked. 4. Authority operator interface. The 'tor-gencert' command will take a number of older certificates to revoke as optional command-line arguments. It will include their keys in revoked-signing-key lines only if they are still valid, or have been expired for no more than a month. 5. Circular revocation My first attempt at writing a proposal here included a lengthy section about how to handle cases where certificate A revokes the key of certificate B, and certificate B revokes the key of certificate A. Instead, I am inclined to say that this is a MUST NOT.
On Sat, 10 Jan 2015, Nick Mathewson wrote:
This proposal describes a simple way for directory authorities to perform signing key revocation.
2. Specification
We add the following lines to the authority signing certificate format:
revoked-signing-key SP algname SP FINGERPRINT NL
Why not implictly revoke any previous signing key when we see a new, valid signing key certificate with a later published timestamp? It would appear to be simpler and require less state. Cheers, -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `- http://www.debian.org/
On Sun, Jan 11, 2015 at 4:23 AM, Peter Palfrader <weasel@torproject.org> wrote:
On Sat, 10 Jan 2015, Nick Mathewson wrote:
This proposal describes a simple way for directory authorities to perform signing key revocation.
2. Specification
We add the following lines to the authority signing certificate format:
revoked-signing-key SP algname SP FINGERPRINT NL
Why not implictly revoke any previous signing key when we see a new, valid signing key certificate with a later published timestamp?
It would appear to be simpler and require less state.
My main worry there is that it's possible to accidentally publish a certificate in the far future. If we can prevent that from ever happening, then we can probably just do what you suggest. Any thoughts? -- Nick
On Sun, 11 Jan 2015, Nick Mathewson wrote:
On Sun, Jan 11, 2015 at 4:23 AM, Peter Palfrader <weasel@torproject.org> wrote:
On Sat, 10 Jan 2015, Nick Mathewson wrote:
This proposal describes a simple way for directory authorities to perform signing key revocation.
2. Specification
We add the following lines to the authority signing certificate format:
revoked-signing-key SP algname SP FINGERPRINT NL
Why not implictly revoke any previous signing key when we see a new, valid signing key certificate with a later published timestamp?
It would appear to be simpler and require less state.
My main worry there is that it's possible to accidentally publish a certificate in the far future. If we can prevent that from ever happening, then we can probably just do what you suggest. Any thoughts?
That wouldn't be a valid certificate yet. It would only become valid after its published timestamp. -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `- http://www.debian.org/
On Sat, Jan 10, 2015 at 03:46:32PM -0500, Nick Mathewson wrote:
5. Circular revocation
My first attempt at writing a proposal here included a lengthy section about how to handle cases where certificate A revokes the key of certificate B, and certificate B revokes the key of certificate A.
Instead, I am inclined to say that this is a MUST NOT.
You still have to tell clients what to do if they see that situation. A little while back, agl and I were discussing X.509 revocation, and we came to the tentative conclusion that by allowing for the recovation of certificates that revoke other certificates, and multiple signatures on certificates, determining whether a certificate was valid could actually be formally incomputable in general.
On Sun, Jan 11, 2015 at 6:33 AM, Ian Goldberg <iang@cs.uwaterloo.ca> wrote:
On Sat, Jan 10, 2015 at 03:46:32PM -0500, Nick Mathewson wrote:
5. Circular revocation
My first attempt at writing a proposal here included a lengthy section about how to handle cases where certificate A revokes the key of certificate B, and certificate B revokes the key of certificate A.
Instead, I am inclined to say that this is a MUST NOT.
You still have to tell clients what to do if they see that situation.
A little while back, agl and I were discussing X.509 revocation, and we came to the tentative conclusion that by allowing for the recovation of certificates that revoke other certificates, and multiple signatures on certificates, determining whether a certificate was valid could actually be formally incomputable in general.
Hm. What do you think of Peter's idea for "newer revokes older" then?
participants (4)
-
Ian Goldberg -
Nick Mathewson -
Nick Mathewson -
Peter Palfrader