JDK's XECPublicKey.getEncoded() deviates from RFC8410

Weijun Wang WEIJUN.WANG at ORACLE.COM
Thu Sep 3 11:56:52 UTC 2020


Because of some very old incompatibility issue, we put a NULL there for most algorithms:

   https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/x509/AlgorithmId.java#L176

We are revisiting this decision now at https://bugs.openjdk.java.net/browse/JDK-8252377. Thanks for pointing this out.

—Max

> On Sep 3, 2020, at 4:49 AM, Anders Rundgren <anders.rundgren.net at gmail.com> wrote:
> 
> Being an early adopter has its challenges...
> https://github.com/cyberphone/openkeystore/blob/master/library/test/org/webpki/crypto/Jdk15XdhSerializationBug.java
> 
>   This test program verifies that JDK 11 - JDK 15 according to section 3 of
>   RFC 8410 incorrectly add an ASN.1 "NULL" to the AlgorithmIdentifier of
>   XDH public keys.  See line 9: below.
>    0: SEQUENCE
>         {
>    2:     SEQUENCE
>             {
>    4:         OBJECT IDENTIFIER X25519 (1.3.101.110)
>    9:         NULL
>             }
>   11:     BIT STRING, 32 bytes
>       0000: 2f 97 25 02 da af 6b dc 0e e6 67 39 25 f2 f0 fe '/.%...k...g9%...'
>       0010: 03 b0 24 09 3c f0 fc ef 3c 23 12 46 3d 5c 8e 15 '..$.<...<#.F=\..'
>         }
> 
> 
> This is not a showstopper since BC remains a compliant alternative. However, for EcDSA and EXH, BC and JDK are incompatible at the java source level.
> If this is accepted as a bug, I hope you will also revisit the (compared to EdDSA keys), unnecessarily quirky use of AlgorithmParameterSpec.
> 
> Thanx,
> Anders




More information about the security-dev mailing list