Expand scope to include CMP

[johngray-dev]

• Add support for CMP in the repo

• Needs .zip file format update to include folders

• output matrix needs to be updates

[dghgit]

This is a suggestion for naming as well as an example, but armed with the new CMS draft, and feeling inspired by an email message earlier in the day, here's a sample using Dilithium for the CA and NTRU for the KEM. Since I'm well and truly out of the suggested OID list, the NTRU key is using ntruhps2048509 as its parameters.

kem_cmp.zip

The files are:

kem_cmp/dil_ca_cert.pem - Dilithium CA
kem_cmp/ntru_cert.pem - the NTRU certificate
kem_cmp/ntru_priv.pem - the NTRU private key
kem_cmp/cmp_cert_conf.pem - the client CMP certificate confirmation message containing a hash of the NTRU certificate
kem_cmp/cmp_init_rep.pem - the CA CMP reply message containing the encrypted NTRU certificate
kem_cmp/cmp_init_req.pem - the client CMP request message containing the NTRU public key and marked as POP encrCert

The CMP messages are PKIMessage type. The client messages use a MAC for protection, the sender MAC password is "secret", the CA message is using a signature. In the normal course of events there would be an acknowledgement message from the CA at the end to finish the transaction which I've left out (the PKIConfirmContent message). If it should be, or is, included I'd suggest calling that one cmp_pki_conf

Any comments or feedback on the files, please let me know. Thanks.

[ralienpp]

@dghgit , is it possible to share the code that produced these outputs?

I'd like to propose an adjustment to the structure of this repository, to bring order to CMP-related stuff. It might be something like this:

• add a cmp directory to the root
• cmp/readme.md with a list of included artifacts and compatibility matrix (instead of the general one used right now, because CMP has a lot of features and this will probably produce a lot of clutter and get in the way of people whose focus is not on CMP)
• a cmp/providers subdirectory for storing the files themselves
• the file names would specify what's in them, e.g. ir or cr request type

I could prepare a draft for the upcoming IETF hackathon, so it could serve as a starting point for some on-site cooperation. I volunteer to curate this section of the repository and seed it with some data. My plan is to put together a prototype with OpenSSL+OpenQuantumSafe, and BouncyCastle - we could test if they can consume each other's outputs.

[dghgit]

@ralienpp They're from the testNTRURequestWithDilithiumCA() method in:

https://github.com/bcgit/bc-java/blob/master/pkix/src/test/java/org/bouncycastle/cert/cmp/test/PQCTest.java

I'll try and put together a specific example to run and post it here as well. You'll need the latest version of Bouncy Castle on https://www.bouncycastle.org/betas to support it. If it's of any interest we've also added some support for this to the bc-kotlin project.

Proposed structure sounds okay with me.

[dghgit]

Here's an update which includes the latest changes in CMS. It's generated by the same code as the previous example but has the correct RecipientInfo type and I've attempted to follow the file name extensions suggested above (assuming I've understood correctly), so the CMP messages are now BER encoded with the suffix (ir, ip, certConf) reflecting the message type. The latest beta on https://www.bouncycastle.org/betas now includes the changes as well. I've left the output statements in the PQCTest in place but commented out so it should be easy to generate.

ntru_dil_cmp.zip

[ralienpp]

There is a pull request where BouncyCastle's CMP features are leveraged: #36

In case anyone is interested, have a look.

[johngray-dev]

Action: Michael and Alexander to discuss possibly putting CMP test server in the cloud. In some cloud somewhere on some venders service... :)

[dghgit]

Here's a CMP/certificate for BIKE 128.

We're currently using the following OIDs for BIKE:

bike128 1.3.6.1.4.1.22554.5.8.1
bike192 1.3.6.1.4.1.22554.5.8.2
bike256 1.3.6.1.4.1.22554.5.8.3

The key is stored a string of octets (so the usual OCTET STRING, but with the value octets mapped to the BIT STRING in the SubjectPublicKeyInfo).

bike_dil_cmp.zip

[dghgit]

Here's a CMP/certificate for HQC 128

We're currently using the following OIDs for HQC:

hqc128 1.3.6.1.4.1.22554.5.9.1
hqc192 1.3.6.1.4.1.22554.5.9.2
hqc256 1.3.6.1.4.1.22554.5.9.3

The key is stored a string of octets (so the usual OCTET STRING, but with the value octets mapped to the BIT STRING in the SubjectPublicKeyInfo).

hqc_dil_cmp.zip

[dghgit]

Last but not least, CMP/certificate for Classic McEliece 348864.

We're currently using the following OIDs for Classic McEliece:

mceliece348864 1.3.6.1.4.1.22554.5.1.1
mceliece460896 1.3.6.1.4.1.22554.5.1.3
mceliece6688128 1.3.6.1.4.1.22554.5.1.5
mceliece6960119 1.3.6.1.4.1.22554.5.1.7
mceliece8192128 1.3.6.1.4.1.22554.5.1.9

The public key is stored a string of octets (so the usual OCTET STRING, but with the value octets mapped to the BIT STRING in the SubjectPublicKeyInfo).

cmce_dil_cmp.zip

[dghgit]

Latest sample of mlkem/mldsa CMP

mlkem_cms.zip

[johngray-dev]

Changed the label to this one to Help wanted. I see there has been some testing between David and Alex, but is there some information we should add to the main readme about how to go about submitting CMP artifacts?