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

Sean Mullan sean.mullan at oracle.com
Wed Aug 15 14:46:54 UTC 2012

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 servernamelist<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 ciphersuites/compression/certs/certrequests, 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... ciphersuites This is a list of the cryptographic options supported by the client, with the client's first preference first. ...deleted... compressionmethods This is a list of the compression methods supported by the client, sorted by client preference. Section 7.4.2 certificatelist This is a sequence (chain) of X.509v3 certificates. The sender's certificate must come first in the list. Section 7.4.4 certificatetypes 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

More information about the security-dev mailing list