Hi Xuelei Long time no discussion on this one.
Updated webrev at http://cr.openjdk.java.net/~weijun/8038089/webrev.05/. Not exactly the same as your suggestion and not final. Just want to ask you take a look. 1. There are still 2 classes. ClientKeyExchange is for that hashshake messgae, and ClientKeyExchangeService is to introduce new service not in the base module. 2. I've tried my best to not mention KRB5 anymore inside the base module, but CipherSuite is an exception: a. Shall we change KeyExchange from enum to a normal class. Otherwise it cannot be subclassed so there is no way to add new exchange in a service. b. We should also move all add(KRB5...) lines into the service. 3. Which is the first class loaded in JSSE? Is it JsseJce? I'd like to load the services and introduce new KeyExchange and CIpherSuite there. Thanks Max On Sep 22, 2014, at 12:06, Xuelei Fan <xuelei....@oracle.com> wrote: > > > My idea about the new service looks like: > -------------------- > public interface ClientKeyExchange { > // Get the peer principal of this client key exchange > public Principal getPeerPrincipal(); > > // Get the local principal of this client key exchange > public Principal getLocalPrincipal(); > > // Create a new client key exchange message > // > // Should be called in client side. > public HandshakeMessage createClientKeyExchange(String hostname, > AccessControlContext acc, int protocolVerson, > SecureRandom rand) throws IOException; > > // Parse a client key exchange message > // > // Should be called in server side. > public HandshakeMessage parseClientKeyExchange(int protocolVerson, > int clientRequestedVersion, SecureRandom rand, > byte[] encodedTicket, byte[] encrypted, > AccessControlContext acc) throws IOException; > > // Negotiate the pre-master secret of this client key exchange. > public SecretKey clientKeyExchange() throws IOException; > } > -------------------- > > Still need a few methods in order to support session resumption. The > initialization method may depend on the service loading approach. For > example, if it is defined as SPI, we can call it via algorithm name > ("KRB5"); if it is defined to be load with ServiceLoader, may need to > define a new sub-class for KRB5. > > In TLS handshaking, the usage of the methods may look like: > ----------------------- > Client Server > krb5-ciphers ---ClientHelloRequst--> Support Krb5? > initialize Krb5 ClientKeyExchange > <----- ServerHello ---- > <---ServerHelloDone---- > initialize Krb5 ClientKeyExchange > create krb5 ClientKeyExchange message > ---ClientKeyExchange--> parse ClientKeyExchange msg > get the pre-master secret > negotiate the shared secret > ---changeCipherSpec---> > -------Finished-------> get the pre-master secret > negotiate the shared secret > <---changeCipherSpec--- > <-------Finished------- > ... > ----------------------- > > > Thanks, > Xuelei > > On 9/17/2014 1:58 PM, Xuelei Fan wrote: >> On 9/17/2014 1:49 PM, Wang Weijun wrote: >>>> I would prefer we do it now. If I did not miss something, the new design >>>> should be more simple >>>> and straightforward. >>> >>> Maybe, but I am not sure since this would surely touch more TLS side codes. >>> If you want to be totally separated, we also need to move the ciphersuites >>> definitions outside CipherSuite.java. The TLS side can iterate through all >>> providers to add them back and create something like a Map<keyExchangeAlg, >>> KeyExchangeService>. Then we could use this map in all "switch >>> (keyExchange)" blocks. >>> >>> Do you think it's easier to make these changes based on the current codes? >>> Or based on my modified codes? >>> >>> Can you describe the KeyExchangeService interface you are thinking about? >>> Currently I have to define a two-level interface -- >>> ExternalCipherSuiteProvider and ExternalCipherSuiteProvider.Exchanger -- to >>> model the service and the exchange instance. >>> >> OK, I will wrap up my ideas of the KeyExchangeService. But it may take a >> few more days. Wish I could get it ready by next Monday. >> >> Thanks, >> Xuelei >> >
