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

[Michael Richardson <[e-mail]>]

Kampanakis, Panos <[e-mail]> wrote:
    > 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.

You are completely correct!  Verifiers will not understand the new OID until
they get an upgrade.  I'm making the argument that if the new OID provides
some functionality outside of the PQC transition, then the cost of the
upgrade will be distributed wider.

I'm also arguing that it would be nice to find the bugs (and vulnerabilities)
that might come with the new code before we need the new mechanisms for PQC.
To do that, we need it to be in widespread use.

    > 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.

So for TLS and IKEv2 and maybe email (if we can ever automate certificate
discovery inband to SMTP), then we can negotiate.
For data at rest, particularly for *certificates* we can't negotiate.

Fortunately, for certificates, there are some options, one of which is to
have a parallel certificate path.
Not legacy vs PQ, but rather, legacy vs OR-algorithm.
As was said elsewhere on this thread, some other formats have slots for
multiple signatures, so we can perhaps win there, but those multiple slots
also is probably an implicit OR mechanism anyway.

I think that there are some entities that might be pleased to have two legacy
signatures from two public CAs, where the expiry dates were staggered.
(I realize that the notAfter is not part of the signature, itself, but part
of the signature.   The certificate one up is where the dates could be
staggered)