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?
