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

Tue Mar 29 17:58:45 UTC 2022

> On Mar 29, 2022, at 10:18 AM, Anders Rundgren <anders.rundgren.net at gmail.com> wrote:
> 
> On 2022-03-28 21:57, xueleifan(XueleiFan) wrote:
>> Thank you for the information and discussion, Anders, Bernd and Mike.  I had a better understand of JOSE/COSE and the problems.
> 
> Thanx Xuelei!
> May I ask a highly related question?
> 
> Assume there is a new cool XYZ algorithm family supported by a third party JCE provider.
> What would be needed in order to make XYZ public keys in X.509 certificates automatically decode into an associated XYXPublicKey (also supplied by the third party)?
> 
It depends.  For the JDK X509 certificate implementation, KeyFactory are used  to generated the public key from X509 encoded key specification (public key DER value in the cert).

    X509EncodedKeySpec x509KeySpec
        = new X509EncodedKeySpec(x509EncodedKeyStream.toByteArray());
    KeyFactory keyFac = KeyFactory.getInstance(algid.getName());
    keyFac.generatePublic(x509KeySpec);

The “algid” is also recorded in the X.509 certificate.  So, a third party provider may be able to get it supported by support XYZ algorithm in its KeyFactory implementation.

    KeyFactory keyFac = KeyFactory.getInstance(“XYZ”/“XYZ-OID”);

But it really depends on the X.509 provider implementation behaviors.  I know there are cases that X.509 provider was updated, or forked, here and there in order to support new algorithms, unfortunately.

Best,
Xuelei

> I tried to follow the JDK X.509 decoder source but I failed :(
> 
> Regards,
> Anders
> 
>> For the crypto implementation, for example Ed25519 in the SunEC provider, I would prefer to keep the footprint in OpenJDK as minimal as possible.  For example, the Ed25519 key factory could accept XECPublicKeySpec and XECPrivateKeySpec only, and support no more encoding format (currently, X509EncodedKeySpec and PKCS8EncodedKeySpec are also supported by the SunEC provider).  Except COSE/JOSE/PEM, there may be a few other known encoding formats, and more in the future.  It would be challenging to track many encoding formats in specific protocols and their development in OpenJDK.  If a provider does not support protocol specific format, the application rely on it could fail, which is not good for application developers.  And thus the purpose to support more encoding format in one provider could be frangible.
>> There could be third party's encoding format specific provider, for example a KeyFactory provider accepting JOSE/COSE format and converting between XECPublicKeySpec/XECPrivateKeySpec and protocol specific formats.  The factory might belong more to the protocol specific library, rather than the OpenJDK reference implementation. Unfortunately, the current KeyFactory.getInstance(“ Ed25519”) design cannot identify the encoding formats, and thus may just return a provider that does not support the expected encoding format.  It might be a workaround to use different algorithm name, like “JOSE/Ed25519”.
>> Alternatively, the JOSE/COSE could transfer the encoded stream to XECPublicKeySpec and XECPrivateKeySpec, without using KeyFactory.  It may be transparent to application developers if the transferring is wrapped in the protocol specific lib.
>> Just my $.02.
>> Xuelei
>>> On Mar 28, 2022, at 2:30 AM, Bernd Eckenfels <ecki at zusammenkunft.net <mailto:ecki at zusammenkunft.net>> wrote:
>>> 
>>> Hello,
>>> 
>>> I think both might be too protocol specific to include it in JCE, but a library for JWK would fit into JWT support in Jakarta EE.
>>> 
>>>  For COSE the key descriptors are very simple (no certificates), not sure if anything besides a cose library is really needed. (That library would benefit from a curve registry, but since cose uses its own code values for the curve access to the CurveDB would not help I think).
>>> 
>>> CBOR is not QR specific, it’s specific for the Covid Vaccination Certificate framework (due to the QR code size restriction it can’t use JSON).
>>> 
>>> Gruss
>>> Bernd
>>> -- 
>>> http://bernd.eckenfels.net <http://bernd.eckenfels.net>
>>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>> *Von:* Anthony Scarpino <anthony.scarpino at oracle.com <mailto:anthony.scarpino at oracle.com>>
>>> *Gesendet:* Monday, March 28, 2022 6:31:29 AM
>>> *An:* Anders Rundgren <anders.rundgren.net at gmail.com <mailto:anders.rundgren.net at gmail.com>>
>>> *Cc:* Bernd Eckenfels <ecki at zusammenkunft.net <mailto:ecki at zusammenkunft.net>>; security-dev at openjdk.java.net <mailto:security-dev at openjdk.java.net> <security-dev at openjdk.java.net <mailto:security-dev at openjdk.java.net>>
>>> *Betreff:* Re: [Internet]Re: "Pluggable" key serialization in JCE/JCA
>>> Thanks for all the info. We don’t have experience with JOSE or COSE, I think we need to digest some of this data before making a future step
>>> 
>>> Not knowing this technology until you brought it up a few days ago, a few questions i have are how is this used and how common?  Would I see this used for more secure sites like banks or shopping through the browser or it more common sites. Is it only browser-based or are their other used cases?  Bernd mentioned QR codes, is COSE used inside the QR code or the authentication for the user to get to their QR code?
>>> 
>>> Thanks
>>> 
>>> Tony
>>> 
>>> > On Mar 26, 2022, at 11:48 PM, Anders Rundgren <anders.rundgren.net at gmail.com <mailto:anders.rundgren.net at gmail.com>> wrote:
>>> > > 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 <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 <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
> 