Expand scope to include CMP

johngray-dev commented 1 year ago

Add support for CMP in the repo
Needs .zip file format update to include folders
output matrix needs to be updates

dghgit commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

There is a pull request where BouncyCastle's CMP features are leveraged: https://github.com/IETF-Hackathon/pqc-certificates/pull/36

In case anyone is interested, have a look.

johngray-dev commented 1 year ago

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

dghgit commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

IETF-Hackathon / pqc-certificates

Expand scope to include CMP #25