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: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption [v3]
On Thu, 10 Mar 2022 08:52:17 GMT, Сергей Цыпанов wrote: >> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with >> smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when >> called with vararg of size 0, 1, 2. >> >> In general replacement of `Arrays.asList()` with `List.of()` is dubious as >> the latter is null-hostile, however in some cases we are sure that arguments >> are non-null. Into this PR I've included the following cases (in addition to >> those where the argument is proved to be non-null at compile-time): >> - `MethodHandles.longestParameterList()` never returns null >> - parameter types are never null >> - interfaces used for proxy construction and returned from >> `Class.getInterfaces()` are never null >> - exceptions types of method signature are never null > > Сергей Цыпанов has updated the pull request incrementally with one additional > commit since the last revision: > > 8282662: Revert dubious changes in MethodType There were changes with `Set.of()`, but I've reverted them as dubious. I'll rename the ticket and PR's title. As of the second question I didn't look namely for `Collections.addAll(set, elements)`, if I find any feasible for replacement with `Set.of()` then I'll add it. - PR: https://git.openjdk.java.net/jdk/pull/7729
Re: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption [v3]
On Thu, 10 Mar 2022 08:52:17 GMT, Сергей Цыпанов wrote: >> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with >> smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when >> called with vararg of size 0, 1, 2. >> >> In general replacement of `Arrays.asList()` with `List.of()` is dubious as >> the latter is null-hostile, however in some cases we are sure that arguments >> are non-null. Into this PR I've included the following cases (in addition to >> those where the argument is proved to be non-null at compile-time): >> - `MethodHandles.longestParameterList()` never returns null >> - parameter types are never null >> - interfaces used for proxy construction and returned from >> `Class.getInterfaces()` are never null >> - exceptions types of method signature are never null > > Сергей Цыпанов has updated the pull request incrementally with one additional > commit since the last revision: > > 8282662: Revert dubious changes in MethodType Just curious, this issue asks to replace set constructions with `Set.of`, but there is no such code changes in this pull request. Is there any set creation patterns that aren't detected by your ide cleanups, such as `Collections.addAll(set, elements)` for creating hash set contents from array? - PR: https://git.openjdk.java.net/jdk/pull/7729
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
>
>
Re: RFR: 8283711: Remove redundant 'new String' calls after concatenation
On Sun, 20 Mar 2022 12:07:52 GMT, Andrey Turbanov wrote: > Result of string concatenation is a newly created String object. There is no > need it wrap it in another 'new String' call. > Such calls are confusing and produce warnings in IDE. Without them code is > easier to read. > Similar cleanup > [JDK-8273375](https://bugs.openjdk.java.net/browse/JDK-8273375) in > java.desktop Good catches! - Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7876
