Code Review Request, JDK-8166103 Allow certs with unknown critical extension in SunX509 validator

[Bradley Hess]

The test case fails for me against JDK 1.7.0_05 and 1.8.0_20 -- the SunX509
validator complains about the presence of the critical extension.  Contrary
to what the OP suggested in the bug report, it doesn't seem like this
behavior is new.

Plenty of implementations in the wild (e.g. Tomcat) either hardcode SunX509
or rely on getDefaultAlgorithm, which returns SunX509.  I would imagine
that in most cases, and especially in cases where the TrustManagerFactory
is being instantiated by a web container using platform defaults, that
there's no user code that does further checking.  To me this change seems
both breaking and inconsistent with RFC 5280.

On Fri, Nov 11, 2016 at 12:47 PM Vincent Ryan <vincent.x.ryan at oracle.com>
wrote:

> Your changes look fine to me.
> Just a minor language correction: ‘to use’ -> ‘using’ (2 instances)
>
> > On 11 Nov 2016, at 05:11, Xuelei Fan <Xuelei.Fan at Oracle.Com> wrote:
> >
> > Hi,
> >
> > Please review this bug fix:
> >
> >   http://cr.openjdk.java.net/~xuelei/8166103/webrev.00/
> >
> > The current validator implementations only allow white listed critical
> certificate extensions, and not all JDK supported extensions are known to
> the validator.  As may result in some issues that the cert is valid, but
> cannot pass the validation because there is a critical extension that is
> not white listed in the validator implementation.
> >
> > This fix will only check the validity of the white listed critical
> certificate extensions, and ignore the critical certificate extensions if
> they can be parsed with X509Certificate.
> >
> > Thanks,
> > Xuelei
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20161111/8ff0a274/attachment.htm>