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

[Development of GNU's TLS library]

Tom commented on a discussion on lib/cert-cred-rawpk.c:

> + *
> + * Obtains pointers to a public/private key pair that has been stored in
> + * @cred with one of gnutls_certificate_set_key(),
> + * gnutls_certificate_set_rawpk_key_mem() or gnutls_certificate_set_rawpk_key_file().
> + * The returned keys must NOT be deallocated since they point directly
> + * to the keys in the credentials struct. With this function you can
> + * retrieve, and if desired, overwrite a previously set key pair.
> + *
> + * A correct @index can be retrieved as the return value from a
> + * gnutls_certificate_set_key(), gnutls_certificate_set_rawpk_key_mem()
> + * or gnutls_certificate_set_rawpk_key_file() function when the
> + * %GNUTLS_CERTIFICATE_API_V2 flag is set.
> + *
> + * If there is no key with the given index,
> + * %GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE is returned. If the public key
> + * with the given index is not a raw public key, %GNUTLS_E_INVALID_REQUEST

> So you say it is applicable to both raw and x509. So it is ok.

Yes.

> In that case why do we introduce the special function to get raw keys with no equivalent in the x509 set? Do you have a particular use case for it?

There are equivalent functions for x509 in `cert-cred-x509.c` called `gnutls_certificate_get_x509_key()` and `gnutls_certificate_get_x509_crt()`. My function for retrieving a raw public-key only retrieves both the private key and public key together (i.e. retrieves the key pair). That reduces the number of new API functions  and most of the time you want to retrieve both of them anyway. You also set them together so I think it's logical to retrieve them together.

If your question is why do we have `gnutls_certificate_get_crt_raw()`, that I don't know. It was already there.

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