[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    =?UTF-8?Q?Re=3A_=5Bgentoo-dev=5D_=5BPATCH_v5_03/16=5D_glep-?= =?UTF-8?Q?0063=3A_=27Gentoo_subkey=27_
From:       Aaron Bauman <bman () gentoo ! org>
Date:       2018-07-25 6:28:48
Message-ID: 0D507B06-D020-4492-8C46-9F425B1635B1 () gentoo ! org
[Download RAW message or body]



On July 25, 2018 1:28:52 AM EDT, Joshua Kinard <kumba@gentoo.org> wrote:
> On 7/8/2018 2:38 PM, Michał Górny wrote:
> > Replace the 'Gentoo subkey' term that might wrongly suggest that
> > the developers are expected to create an additional, dedicated subkey
> > for Gentoo.
> > 
> > Suggested-by: Kristian Fiskerstrand <k_f@gentoo.org>
> > ---
> > glep-0063.rst | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/glep-0063.rst b/glep-0063.rst
> > index 0773e3b..f02537d 100644
> > --- a/glep-0063.rst
> > +++ b/glep-0063.rst
> > @@ -116,7 +116,7 @@ Recommendations
> > 
> > a. Root key: 3 years maximum, expiry date renewed annually.
> > 
> > -   b. Gentoo subkey: 1 year maximum, expiry date renewed every 6
> months.
> > +   b. Signing subkey: 1 year maximum, expiry date renewed every 6
> months.
> > 
> > 5. Create a revocation certificate & store it hardcopy offsite
> securely
> > (it's about ~300 bytes).
> > 
> 
> I lost track of this due to other priorities, but picking through some
> of the
> follow-up messages about the lead time on renewals and all, I don't
> have a
> problem with that.  But why is the maximum of one year on
> subkey/signing key
> expiration still here?
> 
> I'm not seeing a lot of additional follow-up on that, but that is still
> too
> short.  Two years is perfectly fine in this case.  I'd prefer three
> years
> myself, but am willing to compromise for two.  I am not doing one year
> unless
> someone drops some really convincing logic on me.  And no, scrawling
> "logic" on
> the side of an anvil doesn't count.
> 
> Does anyone know what the other projects require for their keys? 
> Without a
> proper explanation of //why// one year needs to be the maximum, looking
> to what
> other projects use seems sensible for guidance.
> 
> I can't seem to find any specific guidance from Debian, but FreeBSD
> appears to
> be fine with three years on their committer keys:
> 
> """
> A three year key lifespan is short enough to obsolete keys weakened by
> advancing computer power, but long enough to reduce key management
> problems.
> """
> 
> https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/article.html#pgpkeys
> 

Everyone will have a different opinion.  NIST, Debian, Redhat, etc.

Shouldn't you be providing the logic as to why it is a bad idea?

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.  

The whole, "I am not doing one year..." and then the "anvil doesn't count" seems \
uncooperative and contradictory.

Is there some obstacle stopping you from updating your key expiration once a year?  \
It takes at most 20 minutes.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.


[prev in list] [next in list] [prev in thread] [next in thread]