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

[Jason Uh]

On 08/25/2014 03:41 PM, Sean Mullan wrote:
> 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

I think that check is actually where it should be because the for loop 
on line 94 loops over each component (while the inner loop on line 115 
checks the characters of that component). The check for the first and 
last characters is done just once per component.

> 2. Not specifically related to your fix, but please remove the text
> "NameConstraints" or "SubjectAltName" from the exception messages.

Done.

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

Done. (Everything now says "DNSNames".)

Updated webrev here:
http://cr.openjdk.java.net/~juh/8054380/webrev.03/

Thanks,
Jason



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