[gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650)

Development of GNU's TLS library gnutls-devel at lists.gnutls.org
Mon Sep 17 12:00:10 CEST 2018

Tom commented on a discussion on lib/includes/gnutls/gnutls.h.in:

>  			        unsigned idx,
>  			        gnutls_datum_t * response);
> +/* RAW public key functions (RFC7250) */
> +#ifdef ENABLE_RAWPK
> +int gnutls_certificate_set_rawpk_keypair(gnutls_certificate_credentials_t cred,
> +				    const gnutls_pubkey_t subjectPublicKeyInfo,
> +				    const gnutls_privkey_t key);
> +
> +int gnutls_certificate_set_rawpk_keypair_raw(gnutls_certificate_credentials_t cred,

Alright. For what it is worth, I forgot to mention that I actually based the function suffixes on the naming convention that you used in pcert.c (e.g. `gnutls_pcert_import_x509_raw`). There you use `_raw` when plain `datum_t` types are being fed into the functions. I think that is quite nice. So the question is now which of the conventions are we going to use? We can do something like:
*  `gnutls_certificate_set_rawpk_key` for abstract types
*  `gnutls_certificate_set_rawpk_key_raw` for raw datums and use a flag to toggle memory read or file read.

*  `gnutls_certificate_set_rawpk_key` for abstract types
*  `gnutls_certificate_set_rawpk_key_mem` for raw datums
*  `gnutls_certificate_set_rawpk_key_file` for files

What do you think?

Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_101782418
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/20180917/c60bfbd7/attachment.html>

More information about the Gnutls-devel mailing list