getParams() for XECKey returns nonsense

[Anders Rundgren]

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
>>>
>>
>