[gnutls-help] [gnutls-devel] higher level session API?
nmav at gnutls.org
Mon Jan 28 12:58:40 CET 2013
On Mon, Jan 28, 2013 at 10:55 AM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> Am Monday 28 January 2013 schrieb Nikos Mavrogiannopoulos:
>> Ok it seems I'm closer to a simpler API. A draft version is in:
>> Currently the code to set credentials is the most complex, but overall
>> it looks quite an improvement in terms of size of code. An example of a
>> client and a server is at:
> I like it. Really much simpler than the current approach. I would like to
> implement it into my current project (libmget / mget) in the near future.
> How can a client 'force' a server certificate to be accepted (switch
> certificate checking off) ?
The gnutls_vmethod_t specifies how the peer will be authenticated. The
current options are NO_AUTH, TOFU, GIVEN_CAS, and SYSTEM_CAS (and more
than one can be specified).
My plan is to increase that with DANE (that would be tricky), OCSP,
and possibly SRP, PSK etc.
Also I'm thinking to remove the specification of a priority string in
the xssl_init function and only specify a security parameter
(gnutls_sec_param_t), which will be translated to a priority string
> Do I still link with -lgnutls, or will there be an extra libgnutls-xssl
> library ?
Currently it is part of the main library, but probably before any
release I move it to a separate one. Since it is a totally new API
that is not tested in the field, I wouldn't like to commit on it so
early. Maybe initially it can be part of an xssl library and when it
is stable enough as an API it moves into the main gnutls library.
> What I can't judge: is xssl_cert_init() complete to handle all cases of a real
> life implementation like e.g. Wget ? There are these kinds of arguments:
I believe all these options are handled by the current code (except
More information about the Gnutls-help