Hybrid X509 Certificates - Clarification on the produced content

[dimhatzi]

Dear all,
I would kindly requesting your valuable feedback related to the creation of hybrid certificates for digital signatures.
More specifically, by reading the information related to the Section of the Supported Algorithms for Authentication, I read the following:

"if SIG claims NIST L1 or L2 security, then the fork provides the methods rsa3072_SIG and p256_SIG, which combine SIG with RSA3072 and with ECDSA using NIST's P256 curve respectively."

Is there any way to seek more information how this actually works and what the word "combine" means? Is it about a serial concatenation of the public keys and the signature values, is it a kind of encapsulation or anything else?

I really appreciate your time and valuable feedback.

Kind regards

[baentsch]

Is there any way to seek more information how this actually works and what the word "combine" means?

It's concatenation. Depending on your preferences, you may want to read either a paper: https://s3.amazonaws.com/files.douglas.stebila.ca/files/research/papers/NISTPQC-CroPaqSte19.pdf or the code, e.g.

openssl/crypto/ec/oqs_meth.c

Lines 990 to 1049 in 38e12f1

	static int oqs_key_print(BIO *bp, const EVP_PKEY *pkey, int indent,
	ASN1_PCTX *ctx, oqs_key_type_t keytype)
	{
	const OQS_KEY *oqs_key = (OQS_KEY*) pkey->pkey.ptr;
	int is_hybrid = is_oqs_hybrid_alg(oqs_key->nid);
	/* alg name to print, just keep the oqs part for hybrid */
	const char *nm = OBJ_nid2ln(is_hybrid ? get_oqs_nid(oqs_key->nid) : pkey->ameth->pkey_id);
	int classical_id;
	if (is_hybrid) {
	classical_id = get_classical_nid(oqs_key->nid);
	}
	if (keytype == KEY_TYPE_PRIVATE) {
	if (oqs_key == NULL || oqs_key->privkey == NULL) {
	if (BIO_printf(bp, "%*s<INVALID PRIVATE KEY>\n", indent, "") <= 0)
	return 0;
	return 1;
	}
	if (is_hybrid) {
	/* print classical private key */
	if (is_EC_nid(classical_id)) {
	eckey_asn1_meth.priv_print(bp, oqs_key->classical_pkey, indent, ctx);
	} else if (classical_id == EVP_PKEY_RSA) {
	rsa_asn1_meths[0].priv_print(bp, oqs_key->classical_pkey, indent, ctx);
	}
	}
	if (BIO_printf(bp, "%*s%s Private-Key:\n", indent, "", nm) <= 0)
	return 0;
	if (BIO_printf(bp, "%*spriv:\n", indent, "") <= 0)
	return 0;
	if (ASN1_buf_print(bp, oqs_key->privkey, oqs_key->s->length_secret_key,
	indent + 4) == 0)
	return 0;
	} else {
	if (oqs_key == NULL) {
	if (BIO_printf(bp, "%*s<INVALID PUBLIC KEY>\n", indent, "") <= 0)
	return 0;
	return 1;
	}
	if (is_hybrid) {
	/* print classical public key */
	if (is_EC_nid(classical_id)) {
	eckey_asn1_meth.pub_print(bp, oqs_key->classical_pkey, indent, ctx);
	} else if (classical_id == EVP_PKEY_RSA) {
	rsa_asn1_meths[0].pub_print(bp, oqs_key->classical_pkey, indent, ctx);
	}
	}
	if (BIO_printf(bp, "%*s%s Public-Key:\n", indent, "", nm) <= 0)
	return 0;
	}
	if (BIO_printf(bp, "%*spub:\n", indent, "") <= 0)
	return 0;
	if (ASN1_buf_print(bp, oqs_key->pubkey, oqs_key->s->length_public_key,
	indent + 4) == 0)
	return 0;
	return 1;
	}

showing print-out of hybrid keys (in general, check the code for the is_hybrid flag).

[dimhatzi]

Thank you for the quick reply.
And how is it possible to differentiate the concatenated values, since I expect that there will not be only the pure key data and signature values data concatenated.
For example, I have produced a trust chain (RootCA and IntermediateCA) for the creation of a hybrid user certificate using rsa3072_dilithium2_aes.

I have the below findings and I would appreciate your advice:

1. Public Keys Section
   When I read the x509 using openSSL command, the depiction of the public key values (for both RSA and Dilithium) are fine. But when serialised, indeed they are concatenated, but at the start and in-between the concatenated values, there are some values, which I suppose have to do with some additional information about the public keys. More specifically, the following bytes where created:
   00 00 01 8E 30 82 01 8A 02 82 01 81 {+RSA Public Key} 02 03 01 00 01 {+dilithium2_aes Public Key}
   The first octet string is unknown to me. The second one (after a HEX to ASN.1convertion) gives the value of U.P.INTEGER 0x010001 (65537 decimal), which I suppose it corresponds to the RSA "Exponent: 65537 (0x10001)" value of the produced certificate.
   I also want to note that the public key length of the RSA is 385 and not the expected 384.

2. Signature Value Section
   The total length of the produced concatenated value is 2808 bytes.
   If I am not mistaken, the signature value length of the rsa3072 is 384 bytes and the length of the signature value of dilithium2_aes is 2420. The sum makes 2804 bytes. I am missing 4 bytes and I do not know how to locate them in order to know the exact signature values for each algorithm.

Your advice and help is much appreciated :)

Kind regards

[baentsch]

The above seems to point to some encoding (padding?) issues, so my best suggestion is to read through the X.509 specification to get an explanation as the logic generating these structures is unmodified OpenSSL (X.509) code.

[dimhatzi]

Thank you. Indeed this is the case.

[pfuentes69]

Hello,
is there any way to generate hybrid certificates with nested signatures?
I mean using the "Alt Signature" extensions.
Txs!

[baentsch]

Hello, is there any way to generate hybrid certificates with nested signatures?

With near-certainty the answer is "No", but to be sure:

I mean using the "Alt Signature" extensions. Txs!

Could you please point to the spec/RFC that you mean?

[pfuentes69]

Hello,
You can check section 9.8 (Page 58) of ITU-T X.509 | ISO/IEC 9594-8 (https://handle.itu.int/11.1002/1000/14033-en?locatt=format:pdf&auth)

You can see an example in the attached cert.
Txs

rsa_hss_root_private.cert.pem.zip

[baentsch]

Any input as to how this RFC relates to your question?

[pfuentes69]

Well, that RFC defines the same alt signature extensions, so my question keeps being if OQS supports this, as it seems the path the industry is following and what other quantum safe implementations support already

[baentsch]

The answer is "No" for oqs-openssl111 and "not yet" for oqs-provider (OpenSSL3): A person indicated interest to contribute such code to that OQS software but without promising a date.