[gnutls-devel] GnuTLS | tpm: Try to use password from the PIN callback if srk_password is NULL (!796)

[Development of GNU's TLS library]

If there aren't any other tools out there that are affected by the behavioral change in how the PIN callback is invoked, I think it wouldn't matter. People now just have to make sure to unset GNUTLS_PIN when using a well known SRK password, which is the behavioral change for certtool.

I have a test case for all of this in the `swtpm` project but tpmtool and certtool are invoked by the tools there rather being explicitly on the command line: https://github.com/stefanberger/swtpm/blob/master/tests/test_samples_create_tpmca

I could try to build a similar test case derived from this for GnuTLS where we could set up `tcsd` (TrouSerS) to talk to `swtpm` over a socket and tpmtool creating keys and certtool doing operations with the keys. Then vary what passwords we are using.

FYI: There's one more problem that I am aware of and haven't been able to fix (and haven't filed a bug for). It's related to a new key's password. Basically one has to supply two passwords when creating a key, one for the SRK and one for the key itself (child of SRK). However, when one creates the key, the SRK password is needed and then somehow the two passwords get mixed up. So I end up having to use the same password for the key and the SRK. It could be a tcsd design issue where the passwords are put into a cookie jar and the first password is taken out when a password is needed and then when another password is needed the next cookie is taken out... Somehow the passwords are not properly associate with the intended keys. So I end up always using --register with tpmtool, which doesn't need that key password but only the SRK password.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/796#note_116247776
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/20181110/943f927b/attachment.html>