[9] RFR: 8054380: X.509 cert extension SubjectAltName should allow digits as first character of dNSName

[Sean Mullan]

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).
>>