<div dir="ltr"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 25, 2020 at 2:53 PM Corey Bonnell <<a href="mailto:CBonnell@securetrust.com">CBonnell@securetrust.com</a>> wrote:<br></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_-7256018352857399905WordSection1"><p class="MsoNormal">> I guess a question here is if a key is compromised, does the CA allow the customer to not specify that reason? I'm particularly interested in the case where the CA is informed (e.g. via a problem report) of the compromise.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">For Subscriber-initiated revocation requests via web portal or API, it is generally possible for Subscribers to select the reason code they feel is most appropriate to fulfill their obligations of section 9.6.3 (5). In the case of key compromise, the CA is reliant on the Subscriber to provide that reason, as there is no way for the CA always prove that is actually the case.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">For revocations stemming from the CA obtaining proof of compromised keys via a Certificate Problem Report by a Relying Party, CA support personnel processing the report should use the keyCompromise reasonCode if one is being specified at all, but I have no idea if that is the generally accepted handling of such reports across CAs.</p></div></div></blockquote><div><br></div><div>Thanks! I'm trying to think how to accomodate or handle this.</div><div><br></div><div>I think the goal is to make sure we have meaningful reasons, when possible. If a system encourages folks to use "unspecified" (or, more specifically, omit reasons), that seems a step-back. If there's a "whatever the subscriber says goes", then there's a worry that CAs processing problem-reports would then request the subscriber to request revocation, and *not* select keyCompromise, particularly if compromised keys require special handling by the CA (e.g. cleanups & clarifications).</div><div><br></div><div>Similarly, consider if a Subscriber requested a cert be revoked for unspecified, and later the CA was informed it was due to keyCompromise. There's utility in the CA updating the revocation reason to reflect that.</div><div><br></div><div>The intent of the current language, and particularly, the proposed change to SC31, <a href="https://github.com/sleevi/cabforum-docs/pull/30">https://github.com/sleevi/cabforum-docs/pull/30</a> , is to put the onus on the CA to document/describe what they do. Do you think the proposed clarification is sufficient to address these expectations, without creating significant challenges? Namely:</div><div><br></div><div>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.<br></div><div><br></div><div>That's fairly open, and I suspect in a future ballot we could explore what sort of scenarios would be relevant for a CA to disclose within its CP/CPS as part of its handling.</div></div></div>