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

[Mike Ounsworth <[e-mail]>]

Hi Peter,

Can you give me some pointers about what you would like those extended
security considerations should say? Better yet, if you open a github issue
with the details, you'd be my best friend!

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

On Wed, 24 Sept 2025 at 10:35, Peter C <[e-mail]> wrote:

> Falko,
>
>
>
> Thanks.  I think it would be useful to extend the security considerations
> to include a discussion of the security of the composite construction in
> the context of X.509 certificates and CRLs.
>
>
>
> Peter
>
>
>
> *From:* Falko Strenzke <[e-mail]>
> *Sent:* 24 September 2025 15:34
> *To:* Mike Ounsworth <[e-mail]>; Peter C <
> [e-mail]>; John Mattsson <[e-mail]>
> *Cc:* Russ Housley <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]
> *Subject:* Re: [lamps] Re: WG Last Call:
> draft-ietf-lamps-pq-composite-sigs-08 (Ends 2025-10-06)
>
>
>
> In this context I want to contribute the following observations:
>
> ## Strong Non-Separability for X.509 and CMS
>
> I claim that Strong Non-Separability (SNS) is naturally fulfilled for
> X.509 certificates and CRLs by a straightforward parallel combiner. This is
> due to the fact that both these data structures contain the signature
> algorithm identifier within the signed data. RFC 5280 requires these
> signature algorithm identifiers within  the signed data to be equal to
> their copy outside the signed data [1]. This means that a stripping attack
> is naturally prevented since removing one signature requires changing the
> signed algorithm identifier and thus invalidates the remaining signature.
>
> It should be noted that the chosen construction in the draft thus, for the
> case of X.509 when component keys are reused as standalone keys,
> unnecessarily weakens the security features since an attacker can, through
> a stripping attack, produce new validly signed artifacts, namely by
> rendering the signed data as M'. This amounts to a violation of EUF-CMA
> under consideration of cross-algorithm attacks (composite and component
> algorithm). Whereas the straightforward parallel combiner doesn't allow
> this or any other kind of stripping attack.
>
> For CMS the case is different, as there is no mechanism that naturally
> prevents stripping attacks. Here it would be possible to achieve SNS by
> specifying a new Signed Attribute that contains the signature algorithm
> identifier and is made a mandatory Signed Attribute in a protocol.
>
> ## Preservation of the SUF-CMA property
>
> Regarding the preservation of the SUF-CMA property of both component
> algorithms by the composite algorithm, note that
> - for X.509 certificates, this is fulfilled by the requirement of the
> unique serial number in RFC 5280. As a result, the same data will never be
> signed twice by a legitimate signer. Since the relevant attack works by
> recombining the component signatures of two different composite signatures
> over the *same* data, the attack is not possible.
> - in X.509 CRLs, there is not unnecessarily a unique serial number
> contained. But the thisUpdate field will in all realistic cases differ
> between two CRLs.
>
> Thus for X.509 certificates and CRLs, I argue that preservation of the
> SUF-CMA property is always fulfilled under realistic conditions.
>
> For CMS, the preservation of the SUF-CMA property could be achieved for
> applications that produce signed messages with a frequency in a domain
> sufficiently smaller than 1/s, namely by making the already existing
> *Signing Time* Signed Attribute mandatory. This attribute contains the
> signing time with an accuracy of seconds. Alternatively, to robustly
> achieve this security property, a new *Nonce* Signed Attribute could be
> specified for CMS.
>
>
> I suggest that these observations be taken into account in the security
> considerations. It should become clear why the specific construction was
> chosen despite the fact that it is – according to my arguments above – only
> degrading the security properties of the important X.509 use case.
>
> Falko
>
> [1] RFC 5280. https://www.rfc-editor.org/rfc/rfc5280.html#section-4.1.1.2,
> https://www.rfc-editor.org/rfc/rfc5280.html#section-5.1.1.2
>
> [2] RFC 5652. https://tools.ietf.org/html/rfc5652
>
> Am 24.09.25 um 13:33 schrieb Mike Ounsworth:
>
> Thanks John and Peter C. I agree that without the randomizer, Composite
> ML-DSA does not give SUF in the case of compromise of ML-DSA. I think Peter
> is right that I wrote this text several versions ago when we had a
> randomizer inside the pre-hash PH(r || M), and I think I have not revisited
> this text since. Thank you Peter also for the comment about
> non-separability. I will do a pass over this text and post a new version;
> probably on the weekend.
>
>
>
> https://github.com/lamps-wg/draft-composite-sigs/issues/275
>
>
>
> On Wed, 24 Sept 2025 at 05:12, Peter C <Peter.C=
> [e-mail]> wrote:
>
> Hi,
>
>
>
> I had a comment about the non-separability discussion in section 10.2.
> The draft says:
>
>     [W]e want to consider a modified version of the EUF-CMA game
>
>     where the attacker has access to either a signing oracle over the
>
>     two component algorithms in isolation […] and attempts to
>
>     fraudulently present them as a composite, or where the attacker
>
>     has access to a composite signing oracle and then attempts to
>
>     split the signature back into components […].
>
>
>
> The first case (attacker constructing a composite signature from
> individual components) is indistinguishable from the situation where a
> legitimate signer stores the component private keys in separate
> cryptographic modules (as mentioned in section 4.1).  Weak non-separability
> only allows a verifier to detect the second case (attacker splitting a
> composite signature into its individual components).
>
>
>
> I’d suggest re-writing the non-separability discussion so that it only
> considers splitting attacks and perhaps expanding the key reuse section so
> that it is clearer that the risk is from **verifier** reuse of component
> public keys in other contexts.
>
>
>
> Peter
>
>
>
> *From:* Russ Housley <[e-mail]>
> *Sent:* 22 September 2025 16:52
> *To:* [e-mail]
> *Cc:* [e-mail]; [e-mail]
> *Subject:* [lamps] Re: WG Last Call:
> draft-ietf-lamps-pq-composite-sigs-08 (Ends 2025-10-06)
>
>
>
> As part of this WG Last Call, be aware that this IPR disclosure was
> submitted four years ago:
>
> https://datatracker.ietf.org/ipr/4761/
>
>
>
> Russ
>
>
>
>
>
> On Sep 22, 2025, at 11:50 AM, 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]
>
> --
>
> *MTG AG*
> Dr. Falko Strenzke
>
> Phone: [phone]
> E-Mail: [e-mail]
> Web: mtg.de <https://www.mtg.de>
> ------------------------------
>
> MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
> Commercial register: HRB 8901
> Register Court: Amtsgericht Darmstadt
> Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
> Chairman of the Supervisory Board: Dr. Thomas Milde
>
> This email may contain confidential and/or privileged information. If you
> are not the correct recipient or have received this email in error,
> please inform the sender immediately and delete this email.Unauthorised
> copying or distribution of this email is not permitted.
>
> Data protection information: Privacy policy
> <https://www.mtg.de/en/privacy-policy>
>