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

[Anders Rundgren <[e-mail]>]

Hi Guys,

May I as an implementer also comment on the idea of overloading the OKP identifier?

Actual code for a COSE public key decoder:

     // Throws an exception if there is no KTY label (=key object is completely malformed).
     int coseKty = publicKeyMap.getObject(COSE_KTY_LABEL).getInt();
     KeyTypes keyType = keyTypes.get(coseKty);
     if (keyType == null) {
         throw new GeneralSecurityException("Unrecognized key type: " + coseKty);
     }

I guess that most decoders do something like this since the parameters associated with each "kty" are quite different.

If you OTOH overload OKP, decoders would assume that they are going to process an x25519, x448, ed25519, or ed448 key and convert these to the platform's own representation.  Such code will fail and in a much less predictive way.  BTW, Oracle would never considering extending their existing interfaces for the mentioned algorithms; they would define new ones.   Some people suggested retrofitting the EC interfaces for ed25519 and friends but Oracle turned down this request since existing crypto providers would either have to be upgraded or just crash and that is not overly appealing.  Clean separation is more important than code reuse.  A key decoder/encoder is also a very small piece of code.

This is also a question about adoption. By using different identifiers, software can be upgraded without support by the platform vendors.  It took Oracle 5 years to introduce native support for Ed25519!

Cheers,
Anders