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

[Eric Rescorla <[e-mail]>]

On Sun, Jan 19, 2020 at 11:22 AM Markku-Juhani O. Saarinen <
[e-mail]> wrote:

> On Sun, Jan 19, 2020 at 4:59 PM Michael Richardson <[e-mail]>
> wrote: hybrid fall-back because it was already being shipped out.
>

> The OQS implementation seems to currently treat hybrid keys and signatures
> simply as OCTET STRING blobs and assigns an arbitrary OID for each such
> pair; I got 1.3.9999.2.2 for a  p256_dilithium2 cert I just created. They
> emphasize that this is research code and not for production; the OID is of
> course not valid and the key/signature format is not properly documented as
> far as I know.
>
> This kind of solution would require n*m OIDs -- perhaps this is
> manageable, perhaps not -- the number of ciphersuites we used to have in
> TLS is an indication that things may get out of hand, especially if we
> further consider different hash functions used for signatures. Anyway, the
> additional ASN.1 structure bytes introduced by the draft would essentially
> document the structure of such blobs and put them under a single and/or a
> small number of OIDs. (Correct me if I'm wrong.)
>

It's not clear to me that this level of complexity is required. At least on
the Web, each algorithm would need to be individually considered by CABF
and the browser vendors, so having a lot of flexibility here isn't that
much of an asset, and having multiple tiers of parameters is not great. So,
absent some evidence that we need this level of flexibility, I tend to
think the one-oid-per-combo approach is fine.

It might still be worth having an RFC which defined how to mint new oids,
but that need not have complex on-the-wire internal structure.

-Ekr