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

[Development of GNU's TLS library]

1.  Since the `key_file2` and `key_mem2` functions already have a flags parameter this can be done fairly easy I think. However, we would encounter the following issue: `gnutls_certificate_set_x509_key_mem2` expects a certificate structure in its `cert` parameter. If we pass our "raw pk" flag then we could simply extract the pub key and store it as a raw pk. So far so good. But what if we want to pass a subjectPublicKeyInfo directly into the `cert` param? First of all, the name of the parameter does not match that scenario. Secondly, how are we going to see the difference between a passed certificate and a passed subjectPublicKeyInfo? We would need an extra flag for that and add extra logic into this routine. The question is, do we want to add extra logic to this already fairly large routine? Also, if we merge `gnutls_certificate_set_rawpk_keypair_raw` into `gnutls_certificate_set_x509_key_file2` and `gnutls_certificate_set_x509_key_mem2` we still have `gnutls_certificate_set_rawpk_keypair` left which accepts the abstract `pubkey_t` and `privkey_t` types. Do we also want to merge this function into some existing function? If not, we only have one rawpk related API function. The raw pk functionality is then split across a dedicated new function and two already existing functions that handle x509 stuff. This might be confusing for library users. Also if we are considering conditional compilation of this feature it might be easier or more desirable to have a separate API to handle raw pk stuff instead of mixing it up with existing x509 routines.

So on one hand I think it would be nice to extend the x509 routines with an extra flag that tells the function to basically extract only the raw public-key portion from a certificate and store that. On the other hand I think we still need the new API to be able to handle raw public-keys directly. In other words, to be able to handle cases where a user inputs raw subjectPublicKeyInfo data instead of raw certificate data. You are right that I've currently only implemented functions to import raw pk data from memory. I can of course also create functions that are able to read this data from file. I think however that we should provide functionality for cases where users provide a raw pk credential via a certificate and for cases where they are provided directly. The latter case is currently provided. The former case can be build by following your flag proposal.

2.  Using TOFU is good idea I think. I can update the documentation to point (more explicitly) in that direction. Can you tell me what should be updated in this TOFU system? Should we included that update in this patch or fix it in a separate patch as it can be seen as a separate issue that improves raw pk authentication?
3.  As you can see one of my tests is failing in the CI (cross-mips image). I don't have a clue why since the same test succeeds locally and on all the other CI images. Could you explain to me what it can be that makes my test fail on this build?

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