On Dec 12, 2010, at 11:50 PM, Daniel Kahn Gillmor wrote: > Can you help me understand why a change in the choice of fingerprint > technique and a change in the must-implement-digest-algorithm would > require a change in the certificates themselves?
It doesn't work that way. If you want to make a proposal, I'm all ears, as are the folks on the IETF list, but it seems to me you are focusing on one specific part of the design (the secret key format), forcing it to remain unchanged, and (presumably) using changes elsewhere to accommodate this fixed point in the design (for example, doubled PKESK packets, one for each key ID). As I see it, three major things need to happen to get OpenPGP using something other than SHA-1: 1) SHA-3 needs to exist: we will almost certainly use SHA-3, but even if we don't, we should wait until the SHA-3 reports are in. SHA-3 is a major amount of effort focused on hashing. It would be foolish to design something new involving hashing without using the latest research. 2) We need OpenPGP changes to incorporate the new hash in a way that works alongside the existing design. It's not as easy as "s/SHA-1/SHA-3/", especially given the deployed base of OpenPGP programs. 3) We need to roll out those changes in a way that won't break things. We're going to be running with SHA-1 and SHA-3 together for (at least) years. Even if we assume that there will be no other unrelated changes at the same time (an assumption I'm not willing to make - everyone has the half-dozen fiddle things (like hard expiration dates) that they think could be better, but aren't really worth fixing unless there is a key version jump), I'm still not willing to go into the design process in step 2 with the assumption that changing the secret key format is somehow off-limits. (And mind you, we haven't even reached step 1 yet!) David _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
