|
List Info
Thread: TLS API
|
|
| TLS API |

|
2007-07-06 01:11:21 |
Hello Justin,
Just went through TLS public API.
Wanted to be sure that:
1. You can verify peer certificate before connection is
opened.
I guess the should be done in firstStepDone() signal.
But because this is so important to be implemented by user,
maybe
having a unique signal for this is important... Something
like
peerCertificateAvailable().
2. You can delay setting the client certificate after it is
required.
I did not find how to do this. How do you know if the peer
requires
client certificate authentication?
I guess I expect a clientCertificateRequired() signal.
The client can provide no certificate if it has none.
3. Be able to investigate root certificates the peer
supports so that
application may prompt the user a subset of available
certificate.
We should solve 2 first...
But I guess peerCertificateChain() is the place to get
these... But
are you sure "chain" is the correct term for
this?
Or maybe the certificate collection is not exposed.
BTW: Why setCertificate does not get KeyBundle?
Alon.
_______________________________________________
delta mailing list
delta lists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com
a>
|
|
| Re: TLS API |
  United States |
2007-07-06 02:18:34 |
On Thursday 05 July 2007 11:11 pm, Alon Bar-Lev wrote:
> Hello Justin,
>
> Just went through TLS public API.
> Wanted to be sure that:
>
> 1. You can verify peer certificate before connection is
opened.
> I guess the should be done in firstStepDone() signal.
> But because this is so important to be implemented by
user, maybe
> having a unique signal for this is important...
Something like
> peerCertificateAvailable().
The primary signal for this purpose is handshaken(). This
signal occurs when
the entire TLS negotiation is complete and the application
stream can begin.
firstStepDone() can also be used, but only by the client.
> 2. You can delay setting the client certificate after
it is required.
> I did not find how to do this. How do you know if the
peer requires
> client certificate authentication?
> I guess I expect a clientCertificateRequired() signal.
> The client can provide no certificate if it has none.
You can call setCertificate() at any time, not just at
initialization. The
client should receive firstStepDone(), examine the
issuerList(), and then
call setCertificate().
> 3. Be able to investigate root certificates the peer
supports so that
> application may prompt the user a subset of available
certificate.
issuerList()
> BTW: Why setCertificate does not get KeyBundle?
No real reason.. probably it is because KeyBundle came
later in the API, and
I never bothered to add convenience methods. I've committed
some now.
-Justin
_______________________________________________
delta mailing list
delta lists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com
a>
|
|
| Re: TLS API |

|
2007-07-06 02:25:33 |
Thanks.
Although I think the signal names are very confusing...
I think most developer would like to construct a state
machine based
on logical events and not hardcore steps...
Logical events will make it easier for them to accomplish
the right
task at the right time lowering the chance of mistake.
You did not answer how the client can know if the server is
requesting
a client certificate.
Alon.
On 7/6/07, Justin Karneges <justin-psi2 affinix.com> wrote:
> On Thursday 05 July 2007 11:11 pm, Alon Bar-Lev wrote:
> > Hello Justin,
> >
> > Just went through TLS public API.
> > Wanted to be sure that:
> >
> > 1. You can verify peer certificate before
connection is opened.
> > I guess the should be done in firstStepDone()
signal.
> > But because this is so important to be implemented
by user, maybe
> > having a unique signal for this is important...
Something like
> > peerCertificateAvailable().
>
> The primary signal for this purpose is handshaken().
This signal occurs when
> the entire TLS negotiation is complete and the
application stream can begin.
>
> firstStepDone() can also be used, but only by the
client.
>
> > 2. You can delay setting the client certificate
after it is required.
> > I did not find how to do this. How do you know if
the peer requires
> > client certificate authentication?
> > I guess I expect a clientCertificateRequired()
signal.
> > The client can provide no certificate if it has
none.
>
> You can call setCertificate() at any time, not just at
initialization. The
> client should receive firstStepDone(), examine the
issuerList(), and then
> call setCertificate().
>
> > 3. Be able to investigate root certificates the
peer supports so that
> > application may prompt the user a subset of
available certificate.
>
> issuerList()
>
> > BTW: Why setCertificate does not get KeyBundle?
>
> No real reason.. probably it is because KeyBundle
came later in the API, and
> I never bothered to add convenience methods. I've
committed some now.
>
> -Justin
> _______________________________________________
> delta mailing list
> delta lists.affinix.com
> http://lists.affinix.com/listinfo.cgi/delta-affinix.com
a>
>
_______________________________________________
delta mailing list
delta lists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com
a>
|
|
| Re: TLS API |
  United States |
2007-07-06 03:22:17 |
On Friday 06 July 2007 12:25 am, Alon Bar-Lev wrote:
> You did not answer how the client can know if the
server is requesting
> a client certificate.
Hmm, I think I planned for this to be
!issuerList().isEmpty(). However,
according to the RFC it looks like it is possible for the
server to request a
certificate without sending any issuers. Do you know if
openssl supports
this discovery? I guess we could add another property
getter to the TLS
class.
-Justin
_______________________________________________
delta mailing list
delta lists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com
a>
|
|
| Re: TLS API |

