[cabfpub] Ballot 167 - Baseline Requirements Corrections

Jeremy Rowley jeremy.rowley at digicert.com
Fri Apr 15 19:38:55 UTC 2016

You’re right. I was thinking of RFC 2560,  I forgot about this note in 6960:

NOTE: The "revoked" status indicates that a certificate with the requested serial number should be rejected, while the "unknown" status indicates that the status could not be determined by this responder, thereby allowing the client to decide whether it wants to try another source of status information (such as a CRL).  This makes the "revoked" response suitable for non-issued certificates (as defined above) where the intention of the responder is to cause the client to reject the certificate rather than trying another source of status information.  The "revoked" status is still optional for non-issued certificates in order to maintain backwards compatibility with deployments of RFC 2560 <https://tools.ietf.org/html/rfc2560> .  For example, the

responder may not have any knowledge about whether a requested serial number has been assigned to any issued certificate, or the responder may provide pre-produced responses in accordance with RFC 5019 <https://tools.ietf.org/html/rfc5019>  and, for that reason, is not capable of providing a signed response for all non-issued certificate serial numbers.




From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Friday, April 15, 2016 1:21 PM
To: Jeremy Rowley
Cc: Peter Bowen; CABFPub
Subject: Re: [cabfpub] Ballot 167 - Baseline Requirements Corrections




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



On Fri, Apr 15, 2016 at 12:03 PM, Jeremy Rowley <jeremy.rowley at digicert.com <mailto: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".




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: <http://lists.cabforum.org/pipermail/public/attachments/20160415/e22e3b0e/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160415/e22e3b0e/attachment-0001.p7s>

More information about the Public mailing list