<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 25, 2020 at 4:11 PM Corey Bonnell <<a href="mailto:CBonnell@securetrust.com">CBonnell@securetrust.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-1953038474602228459WordSection1"><p class="MsoNormal">I don’t think we can get away from trusting what the Subscriber says though. </p></div></div></blockquote><div><snip></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-1953038474602228459WordSection1"><p class="MsoNormal">> If a `reasonCode` CRL entry extension is present, the `CRLReason` MUST indicate the most appropriate reason for revocation of the certificate, as defined by the CA within its CP/CPS.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Having CAs define the semantics of the reasonCodes in their CPS sounds reasonable. However, absent stated expectations on the amount of investigative work that CAs must do to ascertain the correct reasonCode for end-entity certificates (whose meanings are generally not well defined in the first place), the safest bet to avoid non-compliance for CAs is to never supply any revocation information for end-entity certificates. But I agree with you that is a step back. </p></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-1953038474602228459WordSection1"><p class="MsoNormal"><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">As an intermediate step, for the end-entity certificate reasonCode case, could we walk back the “MUST” to a “SHOULD” for specifying the most appropriate reason until the requirements for end-entity reasonCodes are better fleshed out? This would still give CAs an incentive to populate the reasonCode, but not necessarily create a non-compliance event by failing to meet unstated expectations.</p></div></div></blockquote><div><br></div><div>I was actually trying to address both points you raised, although perhaps there's still opportunity for improvement.</div><div><br></div><div>For example, if a CP/CPS said "The Subscriber may request, in writing or via programmatic means, for the CA to revoke the certificate. In such cases, the revocationReason SHALL be cessationOfOperation, unless the Subscriber provides a more specific revocation reason.", that would meet the above, right?</div><div><br></div><div>Am I overlooking something?</div></div></div>