RFR: JEP 249 (OCSP Stapling for TLS)

[Jamil Nimeh]

Hi Thomas, thanks for the comments.  I have some follow-ups below

On 06/21/2015 06:46 AM, Thomas Lußnig wrote:
> Hi,
>
> here are some comments about what i was thinking:
>
> http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java.patch
> - Why not make the parsed message available ?
>    If the client wan't to check it he need to parse/implement the
> handling again.
You're not the first person who has asked for a handshake message to be 
exposed to the consumer.  I think folks have asked for ClientHello and 
verify messages in the past.  It would be better if we could expose 
parsed messages in a more general way rather than do a one-off for 
CertificateStatus or the hellos or whatnot.  Also, I would think we'd 
want a way that would work equally well for SSLEngines and SSLSockets.

Putting that aside, the CertificateStatus message doesn't have much more 
to it than the responses itself.  That you have the OCSP DER-encoded 
responses broken out already means you have the message more or less 
parsed, with the exception that the response DER encodings haven't been 
turned into an object, but JDK doesn't have anything to do that today 
that isn't sun-private.

The X509TrustManager, if configured to do revocation checking at all, 
should handle the checks so the client doesn't have to.  Can you tell me 
a little more about what environment a customer would want to re-check 
the responses above and beyond what is done already?  Could those checks 
be done with a custom CertPathChecker registered with the 
PKIXBuilderParameters used in the trust manager?
> http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java.patch
> - Why not allow to toggle each of the extensions individually ?
>    I think after Heartbleed this would be an good idee
> +        if (enableStatusRequestExtension) {
> +            clientHelloMessage.addCertStatusReqListV2Extension();
> +            clientHelloMessage.addCertStatusRequestExtension();
> +        }
I suppose we could, I didn't because I just didn't want two more 
properties, that's all.  At one point there was some discussion about a 
single property that could be used to toggle the presence of multiple 
extensions, which could help prevent an explosion in the number of 
enable/disable properties related to TLS extensions. Maybe we need to 
reopen that discussion.
> http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/src/java.base/share/classes/sun/security/x509/PKIXExtensions.java.patch
> - Why to break the comments earlyer ?
>
>
You lost me on this last one, can you clarify what you mean?  Do you not 
like where I added the OCSP nonce definition?