gnutls-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnutls-dev] Work in progress: GnuTLS 2.2 release notes on API chang


From: Simon Josefsson
Subject: Re: [gnutls-dev] Work in progress: GnuTLS 2.2 release notes on API changes
Date: Fri, 16 Nov 2007 11:02:34 +0100
User-agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)

Martin Lambers <address@hidden> writes:

> On Thu, 15. Nov 2007, 11:03:17 +0100, Simon Josefsson wrote:
>> Further, I believe we could improve the gnutls_set_default_priority2()
>> API.  Right now it is difficult to use from applications.  Each
>> application would need to have a configuration file token (e.g.,
>> 'gnutls-priority: EXPORT') or command line parameter (e.g.,
>> --gnutls-priority PERFORMANCE) that map to the GnuTLS enum types.  A
>> serious problem is that there would be no consistency between GnuTLS
>> applications on what the enum names should be and their meaning.
>> 
>> I think it would be better if we had a function like:
>> 
>>   int gnutls_set_priority (gnutls_session_t session,
>>                            const char *priority);
>> 
>> It would take strings that can be set by users in application
>> configuration files or command line parameters.  GnuTLS could define a
>> couple of strings:
>> 
>>   DEFAULT
>>   EXPORT
>>   PERFORMANCE
>>   SECURITY
>> 
>> etc.  Eventually we could even support something like OpenSSL's priority
>> strings, which allow things similar to 'DEFAULT:-AES' to use the
>> defaults, but remove all AES ciphers.
>
> I think this is an excellent idea. Applications could give users the
> possibility to tweak the priorities in a simple _and consistent_ way.
> This would elegantly solve a current problem with msmtp and mpop; 
> see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440344 .

Interesting, it seems the set_priority function could do things related
to required diffie-hellman sizes too.  Possibly even the padding stuff.
It seems simpler than having applications have to do each call and
handle the user configuration stuff for each function; instead just have
one call in the application that forwards a string from the user which
can be interpreted by gnutls.

I'll implement this, but I'm going away on vacation later today, so
don't expect anything during next week.  If others have thoughts about
how the feature would work, please discuss it meanwhile.

/Simon



reply via email to

[Prev in Thread] Current Thread [Next in Thread]