[cabfpub] Ballot 167 - Baseline Requirements Corrections

Ryan Sleevi sleevi at google.com
Fri Apr 15 12:21:21 MST 2016


On Fri, Apr 15, 2016 at 12:12 PM, Ryan Sleevi <sleevi at google.com> wrote:

>
>
> On Fri, Apr 15, 2016 at 12:03 PM, Jeremy Rowley <
> jeremy.rowley at digicert.com> wrote:
>
>> The BRs require responding "revoked" if the certificate has not been
>> issued while the RFCs specified that the CA should respond "Good".
>>
>
> Where?
>
> Section 4.9.10 of BRs 1.3.4
>
> If the OCSP responder receives a request for status of a certificate that
> has not been issued, then the responder SHOULD NOT respond with a "good"
> status. The CA SHOULD monitor the responder for such requests as part of
> its security response procedures. Effective 1 August 2013, OCSP responders
> for CAs which are not Technically Constrained in line with Section 7.1.5
> MUST NOT respond with a "good" status for such certificates.
>
> The requirement is that they don't respond "Good", not that they respond
> "Revoked".
>

I should add that none of the section you objected to is related to
Certificates and CRLs, and do not say anything about OCSP. The portion of
the ballot that deals with OCSP does not change any of the normative
requirements beyond updating the reference from 2560/5019 (which already
exist in the BRs, c.f. v1.3.4 Section 4.9.9) to RFC 6960 (which obsoletes
2560)

If you read RFC 6960, Section 2.2, you will find that it's not at conflict
with the spec to not return "Good" - for example, the Unknown status is
sufficient.

You will also recall that the choice of the BR language ("not good") was
precisely because of the intense debate had regarding "return revoked"

You can find this in the discussion in the public mailing list, and in
pkix, with respect to Ballot 80. I think you may just be confused as to
what was actually passed and part of the BRs, as Peter's proposal does not
change or introduce conflict, nor does such conflict exist today.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160415/269b6958/attachment.html 


More information about the Public mailing list