Discrepancy between Java's public key representation and RFC 8410

Question

RFC 8410 lists this as an example of a Ed25519 public key: MCowBQYDK2VwAyEAGb9ECWmEzf6FQbrBZ9w7lshQhqowtrbLDFw4rXAxZuE=

Decoding this with an ASN.1 decoder, this becomes:

30 2A
  30 05
    06 03 2B6570 // Algorithm Identifier
  03 21 0019BF44096984CDFE8541BAC167DC3B96C85086AA30B6B6CB0C5C38AD703166E1

As expected, this matches the SubjectPublicKeyInfo definition in the RFC.

Using the Sun cryptography provider in Java 11+ I can use this code to generate an X25519 (not Ed25519 - which is the difference in the algorithm identifier below) public key:

import java.security.KeyPairGenerator;
import java.util.Base64;

public class PrintPublicKey {
    public static void main(String args[]) throws Exception {
        KeyPairGenerator generator = KeyPairGenerator.getInstance("X25519");
        byte[] encodedPublicKey = generator.generateKeyPair().getPublic().getEncoded();
        System.out.println(Base64.getEncoder().encodeToString(encodedPublicKey));
    }
}

Which will output something like: MCwwBwYDK2VuBQADIQDlXKI/cMoICnQRrV+4c//viHnXMoB190/z2MX/otJQQw==

Decoding this with an ASN.1 decoder, this becomes:

30 2C
  30 07
    06 03 2B656E // Algorithm Identifier
    05 00        // Algorithm Parameters - NULL
  03 21 00E55CA23F70CA080A7411AD5FB873FFEF8879D7328075F74FF3D8C5FFA2D25043

This has an explicit NULL after the object identifier. Is this valid according to the specification? It says:

In this document, we define four new OIDs for identifying the different curve/algorithm pairs: the curves being curve25519 and curve448 and the algorithms being ECDH and EdDSA in pure mode.

For all of the OIDs, the parameters MUST be absent.

user_139985 · Answer

The paragraph after the one you quoted says this:

It is possible to find systems that require the parameters to be present. This can be due to either a defect in the original 1997 syntax or a programming error where developers never got input where this was not true. The optimal solution is to fix these systems; where this is not possible, the problem needs to be restricted to that subsystem and not propagated to the Internet.

So a plausible explanation for the Oracle implementation's behavior is that they want to be interoperable with old systems that require parameters. It is the kind of thing that you do to prevent big customers with large support contracts from complaining loudly that "upgrading to Java 11 broke my infrastructure".

Discrepancy between Java's public key representation and RFC 8410

1 Answers