Code point interoperability

[christianpaquin]

The current 1.1.1 branch breaks interoperability with the previous tagged release due to different assignment of the code points for the PQ KEM algs. Up to the integration of templating code, the code points (used in TLS to specify the selected "curve") were assigned manually and care was taken to keep previously defined values the same, to ensure that client/server remained interoperable between versions or implementations (e.g., openssl and boringssl). Templating simplifies the integration of new algs, but overwrites previous code point values. This means that, in the future, any changes of the OQS supported list of algs will result in different code point values.

We should design a mechanism to assign specific code points to an algorithm, both if this is specified in a standard, or to preserve interop between releases. We support this already for signature OIDs.

If we break compatibility in this release, we should document that and bump the release version number accordingly.

[dstebila]

@xvzcf with the templating approach, is it possible to specify the code points in the configuration file so that they can be kept consistent?

[xvzcf]

Not at the moment, but the modifications to do so should be easy enough.

[dstebila]

@xvzcf It seems like something we should do -- code point compatibility for, at least, KAT compatible algorithms.

@christianpaquin We haven't formally been numbering our OpenSSL releases, just calling them "OQS-OpenSSL 1.1.1 YYYY-MM snapshot release", so we don't have a semantic numbering system implying compatibility. Should we?

[christianpaquin]

I guess it would be confusing to add a second layer of versioning on top of OpenSSL's. The snapshot release id is ok if we keep compatibility intact.

[christianpaquin]

The ability to specify code points in config will become increasingly valuable as these algorithms start appearing in standards.

[xvzcf]

In short:

1) KEM NID's (and therefore CurveID's) already have to be manually specified in the generate.yml file, so no additional work is needed there.

2) The templating code assigns signature OIDs as described here under the "Adding an authentication algorithm" section. Adding (or re-ordering) hybrid variants will affect inter-operability, and so additional work is needed here.

[dstebila]

Can you check which curve IDs are different between the current version and previous releases of OQS-OpenSSL-1.1.1? If there are differences we should decide whether to make them align, or whether to acknowledge that in the release notes, but plan to keep alignment going forward.

[xvzcf]

From examining ssl_locl.h at the 1.1.1c tag (before templating was added) and at the 1.1.1d tag (after templating was added), at the very least, all the post-quantum only schemes and variants except for KEM_DEFAULT have differing curve IDs.

[dstebila]

From examining ssl_locl.h at the 1.1.1c tag (before templating was added) and at the 1.1.1d tag (after templating was added), at the very least, all the post-quantum only schemes and variants except for KEM_DEFAULT have differing curve IDs.

Thanks. It doesn't seem like it would be difficult for us to keep the curve IDs consistent, the only annoyance I can think of is that we might have some gaps since we've dropped some algorithms.

[xvzcf]

It shouldn't be difficult at all since we do specify every single curve ID in the generate.yml file.

[xvzcf]

This PR addresses signature OID consistency.

[dstebila]

Fixed by #120.