Re: [lamps] [EXTERNAL] Re: Call for adoption for the composite-related Internet-Drafts

[Mike Ounsworth <[e-mail]>]

Hi Michael,

Thank you for your comments.

> I specifically still don't really understand if composites are AND vs OR, and I know that we had a lot discussion about this last year (or was it 2021?) with some options being that it would depend.

Your confusion is understandable: draft-ounsworth-pq-composite-sigs-00 was Mar 2019, and this proposal has evolved a lot in the past 4 years.
The current draft locks everything down: composites are AND modes of pairs of algs with the algs and parameters specified by the composite OID, for example " id-Dilithium3-ECDSA-P256-SHA256". The exception (ie where there still is some runtime choice) is "id-Dilithium3-RSA-PSS" where both key size and PSS params are left open to runtime choice. If this work gets adopted then we would be happy to discuss that further.

---
Mike Ounsworth

-----Original Message-----
From: Spasm <[e-mail]> On Behalf Of Michael Richardson
Sent: Friday, June 2, 2023 12:30 PM
To: Stephen Farrell <[e-mail]>; LAMPS <[e-mail]>
Subject: [EXTERNAL] Re: [lamps] Call for adoption for the composite-related Internet-Drafts

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

______________________________________________________________________

Stephen Farrell <[e-mail]> wrote:
    >> With composites in certificates we can mitigate these risks because it
    >> gives us a time window to react, whether it’s a broken algorithm

    > So I don't understand that.

I also have questions, but I think that they could be resolved during the WG process.
I specifically still don't really understand if composites are AND vs OR, and I know that we had a lot discussion about this last year (or was it 2021?) with some options being that it would depend.

    > Let's say if rainbow+ed25519 had been
    > deployed, are you assuming that people would still be willing to accept
    > certificates thusly signed, even after rainbow got busted? ISTM more
    > likely the reaction in that event would be more akin to what happened
    > with heartbleed, which is that end entities would all rush to get new
    > certs without rainbow and rainbow would be disabled entirely by relying
    > parties.

Getting new certificates is a very TLS focused thing, btw.
Manufacturer installed IDevIDs can't do that, nor can SMIME encrypted data on disk, and even >2 level PKIs with subordinate CA certificates are "on disk"

(I also think heartbleed is slight different and slightly easier to recover from, because private keys were disclosed due to no fault in the protocol itself, so there was no code changes required)


--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide




Any email and files/attachments transmitted with it are confidential and 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.