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

[Anthony Vanelverdinghe]

Just for the record, the code for the EU Digital Covid Certificate is 
available on GitHub at 
https://github.com/orgs/ehn-dcc-development/repositories?language=java
Specifically, https://github.com/ehn-dcc-development/dgc-java#structure 
says "CBOR, CWT/COSE - Support for representing the DGC in CBOR and to 
sign/validate it. dgc-create-validate"
Authentication for the user to get to their QR code was done via an eID 
(at least in the countries that issue electronic IDs).

Kind regards
Anthony

On 28/03/2022 11:30, Bernd Eckenfels 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
> ------------------------------------------------------------------------
> *Von:* Anthony Scarpino <anthony.scarpino at oracle.com>
> *Gesendet:* Monday, March 28, 2022 6:31:29 AM
> *An:* Anders Rundgren <anders.rundgren.net at gmail.com>
> *Cc:* Bernd Eckenfels <ecki at zusammenkunft.net>; 
> security-dev at openjdk.java.net <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> 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
> >
> >   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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20220328/73475a57/attachment.htm>