(3rd Round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension

Xuelei Fan xuelei.fan at oracle.com
Wed Aug 15 13:40:27 UTC 2012


On 8/15/2012 9:36 PM, Xuelei Fan wrote:
> Updated webrev according to recent feedbacks:
>     http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.04/
>     http://cr.openjdk.java.net./~xuelei/7068321/README_05.txt
> 
> The major differences:
> 1. add constant SSLParameters.SNI_HOST_NAME, and specify the format of
> unknown SNI type (sni-<integer>) in ExtendedSSLSession.
>    Then we don't need to document the types and values in Java
> Cryptography Architecture Standard Algorithm Name Documentation.
> 
> 2. Other updates according to feedback from Brad, Weijun, and Sean.
>    Please let me know I missed misunderstood something.
> 
missed or misunderstood ;-)

> Thanks,
> Xuelei
> 
> On 8/12/2012 8:50 PM, Xuelei Fan wrote:
>> Hi,
>>
>> Please review the spec of JEP 114, TLS Server Name Indication (SNI)
>> Extension.
>>
>>     http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.04/
>>
>> Please read the README to help you understanding the the specification:
>>
>>    http://cr.openjdk.java.net./~xuelei/7068321/README_04.txt
>>
>> The major differences comparing with previous webrev are:
>> 1. client mode and server mode will use separated API set.
>>    For client, the related APIs are:
>>      setServerName(String type, String value)
>>      clearServerName(String type)
>>      disableServerName(String type)
>>      enableServerName(String type)
>>      isDisabledServerName(String type)
>>      getServerNames()
>>
>>    For server side, the related APIs are:
>>      setServerNamePattern(String type, Pattern pattern)
>>      clearServerNamePattern(String type)
>>      getServerNamePatterns()
>>
>> 2. close the door to use the generated socket in client mode.
>>
>>    SSLSocketFactory.createSocket(Socket s,
>>        InputStream consumed, boolean autoClose)
>>
>>    The returned socket was set in server mode.
>>
>> Regards,
>> Xuelei
>>
> 




More information about the security-dev mailing list