<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:Aptos;}
@font-face
{font-family:"Segoe Script";
panose-1:3 11 5 4 2 0 0 0 0 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:12.0pt;
font-family:"Aptos",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:11.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
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" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Hi,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I would like to discuss the case 3 / affiliationChanged. What if Subscriber has changed their O name and want to replace their current now invalid certificates. Today we have instructed them to use 3 / affiliationChanged
but the described new proposal would deny that. I think that Subscriber initiated 3 / affiliationChanged is better in this use case than 4 / superseded (or 0 / unspecified).
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Best Regards<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Pekka<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Telia Company<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Servercert-wg <servercert-wg-bounces@cabforum.org>
<b>On Behalf Of </b>Wendy Brown - QT3LB-C via Servercert-wg<br>
<b>Sent:</b> Wednesday, October 9, 2024 2:31 PM<br>
<b>To:</b> Aaron Gable <aaron@letsencrypt.org>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg@cabforum.org><br>
<b>Subject:</b> Re: [Servercert-wg] Concrete revocation reason proposal based on Ben Wilson's F2F presentation<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">I disagree with your categorization of 5 / cessationOfOperation<o:p></o:p></p>
<div>
<p class="MsoNormal">Only the subscriber might know if they have decided to stop operating the system for which the certificate was issued and should be able to request revocation for that reason. It does not necessarily mean that the CA messed up.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks,<br clear="all">
<o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Segoe Script"">Wendy</span><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">Wendy Brown<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Supporting GSA<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">FPKIMA Technical Liaison<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Protiviti Government Services<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">703-965-2990 (cell)</span><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Tue, Oct 8, 2024 at 5:37<span style="font-family:"Arial",sans-serif"> </span>PM Aaron Gable via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org">servercert-wg@cabforum.org</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal">We've already made good updates to the list of acceptable revocation reason codes and the circumstances in which they may/must be used in the last few years, but I think we all agree that we can still do better. I like the idea of fully
specifying which reason codes can only be requested by the Subscriber versus which reason codes can only be administratively set by the CA. And I like the idea of having clear delineations around which revocation reasons are more "security critical" than others.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Yes, this means departing somewhat from the original reason code definitions as laid out by ITU-T X.509, but I think the result is clean. And in the end the most important thing is that CAs and Browsers agree on what each reason code means,
and that's what this forum is for.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">So here's a concrete starting proposal:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">0 / unspecified: Can be requested by either the Subscriber or the CA, but can only be used administratively by the CA if no other reason applies.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">1 / keyCompromise: Can be requested by either the Subscriber or the CA. MUST be used in specific circumstances (when compromise is demonstrated or demonstrably easy) and MUST NOT be used in others (when compromise is not demonstrated).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">3 / affiliationChanged: Indicates that the certificate has been revoked because the CA messed up as part of validation (e.g. failed to perform DCV correctly, put a typo in the Organization field). Can only be administratively set by the
CA, and only in response to incidents.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">4 / superseded: Indicates that the certificate has been replaced. Can only be requested by the Subscriber because only they know if it's actually been replaced. Intended to be used to reduce the "stale certificate" issue as presented by
Zane Ma.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">5 / cessationOfOperation: Indicates that the certificate has been revoked because the CA messed up
<i>other than</i> during validation (e.g. issued with a too-long validity period, included the wrong CRL URL, etc). Can only be administratively set by the CA, and only in response to incidents.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">9 / privilegeWithdrawn: Indicates that the certificate has been revoked because the Subscriber messed up (e.g. violated the Subscriber Agreement, presented false validation information, etc). Can only be administratively set by the CA.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The other reason codes (2 / cACompromise, 6 / certificateHold, 7 / unused, 8 / removeFromCRL, and 10 / aACompromise) MUST NOT be used.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">With this framework, it's easy to see that keyCompromise and affiliationChanged are the most critical revocation reason codes to pay attention to. It's clear that Subscribers can only request reason codes 0, 1, and 4; and clear that CAs
can only unilaterally set reason codes 0, 1, and 9, except in exceptional circumstances that should be reflected by a public incident report. It makes it much easier to tell if the appropriate reason code has been set in each circumstance, which in turn makes
it much easier for user-agents to react to different reason codes differently.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">We'd still have the list of circumstances under which a cert must be revoked in Section 4.9.1.1, but the corresponding reason code in each bullet point would change.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I'm certainly not wedded to the details of this proposal, but I wanted to kick off discussion with a concrete starting point. What do people think about moving in a direction similar to this?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks,<br>
Aaron<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
Servercert-wg mailing list<br>
<a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><o:p></o:p></p>
</blockquote>
</div>
</div>
<div style="font-size:9pt; font-family: 'Calibri',sans-serif;"><br>
<i>This email may contain information which is privileged or protected against unauthorized disclosure or communication. If you are not the intended recipient, please notify the sender and delete this message and any attachments from your system without producing,
distributing or retaining copies thereof or disclosing its contents to any other person.
<br>
<br>
Telia Company processes emails and other files that may contain personal data in accordance with Telia Company’s
<a href="https://www.teliacompany.com/en/about-the-company/privacy/">Privacy Policy</a>.</i>
<br>
<br>
<br>
</div>
</body>
</html>