146868 - need to explicitly set trust bits on intermediate CAs

Status: NEW

(MailNews Core :: Security: S/MIME, defect, P5)

Description

[bill]

This is new behavior/regression.

Starting with a fresh certificate database I installed the ActivCard security
module and the AOL intermediate CA.  When I viewed my certs in PSM my signing
certificate showed up as "valid: true" but the encryption cert was "valid: false".

I needed to explicitly set the "trust this CA to issue email certificates to
users" bit on the AOL Intermediate CA in order for the email encryption
certificate to show up as "valid: true".

We didn't used to have to do this.

Comment 1

[bill]

forgot to mention that I was using Mach V, build 2002052304 on Win2000.

Comment 2

[Charles Rosendahl]

When I use a fresh profile, using the card that you gave me:

Without the AOL CA ever being imported:
Both are displayed as verifying false.

Going to the link: http://certificates/getCAChain.html and downloading the CA
chain into my browser prompts me to set the trust bits.  If I set them at the
time of import, the certs on the card verify fine.

If I don't set any of them, here is the bug:
The certs marked as 'sign' actually appear to have both the 'sign' and 'client'
attributes set on them.  The certs marked encryption appear to be tagged with
'encrypt' and 'server' attributes.

For whatever reason, even when all three trust boxes are unchecked on the CA
cert, with this combination the signing cert is showing up as "true".  Viewing
the cert will actually show that it has been verified for an empty set of uses.

Certificates that truly have only the signing extension revert to false when the
email trust bit is turned off.

So I would say this is a bug in the display of the cert based on the underlying
extensions, and not in the setting of trust bits on the CA cert.

Does this make sense?

Comment 3

[Stephane Saux]

Charles, I don't see a bug in what you describe.
If we can reproduce Bill's report, that is a bug.

Not checking the bits on an intermediate CA cert truly means (and as always
meant) that the verification is delegated to the next level (closer to the
root).  Although NSS internally understands three values for trust (trust, don't
trust, not set/delegate), it has never allowed applications to do anything other
than trust and delegate.

The certs issued by the intranet certificate authority are fairly generic, which
explains that, technically, the encryption cert also validates as a "server" cert.

For the signing cert, sign and client is exactly what we want.

Note that the meaning of the "purposes" column is not a list of attributes, but
the result of calling CERT_CertVerifyCert() on the certificate, for each of
about 13 derived purposes. Depending on what's in the cert, and what the chain
allows, you get a list of "verified purposes".  In fact when the cert says
"false" in the verified column, you don't get anything in the "purposes" column,
and anything in the "purposes" column will automatically generate a "true" in
the "verified" column.

Certificates can contain extra attributes, which always *limit* the usage of the
 key.  The Key usage is either sign or encrypt or both. If nothing else is set,
the cert may validate for everything in the world (including CA signing).

Either validate the bug by replicating Bill's behavior (he *has* to trust the
intermediate to validate - and he shouldn't have to) or it's something specific
to his profile.

Comment 4

[Charles Rosendahl]

Builds: 2002052404 and 20020522 NSS3.5 Test Build
Bill and I are seeing symptoms of the following bug:


Scenario 1: New Profile
1.  Install Activcard module in device manager
2.  Log into Card
3.  Without any AOL CA cert present, Signing cert is true, encryption cert is
false (bug 1)
4.  Import AOL CA - do not set trust at time of import.  Both certs are verified
true

Scenario 2: New Profile
1.  Import AOL CA cert - do not set trust at time of import
2.  Install activcard module and log in.
3.  Both certs verify as true

