Add a new section: explicitly list SPKI AlgIds

[ounsworth]

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]

Jan to work on this one and align with what is in composite signatures

[ounsworth]

For now I have added the following section as an appendix. We'll need to fill it out later.

Fixed Component Algorithm Identifiers

The following table lists explicitely the DER encoded AlgorithmID that MUST be used when reconstructing SubjectPublicKeyInfo objects for each component public key, which may be required for example if cryptographic library requires the public key in this form in order to process each component algorithm. The public key BIT STRING should be taken directly from the respective component of the CompositeKEMPublicKey.

Composite KEM	First AlgorithmID	Second AlgorithmID
TODO	TODO	TODO

[ounsworth]

See parallel issue in composite-sigs: https://github.com/lamps-wg/draft-composite-sigs/issues/7