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

Development of GNU's TLS library gnutls-devel at lists.gnutls.org
Fri Oct 19 21:33:57 CEST 2018


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

> Yes you can. We do it in our TLS Pool project (https://github.com/arpa2/tlspool).

I understand that some apps can do it. 

> Secondly, I understand your concern about giving users the power to enable features that the application was not developed for. With that in mind we can introduce a flag to be able to enable/disable rawpk functionality via an init flag. On the other hand, I don't see how a user can mess things up by setting certificate priorities? The system will only use credential types that are actually available and an application developer should check what type it receives and act accordingly. Do you have a specific scenario in mind which will break?

As long as this is a no-op unless one enables raw public keys in the application explicitly, it could work.

> In the end I think we should make a decision about whether or not to use an extra init flag. If we do, I need to figure out how to incorporate it into the code.

I think we should to protect apps which may not be ready for it.

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


More information about the Gnutls-devel mailing list