Three root CA certs don't have explicit CKA_TRUST_STEP_UP_APPROVED flags

RESOLVED FIXED in 3.11.8

Status

NSS
Libraries
P3
trivial
RESOLVED FIXED
13 years ago
11 years ago

People

(Reporter: Wan-Teh Chang, Assigned: Wan-Teh Chang)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

13 years ago
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.
(Assignee)

Comment 1

13 years ago
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?

Comment 2

13 years ago
(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] [edit]).
> 
> Does anyone know what the CKA_TRUST_STEP_UP_APPROVED
> values for these three root CA certs should be?
> 
I can look into it.
Status: NEW → ASSIGNED
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.
(Assignee)

Comment 4

13 years ago
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.

Comment 5

13 years ago
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?

Comment 6

13 years ago
(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".
(Assignee)

Comment 7

13 years ago
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.
(Assignee)

Comment 8

13 years ago
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.
Attachment #180851 - Flags: review?(rrelyea)

Comment 9

13 years ago
(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.

Comment 10

13 years ago
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?
(Assignee)

Comment 11

13 years ago
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.
Attachment #180851 - Attachment description: Interim patch → Proposed patch
QA Contact: bishakhabanerjee → jason.m.reid

Comment 12

13 years ago
Comment on attachment 180851 [details] [diff] [review]
Proposed patch

Given the current data in the bug, the patch is correct. r=relyea
Attachment #180851 - Flags: review?(rrelyea) → review+
(Assignee)

Comment 13

13 years ago
Set target milestone 3.11.  Reduced severity to trivial
because we just want to explicitly set the values to
the default value.
Severity: normal → trivial
Priority: -- → P3
Target Milestone: --- → 3.11
QA Contact: jason.m.reid → libraries
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 15

11 years ago
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?

Comment 16

11 years ago
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.
Depends on: 377489

Comment 17

11 years ago
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
Attachment #180851 - Flags: review+

Comment 18

11 years ago
... fixing dependency to point to real bug number ...
Depends on: 378489
No longer depends on: 377489
I'm targetting 3.11.7, but I agree, this should go in with bug 378489.
Target Milestone: 3.11 → 3.11.7
> 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

Comment 21

11 years ago
I checked this in to NSS trunk and NSS 3.11 branch, together with the patches in bug 378489.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Target Milestone: 3.11.7 → 3.11.8
You need to log in before you can comment on or make changes to this bug.