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

[Richard Barnes]

Fine with me.  That's why I prefixed with "If it's non-controversial..." :)

Happy to work with you on a profile cleanup ballot, Peter.

On Wed, Jan 20, 2016 at 12:01 PM, Peter Bowen <pzb at amzn.com> wrote:

> I agree.  I would prefer to have a separate ballot that focused on
> certificate profiles.  In addition to requiring either AIA OCSP or TLS
> Feature Status Request, I would also like to sunset teletexString and
> disallow control characters in all strings.
>
> There is also the open item of determining what changes, if any, are
> needed to section 7.1.4.2.1.  It seems many CAs are including SAN entries
> which are not dNSNames or iPAddresses.
>
> Thanks,
> Peter
>
> On Jan 20, 2016, at 8:48 AM, Ryan Sleevi <sleevi at google.com> wrote:
>
> 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
>>
>>
> _______________________________________________
> 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/227abae1/attachment-0003.html>