multiple subkeys and key transition

[David Shaw]

On Dec 9, 2010, at 1:01 PM, Daniel Kahn Gillmor wrote:

>> Second, the
>> OpenPGP Working Group ("the WG") is currently figuring out how to get
>> SHA-1 out of the OpenPGP spec and how to replace it with something better.
> 
> This discussion currently seems to be idle, so i would not wait on it.
> We need to get the discussion going again, certainly.

It's not likely to go anywhere useful until the NIST hash competition is finished (or at least is almost finished).  The competition came about at least partially because people realized we don't really know enough about hashing, so it's foolish to make hash-related decisions for OpenPGP before the competition completes.

>> If you do a transition now, it's possible you'll want to transition
>> again in six months or a year once the WG updates the RFC.
> 
> This statement seems to assume that the RFC can't or won't be updated in
> a way that people could make the transition using the same key material,
> assuming they were using strong enough keys and digests in the first place.

I think that an update that truly removes SHA-1 is almost certainly going to not have a way to "upgrade" an existing key.  I ran through a bunch of cases when discussing this a while ago, and the various permutations where where Alice has a new key and Baker has an old implementation were rather unpleasant.  Why would you want to do it?  To avoid the hit to the web of trust? (i.e. getting all of your signatures again?)

This gets dramatically easier (and you can probably keep your existing keys) if you're willing to keep SHA-1 fingerprints, though not everyone is.

> My own personal bottom line: i've been using digests from the SHA-2
> family for well over a year now (and larger RSA keys for twice that
> time) and have had no interoperability problems.

Yes.  This was an issue once.  I don't see it as an issue any longer.  Not just because many implementations support the whole set of ciphers and hashes, but because most implementations properly support the preference system, so even if they don't support a particular cipher or hash, the protocol can properly deal with it.

David