[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

The `gnutls_certificate_get_crt_raw()` function just returns the raw certificate data (in DER encoding). It doesn't look at the certificate type. The user that calls this function must know how to interpret the data (i.e. whether it's a x509 cert or raw pubkey). Therefore I think it doesn't make sense to check for a cert type here (we even don't have a parameter for that) and thus we can not return a `%GNUTLS_E_INVALID_REQUEST`.

The `gnutls_certificate_get_x509_key()` and `gnutls_certificate_get_x509_crt()` functions however actually do a cert type check and are in line with `gnutls_certificate_get_rawpk_keypair`. Do you agree that we should leave `gnutls_certificate_get_crt_raw()` the way it is now?

> This should be removed. We don't provide modify access to internal data, period.

I will change this

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