<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Just for the record, the code for the EU Digital Covid
Certificate is available on GitHub at
<a class="moz-txt-link-freetext" href="https://github.com/orgs/ehn-dcc-development/repositories?language=java">https://github.com/orgs/ehn-dcc-development/repositories?language=java</a><br>
Specifically,
<a class="moz-txt-link-freetext" href="https://github.com/ehn-dcc-development/dgc-java#structure">https://github.com/ehn-dcc-development/dgc-java#structure</a> says
"CBOR, CWT/COSE - Support for representing the DGC in CBOR and to
sign/validate it. dgc-create-validate"<br>
Authentication for the user to get to their QR code was done via
an eID (at least in the countries that issue electronic IDs).</p>
<p>Kind regards<br>
Anthony<br>
</p>
<div class="moz-cite-prefix">On 28/03/2022 11:30, Bernd Eckenfels
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:AM9P193MB11426C991EB601899DE90C5CFF1D9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>
<div dir="ltr">Hello,</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">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.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr"> 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).</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">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).</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Gruss</div>
<div dir="ltr">Bernd</div>
<div id="ms-outlook-mobile-signature">
<div style="direction:ltr">-- </div>
<div style="direction:ltr"><a class="moz-txt-link-freetext" href="http://bernd.eckenfels.net">http://bernd.eckenfels.net</a></div>
</div>
</div>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
face="Calibri, sans-serif" color="#000000"><b>Von:</b> Anthony
Scarpino <a class="moz-txt-link-rfc2396E" href="mailto:anthony.scarpino@oracle.com"><anthony.scarpino@oracle.com></a><br>
<b>Gesendet:</b> Monday, March 28, 2022 6:31:29 AM<br>
<b>An:</b> Anders Rundgren
<a class="moz-txt-link-rfc2396E" href="mailto:anders.rundgren.net@gmail.com"><anders.rundgren.net@gmail.com></a><br>
<b>Cc:</b> Bernd Eckenfels <a class="moz-txt-link-rfc2396E" href="mailto:ecki@zusammenkunft.net"><ecki@zusammenkunft.net></a>;
<a class="moz-txt-link-abbreviated" href="mailto:security-dev@openjdk.java.net">security-dev@openjdk.java.net</a>
<a class="moz-txt-link-rfc2396E" href="mailto:security-dev@openjdk.java.net"><security-dev@openjdk.java.net></a><br>
<b>Betreff:</b> Re: [Internet]Re: "Pluggable" key
serialization in JCE/JCA</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span
style="font-size:11pt;">
<div class="PlainText">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
<br>
<br>
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?<br>
<br>
Thanks<br>
<br>
Tony<br>
<br>
> On Mar 26, 2022, at 11:48 PM, Anders Rundgren
<a class="moz-txt-link-rfc2396E" href="mailto:anders.rundgren.net@gmail.com"><anders.rundgren.net@gmail.com></a> wrote:<br>
> <br>
> On 2022-03-26 23:14, Bernd Eckenfels wrote:<br>
>> Just for completeness, the standard for key
transport in JOSE is JWK (RFC7517).<br>
>> In COSE it is a COSE_Key(Set) as defined in
RFC8152 sect13.<br>
>> BTW the most widely used CBOR/COSE application
are probably the QR codes around Covid and Vaccination
certificates of the EU.<br>
> <br>
> Thanx Bernd and Michael for the additional
clarifications!<br>
> <br>
> Now to the thing that spurred this discussion: <a
href="https://datatracker.ietf.org/doc/html/rfc8037"
moz-do-not-send="true" class="moz-txt-link-freetext">
https://datatracker.ietf.org/doc/html/rfc8037</a><br>
> <br>
> This document defines how to use the Diffie-Hellman
algorithms<br>
> "X25519" and "X448" as well as the signature
algorithms "Ed25519" and<br>
> "Ed448" from the IRTF CFRG elliptic curves work in
JSON Object<br>
> Signing and Encryption (JOSE).<br>
> <br>
> 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:<br>
> <a
href="https://www.ietf.org/archive/id/draft-looker-cose-bls-key-representations-00.html"
moz-do-not-send="true" class="moz-txt-link-freetext">
https://www.ietf.org/archive/id/draft-looker-cose-bls-key-representations-00.html</a><br>
> <br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> WDYT?<br>
> <br>
> 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.<br>
> <br>
> Thanx,<br>
> Anders<br>
</div>
</span></font></div>
</blockquote>
</body>
</html>