Re: In-the-wild implementations of RFC6955?

Michael StJohns <[email protected]> writes:

>I had gotten a request to help one of my contracts understand how to
>implement support for various forms of PKCS10 CSRs, including one with only
>keyAgreement as a proposed keyUsage extension and was a bit surprised as I'd
>never seen such a beast.

I'm not, see the comments about X9.42 DH certs.  In about 2000 I had a
conversation with a rather earnest Israeli gentleman whose company had somehow
managed to figure out how to do something with X9.42 certs and was
flabbergasted that nothing actually implemented them: "But it's a MUST in the
RFC!".  That predated Pirates of the Caribbean so I didn't have the "more what
you'd call 'guidelines' than actual rules" quote handy for use.

>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.  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.

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.

And that's why the de facto interpretation of ecPublicKey = ECDSA.

Peter.