> On Mar 29, 2022, at 10:18 AM, Anders Rundgren <anders.rundgren....@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 <e...@zusammenkunft.net
>>> <mailto:e...@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.scarp...@oracle.com
>>> <mailto:anthony.scarp...@oracle.com>>
>>> *Gesendet:* Monday, March 28, 2022 6:31:29 AM
>>> *An:* Anders Rundgren <anders.rundgren....@gmail.com
>>> <mailto:anders.rundgren....@gmail.com>>
>>> *Cc:* Bernd Eckenfels <e...@zusammenkunft.net
>>> <mailto:e...@zusammenkunft.net>>; security-dev@openjdk.java.net
>>> <mailto:security-dev@openjdk.java.net> <security-dev@openjdk.java.net
>>> <mailto:security-dev@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....@gmail.com <mailto:anders.rundgren....@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
>
