[cabfpub] Fwd: OCSP exception contingent on must-staple (was Re: SHA1 certs issued this year chaining to included roots)
sleevi at google.com
Wed Jan 20 16:48:41 UTC 2016
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>
>> On 19/01/16 21:13, Charles Reiss wrote:
>>> On 01/19/16 11:49, Jakob Bohm wrote:
>>> If there is no OCSP, it obviously cannot be stapled.
>>> The CA/Browser forum BRs contemplate OCSP stapling without an OCSP
>>> being listed in the certificate in section 22.214.171.124.c ("The HTTP URL of
>>> 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
>>> 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?
>> Rob Stradling
>> Senior Research & Development Scientist
>> COMODO - Creating Trust Online
>> dev-security-policy mailing list
>> dev-security-policy at lists.mozilla.org
> Public mailing list
> Public at cabforum.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public