| 1 |
On Sun, 2019-02-24 at 09:38 -0500, Rich Freeman wrote: |
| 2 |
> Overall, really good - just have a few comments for consideration |
| 3 |
> regarding expiration management. |
| 4 |
> |
| 5 |
> On Sun, Feb 24, 2019 at 9:13 AM Michał Górny <mgorny@g.o> wrote: |
| 6 |
> > |
| 7 |
> > +Whenever an old signature expires, a new one is automatically created. |
| 8 |
> |
| 9 |
> Unless this is just intended as loose wording, I'd suggest extending |
| 10 |
> expirations before keys expire, that way if keyservers are |
| 11 |
> inaccessible or users are offline there isn't as much exposure to a |
| 12 |
> period of non-validity. |
| 13 |
> |
| 14 |
> Perhaps renew signatures a month prior to expiry, assuming the key has |
| 15 |
> remaining validity beyond the expiration date. |
| 16 |
|
| 17 |
It's intended to be loose. There's no reason to force specific |
| 18 |
implementation details here; I just indicate that renewing is necessary. |
| 19 |
|
| 20 |
> |
| 21 |
> > +The L2 Authority Keys are used directly to sign developer keys. Since |
| 22 |
> > +they are used in an automated service, they are exposed to attacks. |
| 23 |
> > +They are trust-signed by the L1 key and can be revoked and rotated more |
| 24 |
> > +frequently than the L1 key. |
| 25 |
> |
| 26 |
> If we're going to rotate the L2 keys, then likewise I'd consider |
| 27 |
> managing a period of overlapping validity. That is: |
| 28 |
|
| 29 |
This only means rotating as a result of revocation. Which is not |
| 30 |
something we're going to predict up front. |
| 31 |
|
| 32 |
Well, technically we could have a replacement key prepared up front |
| 33 |
and kept secure but, again, that doesn't belong in the GLEP. |
| 34 |
|
| 35 |
-- |
| 36 |
Best regards, |
| 37 |
Michał Górny |
Archives