Re: [Curdle] AlgorithmIdentifier parameters in draft-ietf-curdle-pkix-03

[Daniel Migault <[e-mail]>]

Hi, 

We need to sort this out. Anyone from Oracle can provide feedbacks ? 

Please let us know if there is any consensus on relaxing the MUST NOT accept parameters even NULL ?

Yours, 
Daniel
 

-----Original Message-----
From: Curdle [mailto:[e-mail]] On Behalf Of str4d
Sent: Saturday, March 11, 2017 1:19 AM
To: [e-mail]; Russ Housley <[e-mail]>; Daniel Kahn Gillmor <[e-mail]>; Peter Gutmann <[e-mail]>
Subject: Re: [Curdle] AlgorithmIdentifier parameters in draft-ietf-curdle-pkix-03

On 02/19/2017 02:14 AM, str4d wrote:
> Hi all,
> 
> In draft-ietf-curdle-pkix-03 there is very clear language around the 
> expected behaviour of parser implementations regarding 
> AlgorithmIdentifier parameters:
> 

[snip]

> The problem is that the Sun AlgorithmId class always adds a NULL when 
> encoding if there are no parameters, for compatibility with Solaris [4].
> So AFAICT it is presently impossible for me to write an implementation 
> that simultaneously:
> 
> - follows draft-ietf-curdle-pkix-03 correctly
> - can retrieve EdDSA keys from a default Java keystore
> 
> Is anyone in the WG aware of a workaround for this, or have links to 
> past WG discussion on this point? I would think that Oracle should at 
> least be made aware of this issue, but even if they changes this in 
> Java 10, that doesn't help my implementation run on earlier Java versions.
> The only alternatives I see at this point are:
> 
> - Remove the NULL restriction from draft-ietf-curdle-pkix-03
> - Require that my library not be used with incompatible keystores (but
> a) I have yet to find a way to enforce this via the JCA, other than 
> just refusing to implement support for PKCS8EncodedKeySpec, which is 
> not particularly usable, and b) I don't yet know of a keystore that 
> *will* implement this properly)

I have found the correspondence in the Curdle WG ML that added the NULL restriction; I have copied in the relevant members to hopefully jog this conversation. If there is no further discussion, then I will have no alternative but to be non-compliant with the eventual RFC, as I have been unable to find a way for my library to work with the default Java keystore :(

Peter Gutmann <[e-mail]> wrote:
> Daniel Kahn Gillmor <[e-mail]> writes:
> >   Implementaions MUST NOT accept any of these OIDs with the
> >   parameters field present, even if parameters has a value
> >   of NULL.
> >
> >If we can convince the early implementations to hard-fail on that, we 
> >can discourage anyone from generating those values in newer 
> >implementations.
>
> +1.  For once there's no argument for supporting existing broken
> implementations, we can get it right from the start

I apologise for providing one :/

Cheers(-ish),
Jack