Bug 1444799 - [tracker] Ship compatible Firefox/NSS trust store modifications as stapled extensions in ca-certificates
Summary: [tracker] Ship compatible Firefox/NSS trust store modifications as stapled ex...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: ca-certificates
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Bob Relyea
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1445913
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-04-24 10:53 UTC by Kai Engert (:kaie) (inactive account)
Modified: 2021-11-10 16:58 UTC (History)
9 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2021-11-10 16:58:32 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Kai Engert (:kaie) (inactive account) 2017-04-24 10:53:11 UTC
The following wiki page documents modifications, that Firefox or NSS implement on top of the static CA certificate trust list:
  https://wiki.mozilla.org/CA:Root_Store_Trust_Mods

We should try to bring them to the crypto libraries that we ship in Fedora.

This will likely be a long-lived project. There are modifications, that today cannot be expressed in a static way, but might be in the future.

As a first work item, the static domain name constraints, that are currently implemented by NSS at the code level, could be added to the ca-certificates package, as Nikos described here:
  http://nmav.gnutls.org/2016/06/restricting-scope-of-ca-certificates.html

This would allow GnuTLS to benefit.

Comment 1 Kai Engert (:kaie) (inactive account) 2017-04-26 20:20:30 UTC
Once we have clarity on bug 1445913, I want to enhance ca-certificates to ship the DNS constraints for ANSSI and Tubitak Kamu SM 1.

.fr .gp .gf .mq .re .yt .pm .bl .mf .wf .pf .nc .tf
%30%66%06%03%55%1d%1e%04%5f%30%5d%a0%5b%30%05%82%03%2e%66%72%30%05%82%03%2e%67%70%30%05%82%03%2e%67%66%30%05%82%03%2e%6d%71%30%05%82%03%2e%72%65%30%05%82%03%2e%79%74%30%05%82%03%2e%70%6d%30%05%82%03%2e%62%6c%30%05%82%03%2e%6d%66%30%05%82%03%2e%77%66%30%05%82%03%2e%70%66%30%05%82%03%2e%6e%63%30%05%82%03%2e%74%66

.gov.tr .k12.tr .pol.tr .mil.tr .tsk.tr .kep.tr .bel.tr .edu.tr .org.tr
%30%6e%06%03%55%1d%1e%04%67%30%65%a0%63%30%09%82%07%2e%67%6f%76%2e%74%72%30%09%82%07%2e%6b%31%32%2e%74%72%30%09%82%07%2e%70%6f%6c%2e%74%72%30%09%82%07%2e%6d%69%6c%2e%74%72%30%09%82%07%2e%74%73%6b%2e%74%72%30%09%82%07%2e%6b%65%70%2e%74%72%30%09%82%07%2e%62%65%6c%2e%74%72%30%09%82%07%2e%65%64%75%2e%74%72%30%09%82%07%2e%6f%72%67%2e%74%72

Comment 3 Simo Sorce 2020-06-10 14:26:01 UTC
bob,
is this bug still relevant ?

Comment 4 Bob Relyea 2020-06-10 15:43:39 UTC
Some background:

Some of mozilla cert disablements are done by specific code baked into NSS because the normal certdata.txt doesn't have the resolution to do the particular disablement that mozilla needs. These include: 
   1) disabling a certificate after or as of a specific date.
   2) adding constraints on the CA that's not otherwise added. Currently only name constraints..
   3) disabling a CA except for it's validation of certain certificates, or other partial disablement.

1) has been pushed to nss-3.53 according to the mozilla page, though I didn't see any new attributes in the 3.53 certdata.txt.
2) is what this bug envisions I think. It involves allowing arbitrary constraints to be added to certdata.txt's trust object in the form of existing certificate extensions. These extensions are used by the PKI code to constraint intermediate certificates. The idea is we treat them as additions to the root when we validate. I think this is really a project because it requires:
     a) first, changes to the nss upstream for nss to process these name constraints and certdata.txt to include them.
     b) openssl to handle them.
     c) gnutls to handle them.
     d) p11-kit to handle converting the certdata.txt format to openssl/gnutls format for them.
3) There's not much we can do about 3. It's used when the desired fix cannot be expressed in any of the other ways.

I think this bug is about 2. It's still relevant, but I suspect a bug isn't the best way to track it since it's more of a project.

bob

Comment 5 Giovanni 2020-10-15 15:52:06 UTC
I don't know if what I'm about to describe can be attributed to this bug but I describe it anyway: I usually use Firefox on eBay. Starting from version 71, I go to memory, on eBay.it you see the password for accessing my area in clear text while if I accessed eBay.com or eBay.co.uk it was not shown. With the latest updates, version 81.1 arrived and suddenly my password to access eBay appeared in the clear also on the other domains. I warned eBay people about this problem and found a temporary solution: revert to the previous version, 75.0. The problem does not arise from eBay and does not arise with other browsers. Does it come from a bug in SSL or is there something else?

Comment 6 Bob Relyea 2021-11-10 16:58:32 UTC
This really is a feature request which should be tracked as an upstream bug first.


Note You need to log in before you can comment on or make changes to this bug.