<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Courier New";}
span.grey
{mso-style-name:grey;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>You’re right. I was thinking of RFC 2560, I forgot about this note in 6960:<o:p></o:p></span></p><p class=MsoNormal style='page-break-before:always'><span style='font-size:10.0pt;font-family:"Courier New";color:black'>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 <a href="https://tools.ietf.org/html/rfc2560">RFC 2560</a>. For example, the<o:p></o:p></span></p><p class=MsoNormal style='page-break-before:always'><span style='font-size:10.0pt;font-family:"Courier New";color:black'>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 <a href="https://tools.ietf.org/html/rfc5019">RFC 5019</a> and, for that reason, is not capable of providing a signed response for all non-issued certificate serial numbers.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><a name="_MailEndCompose"><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></a></p><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> Ryan Sleevi [mailto:sleevi@google.com] <br><b>Sent:</b> Friday, April 15, 2016 1:21 PM<br><b>To:</b> Jeremy Rowley<br><b>Cc:</b> Peter Bowen; CABFPub<br><b>Subject:</b> Re: [cabfpub] Ballot 167 - Baseline Requirements Corrections<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Fri, Apr 15, 2016 at 12:12 PM, Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>> wrote:<o:p></o:p></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Fri, Apr 15, 2016 at 12:03 PM, Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>> wrote:<o:p></o:p></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><p class=MsoNormal>The BRs require responding "revoked" if the certificate has not been issued while the RFCs specified that the CA should respond "Good".<o:p></o:p></p></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Where?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Section 4.9.10 of BRs 1.3.4<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The requirement is that they don't respond "Good", not that they respond "Revoked". <o:p></o:p></p></div></div></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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)<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>You will also recall that the choice of the BR language ("not good") was precisely because of the intense debate had regarding "return revoked"<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p></div></div></div></body></html>