[9] RFR: 8076117: EndEntityChecker should not process custom extensions after PKIX validation

Jason Uh jason.uh at oracle.com
Fri Apr 10 23:18:48 UTC 2015


Thanks, Xuelei.

On 04/10/2015 03:41 PM, Xuelei Fan wrote:
> Looks fine to me except a few minor comments.
>
> Validator.java
> --------------
> Would you mind add a comment about why only check extension for TYPE_SIMPLE?

Added.

> EndEntityExtensionCheck.java
> ----------------------------
> line 26-28:
> We normally use bug tag before other tags.

Moved @bug before @summary. @test still needs to be first for jtreg.

> line 52-55, and similar places:
> Normally, a "*" character is expected for each comment line.  As is
> easier to read.
>
> eeextensioncheck.jks
> --------------------
> Binary file is not preferred in Mercurial.  Would you mind use string
> key store as what you did for CA and EE certs in
> EndEntityExtensionCheck.java?

Just changed it to setCertificateEntry from the already constructed CA 
cert, which is definitely better than using the binary. I'm not aware of 
a way to export an entire keystore as an encoded string. (Is there a way?)

Revised webrev: http://cr.openjdk.java.net/~juh/8076117/01/

Thanks,
Jason

> Xuelei
>
> On 4/11/2015 3:39 AM, Jason Uh wrote:
>> Please review this fix, which prevents redundant extension checking in
>> EndEntityChecker.
>>
>> When checking extensions in an end entity certificate, if
>> sun.security.validator.EndEntityChecker comes across any extensions that
>> are critical and unknown, it throws an exception, even if those
>> extensions had already been checked by custom PKIXCertPathCheckers
>> (specified in the PKIXParameters) earlier in the validation by
>> PKIXValidator. This checking is not necessary when path validation is
>> performed by a PKIXValidator.
>>
>> However, if the validation is performed by a SimpleValidator,
>> EndEntityChecker should continue to check extensions.
>>
>> webrev: http://cr.openjdk.java.net/~juh/8076117/00/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8076117
>>
>> Thanks,
>> Jason
>



More information about the security-dev mailing list