Re: New port in MacPorts and question about TokenD

Replying to this separately as it's a bit of a digression, but still
related...

On Wed, 2016-09-28 at 06:34 +0000, Martin Paljak wrote:
> For some reason (IMHO) it feels like MacPorts is more about things
> that don't integrate with OSX that deeply (unlike the standard
> .pkg/.dmg interface) and thus only to provide PKCS#11 and command
> line tools by default.

OK, so how *should* this work. Let's take the specific example of
OpenConnect, my VPN client. I try to make sure it works for everyone —
on Linux platforms it Just Works™ if you provide a RFC7512 PKCS#11 URI
in place of a filename for a certificate/key, and on Windows there's a
similar string format to identify certificates in the Windows
certificate store (and the GUIs make that work nicely).

OSX is... problematic. I'd love to be able to use certificates from the
Keychain, but I don't know how. I was trying to help a user only last
week who had a key in the Keychain and was trying to make OpenConnect
work.

So you're right. It doesn't integrate with OSX that deeply, and it only
provides PKCS#11. That much I already knew.

But how do I *fix* it? 

I'm aware of https://github.com/slushpupie/KeychainToken which exposes
the Keychain via PKCS#11, and I could attempt to work with that, but
it's basically a dead project and I understand it's not likely to work
with recent versions of OSX. Although Jay has kindly said he's¹ willing
to relicense if we need to import parts of that code into some other
project in some form, which might be useful.

Should there be an OpenSSL ENGINE and/or GnuTLS support for talking
directly to the OSX Keychain? GnuTLS has that support for Windows
system keys and I believe there's an OpenSSL CAPI engine somewhere.

I *want* to make your statement above untrue, at least for OpenConnect.
But I have *no* idea how.


If KeychainToken can be made to work, perhaps that's the way forward.
MacPorts can basically work like other *nix platforms and do it based
on PKCS#11. On Linux we load p11-kit-proxy.so as the default PKCS#11
provider (or directly use libp11-kit to load all the right tokens).

So if we configure p11-kit to indicate that KeychainToken should be
loaded, then well-behaved applications would mostly Just Work.

-- 
dwmw2

¹ I made an assumption there because the language forced me to choose
  a pronoun, and I went with the most likely one. Sincere apologies if
  I got it wrong.

------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensc-devel