Re: [reSIProcate] Security class and client-side authentication (longish)
Random thoughts inline
I think we should consider a design meeting to sort some of this out.
A TLS server certainly can act act as a client and is a superset of that.
The S/MIME certs are different from the TLS certs
The Identity header uses the TLS cert but performs S/MIME like functions
The system needs to support CA certs and self singed certs
The system needs to allow a user to install new root certs
Some servers support a bunch of domains and need to be able to deal with
multiple TLS certs (one for each domain)
Clients needs to be able to store fingerprints of non CA signed servers
certs they are willing to trust
On 10/22/04 5:51 PM, "Bob Bramwell" <bob@xxxxxxxxxx> wrote:
> 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.
uhmm the PublicCert would be used for this
> 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?
No the identity is claims is wrong. It is going to assert something like
"fluffy@xxxxxxxxx" not "host22.cisco.com"
>
> 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.
One can be a server, but not a tlsServer meaning you can act as a server but
you can not accept incoming TLS connections.
>
> 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.
How would the TLS context be different for the two roles?
> 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)?
>
You might be right that this is exactly the right thing to do but I have
certainly not got my head wrapped around what you are talking about yet
> 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.
>
I think there is confusion about server and client mode - and I may be
confused on how I remember it being and how it really is - server means you
have a certificate. client mode means you don't. Perhaps these are named
terribly wrong
> 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.
No self signed certs are fine to send - they just must be received carefully
> 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?
>
Well, let's look at what they would want to be able to control and find a
way to allow that
> 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.
Glad to see some work on this and happy to help (though likely after IETF)