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 expectations[1]. Kind regards Philipp Kern [1] If they are realistic is another question.
Attachment:
signature.asc
Description: OpenPGP digital signature