On Wed, 23 Sep 2020 06:07:09 GMT, Hai-May Chao <hc...@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
