Re: [lamps] [EXTERNAL] Re: PQ-composite OR or K-of-N logic

Panos,

> The only way to avoid a flag day is to negotiate

Careful with this thinking; there are things in the world besides than TLS and IKE; How does one negotiate with an S/MIME encryption cert that you find in a directory, or a signed firmware binary that you're trying to verify in a bootloader?

---
Mike Ounsworth

-----Original Message-----
From: Spasm <spasm-bounces@ietf.org> On Behalf Of Kampanakis, Panos
Sent: April 23, 2022 8:48 PM
To: Michael Richardson <mcr+ietf@sandelman.ca>; LAMPS <spasm@ietf.org>
Subject: [EXTERNAL] Re: [lamps] PQ-composite OR or K-of-N logic

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

______________________________________________________________________
Hi Michael,

Both OR or AND are not backwards compatible. The new OID (regardless of OR or AND logic) will not be understood by verifiers that have not been upgraded. Not to mention that verifiers that don't understand composite will not want to see the extra data which could slow down their communications.

The only way to avoid a flag day is to negotiate; if the verifier understands the composite signature give it to it, otherwise just give the classical.

-----Original Message-----
From: Spasm <spasm-bounces@ietf.org> On Behalf Of Michael Richardson
Sent: Saturday, April 23, 2022 1:06 PM
To: LAMPS <spasm@ietf.org>
Subject: RE: [EXTERNAL][lamps] [EXTERNAL] Re: PQ-composite OR or K-of-N logic

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

Serge Mister <Serge.Mister=40entrust.com@dmarc.ietf.org> wrote:
    > As I mentioned on the call, I'm not fully convinced that deciding which
    > signatures a relying party must verify is entirely a decision for the
    > relying party.  When an entity obtains a certificate from a CA,
    > signatures verifiable with the certificate are attributed to the entity
    > named in the certificate.  The certificate holder then wouldn't want a
    > weak key bound to their identity.  If a composite key can be used in
    > "OR" mode, the key is weakened when any of the algorithms is weakened.

Yeah, but we need this OR mode to operationally be able to deploy.

Yes, it true it could be subject to a bid-down attack against the weaker algorithm.  But, this is where the verify policy does matter.  Bid-down attacks only work when both parties have open policies.
Until there is there is a clear attack, there isn't a weak algorithm.
But, when an attack becomes known, verifies have to change their policies.

Without the OR mechanism, we wind up with a flag day where all signers and all verifiers have to upgrade within a renewal/CRL-signing epoch.  That's just not practical.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works  -= IPv6 IoT consulting =-

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!eYg4o3sJSa0JPjal6u8JoCpp2muoZIeEzWZeCQaNvTwTHqd82T6AICxzCjuYwLtYmEgXZ_fMnGE9BVUKmthW_R3LWu9mQtK4jdLRO-DmyA$
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.