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