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: "Blumenthal, Uri - 0553 - MITLL" <email@hidden>
- Date: Mon, 24 Sep 2018 03:45:27 +0000
- Thread-topic: [Fed-Talk] Beta version of "keychain-pkcs11" available
> >It is misleadingly named “keychain-pkcs11”, while keychain interface is
exactly what’s missing...
>
> I think I mentioned that in the package README...
You certainly did. But that doesn't make it any better.
> I freely admit that the name is not great, but I am unable to come up
with a better one.
How about "ctk-pkcs11", for starters? While admittedly not great, at least it
does not mislead the reader.
> Well, geez Uri ... I think I mentioned it was a work in progress?
I'm questioning whether it's wise to play catch-up when another open source
project with strong community support is doing quite well?
> 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 never 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.
Yes. For the last 2-3 years OpenSC has been the best from what I've seen,
topping the competitors in (a) the spectrum of capabilities it provides, and
(b) the community support/maintenance it gets. I've tried several commercial
and open source packages, and in the end returned to OpenSC. Are you sure
you'll have time to maintain and enhance your library?
> From what I've seen, _most_ (but not all) applications I care about
> can load a PKCS#11 library.
I wish I could say the same.
> 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?
Not sure what you mean here.
Yes, "pivtoken" isn't bad. I haven't used it extensively, and it failed me with
ECC tokens a year or so ago (no, not on High Sierra), but for CAC it was
reasonable.
The problem for me is supporting CAC *and other tokens*, for apps that may *or
may not* allow PKCS#11 interface (and that may or may not support CTK or
Security framework).
> So, my goal with this library is to provide a PKCS#11 interface that
> uses all non-deprecated interfaces.
Non-deprecated for the near future - until Apple decides otherwise...
> 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.
OK, fair enough. Though who's to say that the new Security framework won't
follow the way of CDSA? You may recall that Apple used to supply tokend with
Mac OS X, then they stopped, and then they began providing it again (starting
with Mavericks? Sierra? I don't recall). How long till they stop providing it
again...?
> 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.
That's a good point, though wrt. Apple-provided functionality I don't care
either way. At this time I'm getting it via tokend.
I wonder if you do smartcard policy enforcement with Apple-provided "pivtoken".
Also, FWIW, I found CAC driver to work better than PIV driver using CAC with
Firefox Dev Edition...
> Well, like I said ... beta implementation?
OK, fair enough. I guess I'm spoiled in this area by packages that are already
mature.
> 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.
That's good to know.
> 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).
Thanks, good to know.
> 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.
True. And having to maintain less code is good.
But PCSC-based code has been already written, and is maintained by others, so
it's no skin off my back.
> 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).
Very interesting. You are saying that the current Chrome has already adopted
either CTK or Security framework?
> 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.
If you mean "it doesn't make sense to write new code that depends on CDSA",
then I of course agree. But if you mean "having apps that still rely on CDSA
doesn't make sense...", I can only say that we've no escape from MS Office, and
it's unclear when it would switch to CTK.
>>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.
Alas, if I knew how to do that, I'd either modify tokend myself, or asked
others for help implementing it. I can only lament the lack of the capability
here, and hope that somebody can find a way to address it.
Yes Acrobat can use a PKCS#11 library, though I think accessing all the certs
via one method is better. It was an unexpected good news to me that Chrome
works fine as-is. Office remains the biggest commercial app suite that requires
CDSA.
>>P.S. I’ve opened an issue re. compiling under Xcode-10 on High Sierra
>>on your GitHub page.
>
> Yeah, I replied to it.
I can't say that I'm happy with that response.
> But did you have to leave the snarky comment on the OTHER issue that was
reported?
I merely suggested a *working and tested* alternative solution for the problem
the poster apparently had (and possibly still having, since the issue is not
closed).
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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