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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
