<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 13, 2017 at 2:19 PM, Curt Spann via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> * revoked = unexpired, and present in either/both of CRL and OCSP<br>
</span>CES: Did you really intended for the ‘either/both’ instead of just ‘both'? I don’t think it would be a good idea to only have a certificate’s revoked status in one form the of the revocation data and not the other.<br></blockquote><div><br></div><div>This mostly stems from the fact that 7.1.2.3 allows for omission of the cRLDistributionPoints (Item b), but requires OCSP (Item c), unless the server supports stapling.</div><div><br></div><div>7.1.2.2 requires the cRLDistributionPoints for sub-CAs (which can _also_ be server certificates, since we don't restrict the subjectAltName on such certificates), but also allows (strangely) the omission of OCSP for stapling (I suppose it's presuming OCSP multi-staple)?</div><div><br></div><div>Happy to take a stab at correcting both of these via Ballot, since I suspect the logical intent, as reflected in your question, is that:</div><div><br></div><div>1) CRLs MUST always be present on intermediates</div><div>2) OCSP MUST always be present on intermediates (or are we really advocating for the terribad multi-staple?)</div><div>3) CRLs MAY be present on end-entity certificates</div><div>4) OCSP MUST be present on end-entity certificates, unless the server supports stapling</div><div>5) CRLs and OCSP responses MUST return the same revocation status information (presumably, either in Section 2.1 or Section 4.10.1 / 4.10.2)</div></div></div></div>