[PATCH] session ticket support

[Nikos Mavrogiannopoulos]

On Tue, Aug 4, 2009 at 3:15 PM, Simon Josefsson<simon at josefsson.org> wrote:

> Also the above API hard-codes the use of AES-128 + HMAC-SHA-256 which
> won't be good choices forever.  How about changing the randomize
> function into:
>
>  int gnutls_session_ticket_key_randomize (gnutls_session_ticket_key_t,
>                                          gnutls_cipher_algorithm_t cipher,
>                                          gnutls_mac_algorithm_t mac);

Indeed the rename will make things more clear. However
this might not be proper place to make the algorithms flexible since
the allocation has been done before and had
no knowledge of the required key sizes. Those options could have been
in the allocation part.

> I see that some struct sizes in the RFC (like IV and MAC size) are hard
> coded, so it may not be worth time to extrapolate that part to support
> non-AES-128/HMAC-SHA-256 options.  So
> gnutls_session_ticket_key_randomize could return an error if other
> choices than AES-128/HMAC-SHA-256 are used.  This means the API is ready
> if RFC 5077bis defines support for HMAC-SHA-3 or similar.

I am not really sure about the flexibility here. If a new rfc mandates
some different algorithms would we
expect the application need the change those? I would expect gnutls
should have done it implicitely. Anyway I
don't think is bad since many people would want to use AES-256 and
hmac with 512 etc etc... If we add it we could do
it with a different function that accepts additional parameters such
as gnutls_session_ticket_key_allocate2(z,x,y ) and leave a simple
allocate(x) that will set the defaults?

regards,
Nikos