118612 - valid peer trust should be removed in 4.0

Status: RESOLVED WONTFIX

(NSS :: Libraries, enhancement, P3)

Description

[Ian McGreer]

The softoken never returns a value of CKT_NETSCAPE_VALID as the trust level of a 
cert.  This means that in NSS 3.4, cert->trust never has CERTDB_VALID_PEER.  
This affects the PSM UI in that PSM will regard a cert with no trust (",,") as 
deleted, but a cert with valid peer ("p,p,p") as present but not trusted.  This 
hack is needed for deleting builtins.

I saw a comment saying that valid peer is that same as "must verify", so it 
appears that dropping it was a conscious decision.  Bob, is that the case?

I have a patch that implements valid peer in the softoken, which fixes several 
bugs.  However, I don't know if it is correct, because I don't know why valid 
peer was dropped.

Comment 1

[Ian McGreer]

Attachment: here's the patch

Comment 2

[Wan-Teh Chang]

Bob, could you review Ian's proposed patch?  Thanks.

Comment 3

[Robert Relyea]

This looks good Ian. Clearly CKT_NETSCAPE_VALID is handled on input, so we
should also handle it on output.

I don't consider Ian's patch a hack, but I am concerned with depending on
CKT_NETSCAPE_VALID at the higher levels. Why is it necessary to get trust bits
to move from the built-ins?

bob

Comment 4

[Ian McGreer]

I'll start at the beginning (what I did to discover this).

If you download a web site cert that you don't recognize, and choose to trust it
permanently, it will get a trust of "P,,", and show up in the web sites UI.  If
later on, you choose to edit the trust of that cert and make it untrusted, it
will get a trust of ",," because of the lack of support for VALID_PEER.  Since
PSM regards a cert with trust ",," as deleted (this is used when builtins are
deleted, they receive a trust of ",," in the softoken), the cert will no longer
appear in the UI.  What should happen is that it appears, but as untrusted. 
That requires it to have a trust of "p,,", which I believe is the correct value,
and will happen with this patch.

We can discuss removing the use of CKT_NETSCAPE_VALID in 4.0, but for
compatibility in 3.4 I believe it's necessary.  I'll check this in.

Comment 5

[Robert Relyea]

We should get our nomiclature correct here:
Untrusted - Do not trust this cert: ever, even if it chains.
Trust unknown - Trust this cert only if it chains to a trusted cert. All certs
from unknown sources are trust unknown.
Trusted - This cert is explicity trusted for the given operation.
Trusted Delegator - Trust can chain to this cert for the given operation.

Peer really has no place, but it sound like it's used to distinguish between
certs which are meant to be 'virtually' deleted and those that aren't. I don't
think this is the valid long turn use of this value, but I think we're fine for
3.X (since 3.X already makes this implicit assumption.

bob

Comment 6

[Ian McGreer]

I agree.  The patch is checked in; 3.4 should be the same as 3.3 now.

I'm making this a 4.0 enhancement bug.  I agree with your trust scheme, but we
still need to have a solution for the following problems:

How do we delete a cert from a read-only token?  Is storing it as explicitly
untrusted for all operations the correct long-term solution?

How do we distinguish untrusted certs by their usage for the PSM UI? 
Specifically, as I noted above, PSM uses a trust of "P,," to denote a trusted
web site cert, and a trust of "p,," to denote an untrusted web site cert. 
Instead of using trust to identify SSL certs, should we attempt to find them
from information in the certificate (from the CN or SubjectAltName)?  The goal
is to be able to implement a function GetSSLCerts() that will return all trusted
and untrusted SSL certs.

Comment 7

[Wan-Teh Chang]

Changed the QA contact to Bishakha.

Comment 8

[Robert Relyea]

Julien, I wonder if this bug is related to our AIM discussion?

bob

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

We're not going to do 4.0, at least not as it was defined 4 years ago.
So what should we do with this bug?  WONTFIX?

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

WontFIX