<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;}
@font-face
{font-family:Courier-Bold;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;
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>I think the strategy outlined is fine for this ballot, but I do find myself rather concerned about CAs blindly putting information from subscribers into the revocation reason. I have very little confidence this information will be any better than noise, and injecting noise into the signal will only make the signal worse and degrade confidence in what any reason codes mean (since, after all, it may have come from a less than knowledgeable subscriber, and is therefore meaningless). I mean, what are you going to do when a subscriber specifies CACompromise?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>For “revocation requested by subscriber for reasons other than key compromise”, I can see an argument for CessationOfOperation, but even in the absence of a compliance obligation, I think it’s important that even if the revocation is initiated by a subscriber, revocations are performed by CAs, and CAs should not include revocation reasons that they do not know to be accurate. Simply blindly trusting the subscriber’s assertion seems unhelpful to me.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>-Tim<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Servercert-wg <servercert-wg-bounces@cabforum.org> <b>On Behalf Of </b>Ryan Sleevi via Servercert-wg<br><b>Sent:</b> Monday, June 29, 2020 1:28 PM<br><b>To:</b> Corey Bonnell <CBonnell@securetrust.com><br><b>Cc:</b> CA/B Forum Server Certificate WG Public Discussion List <servercert-wg@cabforum.org><br><b>Subject:</b> Re: [Servercert-wg] Ballot SC31 Browser Alignment - CRL and OCSP profiles<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Mon, Jun 29, 2020 at 1:16 PM Corey Bonnell <<a href="mailto:CBonnell@securetrust.com">CBonnell@securetrust.com</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>>> 1. cessationOfOperation would become the new “unspecified”, except that cessationOfOperation is actively misleading as it excludes the possibility that revocation was due to keyCompromise. I’d think that having a default of “no reason”/unspecified is less misleading/confusing, as it does not exclude the possibility that the reason for revocation was keyCompromise.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>> I'm not really sure I understand this objection. Can you elaborate? I fail to see how it precludes the case of keyCompromise, for example?<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>From X.509 section <a href="http://8.5.3.1" target="_blank">8.5.3.1</a>:<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span style='font-size:9.0pt;font-family:Courier-Bold'>cessationOfOperation </span></b><span style='font-size:10.0pt;font-family:"Times New Roman",serif'>indicates that the certificate is no longer needed for the purpose for which it</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;font-family:"Times New Roman",serif'>was issued but there is no cause to suspect that the private key has been compromised.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;font-family:"Times New Roman",serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>It seems misleading for a CA to assert by default that there is no cause for the associated private key to be compromised if the Subscriber actually did not assert that is that case or the CA otherwise gains evidence to make that assertion. This is why having a default of no reason/unspecified is better than cessationOfOperation.<o:p></o:p></p></div></div></blockquote><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>>> 2. The reasonCode of “cessationOfOperation” will be encoded in CRL/OCSP responses by default, thus no reduction of the number of bytes on the wire will be realized in the common case.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>> If that's a meaningful status - i.e. it provides a way for relying parties to distingush - that doesn't seem a step back. Even omitting for clearly specified reasons seems more useful than the status quo.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I don’t see how claiming the cessationOfOperation reasonCode by default provides any value to RPs. As stated above, it is misleading as it is affirmation that the associated private key has not been compromised despite no information to indicate that is the case.<o:p></o:p></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Thanks for the response. I think we're quickly reaching an impasse, at which point, it probably makes sense to merge the request as-is, with the language you're concerned about still in. While not ideal, in that I want to make sure I'm addressing any concerns that might be there, I'm also not sure the concern you're raising is meaningful or entirely consistent within the broader picture of your objection. If I've overlooked something important, I'd appreciate your timely clarification to see if we can, but absent that, I think it makes sense to go forward as-is.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Recall that your original concern was "We allow Subscribers to define their revocation reasons, is this still allowed?", and I attempted to show that yes, it is still allowed and permitted, provided the CA documents within their CP/CPS how they handle that. I'm not sure if your lack of reply on that means that particular concern was suitably addressed, but I'm hopefully not incorrect in assuming it does.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Similarly, it SHOULD-levels a revocation reason for Subscriber certs, which consistent with RFC 2119, means "that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." The objective here, rather moderate in scope, is to simply ensure the CA adequately documents that within their CP/CPS. That is something we've seen successfully work a number of times before, and is indeed the very basis for SC30, so as a foundation, it doesn't seem necessary to object to it.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The semantic distinction you appear to be making is "It's better for a CA not to say they have no evidence to them (unspecified) than to positively assert they have no evidence available to them (cessationOfOperation), even for situations where they have no evidence available to them." That is, you're treating it as if there is a semantic difference from "unspecified" vs "cessationOfOperation" regarding key compromise, despite them both being neutral (not positive) about it. I don't think we can ever say any revocation reason is truly negative re: keyCompromise; it's within that realm of "known unknowns". The benefit, however, to the SHOULD level requirement is that it encourages a CA to actually document their (presumably) established process and criteria, which in turn can further develop into (at a future point) an objective set of auditable criteria. It also encourages the CA to use those reasons, as has already been requested by Root Programs in the past, so that they can better balance and optimize the privacy, security, and usability of certificates within their products.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>It doesn't seem we have any dispute around the normative (MUST/SHALL) level requirements, which is encouraging. This is why I believe it's better to proceed as-is. If there's something important I'm overlooking that you'd wish to be considered, a reply by the end of today is useful. Otherwise, I'll look to fix the issues that this discussion usefully highlighted, and for which I'm greatly appreciative, while accepting our remaining difference is over a semantic quibble with respect to "no cause" being affirmatively negative versus simply neutral.<o:p></o:p></p></div></div></div></div></div></body></html>