Re: [pkix] In-the-wild implementations of RFC6955?

[Michael StJohns <[e-mail]>]

On 5/26/2022 12:55 PM, Peter Gutmann wrote:
> Michael StJohns <[e-mail]> writes:
>
>
>> The sample keyAgreement only CSR came in as ECDSA signed - which is both
>> pragmatic and wrong.
> It sort of makes sense though because unlike X9.42 DH keys which are marked as
> such, ECDSA keys (that is, ecPublicKey keys) are only marked as generic ECC
> keys and not ECDSA or ECDH or ECanythingelse.  So how you interpret them is up
> to the implementation, and in particular without an explicit hint via keyUsage
> you have no idea what algorithm an ECC key is actually intended to be used
> with.
Strangely, there are OIDs to mark EC keys as ec, echd and ecmqv. No one 
uses them AFAIK and I'm grateful for that after the fiasco I ran into on 
RSA keys marked for OAEP in a couple of TPM 1.2 endorsement 
certificates.     See RFC 5480, section 2.1
> Even with the hint, if there was (say) an ECElgamal and you had an ECC
> key with keyUsage = digitalSignature there'd be no way to tell whether it was
> ECDSA or ECElgamal signing.
Maybe not exactly true.  I always considered that the curve OID 
constrained the appropriate set of cryptographic functions.   For at 
least the Suite B curves. Hmm..
> In addition in order for PKCS #10 to work you have to ignore the keyUsage.  To
> see why, consider a CSR for an RSA key with keyUsage = dataEncipherment.
> Since the CSR has to be self-signed if you enforced keyUsage as written then
> the CSR would fail signature validation.  So the only way for CSR's to work in
> practice is that keyUsage is ignored.

I never actually got a response to whether or not CA's support RFC6955, 
so I'm not sure of the reality of that last statement or not.  I 
wouldn't be surprised if you're correct, or mostly correct.

That said, unless I've completely mis-read RFC6955, I can create a EC 
CSR with a keyAgreement only keyUsage and do it without using the 
proposed EC key in anything but ECDH.  It's a long-winded work around 
and mostly works the same way ECIES works, and requires the recipient of 
the CSR to have published an ECDH certificate.  It's not the more 
general "a CSR can be verified by anyone" model, but it still looks like 
a CSR.

> And that's why the de facto interpretation of ecPublicKey = ECDSA.
>
> Peter.
>
I don't know that I'll have to go down this path.. thanks for the chat! Mike