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

Development of GNU's TLS library gnutls-devel at lists.gnutls.org
Tue Nov 27 14:41:36 CET 2018

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

> + * to prove the authenticity of this key. The keypair can be used during
> + * a TLS handshake but its authenticity should be established via a
> + * different mechanism (e.g. TOFU or known fingerprint).
> + *
> + * The supported formats are basic unencrypted key, PKCS8, PKCS12,
> + * and the openssl format and will be autodetected.
> + *
> + * If the raw public-key and the private key are given in PEM encoding
> + * then the strings that hold their values must be null terminated.
> + *
> + * Key usage (as defined by X.509 extension ( can be explicitly
> + * set because there is no certificate structure around the key to define
> + * this value. See for more info gnutls_x509_crt_get_key_usage().
> + *
> + * Note that, this function by default returns zero on success and a
> + * negative value on error. Since 3.5.6, when the flag %GNUTLS_CERTIFICATE_API_V2

We could do that but users can not get the old behaviour back. Is that what we want? I think it is consistent with all other API functions to return an error code. Only the certificate setters deviate from that by optionally returning an index. Do we really want to change the default behaviour? I would say, let users decide by setting the API flag. What do you think?

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

More information about the Gnutls-devel mailing list