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

[David Benjamin <[e-mail]>]

On Thu, Mar 23, 2017 at 12:49 PM Russ Housley <[e-mail]> wrote:

> > How would the following language (or something to this effect) work as a
> > compromise?
> >
> >   In this document we defined six new OIDs for identifying the
> >   different curve/algorithm pairs.  The curves being Curve25519 and
> >   Curve448.  The algorithms being ECDH, EdDSA in pure mode and EdDSA in
> >   pre-hash mode.  For all of the OIDs, the parameters MUST be absent.
> >   Regardless of the defect in the original 1997 syntax, implementations
> >   MUST NOT write out a parameters value of NULL, and MUST NOT accept a
> >   parameters value of NULL, EXCEPT where doing so is unavoidable due to
> >   legacy PKCS8 interpretation within the implementation language's
> >   standard libraries (such as Java's Sun security provider before
> >   version XX).
>
>
> EXCEPT is not defined in RFC 2119.
>
> How is your proposed language any different in reality than:
>
>   This document specified object identifiers for using Curve25519 and
>   Curve448 for key agreement and digital signature.  Since none of these
>   algorithm identifiers need parameters, the parameters MUST be absent.
>   As a result of the defect in the AlgorithmIdentifier syntax published
>   in 1997, some implementations produce a parameters value of NULL, even
>   when the parameters ought to be absent.  Conforming implementations
>   MUST NOT produce a parameters value of NULL, but conforming
>   implementations MAY accept a parameters value of NULL for
>   interoperability.
>

I think that encourages normal implementations too much towards laxness,
which will harm the ecosystem. I don't particularly care which encoding it
is (with or without NULL), but there must be only one encoding. We've had
enough trouble with id-rsaEncryption's ambiguity in BoringSSL that I do not
think we would be willing implement a new scheme with two encodings.

If MUST NOT on the parser is problematic, perhaps SHOULD NOT? That said, I
do not follow what is wrong with MUST NOT. It sounds like this Java issue
is purely a local thing, right? That is, you don't expect such malformed
structures to escape into the ecosystem, but you need to be able to parse
the structures back out? In that case, there's need to encourage any other
implementation to be lax here. It's purely so that your parser gets the
conforming checkbox? But the serializer is already violating the MUST NOT,
so violate it in the parser too and add an explanatory comment next to the
code.

Or am I misunderstanding the situation?

David