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

[Development of GNU's TLS library]

Nikos Mavrogiannopoulos 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`.

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

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?

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