2 ms·
> The responses are largely tepid, with the conclusion seeming to be that PKIX feels it “can afford to wait until the very last minute, i.e. when SHA1 is actual
by wtbob 11y ago
> The responses are largely tepid, with the conclusion seeming to be that PKIX feels it “can afford to wait until the very last minute, i.e. when SHA1 is actually broken, rather than to upgrade to some fix like SHA256 before SHA1 is broken.”
That right there tells you everything you need to know about XPKI and the CA infrastructure. It's sad that a decade before the event above took place, we had a reasoned, well-thought-out alternative to XPKI, but because no-one cared it went absolutely nowhere.
I really, really hope that after these lost two decades the industry revisits and updates the ideas behind SPKI[1] and finally figures out how to actually secure Internet communications. Can't say that I'm holding my breath though.
[1] http://world.std.com/~cme/html/spki.html http://world.std.com/~cme/html/spki.html
- tptacek 11y agoI also find it upsetting, but this is a phenomenon not limited to PKIX-world; for instance: the DNSSEC root keys, which nobody in the real world even relies on yet, are RSA-1024.
- xorcist 11y agoThat's part of the story. The root keys are RSA-2048, but the intermediary zone signing keys for the root are RSA-1024. The latter keys are changed every third month. So, while there is pressing need to move to larger key sizes, the short validity tends to lessen the impact somewhat. There were some concerns that the larger keys could cause issues with some network equipment, but it looks like those concerns were overblown. Network engineers are a fairly conservative bunch and, perhaps contrary to your expectations, there are real systems in the real world that would break if the root zone broke. These systems tend not to be web, so they might not be as visible to an end user perhaps.
- tptacek 11y ago"Conservative" is not the word I would use about this decision.