On 8038089: TLS optional support for Kerberos cipher suites needs to be re-examine

[Xuelei Fan]

Please give me more time to think about the overall infrastructure.

Xuelei

On 8/4/2014 9:48 AM, Wang Weijun wrote:
> Hi Xuelei
> 
> Are you OK with the code change? The updated webrev is now at
> 
>   http://cr.openjdk.java.net/~weijun/8038089/webrev.02/
> 
> Comparing to the last version. there are some comment changes and emptying refs.allowed. The only major change is that the ServiecLoader now uses system class loader.
> 
> Thanks
> Max
> 
> On Jul 21, 2014, at 16:22, Wang Weijun <weijun.wang at oracle.com> wrote:
> 
>> Please review the updated webrev at
>>
>>  http://cr.openjdk.java.net/~weijun/8038089/webrev.01
>>
>> Some comment changes. Some arguments rearrangement between classes.
>>
>> The interface is still in sun.security.ssl. It will be easy to move it to somewhere else later. When module is introduced, we may need to export the interface from java.base to java.security.jgss.
>>
>> Thanks
>> Max
>>
>> On Jul 17, 2014, at 12:35, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>
>>> On 7/16/2014 4:41 PM, Wang Weijun wrote:
>>>> Hi Xuelei
>>>>
>>>> A *primitive* version of webrev available at
>>>>
>>>>  http://cr.openjdk.java.net/~weijun/8038089/webrev.00
>>>>
>>>> Please confirm this is the way you like it.
>>>>
>>> I have not read too much about the details of the update.  But looks
>>> like it is in the right way.
>>>
>>>> ExternalCipherSuite is the service interface and Krb5CipherSuite implements it. It's a modification of the old Krb5Proxy but I've moved as many as Kerberos-related codes to the implementation side so it has less methods now.
>>>>
>>>> Most likely we will define this new interface in a public package.
>>>>
>>> If krb5 is the only external implementation of TLS cipher suites, I
>>> think, we may want to try the best not to define public interface if
>>> possible.
>>>
>>> Thanks,
>>> Xuelei
>>>
>>>> I didn't touch any core SSL classes except for ClientHandshaker and ServerHandShaker. If you think there are other places too closely connected with kerberos, please let me know.
>>>>
>>>> Ideally, those
>>>>
>>>> case K_KRB5: case K_KRB5_EXPORT:
>>>>   Krb5Helper.doXXX(...):
>>>>
>>>> should be something like
>>>>
>>>> default:
>>>>   getExternalHelper(keyExchange).doXXX(...)
>>>>
>>>> but I guess we won't do that unless we know there will be a second implementation.
>>>>
>>>> Thanks
>>>> Max
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>