Gentoo Archives: gentoo-dev

From: "Robin H. Johnson" <robbat2@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Signing everything, for fun and for profit
Date: Fri, 19 May 2006 04:32:19
In Reply to: [gentoo-dev] Signing everything, for fun and for profit by Patrick Lauer
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. -- Robin Hugh Johnson E-Mail : robbat2@g.o GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85