[cabfpub] Fwd: OCSP exception contingent on must-staple (was Re: SHA1 certs issued this year chaining to included roots)

[Ryan Sleevi]

I would object to adding this to that ballot. It's not non-controversial
(as seen in past discussions on the list), but also, we should keep ballots
as simple as possible and as singularly scoped :)

On Wed, Jan 20, 2016 at 7:26 AM, Richard Barnes <rbarnes at mozilla.com> wrote:

> Redirecting to CABF, where I meant to send it in the first place...
>
> ---------- Forwarded message ----------
> From: Richard Barnes <rbarnes at mozilla.com>
> Date: Wed, Jan 20, 2016 at 9:35 AM
> Subject: OCSP exception contingent on must-staple (was Re: SHA1 certs
> issued this year chaining to included roots)
> To: Rob Stradling <rob.stradling at comodo.com>
> Cc: Charles Reiss <woggling at gmail.com>, "
> mozilla-dev-security-policy at lists.mozilla.org" <
> mozilla-dev-security-policy at lists.mozilla.org>
>
>
> Changing the subject line as this is branching a bit...
>
> On Wed, Jan 20, 2016 at 8:24 AM, Rob Stradling <rob.stradling at comodo.com>
> wrote:
>
>> On 19/01/16 21:13, Charles Reiss wrote:
>>
>>> On 01/19/16 11:49, Jakob Bohm wrote:
>>>
>> <snip>
>>
>>> If there is no OCSP, it obviously cannot be stapled.
>>>>
>>>
>>> The CA/Browser forum BRs contemplate OCSP stapling without an OCSP
>>> responder
>>> being listed in the certificate in section 7.1.2.2.c ("The HTTP URL of
>>> the
>>> Issuing CA’s OCSP responder MAY be omitted, provided that the Subscriber
>>> “staples” the OCSP response for the Certificate in its TLS handshakes
>>> [RFC4366].") I assume the idea is that the OCSP responder URL would be
>>> manually
>>> configured in the server and that this would make the certificate
>>> slightly smaller.
>>>
>>
>> IIRC, the original motivation for this text was to make it possible to
>> suppress OCSP requests directly from TLS clients (that don't support OCSP
>> Stapling).  In particular, there was a concern that some OCSP responders
>> might not be able to cope with the OCSP traffic generated by certs used by
>> sites with extremely high numbers of users.
>>
>> At the time, Firefox didn't support OCSP Stapling, and it was much less
>> common for CAs to use CDNs for their OCSP responders.  (Indeed, some CAs
>> didn't even support OCSP back then).
>>
>
> This sentence has always bothered me, though, because in order to make
> sense, you would have to have the CA verify that the OCSP response is
> stapled, and there's not any requirement to do that.  ISTM that omitting
> the OCSP URL only really makes sense if there's a TLS Feature extension
> requiring stapling (i.e., must-staple).
>
> """
> The HTTP URL of  the Issuing CA’s OCSP responder MAY be omitted, provided
> that the Certificate contains a TLS Feature extension including the value
> status_request(5).  This extension requires that the Subscriber “staples”
> the OCSP response for the Certificate in its TLS handshakes [RFC4366]."
> """
>
> If this is non-controversial, maybe this is something to add to Bowen's
> ballot that's being discussed on another thread?
>
> --Richard
>
>
>
>>
>> --
>> Rob Stradling
>> Senior Research & Development Scientist
>> COMODO - Creating Trust Online
>>
>>
>> _______________________________________________
>> dev-security-policy mailing list
>> dev-security-policy at lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160120/83dadd65/attachment-0003.html>