Add Support for Composite KEM in PKCS11v3.3

[johngray-dev]

Composite KEM is a hybrid KEM format that combines a classical algorithm like RSA-OAEP or ECDH with ML-KEM. They are specified in IETF draft https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-kem/07/

Composite KEM is currently working on getting through a Working Group Last Call process, at which point the drafts will be stable and waiting to be published. The authors believe that should happen by year end. In the meantime we can work out how they can be represented in PKCS11v3.3

[relyea]

I don't think we need to worrky about Composite KEM in PKCS #11 because you don't need PKCS #11 mechanisms to implement them. We already implement Composite KEMs in both IPSEC and TLS using the existing primatives. The one exception might be if S/MIME uses composite KEMs in certificates. Even then, the only real knot is if the composite keys are encoded in PKCS #12 as wrapped PKCS #8 objects combined. (The same case we worry about in Composite signatures). Is that the case we are targetting here John?

[johngray-dev]

I think I see what you are saying, and I agree it is possible to use components which are provided by the HSM to implement composite KEM, but that would end up being a hybrid software/HSM combination. There are essentially 2 ways to implement composite KEM

1. A software controlled implementation that uses black-box implementations of the KEM algorithms (ML-KEM, RSA-OAEP, and ECDH-KEM). The black box pieces could be on an HSM or elsewhere and could be implemented with ML-KEM and parts of RSA and ECDH that are already available in PKCS#11 3.2. However, the critical security component (the KEM combiner) is not currently in the HSM. That shouldn't be left up to implementers, it should be handled by the crypto library (which in this case would be the HSM).
2. A single atomic KEM algorithm which provides a single ObjectID for X509Certificates (or a single Mechanism in the case of PKCS#11) representing the composite KEM (one for each combination). The IETF draft that is about to be standardized is in this direction, and it make use of the composite KEM much simpler as it just drops into any existing implementation. The API is still the standard KEM API, but the complexity of the composite KEM combiner is done in the HSM. The private keys are bound together as are the public key. On the surface it just looks like a regular KEM algorithm.

A Composite KEM should be treated as an atomic KEM algorithm just like pure ML-KEM. IPSEC and TLS do not currently implement composite KEM, they implement a type of hybrid that pulls components from multiple places and it is not cryptographically compatible with composite KEM. We will definitely need to support this in structures like CMS and S/MIME (the CMS composite KEM draft will be published shortly after the main composite KEM draft).

[relyea]

Actually I think this is NOT the preferred way to implement composite KEM. The issue is 3-fold.

1. tokens need to implement the pure implementation anyway, you are greatly increasing the complexity in the token.
2. libraries need to handle composites when those algorithms anyway.
3. we are generating an N-squared problems were you need to implement N-squared composite kem where N is the base number of kems you need to implement.
4. every protocol has (because of their needs) implemented the actual composite kem as different protocols. IPSEC and TLS do not implement the composite kems the same way. Their protocols preclude using the same formulation. Now you have a k*N-squared problem where k is the number of protocols you support.

There are only 2 forcing functions for doing this in the token: 1) unwrapping composite KEM keys. and 2) if validations require everything to be in the token (not just the keys). I think we definitely need to handle case one if composite KEMS are defined in ietf, so we at least need an unwrap function the returns two keys in the composite KEM case. The second is highly unlikely as NIST is very much anti-hybrid solutions. So my priority would be to have the composite KEM unwrap case defined. The falacy that we are just going to push this into the token an everything magically works is just that a falacy. Where the combined operation is in the token or not, NSS does need to know about these keys and key types. There is always small semantic difference in the various signatures. Now, NSS is mostly capable of isolating this from applications, I think openSSL is as well, so the layer we need to implement these things in the security library, not the hardware devices. (The libraries also have faster release and update cycles compared to hardware, which, again, is part of the reason you want the minimal load on hardware vendors compared to libraries).

That being said, as long as I have a way to unwrap composite KEM keys into two keys, I'm good and if others really think we need to define composite KEM actual KEM mechanisms, I'm fine with that. NSS just doesn't need or use them.