Hector Martin

To clarify the Windows crypto fail: The problem isn't in signature validation. The problem is the *root store/cache*. CryptoAPI considers an (attacker-supplied) root CA to be in the trust store if its public key and serial match a cert in the root store, Ignoring curve params.

So it's not that Windows uses the wrong curve parameters or anything like that, it's that at some point the key used to index into a validated cert cache is (serial, pub) when it should be (serial, pub, params). As they say, one of the hardest problems in CS is caching.

Presumably, only for ECC...ah, because only ECC has params significant/agile in this manner?

Yup.

Huh! I was thinking this reminded me of the ancient critical bit bug, and was trying to find the details of it (been a while!) and I found this *other* bug. https://csrc.nist.gov/csrc/media/publications/conference-paper/1996/10/22/proceedings-of-the-19th-nissc-1996/documents/paper075/paper.pdf …

TBF you can do the same thing for RSA if you set e=1, but I assume they *do* consider the RSA pubkey to be e,N and not just N (or at least they reject e=1 elsewhere).

In most RSA implementations I've seen, "e" is described as/considered part of the public key, even though it's almost always fixed as 65537 these days, but curve params are not considered part of the ECDSA public key but rather a separate thing.

It's frequently something other than 65537 for tor hidden services. I think OpenSSH has a different default value as well. Never seen it not considered part of the public key.