| 1 |
On July 25, 2018 1:28:52 AM EDT, Joshua Kinard <kumba@g.o> wrote: |
| 2 |
>On 7/8/2018 2:38 PM, Michał Górny wrote: |
| 3 |
>> Replace the 'Gentoo subkey' term that might wrongly suggest that |
| 4 |
>> the developers are expected to create an additional, dedicated subkey |
| 5 |
>> for Gentoo. |
| 6 |
>> |
| 7 |
>> Suggested-by: Kristian Fiskerstrand <k_f@g.o> |
| 8 |
>> --- |
| 9 |
>> glep-0063.rst | 2 +- |
| 10 |
>> 1 file changed, 1 insertion(+), 1 deletion(-) |
| 11 |
>> |
| 12 |
>> diff --git a/glep-0063.rst b/glep-0063.rst |
| 13 |
>> index 0773e3b..f02537d 100644 |
| 14 |
>> --- a/glep-0063.rst |
| 15 |
>> +++ b/glep-0063.rst |
| 16 |
>> @@ -116,7 +116,7 @@ Recommendations |
| 17 |
>> |
| 18 |
>> a. Root key: 3 years maximum, expiry date renewed annually. |
| 19 |
>> |
| 20 |
>> - b. Gentoo subkey: 1 year maximum, expiry date renewed every 6 |
| 21 |
>months. |
| 22 |
>> + b. Signing subkey: 1 year maximum, expiry date renewed every 6 |
| 23 |
>months. |
| 24 |
>> |
| 25 |
>> 5. Create a revocation certificate & store it hardcopy offsite |
| 26 |
>securely |
| 27 |
>> (it's about ~300 bytes). |
| 28 |
>> |
| 29 |
> |
| 30 |
>I lost track of this due to other priorities, but picking through some |
| 31 |
>of the |
| 32 |
>follow-up messages about the lead time on renewals and all, I don't |
| 33 |
>have a |
| 34 |
>problem with that. But why is the maximum of one year on |
| 35 |
>subkey/signing key |
| 36 |
>expiration still here? |
| 37 |
> |
| 38 |
>I'm not seeing a lot of additional follow-up on that, but that is still |
| 39 |
>too |
| 40 |
>short. Two years is perfectly fine in this case. I'd prefer three |
| 41 |
>years |
| 42 |
>myself, but am willing to compromise for two. I am not doing one year |
| 43 |
>unless |
| 44 |
>someone drops some really convincing logic on me. And no, scrawling |
| 45 |
>"logic" on |
| 46 |
>the side of an anvil doesn't count. |
| 47 |
> |
| 48 |
>Does anyone know what the other projects require for their keys? |
| 49 |
>Without a |
| 50 |
>proper explanation of //why// one year needs to be the maximum, looking |
| 51 |
>to what |
| 52 |
>other projects use seems sensible for guidance. |
| 53 |
> |
| 54 |
>I can't seem to find any specific guidance from Debian, but FreeBSD |
| 55 |
>appears to |
| 56 |
>be fine with three years on their committer keys: |
| 57 |
> |
| 58 |
>""" |
| 59 |
>A three year key lifespan is short enough to obsolete keys weakened by |
| 60 |
>advancing computer power, but long enough to reduce key management |
| 61 |
>problems. |
| 62 |
>""" |
| 63 |
> |
| 64 |
>https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/article.html#pgpkeys |
| 65 |
|
| 66 |
Everyone will have a different opinion. NIST, Debian, Redhat, etc. |
| 67 |
|
| 68 |
Shouldn't you be providing the logic as to why it is a bad idea? |
| 69 |
|
| 70 |
Someone wants to set a reasonable standard for the sake of having *a* policy in place. They did the work, proposed it, and it isn't something awful or intrusive. |
| 71 |
|
| 72 |
The whole, "I am not doing one year..." and then the "anvil doesn't count" seems uncooperative and contradictory. |
| 73 |
|
| 74 |
Is there some obstacle stopping you from updating your key expiration once a year? It takes at most 20 minutes. |
| 75 |
|
| 76 |
-- |
| 77 |
Sent from my Android device with K-9 Mail. Please excuse my brevity. |
Archives