<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 29/5/2024 10:30 π.μ., Ryan Dickson
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CADEW5O_XuPS718T4LvD1O0FA7F6b80HPsG2vedwHPEMEet+LKw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr"><span
id="gmail-docs-internal-guid-6a7ce25e-7fff-7bef-1e93-350d41233f4a">
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"><font
style="" face="arial, sans-serif">Thanks for the update,
Dimitris - and to the ballot endorsers for their
consideration of the points made in my message.</font></span></p>
<font face="arial, sans-serif"><br>
</font>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"><font
face="arial, sans-serif">In general, I have no
objections to the recently described adoption approach
or timeline. </font></span></p>
<font face="arial, sans-serif"><br>
</font>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font
face="arial, sans-serif"><span
style="color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">>
</span><span
style="color:rgb(0,0,0);font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">I'm
fine with the stated preference for pre-signing over
post-signing linting but the post-signing linting should
not be "NOT RECOMMENDED" because it doesn't do any harm
on its own. The fact is that we must clearly state that
the pre-sign linting is mandatory and the post-sign
linting is optional.</span></font></p>
<p dir="ltr"
style="line-height:1.38;margin-right:30pt;margin-top:10pt;margin-bottom:10pt"><span
style="color:rgb(0,0,0);font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"><font
face="arial, sans-serif">The point I was hoping to make
was that the practice of final certificate linting, if
performed exclusively, should be considered NOT
RECOMMENDED. Sorry for not being more clear. <br>
</font></span></p>
</span></div>
</blockquote>
<br>
<font face="arial, sans-serif">Thanks for the clarification. I
believe there is consensus to push for the pre-signed linting
going forward, leaving the post-signed linting as an additional
control to double-check that everything went well in the final
issuance process but also for future updated linters (see below).<br>
<br>
</font>
<blockquote type="cite"
cite="mid:CADEW5O_XuPS718T4LvD1O0FA7F6b80HPsG2vedwHPEMEet+LKw@mail.gmail.com">
<div dir="ltr"><span
id="gmail-docs-internal-guid-6a7ce25e-7fff-7bef-1e93-350d41233f4a">
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"><font
face="arial, sans-serif">> It is also challenging to
define what an "update" is, at which level (major, minor
version), etc. I would prefer leaving that out of this
particular ballot and let someone else address it in a
separate ballot without risking the speed and success of
the linting ballot. I hope this makes sense.</font></span></p>
<font face="arial, sans-serif"><br>
</font>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"><font
face="arial, sans-serif">It’s not clear to me there’s
urgency behind this ballot, or why we should consider
the speed of requirements drafting meaningful in this
specific case. I believe the need to adopt linting, and
the value the practice plays when considering preventing
mis-issuance, is clear to community members. </font></span></p>
<font face="arial, sans-serif"><br>
</font>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"><font
face="arial, sans-serif">In any event, I can appreciate
the perspective of wanting to take a consistent and
holistic approach re: timelines within the BRs. Perhaps
there’s an opportunity for near-term compromise that
recommends use of updated software versions as described
in my message (and below), while also recognizing future
action is needed to more completely address your concern
moving forward. </font></span></p>
<font face="arial, sans-serif"><br>
</font>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"><font
face="arial, sans-serif">For example, something like: </font></span></p>
<font face="arial, sans-serif"><br>
</font>
<ul style="margin-top:0px;margin-bottom:0px">
<li dir="ltr"
style="list-style-type:disc;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline;white-space:pre"><p
dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"
role="presentation"><font face="arial, sans-serif"><span
style="background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">“</span><span
style="background-color:transparent;font-style:italic;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">CAs SHOULD evaluate and adopt relevant updates made available for applicable linting packages in the context of their certificate issuance practices within 30 days of their release.”</span></font></p></li>
</ul>
<font face="arial, sans-serif"><br>
</font>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"><font
face="arial, sans-serif">OR</font></span></p>
<font face="arial, sans-serif"><br>
</font>
<ul style="margin-top:0px;margin-bottom:0px">
<li dir="ltr"
style="list-style-type:disc;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline;white-space:pre"><p
dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"
role="presentation"><font face="arial, sans-serif"><span
style="background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">“</span><span
style="background-color:transparent;font-style:italic;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">CAs MUST describe how they evaluate and adopt relevant updates made available for applicable linting packages in the context of their certificate issuance practices within their CPS.</span><span
style="background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">”</span></font></p></li>
</ul>
<font face="arial, sans-serif"><br>
</font>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"><font
face="arial, sans-serif">I think offering commentary on
linting package update cadence is useful because in the
case of several recent incident reports disclosed to
Bugzilla, we see CA owners committing to updating to the
latest version of a tool because it’s become clear
through the mis-issuance incident report(s) they were
not running the latest version. From this perspective,
establishing good practice in the BRs to offer better
alignment with the ballot’s problem statement is
considered favorable. <br>
</font></span></p>
</span></div>
</blockquote>
<br>
<font face="arial, sans-serif">The biggest challenge with this
update language is that it must be open to support various
implementations and not be super prescriptive. I believe you are
thinking this from the perspective that a CA will use an external
tool for linting, and therefore installing an update 30 days after
a new version release makes sense. However, we should take into
consideration that the CA may be writing its own linters and the
language in the BRs must support it.<br>
<br>
</font>
<blockquote type="cite"
cite="mid:CADEW5O_XuPS718T4LvD1O0FA7F6b80HPsG2vedwHPEMEet+LKw@mail.gmail.com">
<div dir="ltr"><span
id="gmail-docs-internal-guid-6a7ce25e-7fff-7bef-1e93-350d41233f4a"><font
face="arial, sans-serif"><br>
</font>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font
face="arial, sans-serif"><span
style="color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">One
other consideration that might be worth thinking about
is how to promote a recommendation that CAs evaluate new
linting tools as they become available and known to
Forum members (e.g., added to <a
href="https://cabforum.org/resources/tools/"
moz-do-not-send="true" class="moz-txt-link-freetext">https://cabforum.org/resources/tools/</a>).
For example, pkilint (</span><a
href="https://github.com/digicert/pkilint/releases/tag/v0.9.0"
style="text-decoration-line:none" moz-do-not-send="true"><span
style="background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;text-decoration-line:underline;vertical-align:baseline">Version
0.9.0</span></a><span
style="color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">)
was released about 3-weeks prior to the effective date
described in </span><a
href="https://cabforum.org/2023/03/17/ballot-sc62v2-certificate-profiles-update/"
style="text-decoration-line:none" moz-do-not-send="true"><span
style="background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;text-decoration-line:underline;vertical-align:baseline">SC-62</span></a><span
style="color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">.
It is my understanding that the use of pkilint prior to
SC-62’s effective date would have identified and
possibly prevented nearly all of the mis-issuance
incident reports disclosed over the past few months.
There are a few edges here that need to be considered,
but I think the topic is worth further discussion. <br>
</span></font></p>
</span></div>
</blockquote>
<br>
I'd like to provide an additional perspective. CAs have different
change management policies, some more rigorous than others. It is
not unreasonable to consider that when a new software package is
announced in any industry, it passes security checks and analysis
before being considered for adoption. When pkilint was announced,
just like with other linters in the past, it had to be tested and
analyzed until it was deemed appropriate and secure for production
use in the certificate issuance pipeline. IMHO in order to do this
properly, 3 weeks are not enough. Any new software component built
by a third-party needs to be examined carefully (for its security
and performance), and even for a CA with a very competent software
engineering department will probably need more than 3-weeks to vet
such a tool for production use. Judging from publicly disclosed
incident reports, we see that a number of CAs rely on external
vendors for software development, therefore this vetting process for
third-party software would take even longer. <br>
<br>
I agree that, ideally, a 30-day window to install any linting update
is optimistic but reasonable, however we need to consider the level
of updates (minor? major? how can we define it without knowing the
exact software?) because a major update will require significantly
more effort to review, test and implement. <br>
<br>
How about:<br>
<ul>
<li><span style="font-size:11.0pt"> </span>"If a CA uses third
party developed software for Linting , it SHOULD monitor for
updated versions of that software and plan for updates no later
than three (3) months from the release of the update".</li>
</ul>
While we're in this vein, it would also be useful to add a
recommendation for CAs to lint all non-expired, non-revoked
certificates whenever they install an update of their linting
software.<br>
<ul>
<li>"The CA SHOULD perform Linting on the corpus of its
non-expired, non-revoked Subscriber Certificates whenever it
updates the Linting software".<br>
</li>
</ul>
What do people think about these proposals?<br>
<br>
<br>
Thanks,<br>
Dimitris.<br>
<blockquote type="cite"
cite="mid:CADEW5O_XuPS718T4LvD1O0FA7F6b80HPsG2vedwHPEMEet+LKw@mail.gmail.com">
<div dir="ltr"><span
id="gmail-docs-internal-guid-6a7ce25e-7fff-7bef-1e93-350d41233f4a"><font
face="arial, sans-serif"><br>
</font>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"><font
face="arial, sans-serif">Thanks again!</font></span></p>
<font face="arial, sans-serif"><br>
</font>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"><font
style="" face="arial, sans-serif">- Ryan</font></span></p>
</span><br class="gmail-Apple-interchange-newline">
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sun, May 26, 2024 at
3:41 AM Dimitris Zacharopoulos (HARICA) <<a
href="mailto:dzacharo@harica.gr" moz-do-not-send="true"
class="moz-txt-link-freetext">dzacharo@harica.gr</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> Hi Ryan,<br>
<br>
Thank you for the feedback. After some internal discussions
with Corey and Ben, please see comments inline.<br>
<br>
<div>On 20/5/2024 10:35 μ.μ., Ryan Dickson wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><span
id="m_1600128793445267323m_2832419603062105658gmail-docs-internal-guid-a959ac7f-7fff-df49-cc47-fb40c32b2442"><font
face="arial, sans-serif" color="#000000">
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">Hi
Dimitris, Corey, and Ben,</span></p>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">Thank
you for bringing this ballot forward for the
group’s consideration.</span></p>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;text-decoration-line:underline;vertical-align:baseline">A
few questions:</span></p>
<ul>
<li><span style="background-color:transparent">Given
the perceived value of linting, should we
consider a stronger position on its adoption
(i.e., MUST versus SHOULD)? While I recognize
that the Baseline Requirements represent
minimum expectations, consistent and reliable
adoption of linting seems to provide the
ecosystem with the best chance of addressing
the problem statement described in the ballot
summary.</span></li>
<ul>
<li>To accomplish this goal, the ballot could be
modified to require use of linting (either tbs
certificate linting, pre-certificate linting,
or final certificate linting), with tbs
certificate linting being considered
RECOMMENDED and final certificate linting as
being considered NOT RECOMMENDED.</li>
<li>This goal could be further realized by
either a (1) phased-implementation (i.e.,
SHOULD now, MUST later) - or (2) a
forward-looking effective date that considers
a reasonable timeline for adoption for those
CA Owners looking to adhere to the BRs that do
not perform linting today.</li>
</ul>
</ul>
</font></span></div>
</blockquote>
<br>
I see two issues here:<br>
<ol>
<li>Require linting with either a phased-approach or
directly with a single effective date: I'm fine with
either approach with a slight preference to the
phased-in. CAs should have been following public
incidents and m.d.s.p. discussions for years, so
existing CAs should already be doing pre-sign linting.
OTOH new CAs need the additional guidance. A CA will
either have to create its own technical tools to check
their profiles accuracy or use the recommended
open-source tools we reference.<br>
</li>
<li>I'm fine with the stated preference for pre-signing
over post-signing linting but the post-signing linting
should not be "NOT RECOMMENDED" because it doesn't do
any harm on its own. The fact is that we must clearly
state that the pre-sign linting is mandatory and the
post-sign linting is optional.</li>
</ol>
With that said, Ben and Corey have agreed with a SHOULD
effective date of 15 September, 2024 and a SHALL effective
date of 15 March, 2025. If people have objections to setting
these effective dates, please let me know.<br>
<br>
<blockquote type="cite">
<div dir="ltr"><span
id="m_1600128793445267323m_2832419603062105658gmail-docs-internal-guid-a959ac7f-7fff-df49-cc47-fb40c32b2442"><font
face="arial, sans-serif" color="#000000">
<ul>
<li>Is it worth more clearly establishing
expectations for the evaluation and, when
applicable, deployment of <span
style="background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;text-decoration-line:underline;vertical-align:baseline">updates</span><span
style="background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">
made by or to linting tools. For example, can
we establish a reasonable expectation that
within 30(?) days after an update has been
made to a linting tool relied upon by a CA, it
has either (1) been adopted in the production
issuance environment - or (2) considered not
applicable given the scope of recent updates
(for example, if a CA only issues DV
certificates, and the most recent update only
pertains to EV certificates, there is no
expectation that the updated version is
deployed). </span><br>
</li>
</ul>
</font></span></div>
</blockquote>
<br>
This may open a series of questions around updates in other,
more security-critical components of the CA pipeline. I
think we should address this issue more holistically as it
affects updates to hardware firmware, OS patches, CA vendor
software updates, third-party software dependencies,
switches/router firmware, and other dependencies in
Certificate Management Systems.<br>
<br>
It is also challenging to define what an "update" is, at
which level (major, minor version), etc. I would prefer
leaving that out of this particular ballot and let someone
else address it in a separate ballot without risking the
speed and success of the linting ballot. I hope this makes
sense.<br>
<br>
More feedback is welcome before proceeding with the changes.<br>
<br>
<br>
Best regards,<br>
Dimitris.<br>
<br>
<blockquote type="cite">
<div dir="ltr"><span
id="m_1600128793445267323m_2832419603062105658gmail-docs-internal-guid-a959ac7f-7fff-df49-cc47-fb40c32b2442"><font
face="arial, sans-serif" color="#000000"><br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">Thanks
for your consideration.</span></p>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">-
Ryan</span></p>
</font></span><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, May 20, 2024
at 2:04 PM Inigo Barreira via Servercert-wg <<a
href="mailto:servercert-wg@cabforum.org"
moz-do-not-send="true" class="moz-txt-link-freetext">servercert-wg@cabforum.org</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>
<div lang="ES">
<div>
<p class="MsoNormal"><span
style="font-size:11pt">Hi Dimitris,</span></p>
<p class="MsoNormal"><span
style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span
style="font-size:11pt" lang="EN-US">I don´t
know if the “(help to improve)” is adding
any additional hidden requirement. IMO, I´d
remove that.</span></p>
<p class="MsoNormal"><span
style="font-size:11pt" lang="EN-US"> </span></p>
<p class="MsoNormal"><span
style="font-size:11pt" lang="EN-US">Regards</span></p>
<p class="MsoNormal"><span
style="font-size:11pt" lang="EN-US"> </span></p>
<div>
<div
style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0cm 0cm">
<p class="MsoNormal"><b><span
style="font-size:11pt;font-family:Calibri,sans-serif">De:</span></b><span
style="font-size:11pt;font-family:Calibri,sans-serif"> Servercert-wg
<<a
href="mailto:servercert-wg-bounces@cabforum.org" moz-do-not-send="true"
class="moz-txt-link-freetext">servercert-wg-bounces@cabforum.org</a>>
<b>En nombre de </b>Dimitris
Zacharopoulos (HARICA) via Servercert-wg<br>
<b>Enviado el:</b> lunes, 20 de mayo de
2024 19:57<br>
<b>Para:</b> CA/B Forum Server
Certificate WG Public Discussion List
<<a
href="mailto:servercert-wg@cabforum.org" moz-do-not-send="true"
class="moz-txt-link-freetext">servercert-wg@cabforum.org</a>><br>
<b>Asunto:</b> [Servercert-wg] Ballot
SC-75 - Pre-sign linting</span></p>
</div>
</div>
<o:p class="MsoNormal"> </o:p>
<div style="border:1pt solid black;padding:2pt">
<p class="MsoNormal"
style="line-height:12pt;background:rgb(250,250,3)"><span
style="font-size:10pt;font-family:Calibri,sans-serif;color:black">CAUTION:
This email originated from outside of the
organization. Do not click links or open
attachments unless you recognize the
sender and know the content is safe.</span></p>
</div>
<o:p class="MsoNormal"> </o:p>
<div>
<h1>SC-75 Pre-sign linting</h1>
<h2
id="m_1600128793445267323m_2832419603062105658m_-7238962214217580443bkmrk-summary">Summary</h2>
<p
id="m_1600128793445267323m_2832419603062105658m_-7238962214217580443bkmrk-this-pull-request-pr">There
have been numerous compliance incidents
publicly disclosed by CAs in which they
failed to comply with the technical
requirements described in standards
associated with the issuance and management
of publicly-trusted TLS Certificates.
However, the industry has developed
open-source tools, linters, that are free to
use and can help CAs avoid certificate
misissuance. Using such linters before
issuing a precertificate from a
Publicly-Trusted CA (pre-issuance linting)
can prevent the mis-issuance in a wide
variety of cases.</p>
<p
id="m_1600128793445267323m_2832419603062105658m_-7238962214217580443bkmrk-the-following-motion">The
following motion has been proposed by
Dimitris Zacharopoulos of HARICA and
endorsed by Corey Bonnell of Digicert and
Ben Wilson of Mozilla.</p>
<p
id="m_1600128793445267323m_2832419603062105658m_-7238962214217580443bkmrk-you-can-view-and-com">You
can view the GitHub pull request
representing this ballot <a
href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fpull%2F518&data=05%7C02%7Cinigo.barreira%40sectigo.com%7Cba7a2f0fe37e4bb49d7a08dc78f6397c%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638518246126378220%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ZzEsOoXvcYi%2F%2BO8TpaYY%2FIP7FV9sVmgn2sXa4fhHMTo%3D&reserved=0"
moz-do-not-send="true">here</a>. </p>
<h2
id="m_1600128793445267323m_2832419603062105658m_-7238962214217580443bkmrk-motion-begins">Motion
Begins</h2>
<p
id="m_1600128793445267323m_2832419603062105658m_-7238962214217580443bkmrk-modify-the-%22baseline">MODIFY
the "Baseline Requirements for the Issuance
and Management of Publicly-Trusted TLS
Server Certificates" based on Version 2.0.4
as specified in the following redline:</p>
<ul
id="m_1600128793445267323m_2832419603062105658m_-7238962214217580443bkmrk-https%3A%2F%2Fgithub.com%2Fc"
type="disc">
<li><a
href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fcompare%2F049237e096650fe01f67780b7c24bd5211ee3038...ada5d6e0db76b32be28d64edd7b0677bbef9c2f5&data=05%7C02%7Cinigo.barreira%40sectigo.com%7Cba7a2f0fe37e4bb49d7a08dc78f6397c%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638518246126388782%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=0Yf5qjQ41hV93d91TsZ2PpvnRaK4zysf1UKIW%2Btuqwg%3D&reserved=0"
moz-do-not-send="true">https://github.com/cabforum/servercert/compare/049237e096650fe01f67780b7c24bd5211ee3038...ada5d6e0db76b32be28d64edd7b0677bbef9c2f5</a> </li>
</ul>
<h2
id="m_1600128793445267323m_2832419603062105658m_-7238962214217580443bkmrk-motion-ends">Motion
Ends</h2>
<p
id="m_1600128793445267323m_2832419603062105658m_-7238962214217580443bkmrk-this-ballot-proposes">This
ballot proposes a Final Maintenance
Guideline. The procedure for approval of
this ballot is as follows:</p>
<h4
id="m_1600128793445267323m_2832419603062105658m_-7238962214217580443bkmrk-discussion-%2811%2B-days">Discussion
(at least 7 days)</h4>
<ul
id="m_1600128793445267323m_2832419603062105658m_-7238962214217580443bkmrk-start-time%3A-2024-01-"
type="disc">
<li>Start time: 2024-05-20 18:00:00 UTC</li>
<li>End time: on or after 2024-05-27
18:00:00 UTC</li>
</ul>
<h4
id="m_1600128793445267323m_2832419603062105658m_-7238962214217580443bkmrk-vote-for-approval-%287">Vote
for approval (7 days)</h4>
<ul
id="m_1600128793445267323m_2832419603062105658m_-7238962214217580443bkmrk-start-time%3A-tbd-end-"
type="disc">
<li>Start time: TBD</li>
<li>End time: TBD</li>
</ul>
<o:p class="MsoNormal"> </o:p> </div>
</div>
</div>
_______________________________________________<br>
Servercert-wg mailing list<br>
<a href="mailto:Servercert-wg@cabforum.org"
moz-do-not-send="true"
class="moz-txt-link-freetext">Servercert-wg@cabforum.org</a><br>
<a
href="https://lists.cabforum.org/mailman/listinfo/servercert-wg"
rel="noreferrer" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><br>
</div>
</blockquote>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>