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 [EMAIL PROTECTED]" > 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 [EMAIL PROTECTED] > ... > 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 > <[EMAIL PROTECTED]> > 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 > <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]> > [ revoked] (2) Robin Hugh Johnson <[EMAIL PROTECTED]> > [ultimate] (3) Robin Hugh Johnson <[EMAIL PROTECTED]> > [ultimate] (4) Robin Hugh Johnson <[EMAIL PROTECTED]> > [ revoked] (5) Robin Hugh Johnson <[EMAIL PROTECTED]> > [ revoked] (6) Robin Hugh Johnson <[EMAIL PROTECTED]> > [ revoked] (7) Robin Hugh Johnson <[EMAIL PROTECTED]> > [ revoked] (8) Robin Hugh Johnson <[EMAIL PROTECTED]> > [ revoked] (9) Robin Hugh Johnson <[EMAIL PROTECTED]> > > 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 <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
