diff options
| author | Patrick McDermott <pehjota> | 2017-08-07 15:52:54 (EDT) |
|---|---|---|
| committer | Patrick McDermott <pehjota> | 2017-08-07 15:52:54 (EDT) |
| commit | d11d297fb50a44f5c185b1a9818d3d4d876fd6e3 (patch) | |
| tree | 8abe468705cfbf0776109978778f1dd7576f1117 /dev | |
| parent | f9d6377378aa0c2bf02e1a03f7414e50ce8d0f3a (diff) | |
dev/archive/signing: Expand on key transitions and revocations
Diffstat (limited to 'dev')
| -rw-r--r-- | dev/archive/signing.mdwn | 12 |
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 ---- |