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