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

[Robin H. Johnson]

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