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.
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,
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.
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?
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.
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.
On Sat, Jan 10, 2015 at 03:46:32PM -0500, Nick Mathewson wrote:
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:
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?
-
Ian Goldberg -
Nick Mathewson -
Nick Mathewson -
Peter Palfrader