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

[Ilari Liusvaara <[e-mail]>]

On Tue, Mar 15, 2022 at 11:09:13AM -0400, Mike Prorock wrote:
> On Tue, Mar 15, 2022 at 8:54 AM Anders Rundgren <
> [e-mail]> wrote:
> 
> > On 2022-03-15 13:20, Mike Prorock wrote:
> > > Anders,
> > > What are your thoughts on a kty for hash based, one for lattice, and
> > then later for isogeny or other families as required?  That seems in line
> > with the definition of kty from 4.1 of the jwk rfc "The 'kty' (key type)
> > parameter identifies the cryptographic algorithm family used with the key"
> >
> > Hi Mike, I must confess that my insights in the actual algorithms are
> > fairly modest (big understatement); I see this exclusively from an
> > architectural point of view.
> >
> > To avoid talking in riddles, consider the initial part of current X.509
> > public key definitions:
> >
> > SEQUENCE {
> >    SEQUENCE {
> >      OBJECT IDENTIFIER rsaEncryption (1.2.840.113549.1.1.1)
> >
> >
> > SEQUENCE {
> >    SEQUENCE {
> >      OBJECT IDENTIFIER ecPublicKey (1.2.840.10045.2.1)
> >      OBJECT IDENTIFIER NIST-P-256 (1.2.840.10045.3.1.7)
> >
> >
> > SEQUENCE {
> >    SEQUENCE {
> >      OBJECT IDENTIFIER Ed25519 (1.3.101.112)
> >
> > X.509 public keys follow the top-level identifier concept I'm advocating.
> > I would be very surprised if the PKIX folks lump all known PQ key
> > algorithms under a single identifier even if it would be technically
> > feasible.  If we want COSE/JOSE keys to eventually become first class
> > citizens (like X.509) in cryptographic subsystems, a rethink may be
> > necessary.
> >
> > Yes, taking on such a scheme will require a bunch of RFCs but they would
> > all be very short.
> >
> > "One key container to rule them all!"  I hope not :)
>
> That is very helpful.  I have similar thoughts, and setting a 'kty' by
> family of algorithm, and in the post quantum case also requiring 'alg' to
> specify the actual algorithm and parameter set within that family, is very
> much in line with what you outlined.

X.509 does not actually work that way. X.509 has no equivalent to the
COSE/JOSE alg parameter in keys. For some key types, you are not going
to be able to use them in more than one way. E.g., you can't perform
anything but Ed25519 with Ed25519 key. But for many of the key types,
(I think this includes even X25519 keys, but it definitely includes
things like RSA and EC keys) there are many operations one can perform
(yes, it is unsound).


And turns out that one can't emulate the model X.509 uses in COSE/JOSE
by allowing second-chance dispatch on OKP crv (which is something an
implementation could just decide to do), due to the way COSE and
especially JOSE handle ECDSA.
 


-Ilari