Scenario 3: Same profile as Scenario 1 or 2
1.  AOL Cert is untrusted still.
2.  Uncheck trust bits on GTE CA cert.  Signing is true, encrypting is false
(same as bug 1)
3.  View the GTE Cert - Still verified for status responder even though all
possible trust bits have been unchecked (bug 2)
4.  Recheck the Trust bits on the GTE CA cert.  View Cert - no change in
verified uses (bug 3)
5.  Exit cert manager and reopen.  View GTE CA cert - all uses now verified
6.  User Certs still do not change - Signing is true and encrypting is false,
even though trust bits are now active on parent (GTE) CA cert (bug 4)
7.  AOL cert can no longer be verified for unknown reasons (bug 5)
8.  Check the AOL CA certs trust bits.  Signing and encrypting certs are now
verified true.

Confirmed bug(s).

Comment 5

[Stephane Saux]

cc NSS folks. These are serious regressions.
Charles, does Kai NSS3.5 branch build also exhibit this behavior?

Bug number 1 is a P0 as far as I'm concerned.
Bug number 2, I'm not sure.  If you close the cert manager does it still show as
trusted for that purpose?
Bug number 3.  If closing the cert manager and reopenning it solves that issue,
it may not be as bad.  I.e., if the client behaves correctly in terms of
validating certs signed by that CA, even though the view cert only show the
correct info when the cert manager is closed and reopened, the severity is less
than critical.
Bug number 4. If the "behavior" (i.e., actual use of the cert) doesn't reflect
the changes made to the trust, then that's a P0. If it's only the view cert
display that's wrong until the cert manager is closed and reopened, then the
severity is less than critical.
Bug number 5 is a P0 if it prevents users from doing PKI.

Comment 6

[Charles Rosendahl]

yes - the test build and the trunk exhibit these problems.  The beta build on
Windows did not.

regarding your comments:
Bug numbers 1, 4, and 5 are in a permanent state - closing and reopening Cert
Manager/browser doesn't change the state as long as the underlying environment
is as described in the reproduction steps.  Bug number 4 is most likely a
combination of #1 and #3, but there is no way to tell since the disconnect
between the AOL CA cert and the GTE CA cert has already occurred.

Bug number 2 remains that way - apparently the status responder extension (?) is
not checked by any trust setting code.

Bug number 3 is a refresh issue that is not so serious.

Comment 7

[Julien Pierre]

Bill, Charles,

When you go into the ActivCard tool, how many and which certificates show under 
"Digital Certificates" ? I have never been able to get more than one, either my 
signing or encrypting certificate. I can delete that one certificate and import 
the other from a P12. But the AOL CA never gets installed into the token. I 
believe my smartcard may be busted, but I'd like to confirm with you that you 
have more than one certificate showing in your ActivCard.

The other thing I'd like to know about your cert import onto the card is whether 
you used the ActivCard tool or mozilla to import them, or your certs were 
created on the smartcard during enrollment.

Lastly, if you have software copies of your certs, it would be interesting to 
try importing them into the database token, and see if similar bugs exist with 
trust.

Comment 8

[Charles Rosendahl]

I'm not sure how my cert is loaded - I received it from Bill, so probably
through the Activcard tools.

I have both a signing and encrypting cert on the card, it is read-only, and does
not contain the AOL CA cert on the token.

Comment 9

[Charles Rosendahl]

Sorry - I can't export my certs on the card - 'operation not allowed'.  Bill can
probably do this using the activcard tools.

Comment 10

[Julien Pierre]

No, I don't think you can ever export the certs from the card.
The only way you can do it is if you started with software certs and then 
imported them into your card.

Comment 11

[Charles Rosendahl]

Trunk builds:

I have verified that the 2002052104 build works, but the 2002052304 build has
the problems outlined within this bug.

Comment 12

[Charles Rosendahl]

I have also verified that it actually doesn't matter whether you are using a
smartcard or not.  All of the behavior occurs regardless of the token type.

Comment 13

[Julien Pierre]

Charles,

Could you please rewrite the test cases for the database token ? Obviously some 
steps are different, such as installing the module, and the way you import the 
software certs. When I import my certs it also adds the AOL CA. So I'm not sure 
how you can test the behavior when the CA cert is missing. Do you explicitly 
delete it ?

