Remove support for importing RSA and ECC keys with alternative OIDs #325
Conversation
…OIDs The sha1WithRSAEncryption, sha256WithRSAEncryption, sha384WithRSAEncryption and sha512WithRSAEncryption OIDs are not widely supported and rarely checked against the passed hash algorithm specifier. So, we require using the rsaEncryption OID instead.
Require using the rsaEncryption OID instead.
Require using the rsaEncryption OID instead.
Require using the id-ecPublicKey OID instead.
|
I've recently aligned both the Deno and Node implementations with this very proposal. |
Don't refer to object identifiers which are no longer used, and note that JWK can be used to bind a key to a specific algorithm and hash.
twiss
force-pushed
the
remove-alt-oid-import
branch
from
1ced974
to
b5e6d2e
Compare
|
Just want to call out that |
Can you point to the concrete requirements that lead to pkcs#8 or spki import of id-rsassa-pss oid keys? |
Is there something you are specifically looking for? Throughout the Privacy Pass Issuance Protocol spec (which the Private Access Tokens depends) it describes the concrete requirement to use id-rsassa-pss oids. Specifically, it is needed to verify a token. While the spec does not depend specifically on webcrypto, it is a web interop issue. For example, if you use safari you can test Private-Access-Tokens. However, because of the browser deficiency, you can't actually test the RSASSA-PSS-VERIFY(). Firefox fortunately supports this oid and so you can copy the token and verify in firefox's implementation of cebcrypto. |
|
If I'm reading this right (a very cursory read, apologies, i will follow up in depth tho because this is on my agenda) the only need for rsassa-pss oid SPKI is so that the If a different token key id scheme was to be used, e.g. similar to rfc7638 but including the rsa-pss parameters (which i think is the only reason to have the id calculated over the spki of rsa-pss oid key?) then webcrypto interop would be dealt with. It would be great if this new work utilized what's generally available and not what has been an interop nightmare for many years now. What I mean is that out of all the webcrypto implementations I am aware of (chromium, firefox, safari, node.js, deno, bun, CF Workers/workerd, @peculiar/webcrypto, Vercel's Edge Runtime) only
The rest out right doesn't support it. And so, depending on a key oid that won't be accepted by most (and its parameters ignored by the ones that will), is a questionable choice. In reality then, use of this oid will force web developers to deal with spki rather than jwk (which is interoperable already) by having to parse it outside of webcrypto using an asn1 parser (a big fragile pain point to begin with) to get the modulus, exponent, and parameters and then import it as a PS256/PS384/PS512 JWK anyway so that they can validate a signature. |
|
Hi @colinbendell, thanks for raising this. However, it's not obvious to me what the best course of action would be, if we wanted to address this in earnest. These OIDs have been specified in Web Crypto for many years, and almost nobody implemented them. That suggests a lack of interest on the side of implementers. To address this, someone would need to write tests for importing and exporting keys using this OID, and advocate or even volunteer for implementing it. The latter might also not be simple, since it needs to be done in the crypto libraries, and it also adds extra complexity to re-serializing keys (see #307 (comment)). Are you planning or willing to work on this, or do you know who would be? |
For the verification process - correct. the For the other roles (client to issuer, issuer to client), it depends on blinded signatures. I'm not sure which parts of this spec are unique to id-RSASSA-PSS though.
Thanks for this tip! Given this, I found a nice hack to repack the modulus without needing to do asn parsing that enables verification with webcrypto. It is certainly an unfortunate hack. |
I'm not here to tell you what to do, but I would advise against relying on this, as even under the current spec text of the Web Crypto API (as well as with this PR merged), implementations are required to reject such a key. If you're going to monkey-patch the key to make Web Crypto accept it, it would be better to change the OID to rsaEncryption as well, such that it's a valid SPKI key. Then, it will be accepted by all implementations of Web Crypto, and even still be valid after this PR is merged :) |
Yea, that's exactly what I'm doing. Change the oid, set the lengths correctly. It's a valid key in the end. Functionally, using the b64 encoded der you can: |
The specification currently specifies a number of "alternative" OIDs for importing SPKI and PKCS8 keys that indicate the specific algorithm and hash to be used with the key. However, these OIDs are not widely supported, and if they are, the parameters are usually not checked, and instead the key is usually allowed to be imported and used with the wrong algorithm or hash. So, we drop support for these alternative OIDs, simplifying the spec and matching most implementations. The only implementation that seems to have implemented much (but not all) of this is Deno. So, @lucacasonato, are you OK with removing this? Cc @panva, as well.
Instead, JWK can be used to specify the concrete algorithm and parameters, if required.
For more background, see #307.
Preview | Diff