Just a couple of comments:
1. I think the check on lines 106-110 can be done prior to the for loop
on line 94
2. Not specifically related to your fix, but please remove the text
"NameConstraints" or "SubjectAltName" from the exception messages.
DNSNames can be specified in various places in a certificate and the
exception message should not try to include that. Also some message say
"DNSNames" and others say "DNS names". Can you change it to "DNS names"
or "DNS name" to be consistent.
--Sean
On 08/22/2014 05:07 PM, Jason Uh wrote:
Please see the revised webrev here:
http://cr.openjdk.java.net/~juh/8054380/webrev.02/
Additional changes include:
1. Verification of the DNSName during certificate parsing
2. Allowing each component to start with a letter or digit
2. A check to make sure the final character of a component ends in a
digit or letter (RFC 952 grammar rules)
Thanks,
Jason
On 08/08/2014 01:59 AM, Florian Weimer wrote:
On 08/07/2014 03:32 PM, Sean Mullan wrote:
On 08/07/2014 08:47 AM, Florian Weimer wrote:
I wonder why using the HTTPS to access <https://www.3com.com> works
with
the current jdk9-dev code. The name "www.3com.com" is only present in
the SAN.
Is the SAN extension non-critical? If so, that could explain why. We
allow X509Certificates to be created with unparseable non-critical
extensions.
Yes, it's marked as non-critical. But this doesn't really explain the
lack of an exception because the www.3com.com dNSName is obviously used
(there's no TLS handshake failure).