Thanks.

Comment 14

[Charles Rosendahl]

Additional Test Cases for Soft Token:
Builds: 2002052304

Scenario 1: New Profile
1.  Import your dual-key user cert from a p12 file.
2.  AOL CA cert should have been imported with all bits untrusted - Both certs
are verified true
3.  Delete the AOL CA cert. Without any AOL CA cert present, Signing cert is
true, encryption cert is false (bug number 1)

Scenario 2: New Profile
1.  Import your dual-key user cert from a p12 file.
2.  AOL CA cert should have been imported with all bits untrusted - Both certs
are verified true
2.  Uncheck trust bits on GTE CA cert.  Signing is true, encrypting is false
(same as bug 1)
3.  View the GTE Cert - Still verified for status responder even though all
possible trust bits have been unchecked (bug 2)
4.  Recheck the Trust bits on the GTE CA cert.  View Cert - no change in
verified uses (bug 3)
5.  Exit cert manager and reopen.  View GTE CA cert - all uses now verified
6.  User Certs still do not change - Signing is true and encrypting is false,
even though trust bits are now active on parent (GTE) CA cert (bug 4)
7.  AOL cert can no longer be verified for unknown reasons (bug 5)
8.  Check the AOL CA certs trust bits.  Signing and encrypting certs are now
verified true.

Comment 15

[Wan-Teh Chang]

Re: comment #11

To the best of my knowledge, there are only two NSS changes
between those two builds.

1. Bob's fix for bug 144605 (attachment 84692 [details] [diff] [review])
2. Bob's fix for bug 144487 (attachment 84758 [details] [diff] [review])

There are two other changes that were checked in on May 20
that may not have been included in the 2002052104 build.

3. Ian's fix for bug 144309 (attachment 83794 [details] [diff] [review])
4. Julien's fix for bug 137645

I don't know if there are any PSM changes between those two
builds.

Hope this info helps you narrow down which change caused
this bug.

Comment 16

[Kai Engert [:KaiE:]]

According to Bonsai, no checkins have been made to PSM trunk between 05/18 and
05/27.
Neither to mozilla/security/manager nor to mozilla/mailnews/extensions/smime.

Comment 17

[Julien Pierre]

Charles,

I tried your test with Mozilla 1.0 RC3 on Win2k + my own build of NSS 3.5 from 
5/28 .

I'm basing this reply on your comment #14 to this bug.

Scenario 1.
3. I don't see bug 1. At that point, both my signing and encrypting certs are 
false.

Scenario 2.
Note that you have two steps labeled 2 in it. Anyway, I don't see bug 1 either 
in this scenario
3 & 4. I see this - the CA is "still verified for status responder" regardless 
of trust bits. However, I think that is because PSM doesn't expose a way to edit 
the trust bit for that specific purpose.
6. Again, I do not see this bug.
7. I do not see this either.

I have not seen a case where one of my certs was unverified and the other was. 
They are always both true or both false. But I have seen cases while playing 
with the UI after flipping the GTE trust bits back and forth where PSM would 
display my certs as both unverified regardless, until I closed the application 
and restarted it. This may be because my build of NSS 3.5 is slightly different, 
but I'm not sure.

Comment 18

[Charles Rosendahl]

Per meeting with Stephane and Kai, one of the bugs to fix by RTM.  I believe
jpierre was looking at this.

Comment 19

[Julien Pierre]

Yes, Charles, I'm still working on this problem.

Comment 20

[Jaime Rodriguez, Jr.]

lowering impact on this one to ADT2, until someone can lemme know why this is a
high severity issue, that needs to be included with the release of 1.0.1.

Comment 21

[Julien Pierre]

I tried to reproduce your softoken test cases from comment #14 on an OS/2 trunk.

Again, I can't reproduce your scenario 1.

