Re: [Opensc-devel] New port in MacPorts and question about TokenD

[David W. <dw...@in...>]

On Wed, 2016-09-28 at 08:28 -0600, Nathan Toone wrote:
> This is completely beyond my experience and knowledge - but does
> CommonCrypto (the apple-sanctioned crypto API to use instead of
> OpenSSL, for example) provide what is needed?

Maybe that's one option. But in addition to the "normal" TLS connection
with client certificates that CommonCrypto could provide, we *also*
need to support DTLS (TLS over UDP) with a pre-1.0 version of the DTLS
protocol Cisco are still using. The only libraries which support *that*
are OpenSSL and GnuTLS. And then only because I fixed them both to do
so :)

So we'd end up having to have a horrible hybrid of one crypto library
for the TLS connection, and another one for DTLS. Which actually we
*have* had for years but I'd *just* abolished it :)

And it's also been a horribly painful experience trying to get OpenSSL
and GnuTLS to Just Work™ with all the random certificates you're going
to encounter in the wild. Doing it all again for CommonCrypto doesn't
strike me as being a recipe for happiness, especially as I don't even
have an OSX test box to hand.

If somebody *really* wanted to step forward and promise to maintain a
CommonCrypto back end with feature parity, I might be inclined to allow
them. But I doubt it's something I'm going to embark upon myself.

I think we'd be much better off adding Keychain support to GnuTLS under
its "system keys" support, much as it has CAPI/CNG support on Windows.

Hell, you could basically cobble this together by hacking up my
existing TPM support in OpenConnect¹ and making it use the Keychain
functions like SecKeyRawSign()² instead of the Trousers TSS functions.

Forget the whole #ifndef HAVE_GNUTLS_CERTIFICATE_SET_KEY code block
from line 40-96. Nobody cares about versions that old any more.

So the tpm_sign_fn() function ends up basically just being a call to
SecKeyRawSign(), and the load_tpm_key() function just needs to find the
appropriate SecKey object in the (appropriate) Keychain, so it can be
used later in tpm_sign_fn(). How hard can *that* be? :)

cf. http://stackoverflow.com/questions/5767957/get-certificates-in-keychain

But now I look into it, it looks like these Keychain APIs are the
*same* as Jay's KeychainToken is using; I'm not sure it's so obsolete
after all. Perhaps homebrew/MacPorts/etc. should just be shipping
KeychainToken by default, enabled via a p11-kit module file, and then
keys in the token would just automatically be visible to well-behaved
*nix applications.



-- 
dwmw2

¹ http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/gnutls_tpm.c
² https://developer.apple.com/reference/security/1618025-seckeyrawsign