482153 - Need a Stan function to answer: is this cert Trusted for this usage?

Status: RESOLVED FIXED

(NSS :: Libraries, enhancement, P2)

Description

[Nelson Bolyard (seldom reads bugmail)]

NSS lacks a function to ask: Is this NSSCertificate trusted for this usage?

NSS has MANY functions that attempt to return the "Best" certificate 
according to certain criteria.  They all ignore trust, and that is the cause 
of numerous bugs, such as bug 479508.  They nearly all rely on a single underlying function, which is nssCertificateArray_FindBestCertificate.  If
that function could be changed to check certs for being trusted for the 
usage argument, and to select only one of the trusted certs when any are
trusted, that would solve most of these problems.  

To fix that, nssCertificateArray_FindBestCertificate needs a Stan function
to answer: Is this NSSCertificate trusted for this usage?

Header file nss/lib/pki/nsspki.h contains a block comment describing a 
function as:

> PRBool NSSCertificate_GetIsTrustedFor{xxx}(NSSCertificate *c);

Apparently, it was thought that the usage would be part of the function
name.  I now propose a new function:

PRBool NSSCertificate_IsTrustedForUsage(NSSCertificate *c, 
                                        const NSSUsage *usage);

to be called by nssCertificateArray_FindBestCertificate.  But I scarcely
know where to begin to implement it.  All the code I've seen to answer the
question of "is this cert trusted" is old pre-stan code that uses the 
CERTCertificate's trust.  That's clearly NOT what we want to use for this
function.  But I don't know what we should use instead.  

Bob, I'd appreciate an outline of how to implement this Stan function, e.g. 
how to answer the trust question, what objects need to be interrogates, etc.
Do we need to ask a trust domain?  A crypto context?  Are there functions 
to do any of those things?

Although this is an enhancement request, it blocks a P2 bug.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

Attachment: disgusting hack

This disgusting hack effectively unblocks bug 479508, 
but it's too disgusting to contemplate committing. 
Writing it was useful, to convince me we need a Stan solution.

Comment 2

[Robert Relyea]

Comment on attachment 366236 [details] [diff] [review]
disgusting hack 

clearing review, but I'll still give you some comments....

Comment 3

[Robert Relyea]

The disgusting thing about this hack is missing NSS3 and Stan elements together in a stand file.

First things first: the signature... in stan, I think you need the trust domain to really answer the question: is this cert trusted for this operation.

Next, pointers to where the right stuff is. pki/pki3_hack.c is where the NSS3/Stan translators live. NSS3 is treated like an encoding in stan, except we also need to map stan structures back into NSS3 structures to applications continue to work.

I see a couple of functions there that may be interesting:

1) nss3certicate_getUsage(nssDecodedCert *dc). It currently doesn't return anything useful (NULL). I don't know where it's used, but the guts of your hack would seem to naturally live in this function. (though I could be mistaken).

2) nss3certificate_matchUsage() with a comment CERT_FilterCertListByUsage. This does have an implementation, but does not check trust. (probably shouldn't).

3) cert_trust_from_stan_trust and nssTrust_GetCERTCertTrustForCert shows how we currently map stan trust to cert trust. It also shows how to get stan trust from the trustdomain and the certificate.

bob

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

(In reply to comment #3)
> The disgusting thing about this hack is missing NSS3 and Stan elements 
> together in a stan file.

Well, IMO, the disgusting thing is that this stan function is relying on
properties of one of the encodings, when the information being requested
is completely independent of cert encoding (and is not actually part of 
the cert).  

> First things first: the signature... in stan, I think you need the trust 
> domain to really answer the question: is this cert trusted for this 
> operation.

The TD is needed to answer the question the first time it is asked.  After
that, it should be cached in the NSSCert somewhere, just as it is in the
CERTCertificate.  Polling the tokens is the only method implemented by the 
TD to answer that question.  We don't want to go polling all the tokens 
every time that someone asks if the cert is trusted.

The NSSCert has a TD pointer in it, so I think it is unnecessary to also
put the TD pointer into the function signature, because it's implicit in
the NSSCert argument.

> Next, pointers to where the right stuff is. pki/pki3_hack.c is where the
> NSS3/Stan translators live. NSS3 is treated like an encoding in stan, 
> except we also need to map stan structures back into NSS3 structures to 
> applications continue to work.

I think you're saying the code is in the wrong file.  Are you also saying
that the function is incomplete?

Thanks for the other pointers in that comment.

Comment 5

[Kai Engert [:KaiE:]]

(In reply to Robert Relyea from comment #3)
> The disgusting thing about this hack is missing NSS3 and Stan elements
> together in a stand file.

I don't understand this sentence, could you please elaborate?

Comment 6

[Wan-Teh Chang]

Fixed by the patch in bug 764393 comment 29.  I added the isTrustedForUsage
method to the nssDecodedCert structure.