[lamps] Re: WG Last Call: draft-ietf-lamps-pq-composite-sigs-08 (Ends 2025-10-06)

[Daniel Van Geest <[e-mail]>]

GH issue: https://github.com/lamps-wg/draft-composite-sigs/issues/294


I would prepare a PR as well, but that would involve test vector generation changes and I don't want to be responsible for any changes that I'm about to verify with my own implementation.


Table 6 in appendix B lists the curve OIDs.  But the reasoning behind my older PR with the big list of composite parameters in Section 7 was to keep all the composite parameters in one place, so I'd prefer the curve OIDs to be added to the ECDSA algorithms in this list rather than cross-referencing a table in an appendix.


Daniel



On 2025-10-09 2:08 p.m., Mike Ounsworth wrote:
Hi Dan,

Fair point and good catch.


> I believe one of the sub-goals of composites was to avoid an implementer having to do ASN.1 before passing the components on to lower levels

That's not quite true; we have a whole appendix telling you how to reconstruct SPKIs for each component algorithm.


But in this case I think I agree with you, if throwing the named curve into the private key helps interop, then let's do it. Can you open a github issue? Someone will need to prepare a PR. Will that mean adding a new table to the document, or do we already list the right curve OIDs somewhere, and we can just add a single sentence with a cross-ref?

---

Mike Ounsworth



________________________________
From: Daniel Van Geest <[e-mail]><mailto:[e-mail]>
Sent: Thursday, October 9, 2025 5:27 AM
To: Russ Housley <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>
Subject: [EXTERNAL] Re: [lamps] WG Last Call: draft-ietf-lamps-pq-composite-sigs-08 (Ends 2025-10-06)

With a busy last couple weeks I'm just now getting around to implementing the latest version and have one concern (so far). The draft is now more specific about the traditional components in the private key encoding, which is a good thing. Specifically

With a busy last couple weeks I'm just now getting around to implementing the latest version and have one concern (so far).

The draft is now more specific about the traditional components in the private key encoding, which is a good thing.  Specifically for ECDSA:

           The private key MUST be encoded as ECPrivateKey
           specified in [RFC5915] without 'NamedCurve' parameter and without
           'publicKey' field.

The omission of the parameter was done to remove redundancy since the named curve is already defined by the composite algorithm.

However, RFC5915 says this about the ECPrivateKey encoding:

      Though the ASN.1 indicates that
      the parameters field is OPTIONAL, implementations that conform to
      this document MUST always include the parameters field.

My concern is, since one of the goals of composites is to be able to reuse existing implementations, that a composite implementer who is reusing an EC implementation won't be able to encode or decode the ECPrivateKey component because their EC implementation requires the parameters field.

In my particular case, I'm using OpenSSL for the EC implementation and it doesn't appear to have a (non-deprecated) set of APIs which can decode an ECPrivateKey without a parameters field. I can either use the deprecated APIs, do my own ASN.1 parsing to extract ECPrivateKey.privateKey and feed that into an API which takes the raw private key, or do more ASN.1 and rebuild an ECPrivateKey containing the parameters and pass that to an API which takes an encoded ECPrivateKey.  I believe one of the sub-goals of composites was to avoid an implementer having to do ASN.1 before passing the components on to lower levels (hence composite keys and signatures are simple concatenations of components), so none of the three options for my implementation are ideal.  I've been decoding the test keys in the draft, I haven't even tried generating an ECPrivateKey without a parameter, and I suspect I'll run across similar problems.  OpenSSL has a very full-featured API, other implementations might not, making them even more difficult to reuse for the traditional components.

IMO, this means that this document should follow RFC5915 and require the NamedCurve parameter in the ECPrivate key (but still exclude the publicKey).

Daniel


On 2025-09-22 4:50 p.m., Russ Housley via Datatracker wrote:

Subject: WG Last Call: draft-ietf-lamps-pq-composite-sigs-08 (Ends 2025-10-06)

This message starts a 2-week WG Last Call for this document.

Abstract:
   This document defines combinations of ML-DSA [FIPS.204] in hybrid
   with traditional algorithms RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA,
   Ed25519, and Ed448.  These combinations are tailored to meet security
   best practices and regulatory guidelines.  Composite ML-DSA is
   applicable in any application that uses X.509 or PKIX data structures
   that accept ML-DSA, but where the operator wants extra protection
   against breaks or catastrophic bugs in ML-DSA.

File can be retrieved from:
https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-sigs/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-sigs/__;!!FJ-Y8qCqXTj2!blE56x_P1ihtwhuNYy0E7yIuW-Exm1-9B5fX37o-Jz43pHNGwL86N9Y1xbsKHX819vNBpAWTn2AbVpgOM7HhduV-nbKstZ1VPvP_pFkDf_w$>

Please review and indicate your support or objection to proceed with the
publication of this document by replying to this email keeping [e-mail]<mailto:[e-mail]>
in copy. Objections should be motivated and suggestions to resolve them are
highly appreciated.

Authors, and WG participants in general, are reminded again of the
Intellectual Property Rights (IPR) disclosure obligations described in BCP 79
[1]. Appropriate IPR disclosures required for full conformance with the
provisions of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of
any. Sanctions available for application to violators of IETF IPR Policy can
be found at [3].

Thank you.

[1] https://datatracker.ietf.org/doc/bcp78/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/bcp78/__;!!FJ-Y8qCqXTj2!blE56x_P1ihtwhuNYy0E7yIuW-Exm1-9B5fX37o-Jz43pHNGwL86N9Y1xbsKHX819vNBpAWTn2AbVpgOM7HhduV-nbKstZ1VPvP_gxSJYgE$>
[2] https://datatracker.ietf.org/doc/bcp79/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/bcp79/__;!!FJ-Y8qCqXTj2!blE56x_P1ihtwhuNYy0E7yIuW-Exm1-9B5fX37o-Jz43pHNGwL86N9Y1xbsKHX819vNBpAWTn2AbVpgOM7HhduV-nbKstZ1VPvP_hb412Tg$>
[3] https://datatracker.ietf.org/doc/rfc6701/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/rfc6701/__;!!FJ-Y8qCqXTj2!blE56x_P1ihtwhuNYy0E7yIuW-Exm1-9B5fX37o-Jz43pHNGwL86N9Y1xbsKHX819vNBpAWTn2AbVpgOM7HhduV-nbKstZ1VPvP_Demnf_c$>



_______________________________________________
Spasm mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>


Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.