Re: [gentoo-project] GLEP proposal: Gentoo GPG key policies

[Robin H. Johnson]

On Thu, Nov 14, 2013 at 07:52:49PM +0800, Patrick Lauer wrote:
>
> > ================================================
> > GLEP: xx
> > Title: Gentoo GPG key policies
>
> > Specification:
> > ==============
> > Bare minimum requirements:
> > --------------------------
> > 1. SHA2-series output digest (SHA1 digests internally permitted).
> >    "personal-digest-preferences SHA256"
> > 2. root key & signing subkey of EITHER:
> > 2.1. DSA, 2048-bit
> Equal, or at least?
2.1. DSA, >=2048-bit.

I hadn't seen that 3072-bit DSA was supported yet.

> > 2.1.1. Exception: if your hardware token only supports 1024-bit, you may use it
> Is that a relevant corner case? I'd prefer to not have that around.
I'll reword:
If using a hardware token that does NOT support RSA4096 or DSA2048, you
may degrade only to RSA2048/DSA1024 only.

This is more common than you think, most JavaCards don't have the
hardware to go beyond RSA2048.

Here's another software load for JavaCards, that may be easier than
trying to get an FSFE card or a CryptoStick:
https://github.com/CSSHL/MyPGPid
You just need to get a JavaCard w/ the programming keys.

> > 2.2. RSA, >=2048 bits,
> > 2.2.1. RSAv4 or later only: v3 and older are FORBIDDEN.
> > 3. Key expiry: 5 years max.
> Minimum?
> I'd suggest 6 months from the point in time of adding it
>
> > 4.1. Root key: 3 year max, expiry renewed annually.
> You said 5 years just above
> > 4.2. Gentoo subkey: 1 year max, expiry renewed every 6 months.
> Move that from recommendation to standard? See above.
You crossed sections, but let's collapse both to:

Bare minimum requirements:
3. Key expiry: 6 months min, 3 years max.
Recommendations:
4.1. Root key: 6 months min, 3 year max;
4.2. Signing subkey: 3 months min, 1 year max;
4.3. For both keys, expiry date should always be update at least 1 month before expiry.

> > 4. If you intend to sign on a very slow alternative-arch, you may find adding a
> >    DSA1024 subkey significantly speeds up the signing.
> >    TODO: should we codify this exception?
> Is this a real problem? (I already have 30sec+ network lag often enough
> ... )
Slow arches: this is your time to weigh in. Do you mind signing on a
local machine? Network lag shouldn't matter at all here, you should be
signing locally.

> > 9. You MUST upload your key to the SKS keyserver rotation before usage!
> >    TODO: we had considered running an internal keyserver for developers only,
> >    is this still in demand, or not needing with a good public keyserver and the
> >    gentoo-keys project?
> Make that mandatory then.
9. You must make your key available in at least the following two
places:
9.1. Uploaded to pool.sks-keyservers.net
9.2. An ASCII-armored copy at: dev.g.o:~/public_html/.gpgkey.asc

This is because the keys themselves can be quite large, my key with
signatures is about 500kb. Having it in both locations allows:
- redundancy when the keyserver rotation is offline.
- an extra check that keyserver copy is not modified.
- quicker validation of developer key existence.
- easy of use for LDAP interaction (possible workflow: upload your key
  and have it placed in LDAP by a tool when you run and use your
  password).

Regardless, LDAP will remain the canonical source for key fingerprints,
because to update your LDAP entry, you require both your SSH key, and
your developer password.

> That might be obsoleted by dolsen's work on key seeds - what's the
> current status?
No, the key-seeds code is mostly using LDAP to fetch the dev keys from
keyservers.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@g.o
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85