Re: [Fed-Talk] Beta version of "keychain-pkcs11" available
Re: [Fed-Talk] Beta version of "keychain-pkcs11" available
- Subject: Re: [Fed-Talk] Beta version of "keychain-pkcs11" available
- From: Ken Hornstein <email@hidden>
- Date: Sun, 23 Sep 2018 01:54:04 -0400
>My problems with this code are:
>It is misleadingly named “keychain-pkcs11”, while keychain interface is
>exactly what’s missing (and what’s not provided by anything else CTK-based);
Well, fair enough ... I think I mentioned that in the package README
that is on the GitHub web page. I freely admit that the name is not
great, but I am unable to come up with a better one.
>It is unclear what purpose this library serves: PKCS#11 library
>opensc-pkcs11.dylib from the OpenSC (also open source) package already
>does everything that this package can (signing documents with CAC
>and PIV, using SSH with smartcard, using OpenSSL-based apps with
>smartcard, etc. etc.), plus a lot more
Well, geez Uri ... I think I mentioned it was a work in progress?
But, okay, fair enough. Here's where I am coming from.
I have been watching on and off for a while now seeing varying levels of
Smartcard support on MacOS X. It seems like with every release of MacOS X
we newer know if things are going to get better, get worse, or stay the
same. Getting Smartcard support on MacOS X has involved a number of
various packages over the years.
But to be fair to Apple, they are usually pretty good about having
long-term support for their APIs. From what I've seen, _most_ (but not
all) applications I care about can load a PKCS#11 library. With
the release of High Sierra, there was pretty good included Smartcard
support, so I thought ... maybe there is a way to fill in the gap here?
So, my goal with this library is to provide a PKCS#11 interface that
uses all non-deprecated interfaces. My thinking was that if Apple
continues to support the new Security framework interface for Smartcard
support, a PKCS#11 bridge library should continue to work for future
MacOS X releases and applications that can load a PKCS#11 module would
be able to use Smartcards on MacOS X. And you could make this all work
without having to disable any Apple-provided functionality, so you
can use the included PIV support for things like system login, screen
unlock, and sudo.
>(like, decrypting - almost a
>complete PKCS#11 implementation, with C_KeyWrap support coming);
Well, like I said ... beta implementation? My thought was I'd put what
I was working on out there so people could take a gander at it. That's
one of the reasons I didn't provide binary packages; I wasn't ready for
that right now.
I wasn't going to mention it just yet, but SINCE you brought it up ...
the code I have in my local tree actually supports C_Encrypt and C_Decrypt,
and I tested it with Thunderbird and was able to decrypt S/MIME messages
using it. I wanted to actually make an installable package before I did
that, though.
>What
>OpenSC does not do (CTK-based “shim” for CDSA-based apps) - this
>library doesn’t do either. It is unclear whether it makes sense
>architecturally to implement PKCS#11 on top of CTK - layer-wise,
>shouldn’t it be the other way around? E.g., OpenSC implements PKCS#11
>and CDSA on top of PCSC, which seems a cleaner approach to layering.
Well, first off ... I know that people refer to CryptoTokenKit, but it
turns out you don't need to make any calls to the CryptoTokenKit APIs;
at least for me, all I do is make calls into the Security framework
(plus a few calls into LocalAuthentication).
But in terms of layering ... well, I guess what I was thinking is,
writing a whole PCSC layer is a lot of work, and has already been done.
Since Apple provides code which already talks to the card, writing
something which uses Apple-provided support seems like it's a more
stable long-term path. Also, it's less code.
>The current capability gap as I see it is: Current OpenSC.tokend
>provides the necessary functionality, but it uses deprecated CDSA - so
>it’s end of life is visible, maybe near (judging by the fact that
>Apple removed support for libstdc++ from Xcode-10). Current pivtoken
>and OpenSCToken (one Apple-provided, the other one is open source - but
>both are CTK-based) do not make the token accessible via CDSA, so they
>are useless for apps like MS Office and Google Chrome.
Well, FWIW, for me Google Chrome works perfectly fine out of the box,
without my library or any other support needed (I actually used what
it does to point me in the right direction).
Like you said, CDSA is clearly on the way out (I think it's been
deprecated since OS X 10.7), so having things that rely on it doesn't
make sense to me. And yes, I didn't provide a CDSA interface: that
explictly wasn't a goal for me.
>IMHO what's needed is a “bridge” between CTK provided by MacOS and
>CDSA that most of the non-Apple apps (MS Office, Google Chrome, Adobe
>CC,to name the more prominent ones) are still based on.
Well, I'm not sure what to do about Office, but at least for Chrome
AFAIK everything works fine, and Adobe Acrobat can use a PKCS#11 module
(that's one of the things I tested). I"m not sure how one could provide
a bridge between CTK and the older CDSA API; if people have ideas there
I'd love to hear them.
>P.S. I’ve opened an issue re. compiling under Xcode-10 on High Sierra
>on your GitHub page.
Yeah, I replied to it. But did you have to leave the snarky comment on
the OTHER issue that was reported? What the hell, man? What did I ever
do to you to deserve that?
--Ken
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden