51407 - Stan: Multiple certificate databases and SSL

Status: ASSIGNED

(NSS :: Libraries, enhancement, P3)

Description

[Nelson Bolyard (seldom reads bugmail)]

This was originally bugsplat bug 102812 from Steve Parkinson, who wrote:

To facilitate SSL testing, I would like to be able to tie different cert 
databases to different SSL sockets, instead of all SSL sockets sharing a 
process-global certificate database.

------- Additional Comments From jgmyers  May-06-1999 13:36 ------- 

This is important for virtual servers/hosting, as they need multiple sets of CA 
trust policies.

------- Additional Comments From nelsonb  May-12-1999 20:21 ------- 

Some thoughts:

I went and looked at where and how SSL uses DB pointers.
There are exactly 7 calls to CERT_GetDefaultCertDB() in ssl code.
There are 23 calls to GetDefault{Cert,Key}DB in pkcs11 sources.

It would be easy to put a certdb pointer into the SSLSocket struct
and replace 6 of SSL's 7 calls with references to that pointer.
The pointer could be initialized by calling CERT_GetDefaultCertDB()
or by inheritence from a "model socket" or "listen socket".
It would be easy to add a function to allow an application to 
explicitly set the DB pointer to a value of its choosing.  

The one call in SSL that cannot be easily fixed that way is in 
the server session cache code.  Virtual servers need conceptually 
separate Session ID caches.  The SSL code presently assumes
thaat there is exactly one client session cache, and exactly
zero or 1 server session caches.  So, we don't pass any info
to the server cache code to help it identify which of the 
virtual servers we're querying.  It assumes only one server.
Fixing this is a job to do in the Stan time frame.

The bigger problem, in my estimation, is dealing with all the
calls in pkcs11 code.  That code clearly assumes one cert DB.
There's no point in fixing the SSL code to handle separate 
trust spaces (e.g. DBs) until the pkcs11 code can also be changed.

So, this task must wait for the new stan cert/key architecture.

------- Additional Comments From nelsonb  May-25-1999 17:10 ------- 

I have added a CertDBHandle pointer to the sslSocketStr struct,
and use it everywhere that SSL used to call Cert_GetDefaultCertDB().
The value of this is inherited from listen or model sockets, or
is initialized using Cert_GetDefaultCertDB() for new SSL sockets
(when no model socket or listen socket is involved).  

I've added a new function to ssl.h
extern SECStatus SSL_CertDBHandleSet(PRFileDesc *fd, CERTCertDBHandle 
*dbHandle);
which allows an application to set the DBHandle as it wishes.

However, this doesn't completely give SSLSockets independence from 
the "default" cert db, because the PK11_ functions still use 
CERT_GetDefaultCertDB() heavily.
I predict that won't get fixed until Stan, when SSL will stop
directly referencing cert databases alltogether (I think).

I'm not sure if I should mark this bug fixed, and create a new
bug for PK11_, or just reassign this to relyea.

BTW, there's also the issue of key databases.  SSL uses private 
keys a lot, but doesn't ever explicitly use a SECKEYKeyDBHandle,
that I can see.  I'd guess that means we're always using a default
one implicitly :-(.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

Change target fix version for all "stan" RFEs to "Future".

Comment 2

[Thomas]

Is there a way people like me can test this?