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

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

This is not technically *new* information, since this was brought up in Bangkok and Madrid, and voted down 42 - 1. But I am not convinced that that was a mistake, and I'm fairly happy with my PR because for the low low price of a 2 byte length tag, the people who need CHOICE can do CHOICE, and the people who don't can ignore it. It's hard for me to imagine on what technical grounds someone could object to this.

Technical grounds: mainly, an extra attack surface and the extra (unnecessary!) complexity of processing/implementing/validating/etc.


On Mon, 6 Oct 2025 at 15:35, Dennis Jackson <ietf=[e-mail]<mailto:[e-mail]>> wrote:
Hi Mike,

As I said to you privately:

> Thank you for putting it together Mike! I'm not thrilled about CHOICE for the same reasons as for the KEM hybrids, but if we are forced down this line (I'm not convinced yet) then this seems pretty solid
I have seen no argument that we are forced down this line. Unless
someone can bring some compelling new argument or evidence, I don't
think we should re-open this topic.

Best,
Dennis

On 06/10/2025 19:37, Mike Ounsworth wrote:
> Hi,
>
> So, I am hearing people say that it's necessary to support {seed,
> expandedkey, both}. I am hearing people say that it's not.
>
> What I have not heard, is anyone say that they cannot live with this PR.
> https://github.com/lamps-wg/draft-composite-sigs/pull/292
>
> Essentially, it adds a 2-byte length value to the private key format:
>     output len(mldsaSK) || mldsaSk || tradSK
> and then says that since mldsaSK can only take a finite number of forms,
> the length serves double-duty as a tag according to this table:
>
> | ML-DSA alg  | seed  | expandedKey  | both |
> | ----------- | ----- | ------------ | ---- |
> | ML-DSA-44   | 32    | 2560         | 2592 |
> | ML-DSA-65   | 32    | 4032         | 4064 |
> | ML-DSA-87   | 32    | 4896         | 4928 |
>
> I have heard David Hook say that it's not as much encoding (ASN.1) as he
> would like, but he can live with it. I have heard Dennis Jackson say that
> it's more encoding that he would like, but he can live with it.
>
> Pending any hard objections, I am going to merge this PR and then ask Russ
> to pass the WGLC and to ask IANA for official OIDs this week.
> @Russ Housley <[e-mail]<mailto:[e-mail]>>  -- yes please?
>
>
> On Mon, 6 Oct 2025 at 10:20, Jean-Pierre Fiset <[e-mail]<mailto:[e-mail]>> wrote:
>
>> I agree with Sophie's position and perspective.
>>
>> Furthermore, I do not believe that we need to revisit the expanded format
>> as there are no prior implementation (that we know of) in production use.
>>
>> JP
>> On 10/5/25 15:08, Sophie Schmieg wrote:
>>
>> I'm not sure what objections Tim refers to here. As Dennis mentioned, as
>> far as I can tell, all necessary design decisions have been voted on in
>> Madrid and have been decided with what I would characterize as overwhelming
>> working group consensus. We should not revisit these decisions given that
>> no new arguments have been made (and really only security arguments should
>> get us to revisit them at all now in my opinion).
>>
>> We are running out of time when it comes to composite signatures. I
>> already had to greenlight multiple pure-only projects to proceed, simply
>> because no stable signature combiner exists as of yet. If we do not have a
>> published RFC (or, to be more precise, fixed IANA code points, i.e. a draft
>> that is fixed on the bytes on the wire that are produced) by the end of the
>> year, my prediction is that it will simply be too late for composite
>> signatures to see any meaningful adoption. The deadline for being done with
>> at least the majority of the PQC migration, set by various government
>> agencies, threat models, etc, is 2030. If we get an RFC by the end of year,
>> that leaves 4 years for implementation, which even includes various
>> downstream standardization decisions in many cases. We simply cannot afford
>> going back and forth on already decided points.
>>
>> On Sun, Oct 5, 2025 at 10:19 AM Dennis Jackson <ietf=
>> [e-mail]<mailto:[e-mail]>> wrote:
>>
>>> Hi Mike,
>>>
>>> My understanding was that these arguments were brought up in Madrid [1]:
>>>
>>> Discussion about whether or not HSM modules do not support (and has no
>>> plans to support), seed.
>>> DB: there are existing keys whose seeds were lost. This was the concern.
>>> Since we forbid key re-use, and we have an upgrade path, there should be
>>> no issue.
>>> VD: people bought modules, dont know how to upgrade, and we had
>>> stand-alone keys, so can we have a length?
>>>
>>>
>>> and the result of that discussion was a nearly unanimous consensus on the
>>> private key format:
>>>
>>> POLL: Can you live with the seed-only private key format?
>>> Y: 42, NO: 1, NoOpinion: 7.
>>>
>>>
>>> I don't think we should re-open any discussion we've found consensus and
>>> I think that applies doubly when we're in WGLC, it's a breaking change and
>>> this is a draft that other WGs are depending upon.
>>>
>>> Best,
>>> Dennis
>>>
>>> [1]
>>> https://datatracker.ietf.org/meeting/123/materials/minutes-123-lamps-202507220730-00
>>>
>>> On 05/10/2025 17:21, Mike Ounsworth wrote:
>>>
>>> Thank you David for explaining the sticking point here.
>>>
>>> I am sympathetic to this point:
>>>
>>>> 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.
>>>
>>> This point was brought up as far back as Bangkok (March 2025), and
>>> out-voted by the LAMPS WG and the composite authors with the hand-wave
>>> ("well, then those devices won't be able to do composites, oh well").
>>> Perhaps that was the wrong answer. I am willing to re-open that discussion.
>>>
>>> David suggests:
>>>
>>>> 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,
>>>
>>> I am interpreting "sequence of two octet strings" to be the ASN.1 type
>>> SEQUENCE SIZE (2) of OCTET STRING, and not a custom byte encoding.
>>> One of the constraints that the composite authors have is that while
>>> Composite is being standardized in LAMPS, it is not really part of X.509,
>>> it is really a standalone cryptographic primitive that really should have
>>> gone through CFRG, and we want the primitive standardized here to be
>>> re-usable across JWT, CWT, HPKE, which means no ASN.1 in the key encodings.
>>> Also, I don't want to have Composite ML-DSA have a totally different
>>> encoding from Composite ML-KEM. Let me noodle for a few hours on how to
>>> shoehorn the CHOICE thing in here in a way that won't make the authors of
>>> the downstream JWT and CWT drafts balk. I'll open a PR.
>>>
>>> Unfortunately, this will be a breaking change that will need design
>>> discussion, so @Russ Housley <[e-mail]<mailto:[e-mail]>> , I think this means
>>> Composite Signatures fails WGLC :(
>>>
>>> On Sun, 5 Oct 2025 at 10:36, David Hook <[e-mail]<mailto:[e-mail]>> wrote:
>>>
>>>> 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]<mailto:[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]<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/
>>>>> [2] https://datatracker.ietf.org/doc/bcp79/
>>>>> [3] https://datatracker.ietf.org/doc/rfc6701/
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Spasm mailing list -- [e-mail]<mailto:[e-mail]>
>>>>> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
>>>>>
>>>> _______________________________________________
>>>> Spasm mailing list -- [e-mail]<mailto:[e-mail]>
>>>> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
>>>>
>>>>
>>>> _______________________________________________
>>>> Spasm mailing list -- [e-mail]<mailto:[e-mail]>
>>>> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
>>>>
>>> _______________________________________________
>>> Spasm mailing list -- [e-mail]<mailto:[e-mail]>
>>> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
>>>
>>> _______________________________________________
>>> Spasm mailing list -- [e-mail]<mailto:[e-mail]>
>>> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
>>>
>>
>> --
>>
>> Sophie Schmieg | Information Security Engineer | ISE Crypto |
>> [e-mail]<mailto:[e-mail]>
>>
>>
>> _______________________________________________
>> Spasm mailing list -- [e-mail]<mailto:[e-mail]>
>> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
>>
>> _______________________________________________
>> Spasm mailing list -- [e-mail]<mailto:[e-mail]>
>> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
>>
>
> _______________________________________________
> Spasm mailing list -- [e-mail]<mailto:[e-mail]>
> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

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