Align OIDs of Kyber and Dilithium for IETF InteropTests

[janklaussner]

Since end of last year several parties are conducting interoperability tests of the new PQC algorithms within the X.509 environment (see https://github.com/IETF-Hackathon/pqc-certificates). Since there are no official OIDs yet, the participants agreed on a temporary mapping: https://github.com/IETF-Hackathon/pqc-certificates/blob/master/docs/oid_mapping.md Botan needs the following patch for dilithium and kyber OIDs so that compatible certificates can be created or verified. align-oids-of-kyber-and-dilithium-for-ietf-interoptests.patch.txt

Also, it would be good if the planned PQC algorithm implementations would also use this mapping (SPHINCS+, Falcon...)

[reneme]

That's great! Thanks for the pointer.

From my perspective, there isn't any problem with using the proposed OIDs in future algorithms (including SPHINCS+, that is about to be merged).

Kyber and Dilithium are already released in Botan 3.0, so we will probably need to support both sets of OIDs. I would propose the following:

1. Let Botan 3.1.0 use the proposed OIDs for newly generated certificates
2. Keep mapping the currently used private OIDs to Kyber and Dilithium for backward compatibility

@randombit I'm assuming that breaking the OID mappings entirely between released versions isn't desirable.

[randombit]

@reneme Your proposal seems generally fine. We would not want to break the OID mappings, but we already have a mechanism to accept multiple OIDs when decoding, with a single canonical OID used for encoding (this is used for instance for RSA keys which were assigned both 1.2.840.113549.1.1.1 and 2.5.8.1.1).

Only concern here is that we use the same OID also when encoding public keys and private keys. Currently our encoding is the simple, obvious, sane encoding (a single OCTET STRING containing the bytestring that is equal to how Kyber reference implementation encodes keys) but that may not match other implementations.

[randombit]

@janklaussner Can you provide any reference or hints about how these other implementations encode public and private keys for these schemes?

[janklaussner]

@randombit I have no closer insight into the impementations yet. At least Dilithium keys seemed to be compatible once the OIDs matched, I tested this. You can check samples if you look for the artifacts.zip files in the repo, e.g. https://github.com/IETF-Hackathon/pqc-certificates/blob/master/providers/bc/java-artifacts/artifacts.zip for Bouncycastle. There are certificate chains for all supported algorithms with encoded Public Keys and their private counterparts. Does this help?

[randombit]

@janklaussner Thanks - if the public keys were accepted that seems a good sign that everyone is converging on the same idea wrt encoding the keys, and with luck that will carry over into the private keys as well. I'll take a look at these artifacts, hopefully that gives some insights into where things are headed.