[Update]: JEP 249 (OCSP Stapling for TLS)

[Jamil Nimeh]

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 from responseList
>>> to ocspResponses, and the method name from addResponses() to
>>> addOcspResponses()?
>>>
>>> Same for SimpleValidator.java and Validator.java.
>> I've tried to not use "ocsp" in the names, only because OCSP is just one
>> type of stapled response for certificate revocation status. Granted, it
>> is the only one used today.  I didn't want to use a term that denoted
>> that the only kind of data coming through CertificateStatus is OCSP
>> data, since in the future it may be something different.  I know there
>> are places where I didn't adhere to my own rule, but I really tried to
>> where I could.
> Good point.
>
> I had the same concern for the spec of
> ExtendedSSLSession.getStatusResponses().  If the response other than
> OCSP, may need to specify the type of the response.  I'm OK with the
> current API as OCSP is the only cert status we know so far:
>      public List<byte[]> getStatusResponses()
>
> Alternatively, if you want the flexibility to support types other than
> OCSP, the API may look like:
>      public Map<int, List<byte[]>> getStatusResponses()
That's a good idea, Xuelei.  Let me take a closer look at that 
approach.  I think it would pretty easy to make this change, and it 
would involve a minor change to either X509TrustManagerImpl or 
PKIXValidator (probably the latter since that's where we really do 
things with the response bytes).  If the responses are of a type we 
don't currently support, then I think we just treat it as if no 
responses were provided.

If I can get that reworked tonight I'll send out another webrev with 
this last round of comments from you and Sean.

--Jamil