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

Xuelei Fan xuelei.fan at oracle.com
Fri Jul 3 00:15:10 UTC 2015

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),
>>     ocsp_multi-4 (for GeoTrust)
>> We are expected to use ocsp_multi-3 for the server cert.  I think your
>> implementation would use ocsp_multi-1 (for Entrust) as the OCSP
>> responder for Verisign Class 3 server cert.  That's another one of my
>> concerns.
> In a case like this, I think the distinguishing factor between those
> ocsp_multi ItemV2s is one or more ResponderIds.  Since we're not
> supporting server-side ResponderId selection in this first release I
> don't think we can distinguish between these.  I don't know how much of
> a real-world case this is, though when we do support ResponderId
> selection we would definitely need to handle this properly.
In realy-world, if client want to support ResponderIds, the above case
should be common.  The client does not know what kind of cert the server
would be used in general. Therefore, the client would include all
trusted OCSP responders in the request so that the server can selected from.

By "we're not supporting server-side ResponderId selection", I have two
1. we don't support none-empty OCSPStatusRequest, ServerHello would not
include the extension for such cases.
2. we would make an effort to match the requested ResponderID.  If the
ResponderID is the same as what we used to fetch the OCSP response, use
it.  If none of the IDs are available, ServerHello would not include the
extension for such cases.

We cannot send the CertificateStatus if no matching ResponderID, as
would result in handshaking failure.  I would prefer #2 at present.

>>>> See also section 2.2, RFC 6961:
>>>>     "Servers that support a client's selection of responders using the
>>>>      ResponderID field could implement this selection by matching the
>>>>      responder ID values from the client's list with the
>>>> ResponderIDs of
>>>>      known OCSP responders, either by using a binary compare of the
>>>> values
>>>>      or a hash calculation and compare method."
In case we need to handle it in the future, the section above is the
proposal of RFC 6961 about how to handle ResponderId selection.


More information about the security-dev mailing list