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

[str4d <[e-mail]>]

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 fields in AlgorithmIdentifier have the following meanings:

   o  algorithm identifies the cryptographic algorithm with an object
      identifier.  This is one of the OIDs defined below.

   o  parameters, which are optional, are the associated parameters for
      the algorithm identifier in the algorithm field.  When the 1997
      syntax for AlgorithmIdentifier was initially defined, it omitted
      the OPTIONAL key word.  The optionality of the parameters field
      was later recovered via a defect report, but by then many people
      thought that the field was mandatory.  For this reason, a small
      number of implementations may still require the field to be
      present.

   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 accept a parameters value of NULL.

   [/snip]

However, for Java implementations such as my own, we run into a problem.
Oracle Java's default keystore implementation requires that all private
keys be in PKCS#8 format [0] (which draft-ietf-curdle-pkix-03 does seem
to be using, despite never actually referencing PKCS#8 anywhere). The
internal JCA workflow for retrieving a key from a keystore is as follows
(references here are to Java 6, but the relevant code has not changed as
of Java 8):

- Read keystore data and pass it to PKCS8Key [1]
- Read AlgorithmId from start of data [2]
- Encode AlgorithmId + rest of data as a DerOutputStream [3]
- Wrap that in a PKCS8EncodedKeySpec
- Call KeyFactory.getInstance(algid.getName()).generatePrivate(spec)

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)

Cheers,
str4d

[0]
https://docs.oracle.com/javase/8/docs/api/java/security/KeyStore.html#setKeyEntry-java.lang.String-byte:A-java.security.cert.Certificate:A-

[1]
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/security/pkcs/PKCS8Key.java#PKCS8Key.parseKey%28sun.security.util.DerValue%29

[2]
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/security/pkcs/PKCS8Key.java#131

[3]
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/security/pkcs/PKCS8Key.java#171

[4]
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/security/x509/AlgorithmId.java#AlgorithmId.derEncode%28java.io.OutputStream%29