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

[Development of GNU's TLS library]

Tom commented on a discussion on doc/cha-gtls-app.texi:

>  (i.e. different for the client than for the server).
>  
>  Currently supported types are:
> -CTYPE-X509 or CTYPE-X.509. Catch all is CTYPE-ALL.
> +CTYPE-X509 or CTYPE-X.509, CTYPE-RAWPK or CTYPE-RAWPUBKEY. Catch all is CTYPE-ALL.

I propose the following. RFC7250 dictates that the certificate type negotiation extensions will only be sent when non-trivial cert types are set. That means other cert types than the default x.509 type. So this ensure safe default behaviour. We have currently implemented an extra check that toggle these extensions explicitly. This is not necessary anymore when we toggle specific certificate type related functionality via dedicated flags. For example, we can introduce a `GNUTLS_ENABLE_RAWPK` init flag that toggles whether raw public keys are enabled or not. Even if a user sets the rawpk cert type via the priority strings they will simply be ignored if the init flag is not set. That way the cert type extensions function according to spec but we still have the power to enable/disable specific functionality as an application developer. Looking at my next patch that introduces kerberos authentication we can do the same with a `GNUTLS_ENABLE_KDH` flag for example.

To summarize, I would propose to drop the `GNUTLS_ENABLE_CERT_TYPE_NEG` flag in favor of dedicated functionality specific flags such as `GNUTLS_ENABLE_RAWPK` and such. These latter flags will then toggle which cert types will be allowed and which should be ignored during the handshake.

What do you think about this? Also, can we remove the `GNUTLS_ENABLE_CERT_TYPE_NEG` flag and remain ABI compatible? Or don't we really care since this flag is so new that it is probably not being used ATM?

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