johngray-dev
commented
4 months ago Thank you for pointing out this issue, you are correct and we will correct this issue in the next version of the draft. We have been working on PQ interoperability with the IETF and have a github repo of artifiacts (some which are composite). Composite has undergone a number of version changes, so some of the composite artifacts may be older (and not work with the latest version). We would love it if you could post some of your produced keys and certificate samples for composite to this repository so other implementations could be tested with your implementation. Our repository is here: https://github.com/IETF-Hackathon/pqc-certificates.
Honzaik
Hello, I tried to implement composite signatures into BouncyCastle (https://github.com/bcgit/bc-java/pull/1546) according to the draft specification https://www.ietf.org/archive/id/draft-ounsworth-pq-composite-sigs-11.html. However, when I try to test compatibility with provided samples in Appendix A, I come across a few inconsistencies.
Let me preface this that I am a beginner to the topic of ASN.1 and this was my first attempt to implement something according to a X.509/ASN.1-related specification, so it most likely is a misunderstanding on my part but I guess at least I will learn something.
Public key format
From what I can tell, the sample public key for MLDSA44-ECDSA-P256-SHA256 is a SubjectPublicKeyInfo where the subjectPublicKey decodes into a SEQUENCE of 2 OCTET STRINGs but from Section 3.2 I understand that it should be a SEQUENCE of 2 BIT STRINGs.
See provided examples (decoded using https://lapo.it/asn1js):
Sample from RFC
My generated sample
Private key format
The provided private key for MLDSA44-ECDSA-P256-SHA256 is a PrivateKeyInfo where the privateKey decodes into a SEQUENCE of 2 OCTET STRINGs where the 1st string (Dilithium) doesn't seem to decode into anything (not really important as Dilithium formats are still experimental), and the 2nd string (ECDSA) decodes into what seems to be ECPrivateKey (https://datatracker.ietf.org/doc/html/rfc5915).
However, Section 3.3 states that privateKey should be a SEQUENCE of 2 OneAsymmetricKey (aka PrivateKeyInfo).
See provided examples:
Sample from RFC
My generated sample
Certificate format and signature validity
As a consequence of the issue with the public key format, the included certificate contains SubjectPublicKeyInfo with two OCTET STRINGs (instead of BIT STRINGs).
The more important issue is that even when I modified my implementation to parse the OCTET STRING public keys, the signature does not validate in both components. The Dilithium signature not validating can be explained by experimental implementation differences (your library vs BC's implementation), however, the ECDSA signature is also invalid.
I am not sure if that is an issue with my implementation (the main logic is here https://github.com/Honzaik/bc-java/blob/main/prov/src/main/java/org/bouncycastle/jcajce/provider/asymmetric/compositesignatures/SignatureSpi.java#L223) or the provided sample. I provide my self signed certificate sample below.
I'd be happy if someone could clear this up for me. Thank you