Re: [COSE] draft-prorock-cose-post-quantum-signatures [Was: Re: Call for COSE Agenda Items for IETF 113 in Vienna]

[Russ Housley <[e-mail]>]

> On Mar 15, 2022, at 2:57 PM, Ilari Liusvaara <[e-mail]> wrote:
> 
> On Tue, Mar 15, 2022 at 11:16:34AM -0400, Mike Prorock wrote:
>> Orie,
>> I think other alternative would be:
>> kty: PQL        // post quantum - lattice based
>> alg: CRYDI3  // crystals dilithium, parameter set 3
>> x: public
>> d: private
> 
> "Lattice-based post quantum" is not a valid key type. It is not a single
> key shape (unlike every kty currently defined). And it does not look to
> be helpful even working around algorithm dispatch issues in
> implementations, as, e.g., Dilithium and Kyber are both lattice post-
> quantum algorithms, but wildly different.
> 
> If that kty is supposed to be octet-keypair for given alg, that would
> be defensible (mixing algorithms for the same key is unsound), but the
> name for that kty would not be PQL.
> 
> There is also actual security problem with this: Serious cryptographers
> are very unconfortable with unhybridized post-quantum algorithms (with
> exception of hash signatures) at the moment. Gaining confidence on such
> things will take years at the very least.

Agree.  I am hoping that the key structure is invisible at the COSE level.  It is just an octet string at this level, but the crypto code knows about any internal structure, but not the COSE library.

>> and
>> kty: PQH       // post quantum - hash based
>> alg: SP-SHAKE256-[n]-[w]-[h]-[d]-[k]-[t]  // SPHINCS+, shake256, parameter
>> set as noted
>> x: public
>> d: private
> 
> One really should stay away from those parameters and use parameter
> sets made by experts, as at least some of those parameters will
> absolutely destroy security if set the wrong way.
> 
> And "Hash-based post quantum" is also not a valid key type.

I think the intent is to ony register the alg strings that represent a set of parameters that are intended to be used together, not allow arbitrary values.

Russ