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

[David Hook <[e-mail]>]

At the risk of sticking my head out of my foxhole at the wrong time, I 
also have one big reservation about the current draft.

At the moment the private key is being encoded with the ML-DSA component 
as fixed length based on just the seed. While one of the compelling 
points around the original private key discussion in lamps (I hope) was 
around the presence of legacy expanded keys which couldn't simply be 
encoded as seeds as the "seed only ship" had already sailed for some, we 
should have probably made a point concerning the fact that there's going 
to be hardware in process (for certification), possibly even in the 
field now, which also will only export expanded keys and it many cases 
updating such hardware may be very difficult, if not impossible. As this 
is the case, it is not really correct that the new composite encoding 
will work for all new ML-DSA private keys, it is restricted to new 
ML-DSA private keys for which a seed only encoding exists. At the moment 
only the ML-DSA private key draft will work for all ML-DSA private keys 
and I think it would be both a shame, even a loss, that this may not 
turn out to be true for composite as well.

If there is still a chance of discussion I would like to propose that 
the private key is encoded as a sequence of two octet strings, with each 
octet string based on what the privateKey field in the octet string 
would have been if the keys had been encoded into their own 
PrivateKeyInfo fields. This would allow people who are stuck with 
expanded private keys to also make use of the algorithm and, at least in 
our case, simplify reconstruction, as then the octet strings could be 
loaded straight into PrivateKeyInfo structures suitable for passing to a 
key factory (rather than what we need to do now, which is extract the 
right number of bytes, reconstruct the surrounding octet string and then 
build a PrivateKeyInfo structure around it...). It also means people can 
still use seed, it will just cost 4, perhaps 5 extra bytes, allowing for 
the sequence header and the implicitly tagged octet string for the seed.

I think also, given that Falcon is on it's way, and there is also the 
current on-going signature competition, it would provide a more general 
way of future proofing the standard to allow for a simple method of 
including different private key types when appropriate.

Other than that, we have a few organizations very keen to start using 
composite and who are already experimenting with it. It seems to be 
showing a lot of promise in the use of firmware signing amongst other 
things.

With respect,

David

On 6/10/25 00:08, Tim Hudson wrote:
> At this time, I am not in favour of this draft, for the reasons 
> already discussed on list that we don't need to revisit here.
> I will encourage various libraries and other standards body groups to 
> not implement this in the form proposed.
>
> Note this view is unchanged by draft-ietf-lamps-pq-composite-sigs-09 
> and I find it a somewhat unexpected process to have a WGLC active and 
> to be simultanously changing the document.
> I would have expected the WGLC to be terminated if the editors felt 
> that items needed addressing.
>
> Tim.
>
>
> On Mon, Sep 22, 2025 at 5:50 PM Russ Housley via Datatracker 
> <[e-mail]> 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/
>
>     Please review and indicate your support or objection to proceed
>     with the
>     publication of this document by replying to this email keeping
>     [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/
>     [2] https://datatracker.ietf.org/doc/bcp79/
>     [3] https://datatracker.ietf.org/doc/rfc6701/
>
>
>
>     _______________________________________________
>     Spasm mailing list -- [e-mail]
>     To unsubscribe send an email to [e-mail]
>
>
> _______________________________________________
> Spasm mailing list [e-mail]
> To unsubscribe send an email [e-mail]