(2nd round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension

[Sean Mullan]

On 08/14/2012 10:45 PM, Xuelei Fan wrote:
> I only reply on the items that I may need more review.
>
> On 8/15/2012 7:54 AM, Brad Wetmore wrote:
>>>> SSLParameters.java
>>>> ==================
>>>> 76:  Not sure why you want/need a LinkedHashMap with only one currently
>>>> defined NameType.  Even if there were multiple types, I don't think that
>>>> SNI requires an ordering.  You also mention this in
>>>> setAccessibleServerName, but not sure what purpose this serves.  I'm not
>>>> strongly against it, just wondering.
>>>>
>>> I am also not sure about the strong desire that the SNI should be
>>> ordered. But Weijun prefers it to be ordered because he think the SNI in
>>> RFC6066 is defined as an ordered sequence.
>>>
>>>         struct {
>>>             ServerName server_name_list<1..2^16-1>
>>>         } ServerNameList;
>>
>> I've gone through RFC6066 pretty carefully, and I'm not seeing any
>> indication that this should be ordered.
>>
>> In RFC 2246, if there is an ordering required, such as
>> cipher_suites/compression/certs/cert_requests, it's specifically called
>> out.  For any other "lists", it is not specified.
>>
>> Section 7.4.1.2
>>
>>     The CipherSuite list, passed from the client to the server in the
>>     client hello message, contains the combinations of cryptographic
>>     algorithms supported by the client in order of the client's
>>     preference (favorite choice first).
>>
>>     ...deleted...
>>
>>     The client hello includes a list of compression algorithms supported
>>     by the client, ordered according to the client's preference.
>>
>>     ...deleted...
>>
>>     cipher_suites
>>         This is a list of the cryptographic options supported by the
>>         client, with the client's first preference first.
>>
>>     ...deleted...
>>
>>     compression_methods
>>         This is a list of the compression methods supported by the
>>         client, sorted by client preference.
>>
>> Section 7.4.2
>>
>>     certificate_list
>>         This is a sequence (chain) of X.509v3 certificates. The sender's
>>         certificate must come first in the list.
>>
>> Section 7.4.4
>>
>>         certificate_types
>>                This field is a list of the types of certificates requested,
>>                sorted in order of the server's preference.
>>
>> Weijun, did you see something else in your read of the spec that
>> indicates an ordering?  If not, maybe we should not put in the order
>> wording now.  If it turns out we do need it, we can always add that
>> wording later in a later release, but it will be impossible to remove it
>> if we add it now.
>>
> I think you are right. If Weijun has no other concerns, I will remove
> related description.

Doesn't a "List" imply it is ordered? I guess I'm ok with not putting 
any specific wording in right now, since there's likely only going to be 
one entry anyway, but if subsequent standard name types are defined 
later, order might become important for some reason.

--Sean