In lib/ckfw/builtins/certdata.txt, the following three root CA certs don't have explicit CKA_TRUST_STEP_UP_APPROVED flags: Baltimore CyberTrust Root Equifax Secure eBusiness CA 2 AddTrust Public Services Root When Ian checked in his fix for bug 180268 (certdata.txt, rev. 1.29), he didn't add the flag to these three root CA certs. I don't know whether he missed these three by mistake or deliberately.
Neil, since you recently worked on a related bug (bug 288227), I'm wondering if you can find out what happens if no CKA_TRUST_STEP_UP_APPROVED flag is specified on a root CA cert in certdata.txt. It seems that with your fix for bug 288227, the root CA cert will receive the initial value PR_FALSE of the local variable stepUp (see attachment 179346 [details] [diff] [review]). Does anyone know what the CKA_TRUST_STEP_UP_APPROVED values for these three root CA certs should be?
(In reply to comment #1) > Neil, since you recently worked on a related bug > (bug 288227), I'm wondering if you can find out what > happens if no CKA_TRUST_STEP_UP_APPROVED flag is > specified on a root CA cert in certdata.txt. It > seems that with your fix for bug 288227, the root > CA cert will receive the initial value PR_FALSE of > the local variable stepUp (see attachment 179346 [details] [diff] [review] ). > > Does anyone know what the CKA_TRUST_STEP_UP_APPROVED > values for these three root CA certs should be? > I can look into it.
In https://bugzilla.mozilla.org/show_bug.cgi?id=180268#c9 Ian wrote: > I chose which certs to give step-up trust from the list of builtins > used in NSS 2.8. Recall that this approval came from the U.S. Government directly. CAs were not given this trust simply upon their request (to Netscape). I don't know how we tell which of the new CAs added since NSS 2.8 is truly government approved. But I don't think we should give this trust to just any CA that requests it. Might be instructive to see which CAs are trusted for this purpose by Microsoft.
Nelson, You may have misunderstood what the problem is. The problem is that the CKA_TRUST_STEP_UP_APPROVED flags for three root certs are *missing*. My questions are how NSS interprets the "step-up approved" status for these three root certs that don't have explicit CKA_TRUST_STEP_UP_APPROVED flags, and what their correct CKA_TRUST_STEP_UP_APPROVED flags should be.
Wan-Teh, Nelson I will try find out if there are comments accompanying the change to certdata.txt that removed these step up attributes. Nelson suggested looking to see what MS did with step up attributes. As an experiment I ran Outlook Express and looked at the Trusted Root Certs and see no mention of government issue or step up. For example "Thawte Personal Premium," which is one of our step up certs, says this under the heading "This cert is intended for the following purpose(s)" Proves your identity to a remote computer Protects your e-mail messages Ensures software came from SW pub Protects software from alt. after pub. All issuance policies None of these seem to be step up bits. If we cannot verify which root certs are "G" and this is a feature only used in old browsers should we err on the generous side and put the attributes back?
(In reply to comment #0) > In lib/ckfw/builtins/certdata.txt, the following three > root CA certs don't have explicit CKA_TRUST_STEP_UP_APPROVED > flags: > > Baltimore CyberTrust Root > Equifax Secure eBusiness CA 2 > AddTrust Public Services Root > > When Ian checked in his fix for bug 180268 (certdata.txt, > rev. 1.29), he didn't add the flag to these three root > CA certs. I don't know whether he missed these three > by mistake or deliberately. Wan-Teh, how did you find these 3 root certs? I went back to NSS 2.8 source and certdata.txt only defines a "test certificate".
Neil, I found those three roots when I reviewed the trust bits for all the roots in certdata.txt. I noticed that those three don't have any CKA_TRUST_STEP_UP_APPROVED flags specified. The only thing I need from you is to confirm that if the CKA_TRUST_STEP_UP_APPROVED flag is not specified, NSS interprets that as if it were CK_FALSE. I guess this is the case because the 'stepUp' local variable in nssCryptokiTrust_GetAttributes is initialized to PR_FALSE. See your patch (attachment 179346 [details] [diff] [review]) in bug 288227. As to what the right CKA_TRUST_STEP_UP_APPROVED flags should be, I can do that research. I plan to set them to CK_FALSE first.
Created attachment 180851 [details] [diff] [review] Proposed patch Neil, I no longer have access to NSS 2.8, so it turns out I do need you to do that research. NSS 2.8 doesn't use certdata.txt. The builtin roots are somewhere in the lib/certdb directory. Nelson should be able to help you find them in NSS 2.8. As an interim patch I'm setting their CKA_TRUST_STEP_UP_APPROVED flag to CK_FALSE explicitly.
(In reply to comment #8) Wan-Teh, yes, my patch set the CKA_TRUST_STEP_UP_APPROVED to CK_FALSE. I just ran a test and the 3 certs in the bug description are not STEP UP certs. I am looking at NSS2.8 right now.
In NSS2.8 lib/cert/certinit.c none of the 3 certs listed in the original bug report exist. Does this imply that they must not have been step up certs?
Comment on attachment 180851 [details] [diff] [review] Proposed patch No, but it does imply that we can set their CKA_TRUST_STEP_UP_APPROVED flag to CK_FALSE, the default value. Therefore, I'm no longer calling this patch an interim patch.
Comment on attachment 180851 [details] [diff] [review] Proposed patch Given the current data in the bug, the patch is correct. r=relyea
Set target milestone 3.11. Reduced severity to trivial because we just want to explicitly set the values to the default value.
This patch never made it into any release, as far as I can tell. It's not fixed on the trunk. Kai, maybe you can commit this patch for NSS 3.11.7. Gerv, this raises another interesting issue. One of the trust flags in NSS enables a root CA (or its subordinates) to issue SSL "Step up" server certs. SSL Step-Up is equivalent but not identical to what Microsoft calls "SGC" (Server Gated Cryptography). Special SSL step-up certs allowed "export" browsers to use stronger "domestic" crypto when talking to those servers. Back when export browsers were common, the US Government controlled the list of roots with this special ability. Since mozilla doesn't make "export" browsers any more, the setting of this flag should now be completely irrelevant. Some CAs STILL advertise that their SSL server certs enable SSL Step-UP/SGC, even though AFAIK this has been a dead feature for about 7 years. I haven't heard any CAs ask for this capability flag explicitly, recently, although perhaps that is because we haven't prompted them about it. But I can imagine some CA making an issue out of it. I suggest we preempt such a fiasco by stating explicitly somewhere that Mozilla no longer approves any new CAs for SSL Step Up (if we don't already).
Comment on attachment 180851 [details] [diff] [review] Proposed patch Nelson, IIUC, if you want this patch on the 3.11 branch, you'll need a second code review?
As this patch changes the nssckbi module, I propose we do it together with other CA changes. The next scheduled change will happen with bug 378489, so I'm making this bug dependent on it.
Comment on attachment 180851 [details] [diff] [review] Proposed patch After reading the bug comments, it seems reasonable to explicitly add the "not approved for step up" flag. r=kengert
I'm targetting 3.11.7, but I agree, this should go in with bug 378489.
> I suggest we preempt such a fiasco by stating explicitly somewhere that > Mozilla no longer approves any new CAs for SSL Step Up (if we don't already). My only concern with that is that someone might complain that we are giving incumbents some sort of advantage (however small). Perhaps a better approach would be never to mention it, but to not enable it unless an applicant specifically asks for it (which I would expect none of them to do). The end result is basically the same. Gerv
I checked this in to NSS trunk and NSS 3.11 branch, together with the patches in bug 378489.