Closed Bug 180268 Opened 22 years ago Closed 21 years ago

SSL step-up Government approval trust flags missing


(NSS :: Libraries, defect, P1)



(Not tracked)



(Reporter: nelson, Assigned: bugz)


(Whiteboard: needs verification)


(2 files)

Regression: NSS 3.3 programs with NSS 3.3 DBs do SSL Step up OK.
With newer DBs and/or newer libs, SSL step up fails because of missing trust.

I have two NSS DB directories, an old one from the days of NSS 3.3, and a new 
one from NSS 3.4 or later.  The older cert DB has all the trusted roots in it.
The older secmod.db has only one module, the internal module.  

The newer secmod.db has two modules, the internal one and the Built-in roots.
The newer cert DB has no trusted roots in it - All trusted roots are in the 
built-in roots module.  

When I use NSS 3.3 certutil to list the certs in the old DB, I see a list
of certs with the Government trust flag in them. e.g.
certutil -d /tmp/olddb  -L | sort
shows a bunch of certs with the flags CG,C,C

When I use certutil from the trunk to do the same command, there are no G flags.

When I use either certutil from NSS 3.3 or from the trunk, and do the command
certutil -d /tmp/newdb -h builtin -L  | sort
I see no G flags.  

I also tried using vfychain, building it with NSS 3.3 and with the trunk.
I tried verifying a chain of an SSL server with a step-up cert.
I used the option -u 2 which verifies the chain for SSL step up.
When I verified it with NSS 3.3 and the old DBs, the command
vfychain -u 2 -d olddb cert.00 cert.01 cert.02
Chain is good!

When I tried it with the trunk vfychain and the same DBs, it reported errors, 
including that the root was not trusted.
When I tried it with the new DBs, I got errors using either the new or old 
vfychain command (and NSS libs).
Regression: P1.  

We might consider "fixing" this by removing support for SSL Step-Up and 
for old "export" software.  
Priority: -- → P1
Summary: SSL step-up Government approval trust flags missing → SSL step-up Government approval trust flags missing
Target Milestone: --- → 3.7
Ian, could you take a look at this?  Thanks.
Assignee: wtc → ian.mcgreer
Moved to target milestone 3.8 because the original
NSS 3.7 release has been renamed 3.8.
Target Milestone: 3.7 → 3.8
Anyone want to vote?  Should we:

1) remove support for SSL step-up
2) continue to support it and pull the special trust bit out of softoken (since
that is where trust lives in 3.4+)
In a meeting yesterday we heard that, for purposes of continuing to appease
the people who issue export licenses, we should not discontinue support for
the old export controls.  

So, I think that means the vote is: 2) continue to support it.
This patch seems to get step-up working again.	I took out the compile
directives used to hide step-up support, don't see the need for them anymore
and I needed to in order to test anyway.
Attachment #116216 - Flags: review?(relyea)
Comment on attachment 116216 [details] [diff] [review]
reimplement SSL step-up

patch looks good. Minor nit: it might be good to have a comment in pkcs11n.h
that explains that gov't approved is a bool, not a CKA_TRUST value.

Attachment #116216 - Flags: review?(relyea) → review+
OH, one other thing, we should probaly add the bit to the appropriate root certs
in the built-ins module.

I chose which certs to give step-up trust from the list of builtins used in NSS
2.8.  Someone on the AOL side may want to review the list, to see which new
certs need it (if it matters).

Also changed addbuiltin to reflect this change.
Attachment #116451 - Flags: review?(relyea)
Remove target milestone of 3.8, since these bugs didn't get into that release.
Target Milestone: 3.8 → ---
Comment on attachment 116451 [details] [diff] [review]
add step-up trust to builtins

Stephane should look at the actual list of certs that are approved or not.
Attachment #116451 - Flags: review?(rrelyea0264) → review+
This is a P1 bug with two reviewed patches that are 14 months old.
What prevents it from being checked in?  
patch checked in. The list of certs that were given step-up bits is the same as
in the 2nd attachment.
Closed: 21 years ago
Resolution: --- → FIXED
Target Milestone: --- → 3.10
QA verification steps:

The thing remaining to be verified is whether the list of built-in certs 
trusted for step-up approval is the right list.  
That list can be obtained by these steps:

1. certutil -N -d testdb
          (respond to the interactive prompts.  Make up any password)
2. copy nssckbi.dll into the testdb directory
3. certutil -L -h all -d testdb | fgrep G,   

izzit right?
I might suggest comparing to the list from cert DBs made by NSS 3.1 or
by cert DBs from NSS 2.8
Whiteboard: needs verification
I used the settings from 2.8 when I created this patch.  My concern was more 
about new certs added since then, whether they should receive the step-up bit.
You need to log in before you can comment on or make changes to this bug.