Re: [gentoo-project] [pre-GLEP RFC] New GLEP: Gentoo OpenPGP Authority Keys

[Rich Freeman <rich0@gentoo.org>]

Overall, really good - just have a few comments for consideration
regarding expiration management.

On Sun, Feb 24, 2019 at 9:13 AM Michał Górny <mgorny@gentoo.org> wrote:
>
> +Whenever an old signature expires, a new one is automatically created.

Unless this is just intended as loose wording, I'd suggest extending
expirations before keys expire, that way if keyservers are
inaccessible or users are offline there isn't as much exposure to a
period of non-validity.

Perhaps renew signatures a month prior to expiry, assuming the key has
remaining validity beyond the expiration date.

> +The L2 Authority Keys are used directly to sign developer keys.  Since
> +they are used in an automated service, they are exposed to attacks.
> +They are trust-signed by the L1 key and can be revoked and rotated more
> +frequently than the L1 key.

If we're going to rotate the L2 keys, then likewise I'd consider
managing a period of overlapping validity.  That is:

1.  Generate new L2 key and sign with L1 when L2 has at least 30 days
expiry remaining.
2.  Re-sign all dev keys with new L2 key and use the L2 key
exclusively going forward.
3.  Wait 30 days.
4.  Revoke old L2 key, or allow to expire.  Destroy or archive old L2
private key.

This could be trivially implemented by simply not expiring the old L2
key and replacing it a month before it expires, and set the new L2
expiration in line with the rotation strategy.

Rationale:
a. Again, keyservers sometimes are offline, or users are offline, so
overlapping validity means that users are less exposed to invalid
signatures during an instantaneous transition period.
b. No need to continue to sign with the old L2 key during the
transition since users would get the new L2 key at the same time that
they would have gotten any new signatures made by the old key.

My comment is not intended to argue for/against the need for L2 key
rotation in the first place, just suggest that it be managed in a more
graceful manner if it is performed.

I also acknowledge that these comments might be more granular than
intended by the GLEP and suitably generic wording is fine, or perhaps
the original GLEP was already intended to be inclusive of this option.

-- 
Rich