[Internet]Re: "Pluggable" key serialization in JCE/JCA

[Anders Rundgren]

On 2022-03-26 23:14, Bernd Eckenfels wrote:
> Just for completeness, the standard for key transport in JOSE is JWK (RFC7517).
> 
> In COSE it is a COSE_Key(Set) as defined in RFC8152 sect13.
> 
> BTW the most widely used CBOR/COSE application are probably the QR codes around Covid and Vaccination certificates of the EU.
> 

Thanx Bernd and Michael for the additional clarifications!

Now to the thing that spurred this discussion: https://datatracker.ietf.org/doc/html/rfc8037

    This document defines how to use the Diffie-Hellman algorithms
    "X25519" and "X448" as well as the signature algorithms "Ed25519" and
    "Ed448" from the IRTF CFRG elliptic curves work in JSON Object
    Signing and Encryption (JOSE).

When RFC 8037 was created the assumption was that the "OKP" key container {sh|c}ould be used for other crypto systems having the same parameter set.  This is now an active proposal:
https://www.ietf.org/archive/id/draft-looker-cose-bls-key-representations-00.html

Obviously everything works just fine if you look at the container in isolation. However, it means that "OKP" encoder/decoder code must be updated for every new reuse ("overloading").  To be meaningful these new algorithms would also have to coerced into the existing XEC or EdDSA interfaces.

IMO, this would be VERY UNFORTUNATE since it is incompatible with the provider concept as well as with object oriented crypto APIs.  I'm therefore suggesting that key containers for specific crypto systems should have unique names.  In this particular case "BLS" seems logical.  In Java it could eventually be mapped to BLSPublicKey and BLSPrivateKey.

WDYT?

There is no need for a JEP at this stage, only some kind of indication of what the JDK crypto team see as the best way forward from your horizon.  The same discussion has emerged for Post Quantum Crypto algorithms.

Thanx,
Anders