On 29/5/2024 10:30 π.μ., Ryan Dickson wrote:
Thanks for the update, Dimitris - and to the ballot endorsers for
their consideration of the points made in my message.
In general, I have no objections to the recently described adoption
approach or timeline.
> 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.
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.
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).
> 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.
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.
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.
For example, something like:
*
“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.”
OR
*
“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.”
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.
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.
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
https://cabforum.org/resources/tools/). For example, pkilint (Version
0.9.0 <https://github.com/digicert/pkilint/releases/tag/v0.9.0>) was
released about 3-weeks prior to the effective date described in SC-62
<https://cabforum.org/2023/03/17/ballot-sc62v2-certificate-profiles-update/>.
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.
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.
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.
How about:
* "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".
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.
* "The CA SHOULD perform Linting on the corpus of its non-expired,
non-revoked Subscriber Certificates whenever it updates the Linting
software".
What do people think about these proposals?
Thanks,
Dimitris.
Thanks again!
- Ryan
On Sun, May 26, 2024 at 3:41 AM Dimitris Zacharopoulos (HARICA)
<dzach...@harica.gr> wrote:
Hi Ryan,
Thank you for the feedback. After some internal discussions with
Corey and Ben, please see comments inline.
On 20/5/2024 10:35 μ.μ., Ryan Dickson wrote:
Hi Dimitris, Corey, and Ben,
Thank you for bringing this ballot forward for the group’s
consideration.
A few questions:
* 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.
o 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.
o 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.
I see two issues here:
1. 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.
2. 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.
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.
* Is it worth more clearly establishing expectations for the
evaluation and, when applicable, deployment of updatesmade 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).
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.
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.
More feedback is welcome before proceeding with the changes.
Best regards,
Dimitris.
Thanks for your consideration.
- Ryan
On Mon, May 20, 2024 at 2:04 PM Inigo Barreira via Servercert-wg
<servercert-wg@cabforum.org> wrote:
Hi Dimitris,
I don´t know if the “(help to improve)” is adding any
additional hidden requirement. IMO, I´d remove that.
Regards
*De:*Servercert-wg <servercert-wg-boun...@cabforum.org> *En
nombre de *Dimitris Zacharopoulos (HARICA) via Servercert-wg
*Enviado el:* lunes, 20 de mayo de 2024 19:57
*Para:* CA/B Forum Server Certificate WG Public Discussion
List <servercert-wg@cabforum.org>
*Asunto:* [Servercert-wg] Ballot SC-75 - Pre-sign linting
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.
SC-75 Pre-sign linting
Summary
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.
The following motion has been proposed by Dimitris
Zacharopoulos of HARICA and endorsed by Corey Bonnell of
Digicert and Ben Wilson of Mozilla.
You can view the GitHub pull request representing this ballot
here
<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>.
Motion Begins
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:
*
https://github.com/cabforum/servercert/compare/049237e096650fe01f67780b7c24bd5211ee3038...ada5d6e0db76b32be28d64edd7b0677bbef9c2f5
<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>
Motion Ends
This ballot proposes a Final Maintenance Guideline. The
procedure for approval of this ballot is as follows:
Discussion (at least 7 days)
* Start time: 2024-05-20 18:00:00 UTC
* End time: on or after 2024-05-27 18:00:00 UTC
Vote for approval (7 days)
* Start time: TBD
* End time: TBD
_______________________________________________
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg
_______________________________________________
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg
