Re: [reSIProcate] TLS handshake failure

[Bob Bramwell <bob@xxxxxxxxxx>]

Same port & same interface, no.  Same *transport* but different incoming and 
outgoing behaviour, yes.

Since a TlsConnection gets its Security object (and therefore its certificate) 
from the TlsTransport, and since Security (at present) can carry only one 
certificate, each TlsTransport requires ALL connections, regardless of 
direction, to use the same certificate.  Some of us want to make a distinction 
between client and server certificates using the same TlsTransport.

Cullen Jennings wrote:
> There are cases where a single machine might have different certs, even for
> the same DNS name, however, I've yet to see one of these where we are
> talking about different certs for the same port on the same interface. If
> someone knows of a use case like this, I'd love to hear about it.
>
> Cullen
>
>
>
> On 5/18/05 5:16 PM, "Bob Bramwell" <bob@xxxxxxxxxx> wrote:
>
>
> > I haven't been following this discussion from the start, but it is ringing
> > really loud bells for me.  Some time ago we had a rather similar discussion on
> > this list in which the following snippet appeared:
> >
> >
> > > Cullen Jennings wrote:
> > >
> > > 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
> >
> > I remain convinced that there *are* scenarios where distinct client and server
> > certificates have to be presented.  IMO there ought to be provision for this.
> > Presenting the server cert if no client cert were specified seems to be a
> > reasonable default position to take.
> >
> > Hope that helps,
> > Bob.


--
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.