|
2007-07-06 05:19:23 |
On 7/6/07, Justin Karneges <justin-psi2 affinix.com> wrote:
> On Friday 06 July 2007 12:25 am, Alon Bar-Lev wrote:
> > You did not answer how the client can know if the
server is requesting
> > a client certificate.
>
> Hmm, I think I planned for this to be
!issuerList().isEmpty(). However,
> according to the RFC it looks like it is possible for
the server to request a
> certificate without sending any issuers. Do you know
if openssl supports
> this discovery? I guess we could add another property
getter to the TLS
> class.
SSL_CTX_get_client_cert_cb/SSL_CTX_set_client_cert_cb
Also you need to support session resume, it happens after
the socket
disconnect, then there is a quick negotiation to reestablish
the TLS
session.
Alon.
_______________________________________________
delta mailing list
delta lists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com
a>
|
|
| Re: TLS API |
  United States |
2007-07-06 13:58:59 |
On Friday 06 July 2007 3:19 am, Alon Bar-Lev wrote:
> On 7/6/07, Justin Karneges <justin-psi2 affinix.com> wrote:
> > On Friday 06 July 2007 12:25 am, Alon Bar-Lev
wrote:
> > > You did not answer how the client can know if
the server is requesting
> > > a client certificate.
> >
> > Hmm, I think I planned for this to be
!issuerList().isEmpty(). However,
> > according to the RFC it looks like it is possible
for the server to
> > request a certificate without sending any issuers.
Do you know if
> > openssl supports this discovery? I guess we could
add another property
> > getter to the TLS class.
>
> SSL_CTX_get_client_cert_cb/SSL_CTX_set_client_cert_cb
Alright, firstStepDone() is gone. Now there's
certificateRequested().
> Also you need to support session resume, it happens
after the socket
> disconnect, then there is a quick negotiation to
reestablish the TLS
> session.
Ah yes, okay I added a simple API for this now.
-Justin
_______________________________________________
delta mailing list
delta lists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com
a>
|
|
| Re: TLS API |

|
2007-07-06 14:14:51 |
On 7/6/07, Justin Karneges <justin-psi2 affinix.com> wrote:
> Alright, firstStepDone() is gone. Now there's
certificateRequested().
But at this point was also used to validate peer
certificate, right?
Please consider adding peerCertificateAvailable() signal for
both
client and server.
> > Also you need to support session resume, it
happens after the socket
> > disconnect, then there is a quick negotiation to
reestablish the TLS
> > session.
>
> Ah yes, okay I added a simple API for this now.
Great!
Alon.
_______________________________________________
delta mailing list
delta lists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com
a>
|
|
| Re: TLS API |
  United States |
2007-07-06 15:00:07 |
On Friday 06 July 2007 12:14 pm, Alon Bar-Lev wrote:
> On 7/6/07, Justin Karneges <justin-psi2 affinix.com> wrote:
> > Alright, firstStepDone() is gone. Now there's
certificateRequested().
>
> But at this point was also used to validate peer
certificate, right?
Kind of. The handshaken() signal is primarily used as the
moment to examine
certificates.
(It was only luck of the protocol that the server cert also
happened to be
available at the time a certificate is requested by the
server, which is why
I documented that for firstStepDone(). If it turned out to
not be available
at that time, then we wouldn't have had a signal for it.)
> Please consider adding peerCertificateAvailable()
signal for both
> client and server.
Yes, maybe it would be nice to be able to check the server
cert earlier than
handshaken(). I've now added a peerCertificateAvailable()
signal.
-Justin
_______________________________________________
delta mailing list
delta lists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com
a>
|
|
| Re: TLS API |

|
2007-07-06 15:04:01 |
Great!
Now it seems to be complete.
Alon.
On 7/6/07, Justin Karneges <justin-psi2 affinix.com> wrote:
> On Friday 06 July 2007 12:14 pm, Alon Bar-Lev wrote:
> > On 7/6/07, Justin Karneges <justin-psi2 affinix.com> wrote:
> > > Alright, firstStepDone() is gone. Now
there's certificateRequested().
> >
> > But at this point was also used to validate peer
certificate, right?
>
> Kind of. The handshaken() signal is primarily used as
the moment to examine
> certificates.
>
> (It was only luck of the protocol that the server cert
also happened to be
> available at the time a certificate is requested by the
server, which is why
> I documented that for firstStepDone(). If it turned
out to not be available
> at that time, then we wouldn't have had a signal for
it.)
>
> > Please consider adding peerCertificateAvailable()
signal for both
> > client and server.
>
> Yes, maybe it would be nice to be able to check the
server cert earlier than
> handshaken(). I've now added a
peerCertificateAvailable() signal.
>
> -Justin
> _______________________________________________
> delta mailing list
> delta lists.affinix.com
> http://lists.affinix.com/listinfo.cgi/delta-affinix.com
a>
>
_______________________________________________
delta mailing list
delta lists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com
a>
|
|
[1-9]
|
|