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

[str4d <[e-mail]>]

On 03/15/2017 06:42 AM, David Benjamin wrote:
> 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.

As the author of one such parser, I completely agree. Were this a
fully-custom stack (like BouncyCastle when using their keystore, or a
commercial offering), where I controlled everything below my parser, it
wouldn't be a problem. But when the input to my parser is being
transparently rewritten to a non-compliant encoding by standard
libraries of the programming language itself, my hands are tied.

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

I can comply with this, because my implementation will write the single
correct encoding to any destination (keystore or otherwise, modulo
whatever PKCS8 transformations that destination applies), but being a
standalone Java parser it can't know whether it is receiving input from
the default keystore or a compliant one. In a language where the default
PKCS8 parser can be made compliant, the MUST NOT would remain enforced.

Alternatively, the MUST NOT can be left as-is, and I will consider this
a case of "know the rules you're breaking". My concern then would be my
code being copied into other projects without this understanding (which
I would attempt to alleviate via comments), or other independent Java
implementations running up against this issue and just ignoring the MUST
NOT entirely, leading to incorrect encodings being written out
(avoidance of which AFAICT is the primary motivator for the MUST NOT).

Cheers,
Jack