[reSIProcate] Security class and client-side authentication (longish)

[Bob Bramwell]

This note is part reality check and part change proposal.  Your constructive 
feedback will be most welcome.

I am trying to set things up to allow TLS connections to do client 
authentication.  There are a number of things, notably in the Security class, 
that will need to change to accomodate this.

At present a Security object has two public certificates associated with it: its 
publicCert and its publicIdentityCert.  The former is used as the certificate 
presented to a TLS client when it connects to a TlsConnection created in server 
mode.  The latter only appears to be used for signing stuff (computeIdentity and 
checkIdentity functions).  No provision is made for a client side certificate 
per se.  However, if the Security object is not actually going to be used to 
checkIdentity or computeIdentity (these functions do not actually appear to be 
called anywhere by code in the reSIProcate source tree) the publicIdentityCert 
*could* be overloaded to act as a client certificate.

Question:  *should* the publicIdentityCert be overloaded, or should a
            different certificate be attached to the Security object for
            this purpose?

When a Security object is created it is either a server or a client; this is 
recorded in the mTlsServer member variable.  When a Security object is used 
(e.g. by TlsConnection) to obtain an SSL context (using getTlsCtx) the argument 
isServer is passed in the call.  Why does this need to be specified in two 
different places?  What problem is it designed to solve?  The mTlsServer member 
variable is only used in getTlsCtx, and it is far from clear what is supposed to 
happen if mTlsServer and isServer have different values.

Considering the situation when a TlsTransport is used both as a server and as a 
client, it would be convenient to have a Security object that returned a 
different CTX depending on the role.  It therefore seems sensible to remove the 
Security constructor tlsServer argument and the mTlsServer member variable 
altogether.

Question: *should* the Security::mTlsServer variable be removed (and all that
           that implies)?

The Security object only ever creates one SSL_CTX which it stashes in the ctxTls 
member variable.  At present, therefore, if a Security::getTlsCtx call was made 
in "client" mode before a later call in "server" mode, the SSL_CTX provided to 
the server would have no certificate information.  This seems entirely broken, 
and probably reinforces the case for maintaining at least two SSL_CTX's - one 
for each role.

Finally (I hope) the TLS standard requires that a client certificate is sent 
only if it is signed (ultimately) by one of the acceptable CAs provided in the 
certificate request.  The Security class could allow the certificate selection 
to be performed by a caller-provided mechanism by using the 
SSL_CTX_set_client_cert_cb mechanism.

Question: *should* a user of the Security class be allowed to determine how
           certificate selection is performed, or should this be nailed down
           beyond user interference in the Security implementation?

I think that covers my immediate concerns; at least regarding reSIProcate, as 
opposed to those about world hunger, AIDS, global warming, etc..  If anyone 
feels like providing me with a better sense of direction I would be greatly 
obliged.  In particular, if there are M's I should be RTFing please let me know.

-- 
Bob Bramwell            Jasomi Networks (Canada) | This space
Ph: 403 269 2938 x155   #310 602 11th Ave SW     | intentionally
FX: 403 269 2993        Calgary, AB, T2R 1J8     | left blank.