On Thu, 2019-03-14 at 11:33 -0700, David Woodhouse wrote: > On Thu, 2019-03-14 at 10:50 -0700, James Bottomley wrote: [...] > > > Although if you just wanted to use those keys with GnuTLS, you > > > could have done that directly. I already ported it all except the > > > new "importable" keys support. > > > > > > http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/g > > > nutls_tpm2_ibm.c > > > > Well, you know, using engines with gnutls does mean we don't have > > to write the same code twice over ... > > I'm not convinced that an OpenSSL ENGINE is the right form for > implementing this kind of thing in the general case. PKCS#11 is much > better as an existing portable standard, although it doesn't fit the > TPMv2 usage model very well. Actually, here I disagree: the faults in PKCS11 are why we have a problem and a boat load of not quite functional solutions: it has no key id API, so it can't take files, pkcs11: or any other URIs formats as an argument for a key operation. OpenSSL engines can do all of that and as evidence, the seamless construction of both a tpm engine and a p11-kit URI based engine. > Even OpenSSL is moving away from ENGINEs to a different plugin > mechanism. I'm not averse. My only objection is to the idea that the PKCS11 API is better than the existing engine one; it's a more widely accepted standard but it's not a better API. Although, Engines are by no means perfect as and API as our whining about the engine file selector problem shows. At least a newer plugin can finally solve the key identification problem and I think it will fit seamlessly into my current openssl-pkcs11-exporter. James _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
