Expand scope to include the ISARA Catalyst (Certificate extensions format)

[johngray-dev]

This is the certificate format which uses X.509 V3 Extensions for the following

• Alternate Signature Value

• Alternate public Key

• Expired IETF Draft: https://datatracker.ietf.org/doc/html/draft-truskovsky-lamps-pq-hybrid-x509-00

[baentsch]

Can I ask for a reason to follow an RFC draft expired more than 4 years ago? Also, when googling the name Isara Catalyst, a (TM) symbol comes up very prominently: Is this approach somehow protected by trademarks and/or patents?

[johngray-dev]

Isara released the Patent back at the end of October 2022. That is why this has come up on the radar again.
https://www.isara.com/company/newsroom/isara-dedicates-four-hybrid-certificate-patents-to-the-public.html

I agree, maybe it is premature for us to pick it up. There was interest from a number of people on the NIST NCCoE interoperability group, and some other members of the hackathon team. This probably means this IETF draft (or another one) should be picked up and updated. We could wait until IETF 116 to do that, or volunteer to pick this up if we think it is valuable.

[baentsch]

Isara released the Patent back at the end of October 2022.

That is positive indeed. I wonder then why the RFC has not been updated and (re)activated as a baseline for everyone to use? Is the RFC the basis for the implementation by Felipe (please add his github handle)? Would be really glad to see this in the open then (and see it used to provide "OQS" data as per this issue). Thanks for the pointer.

[johngray-dev]

Felipe is working on the composite implementation. We are getting close to posting an updated draft on that one.
https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-keys/

I'm updating the signatures one (a -08 version): Yes, I know it is expired, we have a bunch of updates for explicit. Should be posted next week I'm hoping.
https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-sigs/

This draft: https://datatracker.ietf.org/doc/html/draft-truskovsky-lamps-pq-hybrid-x509-00 uses certificate extensions to contain the PQ keys. It is not a new Signature Algorithm format (like Composite Signatures), it is a set of new X509V3Extensions.

[CBonnell]

The "hybrid" certificate approach has been added to version 2019-10 of X.509 already: https://www.itu.int/rec/T-REC-X.509-201910-I. The extension syntax and processing for signing and signature validation appear to closely mirror that of the Truskovsky draft.

[baentsch]

Thanks for explicitly posting the two RFCs side-by-side. My mistake to confuse "hybrid" and "composite": Both do seem to address the same goal for certs: Enable running PQ & classic signature algorithms "in parallel". Adding this RFC for further clarity on terminology: https://datatracker.ietf.org/doc/html/draft-driscoll-pqt-hybrid-terminology-01

Would it be a fair summary to state then that

• "hybrid"/"truskovsky" certs can contain "dormant" Cryptographic Elements that may be disregarded by software that does not know about them (or has been configured to do so) while "composite" certs simply will never work with software packages written before/unaware of the "ounsworth" RFC?
• "ounsworth" allows retaining all pre-existing X.509 logic (just adding many new OIDs) while "truskovsky" requires updates to it
• "ounsworth" is more generic while "truskovsky" only addresses PQ/T certificates.

Corrections to the above and pointers to more accurate/thorough comparisons of the two approaches very welcome.

[dghgit]

I think both approaches are not without features.

One other side of the X.509 extensions is the key can also be an encryption key (I don't know what anyone else's experiences are in this regard but we seem to have more than a few users who are trying to manage signing/encryption with a single certificate, I won't comment on how some of them are currently going about it...). The useful thing with the original "truskovsky" draft is that it also addresses certification requests, so I think a new draft which added the new X.509 OIDs and included dealing with things like PKCS#10 for signing only certificates would be useful to have.

If it's any interest, I've generated same sample certificates based on the Section X.509 9.8. One's for EdDSA and Dilithium2, the second is for Dilithium2 and Kyber (in both cases the second algorithm is the one specified in the subjectAltPublicKeyInfoExtension).

Sample files attached, I'd appreciate any comments/feedback on either of them.

dual_certs.zip