RFR: JEP 249 (OCSP Stapling for TLS)

[Jamil Nimeh]

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 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?
> One example would be Certificate Transparency that use the same response
> message but with other content.
I did a very cursory scan of RFC 6962...correct me if I'm wrong, but 
CT's intersection with OCSP stapling is just that the OCSP response has 
a specific OCSP extension in it, (The certificate timestamp list) 
correct?  If that's the case, then the List of byte arrays handed back 
by ExtendedSSLSession.getStatusResponses() essentially gives you the 
parsed message back.  The CertificateStatus HandshakeMessage object 
doesn't hold the OCSP responses in a parsed form such as 
sun.security.provider.certpath.OCSPResponse.  It just hangs onto the 
byte arrays in the order they are received.  By getting the list out of 
the getStatusResponses method, you're getting the parsed message, with 
the exception of the leading type (ocsp vs. ocsp_multi).  I don't know 
if exposing the HandshakeMessage object would get you anything more 
useful, at least as it is implemented today.
>>> 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.
> Even one property would be ok if it is not boolean but decimal.
> 0 := Off
> 1 := Simple Request
> 2 := ListV2 Request
> 3 := Both Types
>
>>> 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?
> There are many changes like these sample where only the line length is
> changes.
> I ask because today the monitors become wider but not higher so if we
> have small line length but many lines the screen contain less information.
> The qeustion is if the changes are due to some new rules.
>
> -     * Allows additional identities to be bound to the subject of the certificate.
> +     * Allows additional identities to be bound to the subject of the
> +     * certificate.
>
> Gruß Thomas
>
>