Re: [Internet]Re: "Pluggable" key serialization in JCE/JCA
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 >> <mailto:anthony.scarp...@oracle.com>> >>> *Gesendet:* Monday, March 28, 2022 6:31:29 AM >>> *An:* Anders Rundgren >> <mailto:anders.rundgren@gmail.com>> >>> *Cc:* Bernd Eckenfels >> <mailto:e...@zusammenkunft.net>>; security-dev@openjdk.java.net >>> <mailto: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 >>> > 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 >
Re: [Internet]Re: "Pluggable" key serialization in JCE/JCA
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 *Gesendet:* Monday, March 28, 2022 6:31:29 AM *An:* Anders Rundgren *Cc:* Bernd Eckenfels ; 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 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
Re: [Internet]Re: "Pluggable" key serialization in JCE/JCA
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 Gesendet: Monday, March 28, 2022 6:31:29 AM An: Anders Rundgren Cc: Bernd Eckenfels ; 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 > 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
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 > 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
Re: [Internet]Re: "Pluggable" key serialization in JCE/JCA
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
Re: [Internet]Re: "Pluggable" key serialization in JCE/JCA
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. Gruss Bernd -- http://bernd.eckenfels.net Von: security-dev im Auftrag von Michael StJohns Gesendet: Samstag, März 26, 2022 10:29 PM An: security-dev@openjdk.java.net Betreff: Re: [Internet]Re: "Pluggable" key serialization in JCE/JCA On 3/26/2022 11:05 AM, xueleifan(XueleiFan) wrote: > Hi Anders, > > I would like to have look at the COSE/JOSE specs. If it is convenient to > you, any suggestions about where I could start from? RFC 8812? Do you know > where (areas and products) the COSE/JOSE specs are used in practice? > > Thanks, > Xuelei Hi Xuelei - Just for clarification - JOSE/COSE are data description languages with specific provisions for encoding various type of cryptographic key material. E.g. think ASN1 ~= JOSE or COSE and the RFC's that Anders is pointing you at as approximately equal to PKCS8 and X.509 plus the key type specific stuff (e.g. PKCS1 for RSA key encodings, X9.63 for EC key encodings, later IETF RFCs for newer encodings). This isn't about math so much as it is about encodings. Mike > >> On Mar 25, 2022, at 11:56 AM, Anders Rundgren >> wrote: >> >> Hi Michael & the JDK crypto team, >> >> Although it might be cool writing a JEP it is not really my job. There are >> also multiple ways of addressing this issue. >> >> BTW, the COSE/JOSE folks who are about to introduce new algorithms want to >> overload RFC 8037 which defines a key type OKP. >> I'm not in favor of this idea since breaks existing OKP code. >> I'm suggesting that each new crypto system should get its own name space and >> thus long-term corresponding Java interfaces. >> >> Since this is happening NOW and there is no turning back, it would be useful >> to get some early feedback from the JDK folks. In fact, this is the origin >> of this request. >> >> It seems that nobody representing JDK crypto is involved in COSE/JOSE. >> >> Thanx, >> Anders >> >> >> On 2022-03-25 18:23, Michael StJohns wrote: >>> On 3/25/2022 12:33 PM, Anders Rundgren wrote: >>>> On 2022-03-25 17:12, Anthony Scarpino wrote: >>>>> When you say "construct and EC key", do you mean creating an EC key from >>>>> an existing set of values via PKCS8 or X509 encoding? Or are you >>>>> talking about EC key generation? >>>> I was talking about creating keys from parameter data supplied by for >>>> example JOSE: >>>>{ >>>> "kty": "EC", >>>> "crv": "P-256", >>>> "x": "6BKxpty8cI-exDzCkh-goU6dXq3MbcY0cd1LaAxiNrU", >>>> "y": "mCbcvUzm44j3Lt2b5BPyQloQ91tf2D2V-gzeUxWaUdg" >>>>} >>>> >>>> Apparently this particular issue have solution (as Michael StJohns >>>> showed), although it is not particularity intuitive as well as >>>> undocumented. >>>> >>>> Another take on this issue: >>>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/security/Key.html#getEncoded() >>>> >>>> "Returns the key in its primary encoding format, or null if this key >>>> does not support encoding" >>>> >>>> With COSE/JOSE there is no longer an obvious primary encoding format. >>> Of course there is. You may not like that it's not COSE or JOSE, but >>> the encoding spec remains as is and 10s of 1000s of implementations that >>> use that encoding would be annoyed if you tried to claim a new "primary >>> encoding format". >>> The SubjectPublicKeyInfo encoding for PublicKeys, the PKCS8 encoding for >>> private keys, and RAW encoding for SecretKeys is what's there and I'm >>> pretty sure won't change. I occasionally wished for a getEncoded() >>> method that took an encoding type as an argument (e.g. >>> getEncoded("bareXY") or some such), but that's not in the API. >>> What I'd suggest is that you write a JEP for adding EncodedKeySpec >>> classes for COSE and JOSE to the API. I'd probably also add a >>> GenericKeyEncodingSpec class. That should be simple enough as a first step. >>> The second step would be to write and contribute a Jose and Cose >>> KeyFactory implementation that uses those classes. >>> As I noted, it should be possible to externalize any preferred encoding >>> by using the getKeySpec method of KeyFactory rather than just the key >>> types default encoding. >>> Later, Mike >>>> Anders >>>> >>>>> Tony >>
Re: [Internet]Re: "Pluggable" key serialization in JCE/JCA
On 3/26/2022 11:05 AM, xueleifan(XueleiFan) wrote: Hi Anders, I would like to have look at the COSE/JOSE specs. If it is convenient to you, any suggestions about where I could start from? RFC 8812? Do you know where (areas and products) the COSE/JOSE specs are used in practice? Thanks, Xuelei Hi Xuelei - Just for clarification - JOSE/COSE are data description languages with specific provisions for encoding various type of cryptographic key material. E.g. think ASN1 ~= JOSE or COSE and the RFC's that Anders is pointing you at as approximately equal to PKCS8 and X.509 plus the key type specific stuff (e.g. PKCS1 for RSA key encodings, X9.63 for EC key encodings, later IETF RFCs for newer encodings). This isn't about math so much as it is about encodings. Mike On Mar 25, 2022, at 11:56 AM, Anders Rundgren wrote: Hi Michael & the JDK crypto team, Although it might be cool writing a JEP it is not really my job. There are also multiple ways of addressing this issue. BTW, the COSE/JOSE folks who are about to introduce new algorithms want to overload RFC 8037 which defines a key type OKP. I'm not in favor of this idea since breaks existing OKP code. I'm suggesting that each new crypto system should get its own name space and thus long-term corresponding Java interfaces. Since this is happening NOW and there is no turning back, it would be useful to get some early feedback from the JDK folks. In fact, this is the origin of this request. It seems that nobody representing JDK crypto is involved in COSE/JOSE. Thanx, Anders On 2022-03-25 18:23, Michael StJohns wrote: On 3/25/2022 12:33 PM, Anders Rundgren wrote: On 2022-03-25 17:12, Anthony Scarpino wrote: When you say "construct and EC key", do you mean creating an EC key from an existing set of values via PKCS8 or X509 encoding? Or are you talking about EC key generation? I was talking about creating keys from parameter data supplied by for example JOSE: { "kty": "EC", "crv": "P-256", "x": "6BKxpty8cI-exDzCkh-goU6dXq3MbcY0cd1LaAxiNrU", "y": "mCbcvUzm44j3Lt2b5BPyQloQ91tf2D2V-gzeUxWaUdg" } Apparently this particular issue have solution (as Michael StJohns showed), although it is not particularity intuitive as well as undocumented. Another take on this issue: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/security/Key.html#getEncoded() "Returns the key in its primary encoding format, or null if this key does not support encoding" With COSE/JOSE there is no longer an obvious primary encoding format. Of course there is. You may not like that it's not COSE or JOSE, but the encoding spec remains as is and 10s of 1000s of implementations that use that encoding would be annoyed if you tried to claim a new "primary encoding format". The SubjectPublicKeyInfo encoding for PublicKeys, the PKCS8 encoding for private keys, and RAW encoding for SecretKeys is what's there and I'm pretty sure won't change. I occasionally wished for a getEncoded() method that took an encoding type as an argument (e.g. getEncoded("bareXY") or some such), but that's not in the API. What I'd suggest is that you write a JEP for adding EncodedKeySpec classes for COSE and JOSE to the API. I'd probably also add a GenericKeyEncodingSpec class. That should be simple enough as a first step. The second step would be to write and contribute a Jose and Cose KeyFactory implementation that uses those classes. As I noted, it should be possible to externalize any preferred encoding by using the getKeySpec method of KeyFactory rather than just the key types default encoding. Later, Mike Anders Tony
Re: [Internet]Re: "Pluggable" key serialization in JCE/JCA
On 2022-03-26 16:05, xueleifan(XueleiFan) wrote: Hi Anders, I would like to have look at the COSE/JOSE specs. If it is convenient to you, any suggestions about where I could start from? RFC 8812? Do you know where (areas and products) the COSE/JOSE specs are used in practice? Hi Xuelei, The core JOSE RFCs should be Signatures: https://www.rfc-editor.org/rfc/rfc7515.html Encryption: https://www.rfc-editor.org/rfc/rfc7516.html Algorithms: https://www.rfc-editor.org/rfc/rfc7518.html Ed*,X* support https://www.rfc-editor.org/rfc/rfc8037.html COSE: https://www.rfc-editor.org/rfc/rfc8152.html JOSE is a very wide-spread standard. It is for example a part of OAuth used by for example most social media platforms as well as GitHub. It is nowadays de-facto the replacement for XML Dsig. COSE has a more narrow set of applications but with a huge volume like IoT. It is also a part of FIDO which is how I came in contact with COSE. We will eventually all use FIDO. If there is anything you want to ask, just send me an e-mail, anytime. I'm not a cryptographer but a user of crypto which is why I'm a little bit "obsessed" with the high level APIs :) Regards, Anders Thanks, Xuelei On Mar 25, 2022, at 11:56 AM, Anders Rundgren wrote: Hi Michael & the JDK crypto team, Although it might be cool writing a JEP it is not really my job. There are also multiple ways of addressing this issue. BTW, the COSE/JOSE folks who are about to introduce new algorithms want to overload RFC 8037 which defines a key type OKP. I'm not in favor of this idea since breaks existing OKP code. I'm suggesting that each new crypto system should get its own name space and thus long-term corresponding Java interfaces. Since this is happening NOW and there is no turning back, it would be useful to get some early feedback from the JDK folks. In fact, this is the origin of this request. It seems that nobody representing JDK crypto is involved in COSE/JOSE. Thanx, Anders On 2022-03-25 18:23, Michael StJohns wrote: On 3/25/2022 12:33 PM, Anders Rundgren wrote: On 2022-03-25 17:12, Anthony Scarpino wrote: When you say "construct and EC key", do you mean creating an EC key from an existing set of values via PKCS8 or X509 encoding? Or are you talking about EC key generation? I was talking about creating keys from parameter data supplied by for example JOSE: { "kty": "EC", "crv": "P-256", "x": "6BKxpty8cI-exDzCkh-goU6dXq3MbcY0cd1LaAxiNrU", "y": "mCbcvUzm44j3Lt2b5BPyQloQ91tf2D2V-gzeUxWaUdg" } Apparently this particular issue have solution (as Michael StJohns showed), although it is not particularity intuitive as well as undocumented. Another take on this issue: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/security/Key.html#getEncoded() "Returns the key in its primary encoding format, or null if this key does not support encoding" With COSE/JOSE there is no longer an obvious primary encoding format. Of course there is. You may not like that it's not COSE or JOSE, but the encoding spec remains as is and 10s of 1000s of implementations that use that encoding would be annoyed if you tried to claim a new "primary encoding format". The SubjectPublicKeyInfo encoding for PublicKeys, the PKCS8 encoding for private keys, and RAW encoding for SecretKeys is what's there and I'm pretty sure won't change. I occasionally wished for a getEncoded() method that took an encoding type as an argument (e.g. getEncoded("bareXY") or some such), but that's not in the API. What I'd suggest is that you write a JEP for adding EncodedKeySpec classes for COSE and JOSE to the API. I'd probably also add a GenericKeyEncodingSpec class. That should be simple enough as a first step. The second step would be to write and contribute a Jose and Cose KeyFactory implementation that uses those classes. As I noted, it should be possible to externalize any preferred encoding by using the getKeySpec method of KeyFactory rather than just the key types default encoding. Later, Mike Anders Tony
Re: [Internet]Re: "Pluggable" key serialization in JCE/JCA
Hi Anders, I would like to have look at the COSE/JOSE specs. If it is convenient to you, any suggestions about where I could start from? RFC 8812? Do you know where (areas and products) the COSE/JOSE specs are used in practice? Thanks, Xuelei > On Mar 25, 2022, at 11:56 AM, Anders Rundgren > wrote: > > Hi Michael & the JDK crypto team, > > Although it might be cool writing a JEP it is not really my job. There are > also multiple ways of addressing this issue. > > BTW, the COSE/JOSE folks who are about to introduce new algorithms want to > overload RFC 8037 which defines a key type OKP. > I'm not in favor of this idea since breaks existing OKP code. > I'm suggesting that each new crypto system should get its own name space and > thus long-term corresponding Java interfaces. > > Since this is happening NOW and there is no turning back, it would be useful > to get some early feedback from the JDK folks. In fact, this is the origin > of this request. > > It seems that nobody representing JDK crypto is involved in COSE/JOSE. > > Thanx, > Anders > > > On 2022-03-25 18:23, Michael StJohns wrote: >> On 3/25/2022 12:33 PM, Anders Rundgren wrote: >>> On 2022-03-25 17:12, Anthony Scarpino wrote: When you say "construct and EC key", do you mean creating an EC key from an existing set of values via PKCS8 or X509 encoding? Or are you talking about EC key generation? >>> >>> I was talking about creating keys from parameter data supplied by for >>> example JOSE: >>> { >>> "kty": "EC", >>> "crv": "P-256", >>> "x": "6BKxpty8cI-exDzCkh-goU6dXq3MbcY0cd1LaAxiNrU", >>> "y": "mCbcvUzm44j3Lt2b5BPyQloQ91tf2D2V-gzeUxWaUdg" >>> } >>> >>> Apparently this particular issue have solution (as Michael StJohns >>> showed), although it is not particularity intuitive as well as >>> undocumented. >>> >>> Another take on this issue: >>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/security/Key.html#getEncoded() >>> >>> "Returns the key in its primary encoding format, or null if this key >>> does not support encoding" >>> >>> With COSE/JOSE there is no longer an obvious primary encoding format. >> Of course there is. You may not like that it's not COSE or JOSE, but >> the encoding spec remains as is and 10s of 1000s of implementations that >> use that encoding would be annoyed if you tried to claim a new "primary >> encoding format". >> The SubjectPublicKeyInfo encoding for PublicKeys, the PKCS8 encoding for >> private keys, and RAW encoding for SecretKeys is what's there and I'm >> pretty sure won't change. I occasionally wished for a getEncoded() >> method that took an encoding type as an argument (e.g. >> getEncoded("bareXY") or some such), but that's not in the API. >> What I'd suggest is that you write a JEP for adding EncodedKeySpec >> classes for COSE and JOSE to the API. I'd probably also add a >> GenericKeyEncodingSpec class. That should be simple enough as a first step. >> The second step would be to write and contribute a Jose and Cose >> KeyFactory implementation that uses those classes. >> As I noted, it should be possible to externalize any preferred encoding >> by using the getKeySpec method of KeyFactory rather than just the key >> types default encoding. >> Later, Mike >>> >>> Anders >>> Tony > >