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: Mon, 24 Sep 2018 12:23:29 -0400
> > 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, I'm not sure I would call the name Keychain-PKCS11 misleading,
but fine; reasonable people can disagree on that. But I don't think
ctk-pkcs11 is any better, for two reasons: almost nobody knows what CTK
is, and it's also inaccurate as I don't actually make any calls to the
CryptoTokenKit framework.
> > 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?
Well, I guess I don't really view it as playing catch-up. My view would
be that it is solving a similar problem using a completely different
approach. I fail to see what is wrong with doing that. Also ... isn't
that kind of my decision to make?
>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?
Well, to answer your question ... I have no idea! We will see! Maybe
I'll get hit by a truck and die, maybe I won't have time to work on it.
Who knows? But as far as I can tell, me writing this code shouldn't
affect OpenSC at all; if OpenSC continues to be the best answer for you
or anyone else, then you should continue to use it!
> > 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.
I make no claim here to be solving the Smartcard problems of the
world; if people find this useful, then that's great. If they don't
find it useful, then that's too bad; there are other options that may
work better for them.
> > 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.
Well, I was thinking about the gap between the supplied support in the
Security framework and applications which don't support it, but do
support PKCS#11.
>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).
Again, that is fine! Obviously my primary focus is CAC support, and my
problem space is narrower. If you need things that don't work with the
Apple-supplied components, then this wouldn't be for you.
>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...?
Well, if I had a crystal ball that could predict what Apple was doing in
the future my life would be very different, that's for sure!
So, I don't know if things will be stable in the future. I will point
out that Apple has officially marked the CDSA as deprecated since 10.7,
which came out in 2011, so in theory developers should have had plenty of
time to migrate away from it. My hope is that the current API will remain
stable for a while, but if history is any judge Apple should support the
current API for a number of years even if they decide to abandon it.
That's one reason I was very careful to only use non-deprecated APIs
in this library.
I am encouraged that it seems like Apple is coalescing around a stable
plan for Smartcard support, and it seems like the "new API" (that's what
I've been calling it in my head) for accessing Smartcards fits into
the Security framework reasonably well. But again, I don't know what
the future will bring. It may be Mojave will render this library
completely obsolete; I hope that it doesn't, but we will see.
> > 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.
Well, I mean no slight at the OpenSC people, but part of my motivation
is that disabling the Apple-supplied Smartcard support is a tough
sell in some environments, like ours. And from what I read for the
documentation for OpenSCToken, your choices on using it are: 1) live
with it occasionally being deleted, or 2) install it by disabling system
integrity. That is a LARGE uphill battle to fight in some environments.
>I wonder if you do smartcard policy enforcement with Apple-provided
>"pivtoken".
Well, it depends on what you mean. If you mean key usage restrictions
like requiring that a key marked only for decryption ONLY be used for
decryption, then "yes" ... but that is actually handled by the Security
framework for me. If you mean something else, then if you could explain
in greater detail I would be glad to answer. Really, in terms of crypto
functions this library is a very skinny shim on top of the relevant
Security framework calls; nearly all of the complexity is implementing
various bits of PKCS#11 functionality.
>Also, FWIW, I found CAC driver to work better than PIV driver using CAC
>with Firefox Dev Edition...
Fair enough! FWIW, I have been testing my library with Firefox and I
believe it works pretty well with it.
>But PCSC-based code has been already written, and is maintained by
>others, so it's no skin off my back.
Again, that is totally fair; my concerns with that is I am worried that
it might be tough in some managed environments to replace the whole
Smartcard framework with a third-party one. But like I said, if my
approach doesn't pan out then of course there are other options.
> > 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?
The Security framework, yes. AFAIK, Chrome has always "just worked"
with the the old (CDSA) and new APIs. If you look through the Chrome
source code, you can see comments about how they are calling different
functions so they can work with multiple versions of the operating
system.
>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.
I was talking about the former; I realize we're kind of stuck with
apps that only implement the CDSA API. As far as I know, there is no
solution right for for these apps on High Sierra, right? I can only
say that judging by the comments in Chrome, the changes that are needed
to convert your app over to the newer API are not large, so hopefully
those applications will migrate at some point.
>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.
With respect to Acrobat ... I guess with my library I view it as still
accessing the certs via the Apple smartcard framework, just via a slightly
different method.
> >>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.
Well ... I'm not sure what else to say there. I mean, AFAICT the issue
seems to be some of the extra compilers installed on your system, and
it is possible to compile it on your system with the proper options.
I'm not sure if there is a good way to fix that.
> > 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).
I have no issue with people suggesting alternatives to software packages
on a public mailing list. But going on the issue tracker _for a software
package_ and suggesting an alternative ... well, I guess the politest thing
I can think of to say is that I was taken aback, to say the least.
--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