[gnutls-devel] RFC 7250 and API change

[Nikos Mavrogiannopoulos]

On Mon, May 2, 2016 at 9:48 AM, Rick van Rein <rick at openfortress.nl> wrote:
> Hi Nikos,

> Thanks for sharing your thoughts.
> Relying on an explicit indication from the application that it can handle RFC 7250 does avoid problems in applications.  Its downside is that the acceptance of RFC 7250 is an explicit choice, and will require that explicit choice forever.  Or do you see a future path of phasing out gnutls_certificate_type_get() in favour of separate client/server certtypes?

I think that the explicit acceptance is mandated by the nature of the
change rfc7250 brings. Applications which assume that certificates
types are the same for client and server cannot be changed by a user
configurable string or option. At best they will fail with an error,
while at worst they may even crash on unexpected input from gnutls.

> Another form of explicit indiciation could be the priority string, by the way.  That would combine nicely with a migration to independent client/server certtypes, with a change to the default CTYPE-xxx changes; as soon as CTYPE-RAW and/or CTYPE-KRB are mentioned, it ought to be clear that client and server can each have their own certtype.  A remaining concern would be what to do with CTYPE-ALL though.

I believe we can easily switch from CTYPE-X509 to CTYPE-RAW or KRB,
because of the existing support for openpgp keys, but the asymmetric
certificate negotiation, is not something the current API can
accommodate without the application being explicitly modified for it.

However, even if we could avoid that explicit enabling, would that
really help? I mean is there an application which can transparently
moved to CTYPE-RAW for client and CTYPE-X509 for server keys without a
change?

regards,
Nikos