multiple subkeys and key transition
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Thu Dec 9 23:32:52 CET 2010
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
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.
"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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 900 bytes
Desc: OpenPGP digital signature
More information about the Gnupg-users