Multiple algorithms in a certificate (not hybrid)

[iyanmv]

Hi,

In this IETF draft, later standardized by ITU-T (section 7.2.2 of their X.509 (10/2019) document), it is mentioned how to use subjectAltPublicKeyInfo, altSignatureAlgorithm and altSignatureValue to include two algorithms in a single certificate.

The idea is not to increase security but to facilitate a PQC migration since the extension is marked as non-critical. Clients that can validate PQC signatures would do that, clients that do not support PQC algs (or legacy systems that are not even aware of this extension) would fallback to the classical signature.

Any idea if it is possible to test this using the OQS provider for OpenSSL 3 or the OpenSSL 1.1 fork? If it is currently not possible, someone familiar with X.509 extensions can point me in the right direction to implement this?

Thanks!

[iyanmv]

DigiCert seems to be testing this extension here. Unfortunately, I don't think their PQC toolkit is freely available.

[baentsch]

Any idea if it is possible to test this using the OQS provider for OpenSSL 3 or the OpenSSL 1.1 fork?

The simple answer to this question is "No".

The more complete answer: Those are the "Isara Catalyst" composite certificates: Originally patent-protected and hence not implemented in open source code then. By now Isara seems to have released their legal grip on this approach (otherwise wouldn't have been accepted at ITU, maybe), but I personally wasn't interested in wading into this legal morass which is why we didn't look into this deeper.

Technically, I also think this is rather a question to the OpenSSL upstream code base: Either how to facilitate use of these extensions from within a provider OR how to use the encoding logic of a provider when adding extensions to a certificate by way of standard OpenSSL APIs.

Lastly, have you looked this this alternative for composite certificates? This seems to be implementable in a provider (statement by Entrust -- who also indicated interest to contribute this to the open source community).

[iyanmv]

Thank you for the detailed answer. I was not aware of the issue with the patent. Regarding the alternative you mentioned, I haven't read it in detail yet, but I think it is a different approach because it is about combining different algorithms into single objects, rather than having alternative (and optional) ones. The advantage of the original draft I looked is that backwards compatibility is straightforward, while in this other approach is not so clear to me, and I think they don't even fully address the issue in the draft.

[baentsch]

The advantage of the original draft I looked is that backwards compatibility is straightforward

Completely agree. That's why I (and many other folks) were so irate about Isara patenting something obvious(ly straightforward). On the implementation side in my assessment it does require logic changes in OpenSSL. It may be worth while creating an OpenSSL question about this to see whether I'm right. If not, I'd gladly assist in implementing this via oqsprovider now that the patent issue is resolved: This draft does solve a problem. But then again, there's got to be a reason why this Draft did not get updated at IETF -- and if changes at OpenSSL are required, not having this at least in active Draft state at IETF makes this a non-starter, I'd think -- and rightly so.

[iyanmv]

Alright, let me write the people involved in the original draft to learn more about this. And then I will open another discussion in the OpenSSL project.

[iyanmv]

By the way, I found this email in the IETF mail list:
https://mailarchive.ietf.org/arch/msg/spasm/KNFpie80z_T3Tqes91AniUVCnUk/

At the Hackathon at IETF 116 this March, several participants implemented the "Hybrid Catalyst" certificate extension processing initially documented in [https://datatracker.ietf.org/doc/html/draft-truskovsky-lamps-pq-hybrid-x509-01 and later standardized in ITU-T X.509 10/2019.

[iyanmv]

Just in case someone else arrives at this discussion at some point later. I wrote an email to the IETF lamps mail list that you can read here: https://mailarchive.ietf.org/arch/msg/spasm/ZDrD6KA1IxDM2CRCruljIn_woQs/

And I got two interesting answers. From DigiCert, Tim Hollebeek mentioned that while trying to implement this they found some downsides. So probably it's not worthy trying to implement this. And from Entrust, John Gray pointed out a draft about "Chameleon Certificates", which (at least from reading the introduction) seems to focus on the transition to problem and backwards compatibility.