Re: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v5]
On Sat, 26 Mar 2022 00:27:19 GMT, Valerie Peng wrote: >> Almost the whole class spec is copied from PKCS #1 but at the end you have >> "defined in the ASN.1 encoding from the PKCS#1 standard", which might make >> people wonder if it is something else. If you don't want to remove anything, >> how about "defined in the ASN.1 encoding from the PKCS#1 standard above". >> It's verbose but not confusing. >> >> BTW, on >> https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/security/spec/PSSParameterSpec.html, >> the whole "Note" is shown on one line. I guess that's not intended. > > Ah, Ok, I think I see what you are saying now. I agree about trimming the > class spec. Are you ok with removing line 67-77 (proposed/new version)? This > would reduce the duplication of wordings. Good suggestion. - PR: https://git.openjdk.java.net/jdk/pull/7913
Re: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v5]
On Fri, 25 Mar 2022 21:49:07 GMT, Weijun Wang wrote: >> I am not sure if everyone reads the complete spec from class to fields and >> methods. Which part do you want to remove and just use "defined above"? >> Personally, I find "above" kind of vague... It's better to keep the comment >> near the field. Perhaps we should trim the class spec instead? > > Almost the whole class spec is copied from PKCS #1 but at the end you have > "defined in the ASN.1 encoding from the PKCS#1 standard", which might make > people wonder if it is something else. If you don't want to remove anything, > how about "defined in the ASN.1 encoding from the PKCS#1 standard above". > It's verbose but not confusing. > > BTW, on > https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/security/spec/PSSParameterSpec.html, > the whole "Note" is shown on one line. I guess that's not intended. Ah, Ok, I think I see what you are saying now. I agree about trimming the class spec. Are you ok with removing line 67-77 (proposed/new version)? This would reduce the duplication of wordings. - PR: https://git.openjdk.java.net/jdk/pull/7913
Re: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v5]
On Fri, 25 Mar 2022 21:34:28 GMT, Valerie Peng wrote:
>> src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 78:
>>
>>> 76: * Please do not rely on {@code PSSParameterSpec.DEFAULT} unless these
>>> 77: * values are really what you want to use.
>>> 78: *
>>
>> I just read the whole class spec. Since the default values are already
>> included on lines 38-41, I think there is no need to use so much words and
>> we can just say "defined above".
>
> I am not sure if everyone reads the complete spec from class to fields and
> methods. Which part do you want to remove and just use "defined above"?
> Personally, I find "above" kind of vague... It's better to keep the comment
> near the field. Perhaps we should trim the class spec instead?
Almost the whole class spec is copied from PKCS #1 but at the end you have
"defined in the ASN.1 encoding from the PKCS#1 standard", which might make
people wonder if it is something else. If you don't want to remove anything,
how about "defined in the ASN.1 encoding from the PKCS#1 standard above". It's
verbose but not confusing.
BTW, on
https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/security/spec/PSSParameterSpec.html,
the whole "Note" is shown on one line. I guess that's not intended.
-
PR: https://git.openjdk.java.net/jdk/pull/7913
Re: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v5]
On Fri, 25 Mar 2022 01:33:12 GMT, Weijun Wang wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> More minor edits.
>
> src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 78:
>
>> 76: * Please do not rely on {@code PSSParameterSpec.DEFAULT} unless these
>> 77: * values are really what you want to use.
>> 78: *
>
> I just read the whole class spec. Since the default values are already
> included on lines 38-41, I think there is no need to use so much words and we
> can just say "defined above".
I am not sure if everyone reads the complete spec from class to fields and
methods. Which part do you want to remove and just use "defined above"?
Personally, I find "above" kind of vague... It's better to keep the comment
near the field. Perhaps we should trim the class spec instead?
-
PR: https://git.openjdk.java.net/jdk/pull/7913
Integrated: 8283691: Classes in java.security still reference deprecated classes in spec
On Fri, 25 Mar 2022 15:34:23 GMT, Weijun Wang wrote: > Some spec cleanup. This pull request has now been integrated. Changeset: e97cf157 Author:Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/e97cf157cf20aeaef4a8c16fed6f3bb2bc933819 Stats: 6 lines in 3 files changed: 0 ins; 2 del; 4 mod 8283691: Classes in java.security still reference deprecated classes in spec Reviewed-by: hchao, mullan, wetmore - PR: https://git.openjdk.java.net/jdk/pull/7961
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 the compiler changes looks good - Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7876
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 LGTM. - Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7876
Re: RFR: 8283691: Classes in java.security still reference deprecated classes in spec
On Fri, 25 Mar 2022 15:34:23 GMT, Weijun Wang wrote: > Some spec cleanup. LGTM. - Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7961
RFR: 8283711: Remove redundant 'new String' calls after concatenation
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 - Commit messages: - [PATCH] Remove redundant 'new String' calls after concatenation - [PATCH] Remove redundant 'new String' calls after concatenation Changes: https://git.openjdk.java.net/jdk/pull/7876/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7876=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283711 Stats: 13 lines in 3 files changed: 0 ins; 1 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/7876.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7876/head:pull/7876 PR: https://git.openjdk.java.net/jdk/pull/7876
Re: "Pluggable" key serialization in JCE/JCA
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: 8283691: Classes in java.security still reference deprecated classes in spec
On Fri, 25 Mar 2022 15:34:23 GMT, Weijun Wang wrote: > Some spec cleanup. Marked as reviewed by mullan (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7961
Re: RFR: 8283691: Classes in java.security still reference deprecated classes in spec
On Fri, 25 Mar 2022 15:34:23 GMT, Weijun Wang wrote: > Some spec cleanup. Marked as reviewed by hchao (Committer). - PR: https://git.openjdk.java.net/jdk/pull/7961
Re: "Pluggable" key serialization in JCE/JCA
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: "Pluggable" key serialization in JCE/JCA
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
Integrated: 8283665: Two Jarsigner tests needs to be updated with JDK-8267319
On Fri, 25 Mar 2022 05:11:18 GMT, Valerie Peng wrote: > Max, can you please help review this fix? It updates the two jarsigner tests > which are added to the main trunk during the code review of JDK-8267319. > > Mach5 run succeeds. > Thanks, > Valerie This pull request has now been integrated. Changeset: 3b5dfee9 Author:Valerie Peng URL: https://git.openjdk.java.net/jdk/commit/3b5dfee939dda02e14498baa2b52b0150326b938 Stats: 13 lines in 2 files changed: 0 ins; 0 del; 13 mod 8283665: Two Jarsigner tests needs to be updated with JDK-8267319 Reviewed-by: xuelei, ascarpino, hchao, weijun - PR: https://git.openjdk.java.net/jdk/pull/7952
Re: "Pluggable" key serialization in JCE/JCA
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.
Anders
Tony
On 3/25/22 1:03 AM, Anders Rundgren wrote:
Hi Mike & the JDK crypto team,
What I'm saying is that key serialization in Java haven't gotten enough
attention. Examples:
AFAIK, there is still no support for using named curves to construct an
EC key. Names curves are MANDATORY in JOSE/CODE.
The gap between EdDSA keys as expressed in JOSE/COSE and the Java API is
simply put GIGANTIC:
https://mail.openjdk.java.net/pipermail/security-dev/2020-August/022379.html
The only obvious solution is rolling your own:
https://github.com/cyberphone/openkeystore/blob/master/library/src/org/webpki/crypto/OkpSupport.java
This code [probably] stinks but it is hardly my fault...
The JDK crypto team is the only party who can clean up this mess.
Since importing X.509 certificates through PKCS12/KeyStore works out of
the box without any a prior knowledge of key algorithms, there is
already a precedent. It is almost just copy and paste :)
The new crypto systems that are on the way in (BLS, Post Quantum),
accentuates this issue.
Regarding HSMs, I gave it one more thought and I didn't come up with any
connections except maybe in Keytool but HSMs appear to be X.509-oriented
which not the case with COSE/JOSE.
Regards,
Anders
On 2022-03-25 3:12, Michael StJohns wrote:
On 3/24/2022 12:28 PM, Anders Rundgren wrote:
On 2022-03-24 16:59, Michael StJohns wrote:
On 3/24/2022 2:46 AM, Anders Rundgren wrote:
Hi List,
I find it a bit strange that every user of crypto either have to write
or install specific software for converting JOSE/COSE/PEM keys
back-and-forth to Java's internal representation. This reduces the
value of the abstract types as well.
Now there is whole bunch of new algorithms coming to the Java platform
making this task even less attractive.
So my question is simply: How about including this part in an enhanced
JCE/JCA? That is, making the encoder/decoder "pluggable" and hiding
this complexity from users and library developers?
Hi Anders -
Hi Mike,
Isn't that the exact purpose for KeyFactory and its plugins?
They presume that you know not only the key algorithm but the
associated parameters as well. Why should users or library developers
have to deal with that?
Um - no. They presume you know the key algorithm, but (using EC Public
keys for example), you can use either of the X509PublicKeySpec (to
decode an encoded key), or the ECPublicKeySpec (to deal with building a
key from scratch using the parameters. You can notionally (haven't
tried it, but should work) use KeyFactory.getKeySpec() to convert
between the two formats or use Key.getEncoded() to get the default
encoding for the key.
The equivalent on the ECPrivateKey side are the ECPrivateKeySpec and
PKCS8EncodedKeySpec clases.
PEM is actually not an encoding, but a wrapping of an encoding. The only
part of Java that deals with it natively (I believe) is the
CertificateFactory for X.509 certificates. You may have an extra step
to add or remove a PEM style envelope (or the equivalent BASE64 bare
string), but that's reasonable.
The requirement to know key algorithm in advance forces you into ASN.1
decoding for dealing with PEMs. Been there done that.
Ah - not sure why you wouldn't know the key algorithm, BUT: It should
theoretically be possible to write a KeyFactory provider that does that
decoding for you from the X509PublicKeySpec (or PKCS8PrivateKeySpec) and
returns an appropriate PublicKey. Check the actual return type to figure
out what type of key. E.g.:
KeyFactory kf = KeyFactory.getInstance("GenericDecoder");
As I said below, you'll need to define the equivalent opaque format
KeySpec classes to handle COSE and JOSE. I think that's a class per
type of encoding.
You might need to add KeySpec types for Jose and Cose
(JOSEEncodedKeySpec and COSEEncodedKeySpec) assuming both of those
cover
all of the secret, public and private key specifications.
Or hmm... GenericEncodedKeySpec (String alg, byte[] encoded key) or
GenericEncodedKeySpec (String alg, String encodedKey).
Eventually you could end up with something like:
Re: RFR: 8282819: Deprecate Locale class constructors
On Fri, 25 Mar 2022 15:37:36 GMT, Roger Riggs wrote:
>> Proposing to deprecate the constructors in the `java.util.Locale` class.
>> There is already a factory method and a builder to return singletons, so
>> there is no need to have constructors anymore unless one purposefully wants
>> to create `ill-formed` Locale objects, which is discouraged. We cannot
>> terminally deprecate those constructors for the compatibility to serialized
>> objects created with older JDKs. Please see the draft CSR for more detail.
>
> src/java.base/share/classes/java/util/Locale.java line 245:
>
>> 243: * Factory Method
>> 244: *
>> 245: * The method {@link #forLanguageTag} obtains a {@code Locale}
>
> The factory name `forLanguageTag` is a bit off-putting, it doesn't seem like
> the best name for the factory.
> Yes, it already exists and does what's required but you might get better
> uptake with a more natural name.
>
> Some alternatives:
> - `Locale.of("en_US")` - short and conventional
> - `Locale.ofLanguage("en_US")` - 'of' prefix is used in other factories
> - `Locale.forLanguage("en_US")` - natural but less conventional
I was thinking of a *new* factory method, along the line with Stuart's
suggestion, something like this:
Locale.of(String... elements)
where elements can either `(lang)`, `(lang, ctry)`, `(lang, ctry, vrnt)`, or
`(lang, ctry, vrnt, scpt)`. Either element can be an empty string, but cannot
be null. These elements are *not* language tags, but conventional arguments to
constructors, so it is compatible (and works as a stop-gap) to the old
constructors. This way third parties will not have to deal with the boilerplate
code mentioned above on migration.
-
PR: https://git.openjdk.java.net/jdk/pull/7947
Re: RFR: 8282819: Deprecate Locale class constructors
On Thu, 24 Mar 2022 22:01:30 GMT, Naoto Sato wrote: > Proposing to deprecate the constructors in the `java.util.Locale` class. > There is already a factory method and a builder to return singletons, so > there is no need to have constructors anymore unless one purposefully wants > to create `ill-formed` Locale objects, which is discouraged. We cannot > terminally deprecate those constructors for the compatibility to serialized > objects created with older JDKs. Please see the draft CSR for more detail. Given the large number of cleanups, I would have suggested to keep them separate from the change to re-focus the API on factories. - PR: https://git.openjdk.java.net/jdk/pull/7947
Re: "Pluggable" key serialization in JCE/JCA
On 3/25/2022 12:07 PM, Michael StJohns wrote:
AFAIK, there is still no support for using named curves to construct
an EC key. Names curves are MANDATORY in JOSE/CODE.
Use AlgorithmParameterGenerator with ECGenParameterSpec. Works like a
charm.
Sorry - Got that slightly wrong. Use this instead:
AlgorithmParameters parameters = AlgorithmParameters.getInstance("EC",
"SunEC"); parameters.init(newECGenParameterSpec
("secp128r1"));
ECParameterSpec ecParameters =
parameters.getParameterSpec(ECParameterSpec.class); ECPublicKeySpec
pubKeySpec = newECPublicKeySpec(point, ecParameters); PublicKey key =
KeyFactory.getInstance("EC", "SunEC").generatePublic(pubKeySpec);
Re: "Pluggable" key serialization in JCE/JCA
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?
Tony
On 3/25/22 1:03 AM, Anders Rundgren wrote:
Hi Mike & the JDK crypto team,
What I'm saying is that key serialization in Java haven't gotten enough
attention. Examples:
AFAIK, there is still no support for using named curves to construct an
EC key. Names curves are MANDATORY in JOSE/CODE.
The gap between EdDSA keys as expressed in JOSE/COSE and the Java API is
simply put GIGANTIC:
https://mail.openjdk.java.net/pipermail/security-dev/2020-August/022379.html
The only obvious solution is rolling your own:
https://github.com/cyberphone/openkeystore/blob/master/library/src/org/webpki/crypto/OkpSupport.java
This code [probably] stinks but it is hardly my fault...
The JDK crypto team is the only party who can clean up this mess.
Since importing X.509 certificates through PKCS12/KeyStore works out of
the box without any a prior knowledge of key algorithms, there is
already a precedent. It is almost just copy and paste :)
The new crypto systems that are on the way in (BLS, Post Quantum),
accentuates this issue.
Regarding HSMs, I gave it one more thought and I didn't come up with any
connections except maybe in Keytool but HSMs appear to be X.509-oriented
which not the case with COSE/JOSE.
Regards,
Anders
On 2022-03-25 3:12, Michael StJohns wrote:
On 3/24/2022 12:28 PM, Anders Rundgren wrote:
On 2022-03-24 16:59, Michael StJohns wrote:
On 3/24/2022 2:46 AM, Anders Rundgren wrote:
Hi List,
I find it a bit strange that every user of crypto either have to write
or install specific software for converting JOSE/COSE/PEM keys
back-and-forth to Java's internal representation. This reduces the
value of the abstract types as well.
Now there is whole bunch of new algorithms coming to the Java platform
making this task even less attractive.
So my question is simply: How about including this part in an enhanced
JCE/JCA? That is, making the encoder/decoder "pluggable" and hiding
this complexity from users and library developers?
Hi Anders -
Hi Mike,
Isn't that the exact purpose for KeyFactory and its plugins?
They presume that you know not only the key algorithm but the
associated parameters as well. Why should users or library developers
have to deal with that?
Um - no. They presume you know the key algorithm, but (using EC Public
keys for example), you can use either of the X509PublicKeySpec (to
decode an encoded key), or the ECPublicKeySpec (to deal with building a
key from scratch using the parameters. You can notionally (haven't
tried it, but should work) use KeyFactory.getKeySpec() to convert
between the two formats or use Key.getEncoded() to get the default
encoding for the key.
The equivalent on the ECPrivateKey side are the ECPrivateKeySpec and
PKCS8EncodedKeySpec clases.
PEM is actually not an encoding, but a wrapping of an encoding. The only
part of Java that deals with it natively (I believe) is the
CertificateFactory for X.509 certificates. You may have an extra step
to add or remove a PEM style envelope (or the equivalent BASE64 bare
string), but that's reasonable.
The requirement to know key algorithm in advance forces you into ASN.1
decoding for dealing with PEMs. Been there done that.
Ah - not sure why you wouldn't know the key algorithm, BUT: It should
theoretically be possible to write a KeyFactory provider that does that
decoding for you from the X509PublicKeySpec (or PKCS8PrivateKeySpec) and
returns an appropriate PublicKey. Check the actual return type to figure
out what type of key. E.g.:
KeyFactory kf = KeyFactory.getInstance("GenericDecoder");
As I said below, you'll need to define the equivalent opaque format
KeySpec classes to handle COSE and JOSE. I think that's a class per
type of encoding.
You might need to add KeySpec types for Jose and Cose
(JOSEEncodedKeySpec and COSEEncodedKeySpec) assuming both of those
cover
all of the secret, public and private key specifications.
Or hmm... GenericEncodedKeySpec (String alg, byte[] encoded key) or
GenericEncodedKeySpec (String alg, String encodedKey).
Eventually you could end up with something like:
PrivateKey privateKey = new KeyConverter().readPrivateKey(byte[] or
stream);
You would not even have to know in which format the key is supplied in
since this could be accomplished by simple "sniffing".
Nope. This isn't safe as someone might up with yet another
representation that looks like one of the "sniffable" ones. You could
build a private implementation that takes its best shot, but
Finding out if the container is COSE, JOSE, or PEM is (AFAICT)
trivial. If the guess is incorrect a properly designed decoder should
simply fail.
It's trivial NOW because its a closed set of possibilities. And even
then, you're assuming you don't have to detect ASN1 vs raw key encodings
vs string
Re: "Pluggable" key serialization in JCE/JCA
On 3/25/2022 4:03 AM, Anders Rundgren wrote: Hi Mike & the JDK crypto team, What I'm saying is that key serialization in Java haven't gotten enough attention. Examples: AFAIK, there is still no support for using named curves to construct an EC key. Names curves are MANDATORY in JOSE/CODE. Use AlgorithmParameterGenerator with ECGenParameterSpec. Works like a charm. The gap between EdDSA keys as expressed in JOSE/COSE and the Java API is simply put GIGANTIC: https://mail.openjdk.java.net/pipermail/security-dev/2020-August/022379.html The only obvious solution is rolling your own: https://github.com/cyberphone/openkeystore/blob/master/library/src/org/webpki/crypto/OkpSupport.java This code [probably] stinks but it is hardly my fault... TL;dr - but if you're talking about EDDSA and the equivalent ECDH functions their related key ilk - well, I tried, but lost the battle to use the same API as the existing key material. I'd call that a self inflicted wound. The JDK crypto team is the only party who can clean up this mess. Since importing X.509 certificates through PKCS12/KeyStore works out of the box without any a prior knowledge of key algorithms, there is already a precedent. It is almost just copy and paste :) Yeah, but even then that model has problems. Cf the discussion on this list about an RSA key that was marked with RSA-OAEP as its algorithm and the issued I encountered being able to use it as java key material. I got back a PublicKey, but one that I couldn't coerce into an RSAPublicKey without re-encoding the key and changing the algorithm OID - it just wasn't supported. And that model only knows about ASN1 - or did someone update the CertificateFactory for JOSE/COSE format certificates (if such a thing exists)? The new crypto systems that are on the way in (BLS, Post Quantum), accentuates this issue. And the "converter" as you call it will be far behind. Regarding HSMs, I gave it one more thought and I didn't come up with any connections except maybe in Keytool but HSMs appear to be X.509-oriented which not the case with COSE/JOSE. Think PKCS11, the PKCS11 Java provider, and the ability to retrieve a public key from an HSM for various purposes. The ability to place a private key on the HSM to secure it (there are a number of use cases where generating an unextractable private key on the HSM - the usual model - can't be used). HSMs are cryptographically oriented not X509 oriented and new mechanisms and key types are added all the time. They have tools to do the key loading directly - from well known formats, or programatically through things like Java PKCS11 or C PKCS11. Later, Mike Regards, Anders On 2022-03-25 3:12, Michael StJohns wrote: On 3/24/2022 12:28 PM, Anders Rundgren wrote: On 2022-03-24 16:59, Michael StJohns wrote: On 3/24/2022 2:46 AM, Anders Rundgren wrote: Hi List, I find it a bit strange that every user of crypto either have to write or install specific software for converting JOSE/COSE/PEM keys back-and-forth to Java's internal representation. This reduces the value of the abstract types as well. Now there is whole bunch of new algorithms coming to the Java platform making this task even less attractive. So my question is simply: How about including this part in an enhanced JCE/JCA? That is, making the encoder/decoder "pluggable" and hiding this complexity from users and library developers? Hi Anders - Hi Mike, Isn't that the exact purpose for KeyFactory and its plugins? They presume that you know not only the key algorithm but the associated parameters as well. Why should users or library developers have to deal with that? Um - no. They presume you know the key algorithm, but (using EC Public keys for example), you can use either of the X509PublicKeySpec (to decode an encoded key), or the ECPublicKeySpec (to deal with building a key from scratch using the parameters. You can notionally (haven't tried it, but should work) use KeyFactory.getKeySpec() to convert between the two formats or use Key.getEncoded() to get the default encoding for the key. The equivalent on the ECPrivateKey side are the ECPrivateKeySpec and PKCS8EncodedKeySpec clases. PEM is actually not an encoding, but a wrapping of an encoding. The only part of Java that deals with it natively (I believe) is the CertificateFactory for X.509 certificates. You may have an extra step to add or remove a PEM style envelope (or the equivalent BASE64 bare string), but that's reasonable. The requirement to know key algorithm in advance forces you into ASN.1 decoding for dealing with PEMs. Been there done that. Ah - not sure why you wouldn't know the key algorithm, BUT: It should theoretically be possible to write a KeyFactory provider that does that decoding for you from the X509PublicKeySpec (or PKCS8PrivateKeySpec) and returns an appropriate PublicKey. Check the actual return type to figure out what type of
Re: RFR: 8283665: Two Jarsigner tests needs to be updated with JDK-8267319
On Fri, 25 Mar 2022 05:11:18 GMT, Valerie Peng wrote: > Max, can you please help review this fix? It updates the two jarsigner tests > which are added to the main trunk during the code review of JDK-8267319. > > Mach5 run succeeds. > Thanks, > Valerie Is this fix going to be integrated soon? We're up to 4 Tier2 job sets with these failures. That's 12 failures per Tier2 job set... - PR: https://git.openjdk.java.net/jdk/pull/7952
RFR: 8283691: Classes in java.security still reference deprecated classes in spec
Some spec cleanup. - Commit messages: - 8283691: Classes in java.security still reference deprecated classes in spec Changes: https://git.openjdk.java.net/jdk/pull/7961/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7961=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283691 Stats: 6 lines in 3 files changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7961.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7961/head:pull/7961 PR: https://git.openjdk.java.net/jdk/pull/7961
Re: RFR: 8282819: Deprecate Locale class constructors
On Thu, 24 Mar 2022 22:01:30 GMT, Naoto Sato wrote:
> Proposing to deprecate the constructors in the `java.util.Locale` class.
> There is already a factory method and a builder to return singletons, so
> there is no need to have constructors anymore unless one purposefully wants
> to create `ill-formed` Locale objects, which is discouraged. We cannot
> terminally deprecate those constructors for the compatibility to serialized
> objects created with older JDKs. Please see the draft CSR for more detail.
src/java.base/share/classes/java/util/Locale.java line 245:
> 243: * Factory Method
> 244: *
> 245: * The method {@link #forLanguageTag} obtains a {@code Locale}
The factory name `forLanguageTag` is a bit off-putting, it doesn't seem like
the best name for the factory.
Yes, it already exists and does what's required but you might get better uptake
with a more natural name.
Some alternatives:
- `Locale.of("en_US")` - short and conventional
- `Locale.ofLanguage("en_US")` - 'of' prefix is used in other factories
- `Locale.forLanguage("en_US")` - natural but less conventional
-
PR: https://git.openjdk.java.net/jdk/pull/7947
Re: RFR: 8283665: Two Jarsigner tests needs to be updated with JDK-8267319
On Fri, 25 Mar 2022 05:11:18 GMT, Valerie Peng wrote: > Max, can you please help review this fix? It updates the two jarsigner tests > which are added to the main trunk during the code review of JDK-8267319. > > Mach5 run succeeds. > Thanks, > Valerie Marked as reviewed by weijun (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7952
Re: "Pluggable" key serialization in JCE/JCA
Hi Mike & the JDK crypto team,
What I'm saying is that key serialization in Java haven't gotten enough
attention. Examples:
AFAIK, there is still no support for using named curves to construct an EC key.
Names curves are MANDATORY in JOSE/CODE.
The gap between EdDSA keys as expressed in JOSE/COSE and the Java API is simply
put GIGANTIC:
https://mail.openjdk.java.net/pipermail/security-dev/2020-August/022379.html
The only obvious solution is rolling your own:
https://github.com/cyberphone/openkeystore/blob/master/library/src/org/webpki/crypto/OkpSupport.java
This code [probably] stinks but it is hardly my fault...
The JDK crypto team is the only party who can clean up this mess.
Since importing X.509 certificates through PKCS12/KeyStore works out of the box
without any a prior knowledge of key algorithms, there is already a precedent.
It is almost just copy and paste :)
The new crypto systems that are on the way in (BLS, Post Quantum), accentuates
this issue.
Regarding HSMs, I gave it one more thought and I didn't come up with any
connections except maybe in Keytool but HSMs appear to be X.509-oriented which
not the case with COSE/JOSE.
Regards,
Anders
On 2022-03-25 3:12, Michael StJohns wrote:
On 3/24/2022 12:28 PM, Anders Rundgren wrote:
On 2022-03-24 16:59, Michael StJohns wrote:
On 3/24/2022 2:46 AM, Anders Rundgren wrote:
Hi List,
I find it a bit strange that every user of crypto either have to write
or install specific software for converting JOSE/COSE/PEM keys
back-and-forth to Java's internal representation. This reduces the
value of the abstract types as well.
Now there is whole bunch of new algorithms coming to the Java platform
making this task even less attractive.
So my question is simply: How about including this part in an enhanced
JCE/JCA? That is, making the encoder/decoder "pluggable" and hiding
this complexity from users and library developers?
Hi Anders -
Hi Mike,
Isn't that the exact purpose for KeyFactory and its plugins?
They presume that you know not only the key algorithm but the
associated parameters as well. Why should users or library developers
have to deal with that?
Um - no. They presume you know the key algorithm, but (using EC Public
keys for example), you can use either of the X509PublicKeySpec (to
decode an encoded key), or the ECPublicKeySpec (to deal with building a
key from scratch using the parameters. You can notionally (haven't
tried it, but should work) use KeyFactory.getKeySpec() to convert
between the two formats or use Key.getEncoded() to get the default
encoding for the key.
The equivalent on the ECPrivateKey side are the ECPrivateKeySpec and
PKCS8EncodedKeySpec clases.
PEM is actually not an encoding, but a wrapping of an encoding. The only
part of Java that deals with it natively (I believe) is the
CertificateFactory for X.509 certificates. You may have an extra step
to add or remove a PEM style envelope (or the equivalent BASE64 bare
string), but that's reasonable.
The requirement to know key algorithm in advance forces you into ASN.1
decoding for dealing with PEMs. Been there done that.
Ah - not sure why you wouldn't know the key algorithm, BUT: It should
theoretically be possible to write a KeyFactory provider that does that
decoding for you from the X509PublicKeySpec (or PKCS8PrivateKeySpec) and
returns an appropriate PublicKey. Check the actual return type to figure
out what type of key. E.g.:
KeyFactory kf = KeyFactory.getInstance("GenericDecoder");
As I said below, you'll need to define the equivalent opaque format
KeySpec classes to handle COSE and JOSE. I think that's a class per
type of encoding.
You might need to add KeySpec types for Jose and Cose
(JOSEEncodedKeySpec and COSEEncodedKeySpec) assuming both of those cover
all of the secret, public and private key specifications.
Or hmm... GenericEncodedKeySpec (String alg, byte[] encoded key) or
GenericEncodedKeySpec (String alg, String encodedKey).
Eventually you could end up with something like:
PrivateKey privateKey = new KeyConverter().readPrivateKey(byte[] or
stream);
You would not even have to know in which format the key is supplied in
since this could be accomplished by simple "sniffing".
Nope. This isn't safe as someone might up with yet another
representation that looks like one of the "sniffable" ones. You could
build a private implementation that takes its best shot, but
Finding out if the container is COSE, JOSE, or PEM is (AFAICT)
trivial. If the guess is incorrect a properly designed decoder should
simply fail.
It's trivial NOW because its a closed set of possibilities. And even
then, you're assuming you don't have to detect ASN1 vs raw key encodings
vs string encodings. Simply detecting a) whether a file is character,
b) detecting the character encoding, and c) accidentally thinking a
character file is actually binary or vice versa is fragile.
The addition of the "new" EC variant keys required a
Re: RFR: 8283665: Two Jarsigner tests needs to be updated with JDK-8267319
On Fri, 25 Mar 2022 05:11:18 GMT, Valerie Peng wrote: > Max, can you please help review this fix? It updates the two jarsigner tests > which are added to the main trunk during the code review of JDK-8267319. > > Mach5 run succeeds. > Thanks, > Valerie Marked as reviewed by hchao (Committer). - PR: https://git.openjdk.java.net/jdk/pull/7952
