<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 1:26 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_-2156600808633327054WordSection1"><p class="MsoNormal">> The intent here is that the CA defines this, and what they define, they follow. I agree that there's an opportunity to improve the consistency across CAs, but I think similar to SC30, or past work (e.g. CAA), the first step is to permit CAs to work through their policies as to what most appropriate means, based on the criteria they define and the guidance within RFC 5280 and, where appropriate, ITU-T X.509.<br><br><u></u><u></u></p><p class="MsoNormal">Many CAs provide the ability for Subscribers to revoke their own end-entity certificates and supply their own reasonCodes with no manual intervention by CA support personnel.</p></div></div></blockquote><div><br></div><div>Ah, thanks for clarifying. This is really useful feedback!</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_-2156600808633327054WordSection1"><p class="MsoNormal"> In attempting to fulfill the “MUST” for selecting the most appropriate reasonCode, is the expectation that CAs must now work with the Subscriber on a per-revocation basis to determine the facts and circumstances surrounding the revocation to arrive the most appropriate reasonCode? Or can CAs continue to allow Subscribers to select their own reasonCodes (presumably from an acceptable subset of reasonCodes that can be chosen from)?</p></div></div></blockquote><div><br></div><div>I guess a question here is if a key is compromised, does the CA allow the customer to <i>not</i> specify that reason? I'm particularly interested in the case where the CA is informed (e.g. via a problem report) of the compromise.</div><div><br></div><div>Figuring out how that is handled is, I think, important to figuring out how best to answer your question :) </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_-2156600808633327054WordSection1"><p class="MsoNormal"><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Thanks,<u></u><u></u></p><p class="MsoNormal">Corey<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><div style="border-top:none;border-right:none;border-bottom:none;border-left:1.5pt solid blue;padding:0in 0in 0in 4pt"><div><div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in"><p class="MsoNormal"><b>From:</b> Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>> <br><b>Sent:</b> Thursday, June 25, 2020 12:40 PM<br><b>To:</b> Corey Bonnell <<a href="mailto:CBonnell@securetrust.com" target="_blank">CBonnell@securetrust.com</a>>; CA/B Forum Server Certificate WG Public Discussion List <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>><br><b>Subject:</b> Re: [Servercert-wg] Ballot SC31 Browser Alignment - CRL and OCSP profiles<u></u><u></u></p></div></div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal"><u></u> <u></u></p></div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">On Thu, Jun 25, 2020 at 12:12 PM Corey Bonnell via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>> wrote:<u></u><u></u></p></div><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt"><div><div><p class="MsoNormal">In giving another pass on the SC31 ballot text, I have the following questions/comments:<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">From 7.2.2 (<a href="https://scanmail.trustwave.com/?c=4062&d=ktP03jw8Wsdzf10VIGVklQrreSN-fYkNs3wNRif2sg&s=5&u=https%3a%2f%2fgithub%2ecom%2fcabforum%2fdocuments%2fpull%2f195%2ffiles%23diff-7f6d14a20e7f3beb696b45e1bf8196f2R1986" target="_blank">https://github.com/cabforum/documents/pull/195/files#diff-7f6d14a20e7f3beb696b45e1bf8196f2R1986</a>):<u></u><u></u></p><p class="MsoNormal">> The `CRLReason` indicated MUST NOT be unspecified (0), MUST NOT be certificateHold (6), and MUST indicate the most appropriate reason for revocation of the certificate.<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">1. Does this requirement apply to end-entity certificate CRL entries? The formatting makes it appear that it does, but the Root Program requirement where this is derived from only is for CA certificates. <u></u><u></u></p></div></div></blockquote><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">So there's two parts to unpack:<u></u><u></u></p></div><div><p class="MsoNormal">A)  Is the reason code required<u></u><u></u></p></div><div><p class="MsoNormal">B) If the reason code is present, what's expected<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">The attempt to answer A is<u></u><u></u></p></div><div><p class="MsoNormal"><a href="https://scanmail.trustwave.com/?c=4062&d=ktP03jw8Wsdzf10VIGVklQrreSN-fYkNsyBfF3Ck4A&s=5&u=https%3a%2f%2fgithub%2ecom%2fcabforum%2fdocuments%2fpull%2f195%2ffiles%23diff-7f6d14a20e7f3beb696b45e1bf8196f2R1990-R1994" target="_blank">https://github.com/cabforum/documents/pull/195/files#diff-7f6d14a20e7f3beb696b45e1bf8196f2R1990-R1994</a><u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">It MUST be present for Intermediates. This comes from Microsoft.<u></u><u></u></p></div><div><p class="MsoNormal">It SHOULD be present for end-entities. This comes from browsers consuming CRLs and acting on them (Apple, Google, Mozilla), and those that prioritize reason status (Google).<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">The answer for B is<u></u><u></u></p></div><div><p class="MsoNormal"><a href="https://scanmail.trustwave.com/?c=4062&d=ktP03jw8Wsdzf10VIGVklQrreSN-fYkNsyELECX15Q&s=5&u=https%3a%2f%2fgithub%2ecom%2fcabforum%2fdocuments%2fpull%2f195%2ffiles%23diff-7f6d14a20e7f3beb696b45e1bf8196f2R1995-R1997" target="_blank">https://github.com/cabforum/documents/pull/195/files#diff-7f6d14a20e7f3beb696b45e1bf8196f2R1995-R1997</a><u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">This is profiling a SHOULD of the relevant RFCs into a MUST, and is effectively saying "Use the smallest possible encoding". If a Subscriber certificate is revoked for an unspecified reason, the "minimal encoding" is actually to omit the CRLReason entirely. It has the same semantics, but saves twelve bytes.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Here, this applies to *all* entries in the CRL. The prohibition on certificateHold reflects the prohibition on certificate suspension.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt"><div><div><p class="MsoNormal">2. Given that the semantics of the X.509 reasonCodes are not well defined [1], do Root Programs have guidance on what each allowed reasonCode means and when it is most appropriate to use? Absent this, I think the “MUST” requirement should be relaxed to a “SHOULD” (or eliminated entirely) until there are commonly agreed-upon semantics for the allowed set of reasonCodes.<u></u><u></u></p></div></div></blockquote><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">The intent here is that the CA defines this, and what they define, they follow. I agree that there's an opportunity to improve the consistency across CAs, but I think similar to SC30, or past work (e.g. CAA), the first step is to permit CAs to work through their policies as to what most appropriate means, based on the criteria they define and the guidance within RFC 5280 and, where appropriate, ITU-T X.509.<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt"><div><div><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">From 7.3 (<a href="https://scanmail.trustwave.com/?c=4062&d=ktP03jw8Wsdzf10VIGVklQrreSN-fYkNs3NXRnTx5A&s=5&u=https%3a%2f%2fgithub%2ecom%2fcabforum%2fdocuments%2fpull%2f195%2ffiles%23diff-7f6d14a20e7f3beb696b45e1bf8196f2R1998" target="_blank">https://github.com/cabforum/documents/pull/195/files#diff-7f6d14a20e7f3beb696b45e1bf8196f2R1998</a>):<u></u><u></u></p><p class="MsoNormal">> The `CRLReason` used SHALL contain a value permitted for CRLs, as specified in Section 7.2.2.<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">Similar to question #1 above, does this apply to OCSP responses for end-entity certificates?<u></u><u></u></p></div></div></blockquote><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"> If present, yes.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Similar to answer A, this is optional for end-entity certificates to be present, but when it is present, it should follow a consistent form as the CRL, since OCSP and CRLs are meant to be interchangeable to an extent.<u></u><u></u></p></div></div></div></div></div></div></blockquote></div></div>