Add a new section: explicitely list SPKI AlgIds

[johngray-dev]

From: https://github.com/EntrustCorporation/draft-ounsworth-composite-sigs/issues/116

We should add a section listing explicitly the DER-encoded AlgorithmIdentifiers for the components of each composite public key and signature algorithm. This is important to resolve ambiguity on, for example, whether the RSA should have a NULL param, and the ECC curve params.

Example, for id-MLDSA44-ECDSA-P256-SHA256 the ML-DSA SPKI would have an AlgorithmIdentifier of:

AlgorithmIdentifier ::= SEQUENCE { id-ml-dsa } which is:

AlgorithmIdentifier ::= SEQUENCE { { 1.3.6.1.4.1.2.267.12.4.4 } } And the ECDSA-P256-SHA256 would have a SPKI would have an AlgorithmIdentifier of:

AlgorithmIdentifier ::= SEQUENCE { id-ecPublicKey, secp256r1
} which is:

AlgorithmIdentifier ::= SEQUENCE { { iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 }, iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3) prime(1) 7} And the signature algorithm for id-MLDSA44-ECDSA-P256-SHA256, the first component signature algorithm would have an AlgorithmIdentifier of

AlgorithmIdentifier ::= SEQUENCE { id-ml-dsa } which is:

AlgorithmIdentifier ::= SEQUENCE { { 1.3.6.1.4.1.2.267.12.4.4 } } and the second component signature algorithm would have an AlgorithmIdentifier of

AlgorithmIdentifier ::= SEQUENCE { ecdsa-with-SHA256 } which is:

AlgorithmIdentifier ::= SEQUENCE { { iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 } } With that done, we should replace the message prefix values in Sectien 2.4 with the SHA256 hash of the signature AlgorithmIdentifiers. This has two nice properties that are better than using the ASCII encoding of the OID name: 1) they are all the same length (ie the length of SHA256), and 2) if the inner OIDs change, for example with a new Kyber version, then the message prefix changes, which prevents cryptographic compatibility issues; or otherwise stated: provides signature domain-separation based on the component OIDs.

--- SHA256 of the DER encoding of the following ASN.1 value --- Security Consideration note: the choice of SHA256 here is not security-relevant since it is only to generate fixed string values.

SEQUENCE { AlgorithmIdentifier ::= SEQUENCE { { 1.3.6.1.4.1.2.267.12.4.4 } }, AlgorithmIdentifier ::= SEQUENCE { { iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 } } }

[johngray-dev]

June 5th - Group would like to make the draft more clear in this regard, but not explode the draft. Suggestion of a table or template section for RSA to make things more clear. Action: Jan to take a look at this for the next meeting (June 19th, 2024).

[janklaussner]

Hi @johngray-dev, @ounsworth , I tried to write these things together (https://github.com/lamps-wg/draft-composite-sigs/blob/7-add-a-new-section-explicitely-list-spki-algids/draft-ietf-lamps-pq-composite-sigs.md) and have a question:

The algorithm for compiling the component OIDs to the hash value is easy but nevertheless an algorithm with the possibility for errors. If we want domain separation that way we definitely need to include the EC parameter OID in the algorithm, else NIST and brainpool curves would have the same hash. Additionally we should have a rational why we do not include the PreHash OID here. Or include this also.

This said, this whole thing only makes sense during the development phase, because we dont know the MLDSA OIDs yet. But once they are fixed, also our combination matrix is fixed with new and official CompSig OIDs. So just Hashing the CompSig OID would do the same job and is much easier to describe in the signature algorithm. I am afraid reviewers would reject the compilation algorithm for the same reason.

So the question is, do we want to go the whole way of flexibility and define the compilation algorithm (that I would gladly do and maybe reuse for the kofn algorithm) or do we go the shortcut.

What do you think? Do I miss something here?

[johngray-dev]

Re-opening issue because the SPKI part of the issue has not been completed yet.