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