summaryrefslogtreecommitdiffstats
path: root/dev/archive
diff options
context:
space:
mode:
authorPatrick McDermott <pehjota>2017-08-07 15:52:54 (EDT)
committer Patrick McDermott <pehjota>2017-08-07 15:52:54 (EDT)
commitd11d297fb50a44f5c185b1a9818d3d4d876fd6e3 (patch)
tree8abe468705cfbf0776109978778f1dd7576f1117 /dev/archive
parentf9d6377378aa0c2bf02e1a03f7414e50ce8d0f3a (diff)
dev/archive/signing: Expand on key transitions and revocations
Diffstat (limited to 'dev/archive')
-rw-r--r--dev/archive/signing.mdwn12
1 files changed, 12 insertions, 0 deletions
diff --git a/dev/archive/signing.mdwn b/dev/archive/signing.mdwn
index d29bf73..d5f012d 100644
--- a/dev/archive/signing.mdwn
+++ b/dev/archive/signing.mdwn
@@ -40,6 +40,18 @@ key(s) into their keyring.
If keys are distributed with prokit, **revocations and key transitions need to
be handled somehow**.
+New keys can be distributed with new versions of prokit, though this would
+require users to upgrade prokit to get new keys. Revocations, being more of a
+security risk that can go unnoticed by users, would need to be more actively and
+immediately received by users. prokit could perhaps check a key server (over
+HKPS) each time before using a key.
+
+And if prokit needs to check key servers anyway, it could also use them to find
+new archive signing keys, as long as at least one "seed" key is distributed with
+prokit. prokit should find and use only archive signing keys (by a user ID
+specified in the profile) that are signed by a non-revoked previous key (or a
+signed chain of keys with the user ID).
+
Opkg
----