| 1 |
Overall, really good - just have a few comments for consideration |
| 2 |
regarding expiration management. |
| 3 |
|
| 4 |
On Sun, Feb 24, 2019 at 9:13 AM Michał Górny <mgorny@g.o> wrote: |
| 5 |
> |
| 6 |
> +Whenever an old signature expires, a new one is automatically created. |
| 7 |
|
| 8 |
Unless this is just intended as loose wording, I'd suggest extending |
| 9 |
expirations before keys expire, that way if keyservers are |
| 10 |
inaccessible or users are offline there isn't as much exposure to a |
| 11 |
period of non-validity. |
| 12 |
|
| 13 |
Perhaps renew signatures a month prior to expiry, assuming the key has |
| 14 |
remaining validity beyond the expiration date. |
| 15 |
|
| 16 |
> +The L2 Authority Keys are used directly to sign developer keys. Since |
| 17 |
> +they are used in an automated service, they are exposed to attacks. |
| 18 |
> +They are trust-signed by the L1 key and can be revoked and rotated more |
| 19 |
> +frequently than the L1 key. |
| 20 |
|
| 21 |
If we're going to rotate the L2 keys, then likewise I'd consider |
| 22 |
managing a period of overlapping validity. That is: |
| 23 |
|
| 24 |
1. Generate new L2 key and sign with L1 when L2 has at least 30 days |
| 25 |
expiry remaining. |
| 26 |
2. Re-sign all dev keys with new L2 key and use the L2 key |
| 27 |
exclusively going forward. |
| 28 |
3. Wait 30 days. |
| 29 |
4. Revoke old L2 key, or allow to expire. Destroy or archive old L2 |
| 30 |
private key. |
| 31 |
|
| 32 |
This could be trivially implemented by simply not expiring the old L2 |
| 33 |
key and replacing it a month before it expires, and set the new L2 |
| 34 |
expiration in line with the rotation strategy. |
| 35 |
|
| 36 |
Rationale: |
| 37 |
a. Again, keyservers sometimes are offline, or users are offline, so |
| 38 |
overlapping validity means that users are less exposed to invalid |
| 39 |
signatures during an instantaneous transition period. |
| 40 |
b. No need to continue to sign with the old L2 key during the |
| 41 |
transition since users would get the new L2 key at the same time that |
| 42 |
they would have gotten any new signatures made by the old key. |
| 43 |
|
| 44 |
My comment is not intended to argue for/against the need for L2 key |
| 45 |
rotation in the first place, just suggest that it be managed in a more |
| 46 |
graceful manner if it is performed. |
| 47 |
|
| 48 |
I also acknowledge that these comments might be more granular than |
| 49 |
intended by the GLEP and suitably generic wording is fine, or perhaps |
| 50 |
the original GLEP was already intended to be inclusive of this option. |
| 51 |
|
| 52 |
-- |
| 53 |
Rich |
Archives