757189 - addbuiltin default output for "no explicit trust" should be consistent with certdata.txt

Status: RESOLVED FIXED

(NSS :: CA Certificates Code, task)

Description

[Kai Engert (:KaiE:)]

This bug requests to create consistency.

I apologize for the complicated description, but I believe it's important for clarity to get this done.

The proposed changes shall have no effect on the trust stored in the NSS builtin trust module.

When the addbuiltin tools gets called, a trust string specified is specified,
(which consists of three separate strings for the three separate usage groups website certificates, email certificates and object signing certificates.)

Frequently new roots got added that were marked as trusted only for a subset of the usage groups. For the groups without explicit trust, the common practice was to use an empty trust string.

Example: The trust string C,, has three groups, separated by commas, where the second and the third group are empty.


In addition it's necessary to know that NSS uses two similar trust flags for "not explicitly trusted". In isolation, the trust flags have the same effect. They only differ when multiple sources of trust are being combined.
These related trust flags are:
- CKT_NSS_MUST_VERIFY_TRUST
- CKT_NETSCAPE_TRUST_UNKNOWN


(This bug is further complicated by the fact that these identifieres were recently renamed. Only NSS 3.13.x and newer uses them.)


In the past, in NSS 3.12 and older,
the trust flags CKT_NETSCAPE_UNTRUSTED and CKT_NETSCAPE_VALID
were both used for "explicitly untrusted bad cert".

The only additional trust identifiers found in certdata.txt were:
CKT_NETSCAPE_TRUSTED_DELEGATOR (meaning "explicit trust")
and
CKT_NETSCAPE_TRUST_UNKNOWN (meaning "NO explicit trust").


In 3.13 and newer, only one single identifier is used for
"explicity untrusted bad cert": CKT_NSS_NOT_TRUSTED

The new identifier for "explicit trust"
is: CKT_NSS_TRUSTED_DELEGATOR


===============================================================
However, and this is what this bug is about:

Two different flags are being used for the "no explicit trust":
CKT_NSS_MUST_VERIFY_TRUST and CKT_NSS_TRUST_UNKNOWN
===============================================================


(1) I hereby request that we make a clear decision, 
which flag should be used in certdata.txt.

We should either use
  CKT_NSS_MUST_VERIFY_TRUST
or use
  CKT_NSS_TRUST_UNKNOWN
but not a mix of both.


(2) I request that we change certdata.txt
so that only one of these flags get used.

(3) I request that we ensure that the addbuiltin tool uses our preferred flag
when producing the certdata.txt output when having use the empty string as a trust flag.

Comment 1

[Kai Engert (:KaiE:)]

The previous comment asks for a decision.
Let me start with a proposal:

I propose that we use CKT_NSS_TRUST_UNKNOWN.

I propose that we change certdata.txt, 
remove all occurrences of CKT_NSS_MUST_VERIFY_TRUST
and replace them with CKT_NSS_TRUST_UNKNOWN.

Because addbuiltin on trunk currently produces CKT_NSS_MUST_VERIFY_TRUST
when having used an empty trust string,
I propose to change addbuiltin to produce CKT_NSS_TRUST_UNKNOWN instead.

Comment 2

[Kai Engert (:KaiE:)]

Attachment: Patch v1

This patch implements my proposal

Comment 3

[Kai Engert (:KaiE:)]

Given that we might have to update the list of root certificates on the 3.13.x branch for another while, I propose to get this fixed on both trunk and the 3.13.x, in order to avoid confusion and synchronous maintenance.

Comment 4

[Kai Engert (:KaiE:)]

A test build with this consistency cleanup is available from
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-0aea1af6cb90/

The following roots are affected by this change:
- TDC Internet Root CA
- TDC OCES Root CA
- Certinomis - Autorité Racine
- A-Trust-nQual-03
- TWCA Root Certification Authority
- EC-ACC

Comment 5

[Kai Engert (:KaiE:)]

Maybe testing this change is unnecessary.

It *doesn't* touch the "good trust" flags.

It only modifies the "not trusted flags" from one technical variation to another one.

I don't think this can cause harm, especially given that it will the same "not trusted" flag as all the other roots.

Comment 6

[Kai Engert (:KaiE:)]

The link in comment 4 will go away after a couple of days.
A backup download locaiton is http://kuix.de/mozilla/tryserver-roots-20120521/

Comment 7

[Kathleen Wilson]

(In reply to Kai Engert (:kaie) from comment #4)
> A test build with this consistency cleanup is available from
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-
> 0aea1af6cb90/
> 
> The following roots are affected by this change:
> - TDC Internet Root CA
> - TDC OCES Root CA
> - Certinomis - Autorité Racine
> - A-Trust-nQual-03
> - TWCA Root Certification Authority
> - EC-ACC


I have installed the test build and have checked the trust bits for the listed root certificates, and they match the trust bits as per my records.

Comment 8

[Kathleen Wilson]

I went through all of the root certs in the Cert Manager Authorities list in the test build, and all but the following two matched my records.

1) This root cert is shown as a Builtin Object Token with all 3 trust bits turned off. Do we want that? If we are replacing this one with the new one, then should we just remove this root cert from the authorities list?
CN = StartCom Certification Authority
OU = Secure Digital Certificate Signing
O = StartCom Ltd.
C = IL
SHA1 Fingerprint: 3E:2B:F7:F2:03:1B:96:F3:8C:E6:C4:D8:A8:5D:3E:2D:58:47:6A:0F


