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

No, we should not relax the MUST NOT. We've learned from the previous
algorithms here that multiple options for encodings are an unnecessary
source of complexity and interop headaches. There should only be one
encoding and parsers need to enforce this to avoid an ecosystem mess.

On Tue, Mar 14, 2017 at 1:11 PM Daniel Migault <daniel.migault@ericsson.com>
wrote:

> 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:curdle-bounces@ietf.org] On Behalf Of str4d
> Sent: Saturday, March 11, 2017 1:19 AM
> To: curdle@ietf.org; Russ Housley <housley@vigilsec.com>; Daniel Kahn
> Gillmor <dkg@fifthhorseman.net>; Peter Gutmann <pgut001@cs.auckland.ac.nz>
> 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 <pgut001@cs.auckland.ac.nz> wrote:
> > Daniel Kahn Gillmor <dkg@fifthhorseman.net> 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
>
> _______________________________________________
> Curdle mailing list
> Curdle@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle
>