Supported PKCS8 import formats for ML-KEM and ML-DSA

[twiss]

The PKCS8 formats for ML-KEM and ML-DSA (defined in draft-ietf-lamps-kyber-certificates and draft-ietf-lamps-dilithium-certificates, respectively) define a CHOICE of three formats: seed, expandedKey, and both.

We should decide which of those formats should be supported when importing keys.

If we allow the expandedKey format, we run into an issue when later exporting the key, because we need the seed for that (regardless of whether the requested format is raw-seed, jwk or pcks8, since we specify that exported PKCS8 keys should be in seed-only format).

If we allow the both format, the implementation should perform a consistency check, as per section 8 and 8.2 of the respective drafts.

Allowing only the seed format may be simplest for implementations, but may pose difficulties for applications who can't choose the format of keys they receive.

It would be useful to know what most implementations of these drafts support, to inform this decision.

[panva]

It would be useful to know what most implementations of these drafts support, to inform this decision.

Node.js implemented pkcs8 import of all recognized CHOICEs. Naturally the implementation results in an OperationError when private-only imported key is attempted to be exported as per the current spec language. seed-only and both are essential to support. Supporting private-only was not an issue to implement.

[davidben]

The general consensus at IETF is that private keys should be seeds. The expandedKey form was added at the last minute due to some legacy hardware, which shouldn't matter in this context. The both form is just technically unsound as you can always compute the expandedKey half from the seed half. It just adds risks, since an implementation may look at one side and not the other.

I'm still working on BoringSSL's implementation, but the current plan is to only implement the seed format.

[panva]

The default PKCS8 format of OpenSSL, which is used by a not-insignificant amount of tooling and languages, is both. Supporting only seed-only is a hurdle for developers and in so users of this API as they will be given keys in the both form.

[davidben]

OpenSSL can be configured to use the correct format with ml-dsa.output_formats.

The both format is dangerous. It was added to allow for implementations that only look at one half of the key, without checking consistency, but this approach is simply unsound. The problem is if component A of your system looks at the seed and component B look at the expanded form, they will act inconsistently and you'll break invariants of your system. (E.g. imagine if one component is the customer private key import pipeline of a hosting service and another component is the serving frontends, which assume the import pipeline has validated the config.)

It is truly unfortunate the spec ended in a mess, but here we are.

[panva]

So we shall allow both and require the implementation to perform a consistency check. That's still well within the parameters of the spec and aligned with what user's keys might very well be.

[davidben]

That's not what we plan to implement. See above.

[panva]

That's not surprising but still rather shortsighted. Your implementation already needs to have the means to expand the seed to a private key and so the means to do a consistency check. Userland doesn't. Since these pkcs8 keys are fixed length the result is that users will just subarray the seed from a both pkcs8 and pass it to raw-seed import. So because Chrome is resisting to implement an import that recognizes both users will become susceptible to the issues you're imagining, skipping a consistency check they could otherwise be getting from WebCrypto.