[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've been thinking about this and come to the following conclusion. First of all,

>  However, about certificate types, I cannot really write code which will work with any certificate type available,

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

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?

Whether we use an init flag or not, we still need certificate type priorities. Imagine for example that a user enables an RSA key exchange. We then have two possibilities to transmit the key material; 1) via a regular x509 certificate, 2) as raw public-key. We must be able to distinguish between these certificate types and negotiate which one we are going to use (via our cert type negotiation extensions). Therefore we must also be able to set our priority preferences. Do you agree?

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.

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