RFR: 8252377: Incorrect encoding for EC AlgorithmIdentifier

Weijun Wang weijun at openjdk.java.net
Wed Sep 23 13:13:37 UTC 2020


On Wed, 23 Sep 2020 06:07:09 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> I don't quite understand what the test is for. The bug is about encoding but the test seems to be decoding the
>> certificates. Does the test fail before this fix and succeed after it?
>
> This is because the encoding of Algorithm Identifier incorrectly adds two NULL tags to the parameters field in the
> canned certificate. (There are two Algorithm Identifiers in the cert, with each NULL tag containing two bytes:  tag +
> length.) I use the length of an encoded certificate (x509Cert.getEncoded().length) to verify that the certificate
> contains an extra 4 bytes to hold the two NULL tags. Therefore, the certificate without the fix should be 4 bytes (5
> bytes if one byte alignment is applied) longer in length than the certificate with the fix.

But the certificates included in the test are static and if one day we mistakenly add the NULL back it will not be
detected by the test. My idea is to generate a cert on the fly inside the test so that can check the `derEncode` method
in *this* JDK. As for checking if the NULL is there, you can try looking at the `DerUtils::shouldNotExist` method with
"021" and "11" as arguments.

-------------

PR: https://git.openjdk.java.net/jdk/pull/312



More information about the security-dev mailing list