0

The Subject Public Key Info field can have a value like ECDSA_P256 or ECDH_P256 when ECC is used.

Why is it not sufficient to specify "ECC_P256"? In other words, why is it not enough to specify just the curve parameters (like prime p, generator point G, etc.). This would sufficiently describe the key mathematically.

Depending on how the certificate is used (e.g. in the context of TLS or digital signature), the two parties anyway need to agree on an algorithm. It doesn't seem like it would need to be hardcoded in the Public Key Info field.

With RSA - there is no such distinction and I can, in theory, use the same certificate for different use cases allowed by the purpose field in the x509 certificate.

Improve this question
1
  • 1
    This question might be better suited for the cryptography-focused crypto.stackexchange.com Commented Jan 8, 2024 at 14:46

1 Answer 1

Reset to default
2

It doesn't.

A certificate endorsing a key intended to be used for ECDH can be identified as id-ecdh or id-ecPublicKey, but a certificate endorsing a key for ECDSA can only be identified as id-ecPublicKey.

The Key Usage field that indicates Key Agreement but not Digital Signature or Certificate Signing is probably ECDH. If it's the other way, it's probably ECDSA. (In either case it could be some new algorithm, though).

But Windows CNG makes (made?) a distinction between an ECDH key and an ECDSA key, and so they call them different algorithms. In fact, they called ECDSA with P-256 a different algorithm than ECDSA with P-384. But then they found themselves with two problems: 1) what do you do with a key from a certificate with no Key Usage (or has both Key Agreement and Digital Signature)? 2) what do we do about supporting extra curves? For the former, the decision was "ECDSA keys are signature only, but ECDH can do both", making "ECDH_P256" a potentially algorithm-flexible choice. For the second, they made curve-neutral "ECDH" and "ECDSA", but for backwards compatibility they still use the old identifiers when appropriate.

As to why you see the difference, it's just a quirk/consequence of the Windows Certificate UI; the item you're looking at where Windows has interpreted the OID, Key Usage, and curve identifier to turn that into what algorithm identifier it would need to use when instantiating the public key. The Windows UX people seem to think that's friendlier than showing the OID.

Improve this answer
1
  • From what I can tell Windows can't actually display a certficiate with id-ecdh correctly. Windows displays ECDH P256 when the usage is KeyEncipherment. And it displays ECDSA P256 when the usage is Digital Signature. In both cases the algorythm is actually id-ecPublicKey. But I set the OID to id-ecdh Windows fails to disply in the GUI the certificate correctly. Commented Sep 26, 2024 at 10:22

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.