Re: [gentoo-dev] Signing everything, for fun and for profit

[Ned Ludd]

If there is anything you or genone need to make signing happening you
have to the full support of the council/infra/hardened/security.


On Thu, 2006-05-18 at 21:26 -0700, Robin H. Johnson wrote:
> This email is a discussion on why we need to care about more than the simple
> key parameters, and why - this includes things like changing the validity of an
> existing key. We also need to consider: location of key (primary key vs.
> subkey), expiry policies (expiries are only one element of key validity), key
> signatures, and revoking elements in a key.
>
> I've tried very hard to ensure absolutely all of the following is
> completely fact, and that I have not entered any of my opinions into it,
> except where I've explictly marked it as such.
>
> On Thu, May 18, 2006 at 11:45:17PM +0200, Patrick Lauer wrote:
> > Key policies
> > ============
> > To make signing relevant and verifiable all devs should use the same
> > parameters - key length, key type, validity.
> No, the simple parameters of the have little bearing on how they are used.
> While we do care about them in terms of managing file signatures, some
> understanding is needed first.
>
> Introduction
> ------------
> The following is an introduction into some of the OpenPGP standard, with a
> focus on how it affects file signing, key signing, management of keys (for
> the complex style listed), and revocation.
>
> It's important as to what attacks against a key can lead to what results.
>
> Breakdown of what is a 'key' is
> -------------------------------
> A 'key' under PGP/GnuPG (OpenPGP) consists of several important entities:
> 1. *actual cryptographic primary keys and secondary keys (subkeys) [pub/sub]
> 2. *user ids - one uid per email address [uid]
> 3. signatures, each attached to one uid [sig]
> 4. revocations of any of the above items [rev]
> I've included the packet type name in the [] at the end.
> The first two items marked with a * are the core entities, and items are
> associated with only one element of them.
> There are a few more packet types, but they aren't important to our
> discussion.
>
> After this point, I will use the term 'cryptokey' to refer to the actual
> cryptographic keys, and the generic term 'key' to refer to the collection of
> above items.
>
> To see the various elements of the above, try this:
> "gpg --list-sig SOMEDEV@g.o"
> If you look at my key, it goes on for a few pages (but isn't quite as
> long as the Paludis thread).
>
> The first column has the information type, and you'll see the types I
> mentioned above.
>
> Now let's focus on a single key for a moment:
>
> # gpg --edit-key robbat@g.o
> ...
> pub  1024D/34884E85  created: 2002-08-27  expires: 2008-03-09  usage: CS
>                      trust: ultimate      validity: ultimate
> sub  2048g/CA05A397  created: 2002-08-27  expires: 2008-03-09  usage: E
> sub  2048g/67592A1F  created: 2003-04-12  expires: 2008-03-09  usage: E
> This key was revoked on 2004-09-09 by DSA key 34884E85 Robin Hugh Johnson <robbat2@××××××××××××××.net>
> sub  1024D/FB33B3A4  created: 2002-08-27  revoked: 2004-09-09  usage: SA
> This key was revoked on 2004-09-09 by DSA key 34884E85 Robin Hugh Johnson <robbat2@××××××××××××××.net>
> sub  2048g/CC772FC3  created: 2002-08-27  revoked: 2004-09-09  usage: E
> sub  1024D/3233C22C  created: 2004-08-29  expires: 2008-03-09  usage: S
> [ultimate] (1). Robin Hugh Johnson <robbat2@××××××××××××××.net>
> [ revoked] (2)  Robin Hugh Johnson <rjohnsob@×××.ca>
> [ultimate] (3)  Robin Hugh Johnson <robbat2@×××××××××××××××××.net>
> [ultimate] (4)  Robin Hugh Johnson <robbat2@g.o>
> [ revoked] (5)  Robin Hugh Johnson <rhj@×××.ca>
> [ revoked] (6)  Robin Hugh Johnson <robbat2@×××.ca>
> [ revoked] (7)  Robin Hugh Johnson <robbat2@×××××××.com>
> [ revoked] (8)  Robin Hugh Johnson <robin@×××××××.com>
> [ revoked] (9)  Robin Hugh Johnson <robbat2@×××××××××.com>
>
> The important bit here is the 'usage:' bit at the end of the cryptokeys.
> There are 4 letters that will appear here:
> C - Certify
> S - Sign
> E - Encrypt
> A - Authenticate
>
> We are interested in two of these only: Certify and Sign.
> We aren't dealing with encrypted data at the moment, and usage of authenticate
> is not implemented in gpg-1.4.
>
> 'Certify' is the terminology used for signing uids.
> 'Sign' is the terminology used for digitally signing files/data.
>
> If you attend a keysigning event, you are certifying that a uid does indeed
> belong to a person (more on this in a moment, in how we can gain from it).
>
> From this point forward, I will use 'certify' to indicate signing of a
> key, and signing to indicate other data signing.
>
> Only the primary cryptokey [pub] will ever be marked with Certify.
> The primary cryptokey is used for all uid signatures made with your key.
> It also protects your key itself from some modifications by attackers.
>
> Having multiple UIDs allows a person to go over several email addresses
> over time, without having to invalidate old correspondence, or identify
> themselves to any given third party more than once.
>
> Choice of Length/Type:
> ----------------------
> Any of the cryptokeys marked with Sign will be used in signing Manifest/digest
> data.
> We have a few choices for these - I'm limiting this to what is implemented in
> upstream GnuPG, and not anything added by external patches.
> CryptoKey types: DSA, RSA.
> CryptoKey lengths:
> - DSA provides a length of 1024 bits only (gnupg does not allow you to chose
>   anything else without special options, and that is only weaker keys).
> - RSA lengths between 1024 and 4096 bits available.
>
> The following is a small speed comparison produced with 'openssl bench rsa
> dsa', run single-threaded, and excluding the variants (DSA512, DSA2048) not
> available in GnuPG.
>
> 32-bit x86 (Athlon XP)
>          sign/s verify/s
> DSA1024   592.2    501.3
> RSA1024   264.7   5581.9
> RSA2048    48.0   1763.5
> RSA4096     7.6    510.1
>
> Apple G5, Quad:
>          sign/s verify/s
> DSA1024  2125.7   1735.8
> RSA1024  1032.4  18829.6
> RSA2048   171.0   5988.2
> RSA4096    26.3   1754.4
>
> Not reflected in this is generation time for keys as that is a one time
> occurrence, the time it takes is mostly irrelevant, but for the record, RSA is
> several times slower for equivalent key lengths.
>
> Note: these speeds would not be affected by the size of the data - as GnuPG
> signs a hash of the data only.
>
> There are 11k packages in the tree now, and if we assume 2 signatures per
> package for the moment, that's ~40 seconds to verify the entire tree (assuming
> no other bottlenecks, which is completely unreasonable) with RSA4096 on a
> slower machine.
>
> For the question of key length - I ask the security folk - what do you consider
> reasonable without being paranoid?
>
> <opinion>
> It's pretty obvious in this, that RSA is slow for signing, but fast for
> verifying. Unless we have a specific need for high speed signing, I'd suggest
> we go with RSA.
> </opinion>
>
> Location of the cryptokey:
> --------------------------
> If we require that a Gentoo developer has a primary key for that is used for
> signing, we lose the ability to add web of trust to our system later.
>
> Additionally, if the developer uses the singular primary key for a lot of
> stuff, it is more vulnerable to attack.
>
> <opinion>
> Instead, the developer should create a subkey that is used for signing Gentoo
> work only. They should not sign anything else with this, including their Gentoo
> email.
>
> They may have an additional subkey for signing their Gentoo email if they wish.
> </opinion>
>
> Q: What are the potential downsides to this?
> A: There are some older keyservers out there that do not correctly deal with
>    subkeys - but this should not affect us as we are intending to distribute
>    public cryptokeys ourselves.
>
> Choosing cryptokey expiry times:
> --------------------------------
> GnuPG and the OpenPGP standard in general allow you to change the expiry date
> on a cryptokey, after it is created. With that in mind, what does it having an
> expired cryptokey imply:
> 1. GnuPG will not use that cryptokey for new creation actions (sign/encrypt/certify).
> 2. GnuPG will correctly validate/decrypt anything signed/encrypted by that
>    cryptokey, provided that the data timestamp is older than the key expiry
>    timestamp.
>
> #1 is a logical behavior.
> #2 protects us when data hasn't changed for a long time - but we have to be
>    careful about accurate timestamps (evil can get in here).
>
> Q: What do we actually gain from expiry times in encryption setups?
> A: It would indicate to others which key to use.
>
> Q: What do we actually gain from expiry times in data signing setups?
> A: Marginal protection against attacks from large datasets that might allow
>    compromise of the key, but only by encouraging us to have multiple keys over
>    time. Is this really a concern? No, we aren't signing large amounts of data.
>
> Q: Is there anything else we gain from expiry times?
> A: Yes. If a practice of using medium-term expiry times, and updating them
>    regularly is undertaken, the keys provide an indication of who is still paying
>    attention.
>
> <opinion>
> For the last reason alone, expiry times are worthwhile, and I would like to
> suggest that a period of 6 months is used.
> </opinion>
>
> Revocating of cryptokeys also has the same implications as an expired
> cryptokey, with the exception that you cannot under a revocation.
>
> Other validity elements:
> ------------------------
> Now we lead into some more complex areas. Beyond cryptokey expiry dates, there
> are several other methods for key validity. Of primary importance to us are uid
> signatures.
>
> UID signatures:
> ---------------
> As I wrote last year, these may take several forms.
> We are concerned with several properties that they may have:
>
> Expiry dates of signatures:
> Unlike expiry dates of cryptokeys, these may not be changed - by default, they
> take on the expiry date of the certifying cryptokey, although a lower value may be
> set. If you have an existing signature that has expired, you need to get your
> uid signed again.
>
> Revocation of signatures:
> A signature may be revoked by the certifying cryptokey only.
> (TODO: need to check that the same rules of validity apply here).
>
> Trust markings:
> This is not of immediate concern, but instead offers future options for the
> very paranoid portion of our userbase. They can implement things like only
> trusting a specific web-of-trust of developers.
>
> Using UID signatures:
> ---------------------
> Q: How can we use signatures to our advantage, for the hybrid or complex schemes?
> 1. Take the master key as defined by the 'Simple' proposal.
> 2. Use it to create uid signatures to each trusted developer key.
> 3. In verifying, designate said master key as the top level of trust (this is
>    the same as the simple scheme), and verify all file signatures by developers
>    as you go along.
>
> This schema is extensible to N master keys, by telling GnuPG that it
> needs signatures from M masters before data is considered trusted.
>
> Revoking keys:
> --------------
> <opinion>
> When a developer leaves Gentoo, he should not revoke the subkey used to
> sign (indeed, he may not be able to, think being hit by a bus).
> Instead, any signatures made by a valid master key should be revoked.
> This ensure control remains in the hands of the keymasters (infra, devrel,
> whoever).
> </opinion>
>
> Summary:
> -----------
> This is a brief summary of the suggestions and choices above.
> This summary outline is assuming a model such as the hybrid or complex
> models.
>
> - Each developer shall have a GnuPG key.
> - Each developer key shall contain at least one uid, with name and Gentoo email
>   address of the developer.
> - Each developer must create a secondary cryptokey with the following
>   parameters (designated as their Gentoo signing cryptokey):
>   Key Type: RSA
>   Key Length: 2048 or 4096
>   Expiry time: Set at 6 months out
>   Usage: Marked as signing only.
> - Each developer shall regularly update the expiry time (GnuPG enforces
>   this) of the cryptokey, keeping it no further than 6 months ahead of
>   the present date, except where otherwise decided.
> - Each developer should have a revocation certificate for their key, and
>   store two copies in a secure offline location (I suggest two CD-RWs,
>   of different brands, stored in separate locations, refreshed every 6
>   months, but floppy disks would work as well).
> - Each developer will sign all of their commits with their Gentoo
>   signing cryptokey only. They should not sign anything else, nor use
>   other cryptokeys for signing Gentoo commits.
> - (Optional, for those creating new keys only) a best practice would be
>   to have a primary key that is marked as certifying only.
>
> (This part here needs more discussion, which may end up that N=1 is
> valid).
> - There will be N master keys.
> - A master key will have a secondary cryptokey conforming to the same
>   requirements as the developer Gentoo signing cryptokey.
> - A master key will certify all Gentoo developer keys on a regular
>   basis. This can be done on 4 month intervals safely, with once-off
>   events to sign keys of incoming developers, or other special cases.
> - When a developer leaves, the certification on their key shall be
>   revoked.
> - Both infra and the council should hold the revocation control for a
>   master key in some way so that cooperation is needed to actually revoke
>   a master key.
>
> (For future stuff:)
> For performing releases of Gentoo (releng), a designated key be used,
> and be certified by the master key.
>
> Outstanding points:
> -------------------
> - Discussion of how the keymaster(s) should operate to maintain the
>   keyring.
>
-- 
Ned Ludd <solar@g.o>
Gentoo Linux

-- 
gentoo-dev@g.o mailing list