public inbox for gentoo-project@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Michał Górny" <mgorny@gentoo.org>
To: gentoo-project <gentoo-project@lists.gentoo.org>
Subject: [gentoo-project] [RFC] OpenPGP Authority Keys to provide validity of developer/service keys
Date: Sat, 16 Feb 2019 09:40:21 +0100	[thread overview]
Message-ID: <1550306421.831.16.camel@gentoo.org> (raw)

[-- Attachment #1: Type: text/plain, Size: 2324 bytes --]

Hi,

Following the replies to my earlier GLEP, I'd like to separately discuss
introducing Authority Keys to provide validity proof for @gentoo.org
UIDs.

TL;DR: we'd create OpenPGP key that will be used to (semi-?)
automatically sign @gentoo.org UIDs on developer keys (as listed
in LDAP), so users could trust this key and have all developers verified
instantly.


Problem being solved: making it possible for users to easily verify
developer keys and distinguish them from potential fraud.  Since
by definition Gentoo developers are people having access to Gentoo
servers, it is reasonable to use the key fingerprints stored there
as point of truth.

This is somewhat already achieved by gentoo-keys seeds file.  However,
that file is entirely custom and it doesn't work out of the box outside
gkeys environment.  On the other hand, WoT-based validity checks are
built-in in GnuPG and can be semi-reasonably used for this purpose.

The generic idea is that we'd publish an 'Authority Key' with its
fingerprint presented on the website along with service keys.  We'd sign
all @gentoo.org UIDs matching LDAP entries with this key and publish
the signatures on keyservers.  Then the user would fetch this authority
key, verify its fingerprint, set it to full trust and WoT calculation
would automatically result in all developer keys being trusted.

Developer key revocation: having a single signing point also makes it
easy to handle revocations (e.g. due to developers retiring).  We would
just have to revoke the relevant signatures, and publish updates.


Authority Key protection: since keysigning is done using the primary
key, it would have to be exposed to attacks.  Unlike with subkeys, we
would have to revoke the whole key in case of compromise.

Therefore, I would like to propose creating two layers of Authority
Keys: L1 and L2.  The L1 key would be protected strongly and used only
to sign L2 key.  The L2 key would be used to sign actual keys.

Users would only validate L1 key, and L2 would become valid implicitly. 
If L2 ever becomes compromised, we'd revoke it and use L1 to sign a new
key.  This way, GnuPG would appropriately stop trusting old L2
and verify new L2 as valid.


Your comments?  Anything I've missed?

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

             reply	other threads:[~2019-02-16  8:40 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-16  8:40 Michał Górny [this message]
2019-02-16  8:54 ` [gentoo-project] [RFC] OpenPGP Authority Keys to provide validity of developer/service keys Toralf Förster
2019-02-17  3:08 ` Andreas K. Huettel
2019-02-17  3:45 ` Aaron Bauman
2019-02-17  6:56 ` Robin H. Johnson
2019-02-17  8:55   ` Michał Górny
2019-02-17 18:54     ` Matthew Thode
2019-02-17 19:03       ` Kristian Fiskerstrand
2019-02-18 13:22       ` Michał Górny
2019-02-19 19:47         ` Robin H. Johnson
2019-02-19 20:01           ` Michał Górny
2019-02-19 20:16             ` Rich Freeman
2019-02-19 21:54               ` Alec Warner
2019-02-19 23:21                 ` Rich Freeman
2019-02-23  7:57                 ` Michał Górny
2019-02-23  7:46               ` Michał Górny
2019-02-23 13:38                 ` Rich Freeman
2019-02-23 16:30                 ` Alec Warner
2019-02-23 16:52                   ` Rich Freeman
2019-02-23 17:08                   ` Michał Górny
2019-02-23 17:45                     ` Rich Freeman
2019-02-17 19:04 ` Kristian Fiskerstrand
2019-02-18  5:23 ` Eray Aslan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1550306421.831.16.camel@gentoo.org \
    --to=mgorny@gentoo.org \
    --cc=gentoo-project@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox