Specify how to handle ML-KEM/DSA PKCS8 keys in non-seed-only formats

[twiss]

• When importing a key in the expandedKey format, throw a NotSupportedError.
• When importing a key in the both format, optionally throw a NotSupportedError.
• Alternatively, when importing a key in the both format, require checking that the seed and expanded key match.

Address #29.

---

Preview | Diff

[panva]

I'm okay with throwing expandedKey format out the window as well as having the implementation do a consistency check for both.

When importing a key in the both format, optionally throw a NotSupportedError.

This is to the detriment of users and the spec's usability (already said so in #29 (comment), gotten no response). These keys are going to get to users. And if users cannot rely on these keys being supported they'll have to either

• implement asn1 parsers to extract the seed (which most won't)
• just slice the pkcs8 at a given index to get the seed

In both cases they'll end up using the raw-seed import format with what they extracted and miss out on checking that the seed and expanded key match which is what an actual pkcs8 import format would do for them with the consistency check.

Now given an implementation has to support expanding a seed to an expanded private key anyway in order to sign, I don't understand the reluctance.

[twiss]

Two reasons:

• Since (some) implementations are planning not to implement both, I think it's better if potential users of the API are aware of that, so that they can plan for it and implement workarounds if needed. Just by pretending in the spec that users can rely on both being implemented doesn't make it so, if implementers don't implement it.
• Even if implementers would feel compelled to implement both from the spec text, if the underlying implementation doesn't support it, they might implement it using some hack (without doing a consistency check). Of course an application might do the same, but then at least it's clear and obvious what's going on.

The proposed text makes it clear that if you implement it, you MUST do the consistency check, otherwise it's better not to implement it at all. The reverse would be worse for a web application that cares about the consistency check happening, because - if an implementation implemented the both format without doing the check - then there's no way to know if the check happened, and so the web app would need to implement it even if the browser supported it, which makes it even more useless.

[panva]

It's because the application cannot distinguish between a failure caused by an implementer not supporting both and a failure caused by both consistency check that this is problematic.

Applications are ill-equipped to perform this check on their own (especially if those very same implementers do not plan to support SHAKE which would be needed for the expansion), they will not do it when the easy way out is to take the seed ouf of pkcs8 and run with raw-seed, skipping the consistency check.
Implementers OTOH already have to support signing with an expanded private key that they calculate out of a seed, so there's no world where an implementer who supports both cannot perform a consistency check.

It is beyond any reasoning that an implementation that has asn1 parsers as well as seed-expansion at hand will not support expanding a seed (which they have to anyway) and comparing it byte for byte with the pkcs8 expanded private key. It is a disservice to the implementation's own users.