On 07/18/2015 04:56 PM, Xuelei Fan wrote:
In the new webrev, you try the approach to throw exceptions
CertificateStatus constructor and catch it in ServerHandshaker. It is a
kind a abuse of SSLHandshakeException. I would like to make the
checking before construct CertificateStatus in ServerHa
Hi Jamil,
Looks fine to me. Maybe, a few implementation issues still need to be
addressed, it's OK to me if they get addressed in JDK 9 later in new bugs.
Thank you!
Thanks,
Xuelei
On 7/18/2015 3:19 AM, Jamil Nimeh wrote:
> Sorry for not being explicit about the changes that went into webrev.2
In the new webrev, you try the approach to throw exceptions
CertificateStatus constructor and catch it in ServerHandshaker. It is a
kind a abuse of SSLHandshakeException. I would like to make the
checking before construct CertificateStatus in ServerHandshaker. It's
really hard to understand the
Sorry for not being explicit about the changes that went into webrev.2,
but I've listed them below:
* The StatusResponseManager to do cache checking from the main thread
rather than a worker thread
* A fix in ServerHandshaker's selection of the CertStatusReqItemV2
where I wasn't properly
Hello all,
I have an updated webrev for OCSP stapling which incorporates comments
thus far and a few bug fixes and tests.
webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.2
JEP: https://bugs.openjdk.java.net/browse/JDK-8046321
Thanks,
--Jamil
On 7/3/2015 1:25 AM, Jamil Nimeh wrote:
>> Let's consider one more example, the server cert is issued by Verisign
>> Class 3. The request list looks like:
>>
>> ocsp_multi-1 (for Entrust OCSP responder),
>> ocsp_multi-2 (for Verisign),
>> ocsp_multi-3 (for Verisign Class 3),
>> ocs
On 7/2/2015 9:43 AM, Xuelei Fan wrote:
On 7/2/2015 10:26 PM, Jamil Nimeh wrote:
On 07/02/2015 05:05 AM, Xuelei Fan wrote:
sun/security/ssl/ServerHandshaker.java
==
OCSP stapling only used for certificate-based server authentication at
present. I was wonder
On 7/2/2015 10:26 PM, Jamil Nimeh wrote:
>
>
> On 07/02/2015 05:05 AM, Xuelei Fan wrote:
>> sun/security/ssl/ServerHandshaker.java
>> ==
>> OCSP stapling only used for certificate-based server authentication at
>> present. I was wondering, may be better to ma
On 07/02/2015 05:05 AM, Xuelei Fan wrote:
sun/security/ssl/ServerHandshaker.java
==
OCSP stapling only used for certificate-based server authentication at
present. I was wondering, may be better to make a check before wrap
the ServerHello OCSP extension and
sun/security/ssl/ServerHandshaker.java
==
OCSP stapling only used for certificate-based server authentication at
present. I was wondering, may be better to make a check before wrap
the ServerHello OCSP extension and CertificateStatus message that
Certificate me
src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java
Minor comment:
Not necessary, but in order to indicate the initialization, better to
set statusResponses variable to null explicitly in the constructor.
---
li
On 7/1/2015 10:02 AM, Jamil Nimeh wrote:
>
>
> On 06/30/2015 06:04 PM, Xuelei Fan wrote:
>> On 7/1/2015 6:39 AM, Jamil Nimeh wrote:
src/java.base/share/classes/sun/security/ssl/HandshakeMessage.java
==
line 713/714, 73
On 06/30/2015 06:53 PM, Xuelei Fan wrote:
On 7/1/2015 7:38 AM, Jamil Nimeh wrote:
src/java.base/share/classes/sun/security/validator/PKIXValidator.java
=
minor comment:
Is it more instinctive if changing the parameter name fr
On 06/30/2015 06:04 PM, Xuelei Fan wrote:
On 7/1/2015 6:39 AM, Jamil Nimeh wrote:
src/java.base/share/classes/sun/security/ssl/HandshakeMessage.java
==
line 713/714, 730/731 throws SSLHandshakeException for extension
constructor i
On 7/1/2015 7:38 AM, Jamil Nimeh wrote:
>> src/java.base/share/classes/sun/security/validator/PKIXValidator.java
>> =
>> minor comment:
>>
>> Is it more instinctive if changing the parameter name from responseList
>> to ocspRespons
On 7/1/2015 6:39 AM, Jamil Nimeh wrote:
>> src/java.base/share/classes/sun/security/ssl/HandshakeMessage.java
>> ==
>> line 713/714, 730/731 throws SSLHandshakeException for extension
>> constructor in server side. That's unlikely to
On 06/29/2015 10:29 PM, Xuelei Fan wrote:
src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java
==
minor comment:
1603 if (!staplingActive) {
1604 fatalSE(Alerts.alert_unexpected_message,
1605
Hi Xuelei, I'm working on your comments now. Thanks for all the useful
feedback. I'm working on the comments in your other emails, too.
On 06/30/2015 02:46 AM, Xuelei Fan wrote:
src/java.base/share/classes/sun/security/ssl/HandshakeMessage.java
Hi Jamil,
On 06/27/2015 11:06 AM, Jamil Nimeh wrote:
Hello all, I've posted an updated webrev based on comments I've received
so far:
http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.1
I didn't have time to review the tests yet but was able to review most
of the code in the other fi
src/java.base/share/classes/sun/security/ssl/HandshakeMessage.java
==
676 private List encodedResponses = new ArrayList<>(4);
4 may be not the best estimate. Maybe better to make the initialization
in the constructor.
src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java
==
minor comment:
1603 if (!staplingActive) {
1604 fatalSE(Alerts.alert_unexpected_message,
1605 "Unexpected CertificateStatus
Hello all, I've posted an updated webrev based on comments I've received
so far:
http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.1
Thanks,
--Jamil
On 06/18/2015 05:27 PM, Jamil Nimeh wrote:
Hello all,
I have a first cut at the OCSP stapling webrev posted for your review:
JEP: http
On 06/24/2015 09:32 PM, Xuelei Fan wrote:
src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java
==
A key/trust manager would better to be immutable.
private final ThreadLocal clientValidator ...
private final
src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java
==
A key/trust manager would better to be immutable.
private final ThreadLocal clientValidator ...
private final ThreadLocal serverValidator ...
ThreadLocal
On 06/23/2015 01:17 AM, Bernd Eckenfels wrote:
Hello,
this is a general comment, not necesarily applicable for the OCSP
stapling options directly:
Am Tue, 23 Jun 2015 15:39:30 +0800
schrieb Xuelei Fan:
Caches, for example session/trust manager/key manager, are used a lot
in SSL/TLS handsh
On 6/23/2015 4:17 PM, Bernd Eckenfels wrote:
> Hello,
>
> this is a general comment, not necesarily applicable for the OCSP
> stapling options directly:
>
> Am Tue, 23 Jun 2015 15:39:30 +0800
> schrieb Xuelei Fan :
>
>> Caches, for example session/trust manager/key manager, are used a lot
>> in
Hello,
this is a general comment, not necesarily applicable for the OCSP
stapling options directly:
Am Tue, 23 Jun 2015 15:39:30 +0800
schrieb Xuelei Fan :
> Caches, for example session/trust manager/key manager, are used a lot
> in SSL/TLS handshaking. Dynamic system property may make the
> b
On 6/23/2015 3:04 PM, Jamil Nimeh wrote:
>> src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java
>> ==
>> - private final boolean enableStatusRequestExtension =
>> + private final static boolean enableStatusRequestExten
Hi Xuelei, thanks for the comments. Keep 'em coming!
On 06/22/2015 08:26 PM, Xuelei Fan wrote:
src/java.base/share/classes/sun/security/ssl/HandshakeStateManager.java
===
Thanks for the correction of typos, etc.
line 777-797.
src/java.base/share/classes/sun/security/ssl/HandshakeStateManager.java
===
Thanks for the correction of typos, etc.
line 777-797.
Mayber, we can use the "default" block at line 857, and may not need the
block from line 777 to 797
Just one follow up from a previous set of comments:
On 06/21/2015 12:12 PM, Thomas Lußnig wrote:
On 21.06.2015 17:56, Jamil Nimeh wrote:
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 a
On 21.06.2015 17:56, Jamil Nimeh wrote:
>
> 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
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.pat
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
Hi Xuelei, those are all good comments. I'll make the changes. Thanks
for the quick spec feedback.
--Jamil
On 6/18/2015 9:21 PM, Xuelei Fan wrote:
src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java
=
- * Obtains a
src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java
=
- * Obtains a {@link List} containing all status responses presented by
- * the peer.
+ * Obtains a {@link List} containing DER-encoded OCSP responses
+ * (using t
Hello all,
I have a first cut at the OCSP stapling webrev posted for your review:
JEP: https://bugs.openjdk.java.net/browse/JDK-8046321
Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/
A couple items to note:
* I'm in the process of updating the JEP with some more details.
New JEP Candidate: http://openjdk.java.net/jeps/249
- Mark
38 matches
Mail list logo
