Skip to content

Commit e7d1a04

Browse files
mnm678mnm678
authored
Revocation TAP (#182)
* Initial draft of revocation TAP Signed-off-by: Marina Moore <mnm678@gmail.com> * Clarify roles vs keys Signed-off-by: Marina Moore <mnm678@gmail.com> * Add example revocation file and fix formatting Signed-off-by: Marina Moore <mnm678@gmail.com> * remove extra closing brace Signed-off-by: Marina Moore <mnm678@gmail.com> --------- Signed-off-by: Marina Moore <mnm678@gmail.com>
1 parent d405b79 commit e7d1a04

1 file changed

Lines changed: 169 additions & 0 deletions

File tree

‎revocation-tap.md‎

Lines changed: 169 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,169 @@
1+
* TAP: TBD
2+
* Title: Self-revocation
3+
* Version: 1
4+
* Last-Modified: 29-Jan-2024
5+
* Author: Marina Moore
6+
* Status: Draft
7+
* Content-Type: text/markdown
8+
* Created: 19-Jan-2024
9+
10+
11+
# Abstract
12+
This TAP proposes a mechanism for independent key revocation that allows any key
13+
holder to revoke their key without waiting on delegator. Performing a revocation
14+
in TUF requires parties that delegated trust to a role to change their delegation
15+
to remove the revoked key. However, this introduces a lag between when a key
16+
holder becomes aware of a compromise and when the delegator responds to this
17+
compromise. This TAP will reduce lag time between a key compromise and a
18+
revocation by allowing any key holder to revoke the role they are trusted to sign.
19+
20+
The revocation mechanism is designed to be used by all targets roles. Targets
21+
roles, especially delegated targets roles, are not controlled by the repository,
22+
and so have the greatest likelihood of a delay before revocation.
23+
24+
This TAP uses the rotation mechanism from TAP 8 to achieve revocation. It
25+
adds a 'null key' that, when rotated to, revokes a role. If a rotation to a null
26+
key is detected, it causes the role to no longer be trusted. The client will
27+
detect a rotation to a null key and treat it as if the metadata was unsigned.
28+
A role could use a revocation if they suspect a threshold of keys have been
29+
compromised (a lost hard drive, system breach, etc). A rotation to a null key
30+
revokes trust in the role, not specific keys, so all keys associated with the
31+
role will be invalid after a rotation to null. If only a single key needs to be
32+
replaced, it can be safely rotated using the mechanism in TAP 8 especially in
33+
the case that a threshold of keys is required.
34+
35+
A delegator to a role A is able to help A recover from a rotation to null of A
36+
by delegating to a new set of keys for A. This ensures that the delegator is
37+
still the source of trust, but allows the role to act independently.
38+
39+
40+
# Motivation
41+
42+
Several use cases can benefit from an independent revocation mechanism:
43+
44+
45+
## Community repositories
46+
47+
Community repositories are often managed by a small group of volunteer
48+
administrators. These administrators are responsible for managing the targets
49+
metadata that delegates to all projects on the repository, often with an offline
50+
key for additional security. This means that any revocations of compromised keys
51+
will not be reflected in the metadata until the volunteer administrator learns
52+
about and verifies the revocation, then manually signs new metadata with their
53+
offline key that either removes the revoked key(s), or replaces them. Each of
54+
these steps can be time consuming, and the whole process may take many hours or
55+
even days. During this period, users will continue to use the compromised key.
56+
57+
# Rationale
58+
59+
TUF is a framework for securing software update systems that is designed
60+
to maintain trust in the system through key compromises. The trust
61+
is rooted in a quorum of root keys, which delegate trust to other roles.
62+
When the root keys delegate trust to a role T for all names, this can be
63+
used to delegate some names to role D, etc. If one of role D's keys is
64+
compromised, they have to wait for role T to replace the key with a new,
65+
trusted key.
66+
67+
With this proposal, the owner of role D can
68+
revoke their role without relying on the delegator. This will improve
69+
response time to key compromises.
70+
71+
TAP 8 already proposes a mechanism for key rotation. We utilize document formats
72+
from that proposal to support key revocation.
73+
74+
75+
# Specification
76+
77+
## Rotate file (from TAP 8)
78+
79+
The signed portion of a `rotate` file is as follows (there's also a
80+
signatures wrapper as in tuf spec, not shown here):
81+
82+
```python
83+
{
84+
"_type" : "rotate" ,
85+
"previous" : PREV_FILENAME
86+
"role" : ROLE,
87+
"keys" : {
88+
KEYID : KEY
89+
, ... } ,
90+
"threshold" : THRESHOLD }
91+
}
92+
```
93+
94+
Where ROLE, KEYID, KEY, and THRESHOLD are as defined in the original
95+
tuf spec. The value of ROLE has to be the same as the role for the
96+
delegation. The value of THRESHOLD is its new value. PREV_FILENAME is
97+
the name of the previous rotate file in the chain, or the empty string if this is
98+
the first rotate file for this role. The keys specify the new valid keys
99+
and associated key ids (which may be a subset or superset of
100+
the old ones). A rotate file does _not_ contain an expiration date,
101+
it is meant to be signed once and never modified. The rotate
102+
file has to be signed with an old threshold of old keys.
103+
104+
105+
## Rotation to Null
106+
107+
Clients need to check for rotations to a null key, and any delegation pointing
108+
to a rotation to a null key is invalid. The null key is a hard coded value used
109+
across TUF implementations. This enables a role to explicitly revoke their
110+
own key(s) by introducing a rotation to null. As example rotate file would be:
111+
112+
```python
113+
{
114+
"_type" : "rotate",
115+
"version" : 2,
116+
"role" : "foo",
117+
"keys" : {
118+
NULL
119+
},
120+
"threshold" : 1
121+
}
122+
```
123+
124+
where NULL is the null key.
125+
126+
### Prioritizing Self Revocation
127+
128+
Rotation files are immutable unless replaced with a revocation (rotate
129+
to null). This is the only case in which they can be replaced or
130+
modified. If a client wants to rotate to a different
131+
key, without having access to their currently delegated private key,
132+
this requires a key revocation by the delegating metadata.
133+
134+
135+
# Security Analysis
136+
137+
There should be no negative security impact. The major benefits are
138+
that many security-sensitive revocations that require key use by
139+
multiple parties, will now be much easier to do.
140+
141+
Clients need to take care to check for rotation to a null key (rotate
142+
files that contain a null key). This shall be handled in the
143+
same manner as an invalid metadata signature on by the role possessing
144+
the key. The role will be invalid until it is re-delegated to with a new key.
145+
Clients MUST use snapshot metadata to ensure that they receive all rotate files
146+
in the chain.
147+
148+
Intentionally rotating to null enables a repository, a
149+
project, and individuals to explicitly revoke their key material
150+
themselves. An individual whose key is compromised can introduce
151+
a rotation to null, and all delegations to them will be invalid.
152+
153+
As a general note, this TAP only extends the possibilities of a target,
154+
but the delegation mechanism is still in place - i.e. a key higher up
155+
in the delegation can always revoke / modify the delegation itself.
156+
157+
158+
# Backwards compatibility
159+
160+
This TAP is not backwards compatible since clients have to download and
161+
verify the revocations.
162+
163+
# Augmented Reference Implementation
164+
165+
TODO
166+
167+
# Copyright
168+
169+
This document has been placed in the public domain.

0 commit comments

Comments
 (0)