multiple subkeys and key transition

[Daniel Kahn Gillmor]

On 12/09/2010 04:33 PM, Robert J. Hansen wrote:

> Someone else exploits the old, insecure cert format in a way you don't
> like.

Again, can you give an example of such an exploit?

> Now you're stuck arguing, "wait, that's not my cert... well, it
> /is/ my cert, it's the same cert material, but it's /not/ my cert,
> because that's an old insecure format..."

This sounds confused mainly because you're not distinguishing between
public key material and certificates.  I grant that the distinction may
well not be understood by lawyers and judges, but the conflation of the
terms here makes it needlessly confusing.

Clearer:

"That is not my certificate.  It was revoked (marked as superseded) on
$date.  I continue to use the same key material in a different certificate."

And if addressing a hopelessly legally-minded audience in the USA, you
could add: "of course i didn't make that signature; it uses
$deprecated_algorithm, which i haven't used since NIST deprecated it
back in 2010."

Unless, of course, you didn't follow NIST's guidelines and continued to
use the deprecated algorithms.  Then you couldn't make that claim.

> Remember, in the eyes of the U.S. federal
> court system, MD5 is considered a strong hash with no known attacks
> against it.

Could you cite a reference for this?

> I don't trust the courts to understand these subtle nuances.

There are lots of attacks that can be used against a clueless judiciary,
including things like creating a new key and associating it with your
victim's user ID, generating back-dated signatures and certifications,
etc.  That doesn't make the clueless judiciary a good argument against
the use of User IDs or timestamped signatures and certifications, though.

> There is a big difference between something that is possible and
> harmless in a technical sense, and something that is possible but not
> recommended in a human sense.  Technically, yes, it's possible.  From a
> human factors perspective I would revoke the old cert, create a new one,
> make a clean break with the past and move forward.  Less opportunities
> for human factors to bite me in the posterior.

Except that you've now broken entirely with the past, which is itself a
human factor.  Smooth migration, phased upgrades, and planned
transitions are all good things from a human factors perspective.

Propagating a key across certificate formats might be a reasonable
approach for some of these goals (and of course, there may be other ways
to accomplish them too).

As part of the plans for a new OpenPGP certificate format, i certainly
hope we'll address ways to make the transition to the new format as
smooth as possible for most existing users.

>> Could you point to a reference that explains why a person with a v3 key
>> considered sufficiently-strong by that day's estimation (say, 1024-bit
>> RSA) would have had to create an entirely new key instead of just
>> migrating their old key to v4?
> 
> *Have* to?  None.

OK, how about "were recommended to", or any other reference that
discusses the topic for that key version transition?

My point here is to avoid the creation of FUD around a potential new
version of OpenPGP causing a lot of work, or discouraging people from
using stronger crypto.

The possibility (probability) of a new certificate format coming down
the pike eventually should *not* be used to discourage people from
migrating away from known-weak and deprecated cryptographic algorithms
today.

Regards,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20101209/6b89157c/attachment-0001.pgp>