Re: TLS extensions API, ALPN and HTTP 2.0

Hi, On Tue, Sep 2, 2014 at 11:11 AM, Vincent Ryan wrote: > Your OCA is still being processed. When that has completed your name will be > listed at: > http://www.oracle.com/technetwork/community/oca-486395.html#b > > Until then, we can discuss these TLS/HTTP issues but we cannot include your

Re: [9] RFR 8056026 Debug security logging should print Provider used for each crypto operation

I’ve renamed that boolean flag and inverted its logic: -private static final boolean doDebug = !(Debug.isOn("engine=") && !Debug.isOn(“XXX")); +private static final boolean skipDebug = Debug.isOn("engine=") && !Debug.isOn(“XXX”); Updated webrev: http://cr.openjdk.java.net/~vinnie/80560

Re: TLS extensions API, ALPN and HTTP 2.0

Hi Simone, I'm interested to understand why you think this Http 2 requirement is difficult or impossible to implement in the JDK currently. I thought, cipher suite selection would be independent of the ALPN mechanism. So, a Http 2 client implementation would ensure that allowed ciphers are in

Re: Kerberos Enc Type Expectations for delegated credential within AP_REQ message.

Ignore my ramblings, I have just checked the code at the tip for OpenJDK 9 and I find the changes I think need making to earlier versions have already been made for 9 ;-) From 9 the encryption type of the session key is no longer taken into account and instead the encryption type of the enc pa

Re: TLS extensions API, ALPN and HTTP 2.0

Hi, On Wed, Sep 17, 2014 at 12:57 PM, Michael McMahon wrote: > Hi Simone, > > I'm interested to understand why you think this Http 2 requirement > is difficult or impossible to implement in the JDK currently. > > I thought, cipher suite selection would be independent of the ALPN > mechanism. Ind

Re: TLS extensions API, ALPN and HTTP 2.0

See also: https://github.com/http2/http2-spec/issues/612 On Wed, Sep 17, 2014 at 3:17 PM, Simone Bordet wrote: > Hi, > > On Wed, Sep 17, 2014 at 12:57 PM, Michael McMahon > wrote: >> Hi Simone, >> >> I'm interested to understand why you think this Http 2 requirement >> is difficult or impossible

Re: TLS extensions API, ALPN and HTTP 2.0

Okay, I see the point you are making. It's more a question of whether the constraints themselves are appropriate. I've another question. In the work you've done so far, did you allow for the possibility of separate certificates to be selected per ALPN instance? I'm guessing that if multiple ap

Re: [9] RFR 8056026 Debug security logging should print Provider used for each crypto operation

Thanks for tackling this one Vinnie. It'll certainly help better debug environments where several providers are available to perform similar crypto operations. One minor suggestion might be to use a simple boolean to control whether the engine provider info gets printed. i.e. change "private st

Re: [undertow-dev] NoSuchMethod in 9ea-b30 getRawHostnameSE

Hello, thanks Stuart, I should have known to look for this. I mentioned before, that this is a quite important thing for JSSE to support (or actually the SSL API). But I did not expect that the JEtty workaround is already used. Hopefully Simone can influence the JDK to make stuff like this less

Re: TLS extensions API, ALPN and HTTP 2.0

Hi, On Wed, Sep 17, 2014 at 4:11 PM, Michael McMahon wrote: > Okay, I see the point you are making. It's more a question of whether > the constraints themselves are appropriate. And convince the HTTP/2 editors :( > I've another question. In the work you've done so far, did you allow > for the p

Re: [9] RFR 8056026 Debug security logging should print Provider used for each crypto operation

On 17 Sep 2014, at 16:00, Seán Coffey wrote: > Thanks for tackling this one Vinnie. It'll certainly help better debug > environments > where several providers are available to perform similar crypto operations. > > One minor suggestion might be to use a simple boolean to control whether > the

Re: [undertow-dev] NoSuchMethod in 9ea-b30 getRawHostnameSE

Hi, On Wed, Sep 17, 2014 at 5:04 PM, Bernd Eckenfels wrote: > Hello, > > thanks Stuart, I should have known to look for this. > > I mentioned before, that this is a quite important thing for JSSE to > support (or actually the SSL API). But I did not expect that the JEtty > workaround is already u

Re: TLS extensions API, ALPN and HTTP 2.0

On 17/09/14 16:25, Simone Bordet wrote: Hi, On Wed, Sep 17, 2014 at 4:11 PM, Michael McMahon wrote: Okay, I see the point you are making. It's more a question of whether the constraints themselves are appropriate. And convince the HTTP/2 editors :( I've another question. In the work you've

Re: TLS extensions API, ALPN and HTTP 2.0

Hi, On Wed, Sep 17, 2014 at 5:41 PM, Michael McMahon wrote: > No, I was thinking something like the following: > > foo.domain.com:443 supports two different server applications - "h2" > and something else (say some proprietary application "fooapp"). > They require two different certificates and w

JEP Review Request: Transition the default keystore type from JKS to PKCS12

Hello, The draft JEP “Transition the default keystore type from JKS to PKCS12” is now available for community review: https://bugs.openjdk.java.net/browse/JDK-805 It’s a proposal to move to an improved default keystore format without disrupting existing applications that access keystore

Re: [9] RFR 8056026 Debug security logging should print Provider used for each crypto operation

Looks good to me. --Sean On 09/17/2014 06:33 AM, Vincent Ryan wrote: I’ve renamed that boolean flag and inverted its logic: - privatestaticfinalbooleandoDebug = !(Debug.isOn("engine=") && !Debug.isOn(“XXX")); + privatestaticfinalbooleanskipDebug = Debug.isOn("engine=") && !Debug.isOn(“XXX”);