Be more specific on component signature and public key serialization.

[janklaussner]

A colleague of mine struggled to find the correct way for serializing the component signatures and public keys.
We want bytes to conacatenate both components. While its quite clear for ML-DSA since the FIPS-204 defines the byte encoding. But for e.g. ECDSA its unclear.
Or do I miss something?
@ounsworth @johngray-dev @feventura

[johngray-dev]

The appendix has the encoding section that you added right? Doesn't that make it clear? For example, Around Page 62: we have this description:

ECDSA NIST 256 -- AlgorithmIdentifier of Public Key

ASN.1:
algorithm AlgorithmIdentifier ::= {
algorithm id-ecPublicKey -- (1.2.840.10045.2.1)
parameters ANY ::= {
AlgorithmIdentifier ::= {
algorithm secp256r1 -- (1.2.840.10045.3.1.7)
}
}
}

DER:
30 13 06 07 2A 86 48 CE 3D 02 01 06 08 2A 86 48 CE 3D 03 01 07

ECDSA NIST 256 -- AlgorithmIdentifier of Signature

Ounsworth, et al. Expires 24 April 2025 [Page 63]
Internet-Draft Composite ML-DSA October 2024

ASN.1:
signature AlgorithmIdentifier ::= {
algorithm ecdsa-with-SHA256 -- (1.2.840.10045.4.3.2)
}

DER:
30 0A 06 08 2A 86 48 CE 3D 04 03 02

Appendix B has this table that shows where the specification comes from:

+=========================+=========================+=============+
| Component Signature | OID |Specification|
| Algorithm ID | | |
+=========================+=========================+=============+
| id-ML-DSA-44 | 2.16.840.1.101.3.4.3.17 |[FIPS.204] |
+-------------------------+-------------------------+-------------+
| id-ML-DSA-65 | 2.16.840.1.101.3.4.3.18 |[FIPS.204] |
+-------------------------+-------------------------+-------------+
| id-ML-DSA-87 | 2.16.840.1.101.3.4.3.19 |[FIPS.204] |
+-------------------------+-------------------------+-------------+
| id-Ed25519 | 1.3.101.112 |[RFC8410] |
+-------------------------+-------------------------+-------------+
| id-Ed448 | 1.3.101.113 |[RFC8410] |
+-------------------------+-------------------------+-------------+
| ecdsa-with-SHA256 | 1.2.840.10045.4.3.2 |[RFC5758] |
+-------------------------+-------------------------+-------------+
| ecdsa-with-SHA512 | 1.2.840.10045.4.3.4 |[RFC5758] |
+-------------------------+-------------------------+-------------+
| sha256WithRSAEncryption | 1.2.840.113549.1.1.11 |[RFC8017] |
+-------------------------+-------------------------+-------------+
| sha512WithRSAEncryption | 1.2.840.113549.1.1.13 |[RFC8017] |
+-------------------------+-------------------------+-------------+
| id-RSASA-PSS | 1.2.840.113549.1.1.10 |[RFC8017] |
+-------------------------+-------------------------+-------------+

So RFC 5758 should specify what he is looking for, does it not? I looked at 5758 and it says this:

Encoding rules for ECDSA signature values are specified in RFC 3279
[RFC3279], Section 2.2.3, and RFC 5480 [RFC5480].

And RFC 5480 contains the ASN.1 needed to encode ECDSA keys (for example).

I guess we could pull the encodings from 5480 into our already huge document if we think it is helpful.

[janklaussner]

OK, thanks.
I had the impression we get rid of ASN.1 encondings altogether, but it seems I was mistaken.
Anyway I think we need to add some more guidance here.
First some hint to the appendix B where the references are stated.
Second some hint for the encoding: The ECDSA example is quite good: an ASN.1 structure is not a byte string, it needs to be encoded, and this is not part of the RFC. At least we should have the standard sentence like "contains the DER encoding of an ASN.1 value" or something there.
Does this makes sense?