Re: [Secdispatch] Can Composite sigs move back to LAMPS?

["Markku-Juhani O. Saarinen" <[e-mail]>]

On Thu, Jan 16, 2020 at 7:13 PM Mike Ounsworth <
[e-mail]> wrote:

> Following up on in-room discussions at 106, and the ensuing list
> discussions, I'd like to ask for confirmation of the following points:
>
> 1. There is enough interest in an obvious-and-straightforward
> implementation of composite signatures to continue working on it?
>    1a. The current draft for this is draft-ounsworth-pq-composite-sigs-02
>

I'd certainly like this to proceed as it the only document of this type
that is currently alive in IETF (as far as I know).

As everyone knows, the NIST PQC process will soon be in its final
third-round stretch and we're not the only vendor who is already quite
familiar with the various proposals, has implemented them, and are in the
process of making them commercially available in cooperation with PKI
vendors. We don't want to end up in a nightmare scenario where each vendor
pushing their own kind of dual/hybrid/composite/twin/double/mixed signature
solution of highly variable design quality.

In some ways IETF is perhaps behind the curve here as FIPS certification
guidelines are being created for exactly the types of technologies that
"draft-ounsworth-pq-composite-sigs-02" discusses. See e.g.
https://csrc.nist.gov/Projects/Post-Quantum-Cryptography/faqs#xisl "In
particular, a hybrid mode for signatures consists of two signatures. The
mode is valid if and only if both signatures are valid." Hence the need for
standardization of composite signatures.

Stephen Farrell referred to CVE-2020-0601 --  I don't see how composite
signatures is related to specific parameter representations. That has not
been proposed, apart from OID identifiers for a type of composite
signature. The composite can even be made up of ECC and RSA signatures. It
is just an abstraction intended to help with the transition to the next set
of standards, which is very much happening as it has been on e.g. the USG
roadmap at least since the CNSA announcement in 2015.


> 2. SecDispatch is assigning this back to LAMPS?
>    2a. The current draft might not be the most obvious-and-straightforward
> implementation; we're willing to simplify until it's in-scope for LAMPS.
>

This bouncing back and forth seems symptomatic of IETF. Those of use who
are working on this technology will just have to "follow the specification
around" if that happens.

Anyway let's keep working on it. I'd be even ready to help push it through
as "informational" on the strength of having interoperable industry
implementations. Currently the level of detail is not sufficient for that,
but we should be able to iterate enough detail in there if we do a little
bit of engineering interop. As to what is the most appropriate forum for
that, I'm open to suggestions.

Cheers,
- markku

Dr. Markku-Juhani O. Saarinen <[e-mail]> PQShield, Oxford UK.