hello, this is good news!
jut a quick question before I prepare a full response. There is a "tunables" section mentioned in the JIRA which is not very concrete, is there a draft somewhere for it? Because, I would add as a sample/recommended tunable the option to deny for ServerSockets to respond to requests with nonces, as this is a major DOS risk and most of the good properties of OCSP stapling wont be present if a client requests it. Instead of denying it might also be OK to ignore it, as the per RFC6066 passing request_extension(ocsp-nonce) is a SHOULD in 6961 an "conditional MUST". I guess the responderID will not be honored by the server implementation? (and it is a shame that 6066 and 6961 do not mention the most typical use case with no responderid, no nonce and a single OCSP response provided by the CA issuing the intermediate as well, therefore no multiple-response is needed. I guess the client will not sent a nonce by default (or not at all?)). Also I can understand the restriction to not require API changes I wonder if this is a good idea. I will come back to that later, but just a prelimiary question: will a TrustManager (or HostnameVerifier) be able to actually see and work on the OCSP response - maybe via getHandshakeSession()? In the case I have to connect to a larger number of remote servers it would be good for me to turn the request of on a destination base. With a security/system property thats not so easy. In case of SNI I could work around by constructing the client socket with no hostname, but I really wish both features could be controlled dynamically. Greetings Bernd Am Tue, 02 Sep 2014 14:15:45 -0700 schrieb Jamil Nimeh <jamil.j.ni...@oracle.com>: > Hello all, > > The draft JEP "OCSP Stapling for TLS" has been opened up for > community review. This is an update to the original call for > comments back in mid-March this year[*]. Like some of the other > early JEPs this year, this has been brought under the JEP 2.0 process. > > https://bugs.openjdk.java.net/browse/JDK-8046321 > > Thank you, > --Jamil > > * > http://mail.openjdk.java.net/pipermail/security-dev/2014-March/010327.html
