On 2020-09-08 22:05, Anthony Scarpino wrote:
On 9/8/20 11:42 AM, Anders Rundgren wrote:
On 2020-09-08 19:29, Anthony Scarpino wrote:
On 8/30/20 9:51 AM, Anders Rundgren wrote:
Hi,
This applies to JDK 11.
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/security/interfaces/XECKey.html
what is the value of "AlgorithmParameterSpec"?
In JDK 15 the new EdECKey has gotten a more logical solution:
https://urldefense.com/v3/__https://download.java.net/java/early_access/jdk15/docs/api/java.base/java/security/interfaces/EdECKey.html__;!!GqivPVa7Brio!M6lIhNj1Si4NHI4Q9JggmTsJyTybhNLe9w7uQWg8WhivilAk6ALuc5-5pefjwY68yM9W$
thanx,
Anders
The return type for XECKey.getParams() was trying to be more generic,
probably too generic.
I guessed that. Don't you have the same problem with EdECKey?
Different opinions as the APIs were developed several years apart
NamedParameterSpec implements AlgorithParameterSpec.
Right, this is clear by looking at the API.
The implementationf or XECKey returns a NamedParameterSpec.
Here is gets a bit slippery (at least compared to the solution for
EdECKey) because this is 1) Undocumented 2) Oracle-provider-specific,
both which pretty much nullifies the value of the public interface.
The intention at the time was if in the future XEC required different an
AlgorithmParameterSpec that it would not have to inherit
NamedParameterSpec. With EdDSA, we decided that was unnecessary.
The implementation returning NamedParameterSpec does not nullify the
public interface. I was stating XECKey's return type in the context of
the differences between EdECKey and XECKey and that it is consistent in
the end. When using XECKey.getParams(), checking the instanceof maybe a
good idea. I would say the API allows for more flexibility for
non-oracle providers by returning AlgorithmParameterSpec. As far as
being undocumented, that maybe true in other documentation, but the API
should not be specifying what SunEC is returning.
I don't understand how developers of libraries for things like the JOSE
stack are supposed to deal with a public API that doesn't provide the
exact type of the key. For public keys you can do your own ASN.1 parsing
but for private keys there is no workaround if the key is in protected
storage.
Effectively you are requiring that each provider vendor publish their
AlgorithmParameterSpec implementation which then library developers
must know and implement specific support for!
I may (surely) be wrong but changing the API to return
NamedParameterSpec should not break any existing code based on the
Oracle provider.
Once the API is published, we cannot change it.
In this case I think you can because the majority of people wanting to
use curve25519 and curve448 algorithms needed signatures as well and
have therefore turned to other solutions like Bouncycastle using
proprietary interfaces and APIs.
In the unlikely case we need new key variants based on the same core,
creating a new set of key interfaces would create much less fuzz since
new types won't work automatically anyway due to the complex relation
between key algorithms and JCE providers.
I leave it there but in my book this a design bug. Fortunately (for
us all...), I expect third parties targeting the JDK interfaces will
follow Oracle's implementation which then become the de-facto API :-)
thanx,
Anders
Tony
Thanx,
Anders
Tony