With scenario 2, after making several changes to the trust of the GTE CyberTrust
root (on and off back & forth), I end up with two copies of "GTE CyberTrust
Root", both on "Builtin Object Token". They both show the same trust bits - eg.
when editing the bits in one, it changes the bits in the other when you click
edit. I think PSM is displaying the two copies of the cert objects we have - the
copy of the root cert in the database with the modified trust, and the copy from
the actual builtin. It should only show one copy, as it does when you start with
a fresh profile or after making only a single change to the trust. Also, it
appears that NSS is confused too about which trust entry to use : when clicking
"view", none of the cert usages are trusted for the root cert anymore except
"status responder" for which there is no edit function in the browser.

I have seen similar behavior with multiple entries of root cert after trust
changes on the 1.0 branch build as well as well.

Comment 22

[Julien Pierre]

FYI : after exiting the browser and restarting it, there are no longer two
entries of the GTE root cert showing. However, the trust bits for that cert when
the browser came back up were not the same as the way I had left them when I
quit the browser. This suggests that at some point when I was doing my many
edits of the trust bits on that cert, PSM or NSS "lost track" of where to store
the trust, ie. the real trust of the cert wasn't getting persisted to the database.

Comment 23

[Julien Pierre]

I have created a full detailed scenario, starting from a fresh profile, to
reproduce this completely. It is quite complicated, and shows a number of issues :

a) when setting the bits to on from PSM in one of the categories, all the bits
are set at once. Eg. when you check "web users" it sets both the client and
server bits, which isn't necessarily what you want
b) something is causing PSM to display two cert objects in some cases when root
certs have modified trust
c) somehow after the application gets into that state, the changes that are made
to the trust of the root cert aren't taken into account for the other cert. Eg.
looks as if the modified trust is incorrectly prioritzed (lowest priority)

Here is the full test case :

1. open cert manager

2. under "your certificates" tab, click import to load mycert.p12

3. under "your certificates" tab, "Julien Pierre" shows as 
verified : true
purpose : Sign, Encrypt

4. under "authorities" tab, select "GTE Cybertrust Root" and click "view"
verified for : SSL server, email signer, email recipient, status responder

5. under "authorities" tab, select "GTE Cybertrust Root" and edit
uncheck web sites, mail users, software makers

6. close cert manager

7. open cert manager

8. under "your certificates" tab, "Julien Pierre" shows as
verified : false

9. under "authorities" tab, select "GTE Cybertrust Root" and edit
re-enable web sites, mail users, software makers

10. close cert manager

11. open cert manager

12. under "your certificates" tab, "Julien Pierre" is marked
verified : false

It should be true

13. go to "authorities" tab
There are now two entries for GTE CyberTrust root for Builtin Object Token !!!

- clicking "edit" for either one shows the same trust bits, enabled for
web sites, mail users and software makers

- clicking "view" on the first one shows
verified for : SSL client, SSL server, email signer, email recipient, status
responder
Note the additional "SSL client" usage which wasn't there in step 4

- clicking "view" on the second one shows
verified for : status responder

14. close cert manager

15. exit mozilla

16. restart mozilla

17. go to cert manager

18. under "your certificates" tab, "Julien Pierre" is marked
verified : true
purpose : Client, Sign, Encrypt

Note the new "client" usage that wasn't there after the cert import in step 3 ...

19. go to "authorities" tab
there is now only one GTE CyberTrust root
- clicking "edit" shows  enabled for web sites, mail users and software makers
- clicking "view" shows
verified for : SSL client, SSL server, email signer, email recipient, status
responder
Note the new "SSL client usage" that wasn't there in steps 4

Comment 24

[Stephane Saux]

kai

Comment 25

[Stephane Saux]

as per Julien's comments, I don't see this as a very serious bug. Moreover, we
will problably have to work together with NSS to make sure we do everything the
right way.

Comment 26

[Nelson Bolyard (seldom reads bugmail)]

Another bug "futured" years ago, with no progress since.