2) This is a new one as per bug #751954. All 3 trust bits are supposed to be turned on, but only the Websites trust bit is currently turned on.
CN = StartCom Certification Authority G2
O = StartCom Ltd.
C = IL
SHA1 Fingerprint: 31:F1:FD:68:22:63:20:EE:C6:3B:3F:9D:EA:4A:3E:53:7C:7C:39:17

Thanks!
Kathleen

Comment 9

[Kai Engert (:KaiE:)]

Kathleen, I cannot confirm what you said in comment 8.
When I run the provided test build with an empty profile, I see that all 3 trust flags are enabled for each of the 3 StartCom CAs.

I suspect you might not be aware of the following:

Whenever you execute Firefox/Thunderbird, the trust information used (and displayed) by the software is the result of a dynamic combination of trust information from at least two locations:
(a) the trust stored in the downloaded/executed program
(b) the trust stored in the "profile" where you have all your preferences

Let's say you start Firefox 12.
You go to certificate manager, and you change the trust settings for some UltraCA. Your changes will be stored in area (b), and will override what exists in area (a).

Next you quit Firefox 12, and you start the test build that I have provided.
Whatever new trust flags are stored in (a), any changes you made earlier and that are stored in (b) still have precedence.

Let's suppose the trust for UltraCA differs in Firefox 12 and the test build, in other words, the two flavors of (a) have different trust information. However, because you had manually modified the trust flags of UltraCA, the trust flags shown by Firefox for UltraCA will show your explicit preference, found from (b). The different information in (a) is ignored.

Whenever you are testing a test build, you should make sure that you use a clean profile with an empty (b) area. Only this way you can correctly verify which trust flags come with (a).

You could create a new profile whenever you want to test a new build (and you can delete old profiles from old tests). Here is an article that explains how to use multiple profiles. http://lifehacker.com/231646/geek-to-live--manage-multiple-firefox-profiles

Make sure you never delete your original profile, the one that you usually use and which has all the settings that you want to keep. It's usually named "default".

Comment 10

[Kathleen Wilson]

Ooops! I forgot about that.  I just moved cert8.db, and restarted the test build, and now I see all three StartCom roots with all three trust bits turned on.

I'll look through the trust bits for the other roots again.

Comment 11

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #10) 
> I'll look through the trust bits for the other roots again.

I have checked the trust bits for the builtin certificate authorities in the test build, and I see no issues with this test build.  

Thanks!

Comment 12

[Kai Engert (:KaiE:)]

Comment on attachment 625750 [details] [diff] [review]
Patch v1

Yesterday we discussed this bug in the conference call, and we agreed on a new plan:

- keep what addbuiltin does today:
    continue to print CKT_NSS_MUST_VERIFY_TRUST
   
- change the majority of entries in certdata.txt to be consistent:
    change all occurrences of CKT_NSS_TRUST_UNKNOWN to CKT_NSS_MUST_VERIFY_TRUST

I'll attach a new patch and produce a new test build.

Comment 13

[Kai Engert (:KaiE:)]

Attachment: Patch v2

Bob, this is what you had suggested yesterday.

I used a large context for the diff, allowing you to see the label (name of CA) of the trust sections.

Comment 14

[Kai Engert (:KaiE:)]

I expect a new tryserver build to arrive at
  http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-5a0dcaa699c1/
within the next couple of hours.

Kathleen, may I ask you to please do another quick sanity check?
The build includes the changes from this bug, and 757197 and 757240.

Comment 15

[Kai Engert (:KaiE:)]

The earlier try build had partially failed.

The new try build is available at
  http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-b51f34a5b5c1/

I created backups at
  http://kuix.de/mozilla/tryserver-roots-20120604/

Comment 16

[Kathleen Wilson]

I downloaded the try build in Comment #15, moved cert8.db, and tested the build by checking the trust bit settings of certificates in the Authorities list of the Cert Manager. 

My testing is completed, and I did not find any issues.

Comment 17

[Robert Relyea]

Comment on attachment 629321 [details] [diff] [review]
Patch v2

r+ rrelyea

Comment 18

[Kai Engert (:KaiE:)]

Thanks for the r+

Now that we're sure that this part of the batch is acceptable, we can proceed with asking the CAs to give feedback on the test build and the remainder of the changes.

Comment 19

[Kai Engert (:KaiE:)]

trunk for 3.14:

cvs commit: Examining .
Checking in certdata.c;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.c,v  <--  certdata.c
new revision: 1.87; previous revision: 1.86
done
Checking in certdata.txt;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v  <--  certdata.txt
new revision: 1.84; previous revision: 1.83
done
Checking in nssckbi.h;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/nssckbi.h,v  <--  nssckbi.h
new revision: 1.37; previous revision: 1.36
done



3.13.4 branch for 3.13.6:

cvs commit: Examining .
Checking in certdata.c;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.c,v  <--  certdata.c
new revision: 1.85.2.1; previous revision: 1.85
done
Checking in certdata.txt;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v  <--  certdata.txt
new revision: 1.82.2.1; previous revision: 1.82
done
Checking in nssckbi.h;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/nssckbi.h,v  <--  nssckbi.h
new revision: 1.35.2.1; previous revision: 1.35
done

Comment 20

[Kai Engert (:KaiE:)]

https://hg.mozilla.org/releases/mozilla-esr10/rev/ef60da380f1b

Comment 21

[u279076]

Kai, anything QA needs to be on the lookout for in terms of potential Firefox 10.0.12esr regressions?

Comment 22

[Kai Engert (:KaiE:)]

Anthony, this one should have zero effect.

Comment 23

[u279076]

(In reply to Kai Engert (:kaie) from comment #22)
> Anthony, this one should have zero effect.

Thanks Kai. Tagging this [qa-] in that case. Please add the qawanted keyword if something comes up that needs testing.