<div dir="ltr">To be clear, I think this ballot does provide much-needed clarity, and in a vacuum am generally supportive of it (hence my earlier engagement and contributions to refine the phrasing in certain aspects).<div><br></div><div>I'm reacting largely to Ryan's question, as well as to similar comments/questions that have been posed in other CABF meetings over the last year or so. It's felt like there's been a general drift among root programs <i>away</i> from wanting to require weak-key checks. Perhaps that feeling was misplaced, perhaps it was misunderstood and based on statements solely about the Debian checks, or perhaps we're anticipating too far into the future. Regardless, we just want to make sure that CAs aren't asked to do work which would be quickly made moot.</div><div><br></div><div>Thanks,</div><div>Aaron</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 6, 2023 at 3:37 PM Clint Wilson <<a href="mailto:clintw@apple.com">clintw@apple.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>I may have missed something, but has there been a proposal to fully remove weak key checking requirements, or is this more in response to the question Ryan posed as to whether Forum participants feel such checks should be removed? I had understood the discussion to primarily have been centered on/specific to Debian weak keys, using the time since that vulnerability was disclosed as the main justification for considering such a removal.<div><br><div>Since we currently have weak key checking requirements, can you help me understand in what ways this ballot doesn't provide the clarity you’re seeking?</div><div><br></div><div>I think there’s a meaningful difference between a website’s software generating weak keys and a CA choosing to sign a weak key. The former stems from an evergreen problem which the Forum can likely not meaningfully impact. The latter involves a highly-trusted, technically capable, security conscientious party knowingly enabling a complicit veneer of security easily broken, allows for potentially undetected compromise of websites and/or their users, and is fully within the Forum’s remit to effect positively. I cannot see how discarding all weak key checking would result in greater protection of a website than the rejection of a certificate request due to a known weak key being presented by the Applicant, which at the bare minimum provides a signal to the website that something is amiss. Given that the website’s goal was to receive a TLS certificate, its failure to do so (ideally with a descriptive error from the CA) would seem to be more likely to result in a desired outcome than the website receiving a certificate containing an easily compromised key.</div><div><br></div><div>I do empathize with concerns about performing due diligence if there’s the likelihood it would be for naught in the very near future. For example, if the requirements represented in this ballot were replaced or removed prior to November 15, 2023, then certainly the due diligence needed to ensure compliance with this ballot would be quite pointless. I don’t currently see that as remotely likely, however.</div><div>While I think there is interesting conversation to be had regarding Debian weak keys, the barrier to achieving a consensus regarding removing all expectations that CAs check for much more recent vulnerabilities (and ensuring new vulnerabilities are properly protected against when found and disclosed) is substantially higher in my view. As such, in this instance, I don’t believe the due diligence would be misplaced or misspent — though I understand that’s likely not worth much :)</div><div><br></div><div>FWIW, I think the expectation would be to establish that <a href="https://github.com/titanous/rocacheck" target="_blank">https://github.com/titanous/rocacheck</a> behaves in a manner equivalent to <a href="https://github.com/crocs-muni/roca" target="_blank">https://github.com/crocs-muni/roca</a>; maybe ensuring they behave identically is the easiest or most comprehensive way to do that, but I think equivalency is about ensuring they serve the same purpose and provide the same value, which seems more approachable than confirming 1:1 identical behavior in all aspects. Regardless, I definitely hear your point here.</div><div><br></div><div>Thanks!</div><div>-Clint</div><div><div><br><blockquote type="cite"><div>On Jul 6, 2023, at 1:54 PM, Aaron Gable <<a href="mailto:aaron@letsencrypt.org" target="_blank">aaron@letsencrypt.org</a>> wrote:</div><br><div><div dir="ltr">We agree that, if we are going to have requirements for weak key checking, they should be as clear as possible. However, we believe that overall we should be moving away from weak-key requirements.  Weak key checks do little to protect websites: if their software is generating weak keys, it is going to continue to generate weak keys, and end up with no certificate at all. And CAs are already required to revoke and subsequently refuse to issue for known-compromised keys.<div><br></div><div>Adding more clarity now would require CAs to engage in significant amounts of due diligence (for example, to prove beyond a doubt that <a href="https://github.com/titanous/rocacheck" target="_blank">https://github.com/titanous/rocacheck</a> behaves identically to the soon-to-be-blessed <a href="https://github.com/crocs-muni/roca" target="_blank">https://github.com/crocs-muni/roca</a>). We would prefer not to engage in that when weak key requirements may be fully removed shortly thereafter.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 15, 2023 at 10:03 AM Clint Wilson <<a href="mailto:clintw@apple.com" target="_blank">clintw@apple.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>I broadly agree that Debian weak key checking has had diminishing returns in ecosystem value over time, and think dropping those checks specifically to be a reasonable proposal, however I’m not supportive of dropping all weak key checks (especially as new vulnerabilities arise and are identified).<div><br></div><div>Approach-wise, I would prefer moving forward with this ballot as-is, with a follow-on ballot to propose pulling out Debian weak key checks. Just my 2 cents.</div><div><br></div><div>Cheers,</div><div>-Clint<br><div><br><blockquote type="cite"><div>On Jun 8, 2023, at 7:14 AM, Tim Hollebeek via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>> wrote:</div><br><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Yes, if the consensus is to drop them as a requirement, we aren’t necessarily opposed, as that also improves the clarity.  We would probably continue to do most of the checks, as they do provide value to our customers, but other CAs need not be required to do absolutely everything we do.<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">-Tim<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="border-width:medium medium medium 1.5pt;border-style:none none none solid;border-color:currentcolor currentcolor currentcolor blue;padding:0in 0in 0in 4pt"><div><div style="border-width:1pt medium medium;border-style:solid none none;border-color:rgb(225,225,225) currentcolor currentcolor;padding:3pt 0in 0in"><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><b>From:</b><span> </span>Servercert-wg <<a href="mailto:servercert-wg-bounces@cabforum.org" style="color:blue;text-decoration:underline" target="_blank">servercert-wg-bounces@cabforum.org</a>><span> </span><b>On Behalf Of<span> </span></b>Wayne Thayer via Servercert-wg<br><b>Sent:</b><span> </span>Tuesday, June 6, 2023 3:44 PM<br><b>To:</b><span> </span>Aaron Gable <<a href="mailto:aaron@letsencrypt.org" style="color:blue;text-decoration:underline" target="_blank">aaron@letsencrypt.org</a>>; CA/B Forum Server Certificate WG Public Discussion List <<a href="mailto:servercert-wg@cabforum.org" style="color:blue;text-decoration:underline" target="_blank">servercert-wg@cabforum.org</a>><br><b>Subject:</b><span> </span>Re: [Servercert-wg] [EXTERNAL] Re: SC-59 Weak Key Guidance<u></u><u></u></div></div></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">I agree with Tim's comments about the need to clarify these requirements. I'm not opposed to dropping them, but if we do that, we need to remove BR 4.9.1.1 (4). If CAs are not required to check for weak keys, they should also not be required to revoke certs containing weak keys.<u></u><u></u></div></div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div></div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Thanks,<u></u><u></u></div></div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div></div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Wayne<u></u><u></u></div></div></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">On Tue, Jun 6, 2023 at 11:42 AM Aaron Gable via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" style="color:blue;text-decoration:underline" target="_blank">servercert-wg@cabforum.org</a>> wrote:<u></u><u></u></div></div><blockquote style="border-width:medium medium medium 1pt;border-style:none none none solid;border-color:currentcolor currentcolor currentcolor rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in"><div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">I concur with the above: the effort required for weak key checking (especially for Debian weak keys, which requires generating and storing huge collections of keys, and doing so again every time the CA's potential key-space expands) outweighs the benefits. All of the weak-key incidents that I personally recall have only found keys purposefully generated by security researchers.<u></u><u></u></div></div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div></div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Additionally, under the ACME protocol, anyone who can derive a private key from a public key can cause any certs using that public key to be revoked. So security researchers who do decide to continue scanning for various forms of weak keys can simply revoke the affected certs immediately.<u></u><u></u></div></div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div></div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Aaron<u></u><u></u></div></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">On Fri, Jun 2, 2023 at 11:22 AM David Kluge via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" style="color:blue;text-decoration:underline" target="_blank">servercert-wg@cabforum.org</a>> wrote:<u></u><u></u></div></div><blockquote style="border-width:medium medium medium 1pt;border-style:none none none solid;border-color:currentcolor currentcolor currentcolor rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in"><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">GTS complies with the ballot as it is written, but we believe that we should carefully assess whether each required weak key check is a valuable use of resources. In particular, the requirement to check for Debian Weak keys appears to have little value relative to the cost to us. The Debian Weak key vulnerability was fixed in 2008, over 15 years ago. Any client that is submitting a vulnerable key is running unpatched code from 2008 or earlier and they are going to be vulnerable to a significant number of other critical CVEs merely from running unpatched code.<br><br>The cost of maintaining this check is not free. The recent publication of ECDSA keys and atypical architectures meant that many CAs likely had to re-architect their Debian Weak key checks to accommodate the new expectations [1]. There is of course always maintenance of code even if the architecture is constant.<br><br>As Ryan mentioned, it may be more prudent for CAs to spend their time on other areas. Ryan mentioned linting, but there are of course many other areas the ecosystem can improve upon. Strengthening domain validation, automation technologies for renewal, increasing capacity/availability to enable shorter-lived certificates, preparing for mass revocation scenarios, etc.<br><br>[1]<span> </span><a href="https://url.avanan.click/v2/___https:/bugzilla.mozilla.org/show_bug.cgi?id=1789521___.YXAzOmRpZ2ljZXJ0OmE6bzozMzA2NTI2NDU3ZDMyZWJhMjM0NzE0MTJkMGE0MzQyYjo2OjZhZjc6NDkyOTQzMTdjYjdmZGJlN2ExZTNiYzUyZGNkMTVhMGRhN2EzZjk4MTQwZWZmNWEzNjJhNjEzMzI1OTdmYWM0YjpoOkY" title="Protected by Avanan: https://bugzilla.mozilla.org/show_bug.cgi?id=1789521" style="color:blue;text-decoration:underline" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1789521</a><u></u><u></u></div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div></div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">On Thu, Jun 1, 2023 at 7:58 PM Tim Hollebeek via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" style="color:blue;text-decoration:underline" target="_blank">servercert-wg@cabforum.org</a>> wrote:<u></u><u></u></div></div><blockquote style="border-width:medium medium medium 1pt;border-style:none none none solid;border-color:currentcolor currentcolor currentcolor rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in"><div><div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Having these requirements does make some sense, as customers do submit these weak keys from time to time (though rather rarely …).  Where simple checks are able to detect them, it makes sense to do so.<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">For us, there are basically two things that take up the vast majority of time related to weak keys:<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div><ol start="1" type="1" style="margin-bottom:0in"><li class="MsoNormal" style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">The lack of clarity in the current requirements wastes a lot of people’s time figuring out exactly what is required and what isn’t.  The requirements as they exist today, with extremely vague and open-ended guidance, are a compliance nightmare, taking far more time and effort than the benefit they provide.<u></u><u></u></li><li class="MsoNormal" style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">This ballot, and analyzing its many iterations over the years.  It does provide additional clarity, and can and should fix issue #1.  IMO there were, at times, too many efforts to make it perfect instead of good.  We should get it to good, pass it, and move on.<u></u><u></u></li></ol><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">I’m HIGHLY sympathetic to the suggestion that we’ve spent far more time on this than it was worth, but having spent that time, the additional clarity is actually useful.  It does occasionally prevent customers from getting a certificate with a key that is trivially weak, possibly with disastrous consequences.  And it’s pretty easy to comply with an explicit list of concrete technical checks that should be performed on a key before accepting it.<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">-Tim<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div><div style="border-width:medium medium medium 1.5pt;border-style:none none none solid;padding:0in 0in 0in 4pt;border-color:currentcolor currentcolor currentcolor blue"><div><div style="border-width:1pt medium medium;border-style:solid none none;padding:3pt 0in 0in;border-color:currentcolor"><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><b>From:</b><span> </span>Servercert-wg <<a href="mailto:servercert-wg-bounces@cabforum.org" style="color:blue;text-decoration:underline" target="_blank">servercert-wg-bounces@cabforum.org</a>><span> </span><b>On Behalf Of<span> </span></b>Ryan Dickson via Servercert-wg<br><b>Sent:</b><span> </span>Thursday, June 1, 2023 10:32 AM<br><b>To:</b><span> </span>Bruce Morton <<a href="mailto:bruce.morton@entrust.com" style="color:blue;text-decoration:underline" target="_blank">bruce.morton@entrust.com</a>><br><b>Cc:</b><span> </span>CA/B Forum Server Certificate WG Public Discussion List <<a href="mailto:servercert-wg@cabforum.org" style="color:blue;text-decoration:underline" target="_blank">servercert-wg@cabforum.org</a>><br><b>Subject:</b><span> </span>Re: [Servercert-wg] [EXTERNAL] Re: SC-59 Weak Key Guidance<u></u><u></u></div></div></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Hi Bruce,<br><br>Sorry for not being clear. <u></u><u></u></div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div></div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">I was using linting as an example of an automated check that would occur at roughly the same frequency as we observe necessary for weak-key checks (i.e., once for every certificate). While I can't easily quantify the difference in effort comparing linting versus weak-key checking, based on incident disclosures to Bugzilla - we often see issues that could have been prevented with linting, but rarely see incidents related to weak-keys. It's also not clear, on average, what % of certificate requests are rejected due to a violation of 6.1.1.3 (i.e., how prevalent is the "weak-keys problem"?)<br><br>I didn't intend for us to shift the scope of this ballot to focus on linting, but instead, to understand whether CAs thought continued weak-key checking was considered valuable.<span> </span><br><br>Thanks,<br>Ryan<u></u><u></u></div></div></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div><div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">On Thu, Jun 1, 2023 at 10:09 AM Bruce Morton <<a href="mailto:Bruce.Morton@entrust.com" style="color:blue;text-decoration:underline" target="_blank">Bruce.Morton@entrust.com</a>> wrote:<u></u><u></u></div></div><blockquote style="border-width:medium medium medium 1pt;border-style:none none none solid;padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt;border-color:currentcolor currentcolor currentcolor rgb(204,204,204)"><div><div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Hi Ryan,<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">I like your direction, but I need some help understanding how “requiring pre-/post-issuance linting instead of weak-key checks” would reduce the effort by the CA? I’m assuming a CA can meet the proposed ballot by doing pre-issuance linting of the CSR?<span> </span><u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Thanks, Bruce.<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div><div style="border-width:1pt medium medium;border-style:solid none none;padding:3pt 0in 0in;border-color:currentcolor"><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><b>From:</b><span> </span>Servercert-wg <<a href="mailto:servercert-wg-bounces@cabforum.org" style="color:blue;text-decoration:underline" target="_blank">servercert-wg-bounces@cabforum.org</a>><span> </span><b>On Behalf Of<span> </span></b>Ryan Dickson via Servercert-wg<br><b>Sent:</b><span> </span>Thursday, June 1, 2023 9:44 AM<br><b>To:</b><span> </span>Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr" style="color:blue;text-decoration:underline" target="_blank">dzacharo@harica.gr</a>>; CA/B Forum Server Certificate WG Public Discussion List <<a href="mailto:servercert-wg@cabforum.org" style="color:blue;text-decoration:underline" target="_blank">servercert-wg@cabforum.org</a>><br><b>Subject:</b><span> </span>[EXTERNAL] Re: [Servercert-wg] SC-59 Weak Key Guidance<u></u><u></u></div></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">WARNING: This email originated outside of Entrust.<br>DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.<u></u><u></u></div><div class="MsoNormal" align="center" style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif;text-align:center"><hr size="1" width="100%" align="center"></div><div><div style="margin:0in"><span style="font-family:Arial,sans-serif">[back to discussing the ballot]</span><u></u><u></u></div><div style="margin:0in"> <u></u><u></u></div><div style="margin:0in"><span style="font-family:Arial,sans-serif">Hi all,</span><u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div><div style="margin:0in"><span style="font-family:Arial,sans-serif;color:rgb(14,16,26)">I raised the following question during the<span> </span></span><a href="https://url.avanan.click/v2/___https:/urldefense.com/v3/__https:/cabforum.org/2023/01/19/2023-01-19-minutes-of-the-server-certificate-working-group/__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIEn9o8sx8A$___.YXAzOmRpZ2ljZXJ0OmE6bzo0YjI4MjA3MmQyM2YzYTA3YjI4ZjdjNDM2MGNmNjMzMzo2OjU1NzM6ODVjN2M4MTM0NTdjZWY4MDY1ZDVmNTA3YzEwMDhmMTk0ZmYyOGZhZDljZTZkNDRlYzkyYzM3ZDg5NmExMjYzMTpoOkY" title="Protected by Avanan: https://urldefense.com/v3/__https:/cabforum.org/2023/01/19/2023-01-19-minutes-of-the-server-certificate-working-group/__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIEn9o8sx8A$" style="color:blue;text-decoration:underline" target="_blank"><span style="font-family:Arial,sans-serif;color:rgb(74,110,224)">January 19th</span></a><span style="font-family:Arial,sans-serif;color:rgb(14,16,26)"><span> </span>SCWG meeting, but I recognize only some group members can participate in our regularly scheduled meetings.</span><u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div><div style="margin:0in"><span style="font-family:Arial,sans-serif;color:rgb(14,16,26)">Do participants in this Forum feel that weak-key checks should be removed from the scope of a CA’s set of mandatory responsibilities?   </span><u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div><div style="margin:0in"><span style="font-family:Arial,sans-serif;color:rgb(14,16,26)">While I appreciate the work carried out by ecosystem members to produce this ballot, primarily led by the<span> </span></span><a href="https://url.avanan.click/v2/___https:/urldefense.com/v3/__http:/ssl.com__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIElUnEh06Q$___.YXAzOmRpZ2ljZXJ0OmE6bzo0YjI4MjA3MmQyM2YzYTA3YjI4ZjdjNDM2MGNmNjMzMzo2OjQ3ZTU6ZDZjZjFlNmE1M2QwYzJiY2Y5NGNkNjU0MjdlYzkwMjY2YTg4OTUyYWRjZDBjNmQwN2UyNzBlMTY1ZTc3Nzc3MDpoOkY" title="Protected by Avanan: https://urldefense.com/v3/__http:/ssl.com__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIElUnEh06Q$" style="color:blue;text-decoration:underline" target="_blank"><span style="font-family:Arial,sans-serif;color:rgb(74,110,224)">SSL.com</span></a><span style="font-family:Arial,sans-serif;color:rgb(14,16,26)"><span> </span>team, I struggle with the demonstrated security value of these checks compared to the overall effort they represent. </span><u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div><div style="margin:0in"><span style="font-family:Arial,sans-serif;color:rgb(14,16,26)">In a recent Validation Subcommittee meeting where we focused on delegating parts of the domain validation process, we discussed that subscribers often make security decisions that can have considerable consequences but are ultimately beyond the CA’s scope of responsibility (for example, delegating domain validation to an insecure third-party service). Wouldn’t we consider using an outdated software application/library to generate key-pairs along the same lines?</span><u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div><div style="margin:0in"><span style="font-family:Arial,sans-serif;color:rgb(14,16,26)">Beyond perceived security value, I also struggle with the opportunity cost of time spent evaluating weak keys and responding to weak key incidents. It seems to me that something like requiring pre-/post-issuance linting instead of weak-key checks is a better tradeoff and would be more valuable for the ecosystem (e.g., reducing the likelihood of unexpected customer impact due to prescribed revocations timelines in the BRs related to mis-issuance). </span><u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div><div style="margin:0in"><span style="font-family:Arial,sans-serif">As this is now in discussion, I wanted to again offer the perspective that maybe weak-key checks should not be in scope of a CA’s responsibilities in case others share the same opinion. </span><u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div><div style="margin:0in"><span style="font-family:Arial,sans-serif">- Ryan</span><u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div><div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">On Mon, May 29, 2023 at 1:18 AM Dimitris Zacharopoulos (HARICA) via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" style="color:blue;text-decoration:underline" target="_blank">servercert-wg@cabforum.org</a>> wrote:<u></u><u></u></div></div><blockquote style="border-width:medium medium medium 1pt;border-style:none none none solid;padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt;border-color:currentcolor currentcolor currentcolor rgb(204,204,204)"><div><p class="MsoNormal" style="margin:0in 0in 12pt;font-size:11pt;font-family:Calibri,sans-serif">Hi Clint,<u></u><u></u></p><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">On 26/5/2023 6:45 μ.μ., Clint Wilson wrote:<u></u><u></u></div></div><blockquote style="margin-top:5pt;margin-bottom:5pt"><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Hi Tom, Dimitris,<u></u><u></u></div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div></div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">I continue to be opposed to the SCWG trying to limit effective dates to 2 per year. I think it’s entirely reasonable to align on a day of the month (I think the 15th has broadly been the only one I’ve heard proposed). I think it’s reasonable to try to avoid January and December. I also think there may be value in trying to reduce the overall number of effective dates somewhat. The dates I’m personally in favor of aligning on are February, April, June, August, and October 15th.<u></u><u></u></div></div><div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div></div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">If there’s a particular penchant towards March and September, however, then I’d be unopposed to March, May, July, September, and November 15th. <u></u><u></u></div></div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div></div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">For this ballot in particular, I think October 15 or November 15 2023 are feasible targets for implementing these changes and would greatly prefer closing this issue (open now for<span> </span><u>more than 3 years</u>) sooner than later, especially given the number of incidents we’ve seen in the last years related to weak key vulnerabilities and CAs issuing certificates with weak keys.<u></u><u></u></div></div></div></blockquote><p class="MsoNormal" style="margin:0in 0in 12pt;font-size:11pt;font-family:Calibri,sans-serif"><br>It's fine for me also to close this issue sooner than later which is why I recommended even the September 15, 2023 effective date.<br><br>On the 2 document releases per year issue, this is a preliminary result after having long discussions. I was not aware of any opposition until now, but perhaps your opposition didn't consider the emergency options of the proposal? The "standardized release cycle for Guidelines" proposal addresses a series of concerns about the frequency and number of document updates, as highlighted in the presentation shared in my previous reply. If you recall, the proposal still allows the release of "Emergency Guidelines" that bypasses the 6-month regular release cycle. We still need to work on the details which I hope to make progress on after passing the first Bylaws updates that are already prepared, but I'm confident that all concerns will be addressed.<br><br>If we use this ballot as an example for applying the "standardized release cycle for Guidelines", Apple would propose that this is an Emergency Guideline and specify an effective date that would not be one of March 15 or September 15. If there was no opposition, we would proceed with a ballot that would result in an emergency guideline release and the proposed effective date exactly as we normally do today.<br><br>I plan to start a separate thread to continue this discussion at the Forum level after we make some progress with the recently proposed Bylaws changes.<br><br><br>Thanks,<br>Dimitris.<u></u><u></u></p><blockquote style="margin-top:5pt;margin-bottom:5pt"><div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div></div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Thanks,<u></u><u></u></div></div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">-Clint<u></u><u></u></div></div><div><p class="MsoNormal" style="margin:0in 0in 12pt;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></p><blockquote style="margin-top:5pt;margin-bottom:5pt"><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">On May 26, 2023, at 7:37 AM, Tom Zermeno via Servercert-wg<a href="mailto:servercert-wg@cabforum.org" style="color:blue;text-decoration:underline" target="_blank"><servercert-wg@cabforum.org></a><span> </span>wrote:<u></u><u></u></div></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div><div><div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Hello Dimitris,<u></u><u></u></div></div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div></div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Thank you for the input.  We feel that September 15^th does not provide enough time for CAs to implement these changes, but we are not against the March 15, 2024 effective date, if there is consensus from the Community. <u></u><u></u></div></div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div></div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Thank you,<u></u><u></u></div></div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div></div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Tom<u></u><u></u></div></div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><a href="https://url.avanan.click/v2/___https:/urldefense.com/v3/__http:/ssl.com/__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIEmQZfKH8A$___.YXAzOmRpZ2ljZXJ0OmE6bzo0YjI4MjA3MmQyM2YzYTA3YjI4ZjdjNDM2MGNmNjMzMzo2OmE5ODI6Y2RjOGZmZGQyMWQwZDdlNDQ4ZDhlOTc5YWQ4MzMzMjhhNDJiODYyZTgwNjE2ZmYyZGUxMTAwZTQ2M2Q1YjhiZTpoOkY" title="Protected by Avanan: https://urldefense.com/v3/__http:/ssl.com/__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIEmQZfKH8A$" style="color:blue;text-decoration:underline" target="_blank">SSL.com</a><u></u><u></u></div></div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div></div><div><div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><b>From:</b> Servercert-wg <<a href="mailto:servercert-wg-bounces@cabforum.org" style="color:blue;text-decoration:underline" target="_blank">servercert-wg-bounces@cabforum.org</a>> <b>On Behalf Of </b>Dimitris Zacharopoulos (HARICA) via Servercert-wg<br><b>Sent:</b> Friday, May 26, 2023 1:54 AM<br><b>To:</b> <a href="mailto:servercert-wg@cabforum.org" style="color:blue;text-decoration:underline" target="_blank">servercert-wg@cabforum.org</a><br><b>Subject:</b> Re: [Servercert-wg] SC-59 Weak Key Guidance<u></u><u></u></div></div></div></div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div></div><p class="MsoNormal" style="margin:0in 0in 12pt;font-size:11pt;font-family:Calibri,sans-serif"><br>Hi Tom,<br><br>Historically, the SCWG has been trying to avoid effective dates during January or December. I recommend using September 15, 2023 or March 15, 2024 as possible effective dates. These two dates seem to be <a href="https://url.avanan.click/v2/___https:/urldefense.com/v3/__https:/docs.google.com/presentation/d/1oTGVYqggQpQMR4Lktbu_L6DhuBVJzeuiFGd9EAU1zsE__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIEmlvDMTQg$___.YXAzOmRpZ2ljZXJ0OmE6bzo0YjI4MjA3MmQyM2YzYTA3YjI4ZjdjNDM2MGNmNjMzMzo2OmIwNmU6MjY1N2MzM2E2YTgwNGI3N2M3OWI1NzAzNDFlOGZhODYwZjFlY2Y0YjI2NGVjNDY3YWQzYmUzYWEwYjdlMDEzODpoOkY" title="Protected by Avanan: https://urldefense.com/v3/__https:/docs.google.com/presentation/d/1oTGVYqggQpQMR4Lktbu_L6DhuBVJzeuiFGd9EAU1zsE__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIEmlvDMTQg$" style="color:blue;text-decoration:underline" target="_blank">more favorable</a> than others. <br><br><br>Thanks,<br>Dimitris.<u></u><u></u></p><div><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">On 25/5/2023 10:51 μ.μ., Tom Zermeno via Servercert-wg wrote:<u></u><u></u></div></div></div><blockquote style="margin-top:5pt;margin-bottom:5pt"><p style="vertical-align:baseline">Purpose of Ballot SC-059 V3 <u></u><u></u></p><p style="vertical-align:baseline">Several events within the community have led to concerns that the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates (BRs) lacked a specificity required to properly guide CAs on matters dealing with the identification and processing of digital certificates based on private keys considered weak, or easy to ascertain.  In the hopes that elaboration and clarity on the subject would be beneficial to the community, we are presenting updates to §4.9.1.1(“Reasons for Revoking a Subscriber Certificate) and §6.1.1.3 (Subscriber Key Pair Generation) of the BRs. <u></u><u></u></p><p style="vertical-align:baseline">The first update is to §4.9.1.1 and is made to expand the scope of easily computable Private Keys from “Debian weak keys” to “those listed in section 6.1.1.3(5)”.  While the initial language in the BRs did not exclude other concerns, the use of a single example could be interpreted to mean that other easily computable Private Keys are few and far between.  The next update was to §6.1.1.3(5), wherein we added specific actions to be taken for ROCA vulnerability, Debian weak keys - both RSA and ECDSA – and Close Primes vulnerability.  We also added a link to suggested tools to be used for checking weak keys. Finally, an implementation date of December 1, 2023 was added to allow CAs time to update processes to meet the requirements.  <u></u><u></u></p><p style="vertical-align:baseline">The following motion has been proposed by Thomas Zermeno of <a href="https://url.avanan.click/v2/___https:/urldefense.com/v3/__http:/ssl.com/__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIEmQZfKH8A$___.YXAzOmRpZ2ljZXJ0OmE6bzo0YjI4MjA3MmQyM2YzYTA3YjI4ZjdjNDM2MGNmNjMzMzo2OjQ1YmM6ZTY5NzU0YjkzNjYwNmY0ODY4Y2U2YTE5NDZkNzMxZGNmZmUxOTI1NmI4MjEwZmNlMWQ1OWI3ODA2YTY1MTY2MzpoOkY" title="Protected by Avanan: https://urldefense.com/v3/__http:/ssl.com/__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIEmQZfKH8A$" style="color:blue;text-decoration:underline" target="_blank">SSL.com</a> and endorsed by Ben Wilson of Mozilla and Martijn Katerbarg of Sectigo. <u></u><u></u></p><p style="vertical-align:baseline">--Motion Begins— <u></u><u></u></p><p style="vertical-align:baseline"><span style="font-size:12pt">This ballot is intended to clarify CA responsibilities regarding weak key vulnerabilities, including specific guidance for Debian weak key, ROCA and Close Primes attack vulnerabilities, and modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” as follows, based on Version 2.0.0.  <br> <br>Notes: Upon beginning discussion for SC-59, the then-current version of the BRs was 1.8.4; since that time several ballots have been approved, leading to the increment of the version to 1.8.7 and eventually 2.0.0, which is the latest approved version of the BRs.  The changes introduced in SC-59 do not conflict with any of the recent ballots. As observed with other ballots in the past, minor administrative updates must be made to the proposed ballot text before publication such that the appropriate Version # and Change History are accurately represented (e.g., to indicate these changes will be represented in Version 2.0.1). </span><u></u><u></u></p><p style="vertical-align:baseline">  <u></u><u></u></p><p style="vertical-align:baseline">MODIFY the Baseline Requirements as specified in the following Redline: <a href="https://url.avanan.click/v2/___https:/urldefense.com/v3/__https:/github.com/cabforum/servercert/compare/a0360b61e73476959220dc328e3b68d0224fa0b3...SSLcom:servercert:3b0c6de32595d02fbd96762cda98cdc88addef00__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIEkXOeodFw$___.YXAzOmRpZ2ljZXJ0OmE6bzo0YjI4MjA3MmQyM2YzYTA3YjI4ZjdjNDM2MGNmNjMzMzo2OjMzMDU6ODViNTk3NjgzZmUyNTQ2ZWE1YzMzZjE3ODk2MWE3NWZmYTdjZWRhMWUzZmM4YTE1YzM3YjE2YzZmYjc4ZDczYzpoOkY" title="Protected by Avanan: https://urldefense.com/v3/__https:/github.com/cabforum/servercert/compare/a0360b61e73476959220dc328e3b68d0224fa0b3...SSLcom:servercert:3b0c6de32595d02fbd96762cda98cdc88addef00__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_R" style="color:blue;text-decoration:underline" target="_blank">https://github.com/cabforum/servercert/compare/a0360b61e73476959220dc328e3b68d0224fa0b3...SSLcom:servercert:3b0c6de32595d02fbd96762cda98cdc88addef00</a> <u></u><u></u></p><p style="vertical-align:baseline">  <u></u><u></u></p><p style="vertical-align:baseline">--Motion Ends— <u></u><u></u></p><p style="vertical-align:baseline">This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows: <u></u><u></u></p><p style="vertical-align:baseline">Discussion (11+ days) • Start time: 2023-05-25 19:00:00 UTC • End time: 2023-06-08 18:59:00 UTC <br>Vote for approval (7 days) • Start time: TBD • End time: TBD <u></u><u></u></p><div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div></div><div><p class="MsoNormal" style="margin:0in 0in 12pt;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></p></div><pre style="margin:0in;font-size:10pt;font-family:"Courier New""><u></u> <u></u></pre></blockquote></div></div></blockquote></div></div></blockquote></div></blockquote></div></div></div></div></blockquote></div></div></div></div></div></blockquote></div></div></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">_______________________________________________<br>Servercert-wg mailing list<br><a href="mailto:Servercert-wg@cabforum.org" style="color:blue;text-decoration:underline" target="_blank">Servercert-wg@cabforum.org</a><br><a href="https://url.avanan.click/v2/___https:/lists.cabforum.org/mailman/listinfo/servercert-wg___.YXAzOmRpZ2ljZXJ0OmE6bzozMzA2NTI2NDU3ZDMyZWJhMjM0NzE0MTJkMGE0MzQyYjo2OjI1MjI6OGRjZWVkNDU1MjJiOWY1NDY5MDNhYmMyMzI2ZGEyOWM0YTg2NDM2MTU0OTJiNzA4NTcyOWI0YjU2ZTliMDU0MzpoOkY" title="Protected by Avanan: https://lists.cabforum.org/mailman/listinfo/servercert-wg" style="color:blue;text-decoration:underline" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><u></u><u></u></div></blockquote></div></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">_______________________________________________<br>Servercert-wg mailing list<br><a href="mailto:Servercert-wg@cabforum.org" style="color:blue;text-decoration:underline" target="_blank">Servercert-wg@cabforum.org</a><br><a href="https://url.avanan.click/v2/___https:/lists.cabforum.org/mailman/listinfo/servercert-wg___.YXAzOmRpZ2ljZXJ0OmE6bzozMzA2NTI2NDU3ZDMyZWJhMjM0NzE0MTJkMGE0MzQyYjo2OjdmM2Y6MTc2OWM0YTdiMzRhZmFjNGZhZTRhN2Q3M2Q2NDZlYzYyYmMzOWM1MWJlNzhlNGJlNGMxOTVlNjM2OTZkMTFiYjpoOkY" title="Protected by Avanan: https://lists.cabforum.org/mailman/listinfo/servercert-wg" style="color:blue;text-decoration:underline" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><u></u><u></u></div></blockquote></div></div></div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">_______________________________________________</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">Servercert-wg mailing list</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><a href="mailto:Servercert-wg@cabforum.org" style="color:blue;text-decoration:underline;font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">Servercert-wg@cabforum.org</a><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg" style="color:blue;text-decoration:underline;font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"></div></blockquote></div><br></div></div></blockquote></div>
</div></blockquote></div><br></div></div></div></blockquote></div>