236887 - implement CERT_IsServerCert()

Status: NEW

(NSS :: Libraries, enhancement, P2)

Description

[John G. Myers]

Requesting a new function PRBool CERT_IsServerCert(CERTCertificate *) to
determine if the input certificate is usable for an SSL server.

The logic should be similar to CERT_VerifyCertName() in the fields it examines.
 It should return true if there is any domain or ip that can match.  It probably
isn't necessary to check name constraints.

Comment 1

[John G. Myers]

The function should also check the usage constraints.

Comment 2

[John G. Myers]

I can also see a need for "is usable for S/MIME" and "is usable for code
signing" functions.

Comment 3

[Robert Relyea]

Uh, What is wrong with CERT_VerifyCertificate with the appropriate Usage? This
is how SSL tests to see if a Certificate is useable for a given purpose.

bob

Comment 4

[John G. Myers]

I need it to ignore trust and revocation status.

Comment 5

[Robert Relyea]

1) Why do you want to ignore trust (I'm not saying it's not reasonable, but
little bells go off when you say this and I want to make sure there isn't an issue).

2) How do you want to handle the root cert? Should the check ignore the root
cert attributes? (many root certs are 'grandfathered' using the trust system).

bob

Comment 6

[John G. Myers]

1) The function is to be used to determine for which certs it is reasonable to
give the user an opportunity to edit the server trust bits.  If the function
looked at trust, there would be no way to mark an untrusted certificate as trusted.

2) The root CA certs are presumably not usable for SSL servers and it does not
make sense to edit the server trust bits for such certs, so the function should
return false for such certs.  It is sufficient for CERT_IsCACert() to return
true for such certs so that the user can be given the opportunity to edit the CA
trust bits.

Comment 7

[Robert Relyea]

Oh, OK I see your purpose. I thought you wanted to some chain validation that
said: "If this cert chains to a root cert that isn't explicitly trusted, return
true (all other processing like basic constraints, etc. are still processed)."
In this case we need to know how you want to deal with root most certificates
(thus my question)

Now I see that what you really want to do is catorgorize a random cert in the
database appropriately so that you can set the trust bits on it if you want. The
problem with this is there is no way to catagorize a cert for a particular
purpose without the chain and trust. We could make some guesses, but we will
either 1) ignore certs that the user wants to make SSL/SMIME, 2) miscatagorize a
cert the user wants to use as an SSL cert as an S/MIME cert, or 3) miscatagorize
ann S/MIME cert as an SSL cert. The problem is some certs could function as
both! (many SSL certs include email addresses, for instance).

How one catagorize these for an application UI seems to be an application policy
rather than an NSS function (I'm willing to be convinced otherwise). I'm just
thinking about who should handle the question, "my OpenSSL generated cert shows
up in the wrong box in mozilla".

On the other hand, this issue was solved in another application with the
'Miscellaneous' tab. Any cert that doesn't test out as 1) a CA, 2) a trusted
Website, 3) email, or 4) User cert winds up in this tab. It's also great tab to
catch other certs in the database the 'fall through the cracks'.

Comment 8

[John G. Myers]

Certs that don't include a usable SSL server name or which have policies which
preclude their use for SSL servers can be categorized as unusable for SSL
servers, without reference to chain, trust, or application policy.  This is the
information I'm asking to be able to get.

Certs that are usable for both SSL servers and S/MIME should categorize as being
appropriate for both.  That a cert is usable for S/MIME does not lessen its
usablility for SSL.

As to who should handle the question you posed, that would be me, as Mozilla's
PSM module owner.  An appropriate UI would be to make the cert appear under both
tabs.

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

John, I agree with your comment 8 whole-heartedly.  
I think this new function wants to take a purpose argument, and return
a bool, so that one new function can answer
  - is SSL server cert
  - is SMIME encryption cert
and wants to answer it using only the info in the cert itself, without
regard for validity of signature, trust of issuer, or validity period dates.

Or perhaps it wants to return a bit map of purposes.  That would make orphans
easy to identify.

What do you think of these alternative ideas?

Comment 10

[John G. Myers]

Either of those alternatives would be fine.  I suggest that "CA" and "code
signing" could be additional purposes handled by a generic function.

CERT_IsCACert() is close enough to indicate CA purpose, though CERT_IsCACert()
will classify a non-CA cert as CA if it is trusted for CA.

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

Putting on the NSS 3.10 radar screen

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

This is an enhancement request specifically for the browser.
Bob, Wan-Teh, any chance that you're interested in this/