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

[Dennis Jackson <[e-mail]>]

I'm trying to unpack exactly what the concern is:

1) There are some 1st gen PQ HSMs which can do ML-DSA but don't keep 
around the seed. Hence we have this horrible ASN.1 CHOICE format for 
ML-DSA private keys.

2) These 1st gen HSMs don't understand composites at all, but you can do 
them in software from the two individual components in the HSM.

3) In the future, there will be 2nd gen HSMs which understand composites 
natively. Folks will want to export their private keys from their 1st 
gen HSMs and put them into the newer composite-supporting HSMs.

5) Since this draft only supports seeds in composite private keys - and 
the seed might have been thrown away by the 1st gen HSM - this won't be 
possible.

However, it seems like this could be easily worked around by just 
importing the two private keys into the newer HSM and continuing to use 
software to produce the composite. Is that correct?

If so, then I really think the current draft is fine as-is. It's just 
not worth inflicting the complexity of multiple private key 
representations on the rest of the world when there's an easy workaround 
for the small number of people that would ever have to care about this.

Best,
Dennis

On 06/10/2025 21:54, Mike Ounsworth wrote:
> Bas, Uri, Dennis,
>
> I know that Tim Hudson and David Hook are at the Openssl Conference this
> week, so might not reply in the timeframe that we need to close out WGLC,
> so I'll try to reply on their behalf (which is dangerous, I know).
>
> I am trying to not have an opinion of my own, but I am swayed by the
> argument that we know that the first gen of PQC HSMs going through FIPS
> certification now submitted their modules for certification a year ago
> before NIST said that seeds were allowed. Once those get certified, there
> will likely be a rush to put that first gen of PQC HSM into production,
> where they will probably sit for 5 - 10 years. Sure, subsequent generations
> will support seeds, but we need composites as an immediate transition
> mechanism, and if we KNOW that the first gen of hardware won't be able to
> do it (to be precise: "it" means able to export an ML-DSA key as seed),
> then we're majorly harming the usefulness and adoption of composites. I
> notice that the people objecting to the CHOICE are not operators of CAs on
> HSMS, which is where this is going to feel the pinch.
>
> 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.
>
>
>
> On Mon, 6 Oct 2025 at 15:35, Dennis Jackson <ietf=
> [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]>  -- yes please?
>>>
>>>
>>> On Mon, 6 Oct 2025 at 10:20, Jean-Pierre Fiset <[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]> 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]> , I think this
>> means
>>>>> Composite Signatures fails WGLC :(
>>>>>
>>>>> On Sun, 5 Oct 2025 at 10:36, David Hook <[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]> 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 to [e-mail]
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Spasm mailing list -- [e-mail]
>>>>>> To unsubscribe send an email to [e-mail]
>>>>>>
>>>>> _______________________________________________
>>>>> Spasm mailing list -- [e-mail]
>>>>> To unsubscribe send an email to [e-mail]
>>>>>
>>>>> _______________________________________________
>>>>> Spasm mailing list -- [e-mail]
>>>>> To unsubscribe send an email to [e-mail]
>>>>>
>>>> --
>>>>
>>>> Sophie Schmieg | Information Security Engineer | ISE Crypto |
>>>> [e-mail]
>>>>
>>>>
>>>> _______________________________________________
>>>> Spasm mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>>> _______________________________________________
>>>> Spasm mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>> _______________________________________________
>>> Spasm mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>> _______________________________________________
>> Spasm mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>
> _______________________________________________
> Spasm mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]