[feature request] importing SPKI from X.509 Certificates

[panva]

I wish Web Crypto API could deal with importing the SPKI from X.509 Certificates.

This could either be an extension to the existing SPKI import steps tied to the spki KeyFormat, or a totally new import-only step x509 KeyFormat.

The import format steps for x509 are simple, extract the SPKI out of the passed in X.509 BufferSource and call importKey with spki as the format.

Reason is simple, dealing with X.509 for the simple purpose of validating signatures requires a lot of brittle javascript to get right and the Web Crypto API runtimes already have the ability to deal with X.509, it should not be a big deal and would simplify developer's job a lot.

[twiss]

Hey 👋

The import format steps for x509 are simple, extract the SPKI out of the passed in X.509 BufferSource and call importKey with spki as the format.

I'm not sure this is what people would expect from importing an X.509 certificate. Those have a validity period, a subject, an issuer, etc. When verifying a signature with an expired certificate, shouldn't the signature fail to verify? If not, then why use X.509 rather than SPKI?

To be perfectly honest, I don't think pulling in the complexity of X.509 is worth it, especially if it's purely for extracting the SPKI key. It's true that Web Crypto was born from the idea of exposing the capabilities from TLS to JS, but I would prefer to focus on providing a generic cryptography API that's useful for many web apps. X.509 is very specific to TLS, and if you care about it, I think you probably need an X.509 parser anyway.

[panva]

Those have a validity period, a subject, an issuer, etc. When verifying a signature with an expired certificate, shouldn't the signature fail to verify?

Is the signature a produce of those certificate properties? No. When importing SPKI from an X509 container I don't expect the container's properties to matter.

If not, then why use X.509 rather than SPKI?

Question that's best aimed at service providers who keep on using x509 to wrap around spki. My request is coming from the other side, the consumers, relying parties, who are forced to consume these services. They are the ones that need to pull in either heavy or fragile x509 parsers to their js bundles. And they don't have a say/choice in the matter.

X.509 is very specific to TLS

If only that was universally true.

and if you care about it, I think you probably need an X.509 parser anyway

I don't, i only ask the spki out of it. Which is I think could be bolted on the spki format rather than a new x509 one.

In this case, I think it's great we have a distinct subtle warning because it allows us to do this to be of help to developers who are stuck between not needing or caring about x509 but having the need to verify signatures using the spki within.

[twiss]

Yeah, I'm not doubting that you have a use case for this. I'm just questioning whether it's the same as what others would expect from this API. Imagine that there is someone who does want to validate the certificate properties before using it. Then, if we add this API, they are stuck between the easy, fast option of importing it into Web Crypto without validation, and the (relatively) difficult, slow option of using an x509 library for full validation. I don't want to put them in that position.

There are some existing instances of this, where using Web Crypto is not the most secure option (e.g. for password hashing, where it only provides PBKDF2) but those are things I'd like to fix. IMO, the "subtle" qualifier should merely mean that it might be tricky to use correctly and securely, not that the most secure option is not to use Web Crypto at all.

[panva]

I'm just questioning whether it's the same as what others would expect from this API.

Are you saying that if the KeyFormat remains spki but it would allow X.509 to be passed in that the expectation would be different than the one explained?

[twiss]

I'm not sure, but the concern from the rest of that paragraph remains, even in that case, I think.

There's also a more practical concern which is that the charter calls for maintenance of the spec by adoption of proposals from incubation, and it's not really clear how to make a separate spec for this, I think (and personally I don't think it's likely to be worth the effort, but obviously you probably disagree on that point 😊).