289979 - Three root CA certs don't have explicit CKA_TRUST_STEP_UP_APPROVED flags

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P3)

Description

[Wan-Teh Chang]

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.

Comment 1

[Wan-Teh Chang]

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

[Neil Williams]

(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.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 4

[Wan-Teh Chang]

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

[Neil Williams]

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

[Neil Williams]

(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".

Comment 7

[Wan-Teh Chang]

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.

Comment 8

[Wan-Teh Chang]

Attachment: 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.

Comment 9

[Neil Williams]

(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

[Neil Williams]

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 11

[Wan-Teh Chang]

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 12

[Robert Relyea]

Comment on attachment 180851 [details] [diff] [review]
Proposed patch

Given the current data in the bug, the patch is correct. r=relyea

Comment 13

[Wan-Teh Chang]

Set target milestone 3.11.  Reduced severity to trivial
because we just want to explicitly set the values to
the default value.

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

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

[Kai Engert (:KaiE:)]

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

[Kai Engert (:KaiE:)]

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 17

[Kai Engert (:KaiE:)]

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

Comment 18

[Kai Engert (:KaiE:)]

... fixing dependency to point to real bug number ...

Comment 19

[Nelson Bolyard (seldom reads bugmail)]

I'm targetting 3.11.7, but I agree, this should go in with bug 378489.

Comment 20

[Gervase Markham [:gerv]]

> 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

[Kai Engert (:KaiE:)]

I checked this in to NSS trunk and NSS 3.11 branch, together with the patches in bug 378489.