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

In both of those cases (S/MIME Encryption certificate and firmware signature
verification), there is a relying party to verify signatures on certificates
and payload and its policy can dictate the verification logic.

AND, OR or k of n, all should be part of relying party decision.

-----Original Message-----
From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Mike Ounsworth
Sent: Wednesday, April 27, 2022 9:50 AM
To: Kampanakis, Panos <kpanos=40amazon.com@dmarc.ietf.org>; Michael
Richardson <mcr+ietf@sandelman.ca>; LAMPS <spasm@ietf.org>
Subject: 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!eYg4o3sJSa0JPjal6u8JoCpp2muoZIeEzWZeCQaNvTwTHqd82T6AICxzCjuYwLt
YmEgXZ_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.

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm