[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: should ca-certificates certdata.txt synchronize across all suites?

On 07/06/2017 08:01 PM, Antoine Beaupré wrote:
> In looking at fixing #858539 (blocking WoSign and StartCom, in CC) for
> wheezy, I noticed the issue was also pending in jessie. Furthermore, the
> idea originally raised by pabs[1] was to also update the packages for
> the latest changes in certdata.txt in wheezy, including the ISRG Root
> for Let's Encrypt (LE).
> While it should be fairly trivial to do this update, I wonder if the
> same logic should apply to jessie itself. Right now, jessie and stretch
> are synchronized, but that's only because there's an update pending in
> unstable to synchronize with the upstream 2.11 NSS database.
> This raises the question of how synchronized we want this file to be? It
> seems a little arbitrary to me to synchronize the file from jessie to
> wheezy only for this one certificate authority (LE). How about the other
> authorities? It doesn't seem like we should be calling the shots on
> this: if we follow the Mozilla policies here, either we update all
> supported suites at once, or we accept that some suites will have
> outdated material.
> I have therefore opened this specific discussion with the release team
> in #867461 (in CC as well). Hopefully this will bring a consistent
> policy.
> For what it's worth, my opinion is that we should attempt to synchronize
> certdata.txt (and blacklist.txt, for that matter) across all suites (but
> not other changes to the packaging). This would remove another decision
> point in our infrastructure and ensure harmonious X509 processing across
> suites.
> [1]: https://lists.debian.org/1490430746.9127.2.camel@debian.org
> Thanks for any feedback. For now I'll hold on another week or so for the
> wheezy update, since it seems unreasonable to push that update out
> before jessie is updated and that question is resolved.

But it's not just about certdata.txt. The WoSign and StartCom distrust
was actually hardcoded in NSS and hence what Mozilla enforced in NSS we
couldn't check in any other tools using ca-certificates. We also do not
sync the NSS version or backport the cert checks when such distrusts
happen. So we can only react in a similar way when the time for full
distrust has come (which is sort of the case now with these two),
otherwise we diverge in logic and potentially break users with different

Kind regards
Philipp Kern

[1] If they are realistic is another question.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: