[gnutls-devel] GnuTLS | Support for raw public keys for gnutls-cli and gnutls-serv (!1059)

[Development of GNU's TLS library]

Tom commented on a discussion on src/cli.c: https://gitlab.com/gnutls/gnutls/merge_requests/1059#note_214167349

>  const char *x509_cafile = NULL;
>  const char *x509_crlfile = NULL;
>  static int x509ctype;
> +const char *rawpk_keyfile = NULL;
> +const char *rawpk_file = NULL;
>  static int disable_extensions;
>  static int disable_sni;
> -static unsigned int init_flags = GNUTLS_CLIENT;
> +static unsigned int init_flags = GNUTLS_CLIENT | GNUTLS_ENABLE_RAWPK;

I will create a test for that.

>  Nevertheless, I find it a regression for the tool to suddenly starting negotiating raw public keys with an existing server where previously it would negotiate pkix.

This does not happen. Default behaviour is guaranteed unless a user explicitly sets the raw pk certificate type to be negotiated (via the priority strings).

The `GNUTLS_ENABLE_RAWPK` flag is for the application developer to enable this functionality in the library. The application developer is responsible for implementing / handling the raw pk functionality in the application. That would be me / us in this case.

The user is then responsible for actually using raw pk stuff by 1) setting the raw pk credentials, 2) telling the application via the priority strings (`CTYPE-*` flags) that raw public keys are to be negotiated with the peer. If 2) is not done by the user then the application just behaves as if it only knows x509.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1059#note_214167349
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20190909/21713ec6/attachment-0001.html>