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

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

On Mon, Jan 20, 2020 at 1:12 PM Eric Rescorla <[e-mail]> wrote:

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

Hi,

I'd be fine with either way (on the hardware firmware front) and colleagues
working on the TLS code comment that they don't see much difference in
implementation complexity either. The additional structure is certainly
helpful in the experimentation phase and is there to make things easier and
more robust, not harder. We would just like to have at least one open
specification for this thing, and preferably not more than one.

Basically the only additional structure carried here is the OIDs for the
key and signature components. Their lengths need to be encoded anyway, so
some structure is needed.

The PQC binary formats don't define what kind of keys/signatures they are
or how long they are. So I see the advantage of having that information
available at least somewhere. Combining several OIDS directly into a single
OID, or having to go through IANA to get a one or two dozen new OIDs for
each variant or hash function combination seems clumsy.

A couple of additional technical points:
- The reason why I mentioned SHA3/SHAKE for RSA and ECC is that this would
seem to allow message hashing to be performed only once, rather than twice
(at least for Dilithium and Falcon).
 - We don't see this as being as widely used for TLS server authentication
as for smart cards, secure elements and similar applications that can't
just switch or negotiate certificate chains on the fly. I work on the
hardware side myself and especially there we have additional considerations
such as hardcoded cert chains and FIPS certification, which is currently
only available for the hybrid case. I wouldn't want to leave the issuance
of OIDs for this purpose at the mercy of TLS folks, which is just one of
many applications of this format.

Cheers,
- markku

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