Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Fwd: GLOBALTRUST 2020's reinclusion in Mozilla's trusted certificates
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Jeffrey Walton via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 10 Jan 2025 16:01:43 -0500
FYI...
Mailing list post at
<https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/22GoYSOo7NY/m/xLqNxM2VCQAJ>.
---------- Forwarded message ---------
From: Andrew Ayer <agwa_at_andrewayer.name>
Date: Fri, Jan 10, 2025 at 12:13 PM
Subject: Re: GLOBALTRUST 2020's reinclusion in Mozilla's trusted certificates
To: Mike Benza <mikebenza_at_gmail.com>
Cc: dev-security-policy_at_mozilla.org <dev-security-policy_at_mozilla.org>
Hi Mike,
GLOBALTRUST was never removed from the Mozilla root store. Rather, it
was tagged with a "Distrust After" date which instructs Firefox to
distrust certificates whose Not Before date is after the root's
Distrust After date. This is not a security measure (since backdating
certificates is trivial), but rather a mechanism to gracefully sunset
a root so it can be removed without causing problems 398 days later.
However, Curl's mk-ca-bundle.pl script was incorrectly interpreting
the Distrust After date <https://github.com/curl/curl/issues/15547>,
causing GLOBALTRUST to be incorrectly excluded. Once that bug was
fixed, mk-ca-bundle.pl began emitting GLOBALTRUST again.
There are several reasons why this is unsatisfying. To begin with,
Mozilla should not be trusting a CA like GLOBALTRUST _at all_, a point
that I and others raised last year
<https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/XpknYMPO8dI/m/j76_U_fMAAAJ>.
Second, root constraints like Distrust After would ideally be
propagated in the PEM bundle through to certificate validators instead
of being dropped by mk-ca-bundle.pl, but there is no widely-supported
mechanism for this at the moment. For more background, see
https://sslmate.com/blog/post/entrust_distrust_more_disruptive_than_intended
Regards,
Andrew
Date: Fri, 10 Jan 2025 16:01:43 -0500
FYI...
Mailing list post at
<https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/22GoYSOo7NY/m/xLqNxM2VCQAJ>.
---------- Forwarded message ---------
From: Andrew Ayer <agwa_at_andrewayer.name>
Date: Fri, Jan 10, 2025 at 12:13 PM
Subject: Re: GLOBALTRUST 2020's reinclusion in Mozilla's trusted certificates
To: Mike Benza <mikebenza_at_gmail.com>
Cc: dev-security-policy_at_mozilla.org <dev-security-policy_at_mozilla.org>
Hi Mike,
GLOBALTRUST was never removed from the Mozilla root store. Rather, it
was tagged with a "Distrust After" date which instructs Firefox to
distrust certificates whose Not Before date is after the root's
Distrust After date. This is not a security measure (since backdating
certificates is trivial), but rather a mechanism to gracefully sunset
a root so it can be removed without causing problems 398 days later.
However, Curl's mk-ca-bundle.pl script was incorrectly interpreting
the Distrust After date <https://github.com/curl/curl/issues/15547>,
causing GLOBALTRUST to be incorrectly excluded. Once that bug was
fixed, mk-ca-bundle.pl began emitting GLOBALTRUST again.
There are several reasons why this is unsatisfying. To begin with,
Mozilla should not be trusting a CA like GLOBALTRUST _at all_, a point
that I and others raised last year
<https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/XpknYMPO8dI/m/j76_U_fMAAAJ>.
Second, root constraints like Distrust After would ideally be
propagated in the PEM bundle through to certificate validators instead
of being dropped by mk-ca-bundle.pl, but there is no widely-supported
mechanism for this at the moment. For more background, see
https://sslmate.com/blog/post/entrust_distrust_more_disruptive_than_intended
Regards,
Andrew
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2025-01-10