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: "Miller, Timothy J." <email@hidden>
- Date: Mon, 24 Sep 2018 13:30:43 +0000
- Thread-topic: [Fed-Talk] Beta version of "keychain-pkcs11" available
PKCS#11 modules are often just compatibility layers between an application and
a cryptomodule. Having no crypto or key management functions itself, that kind
of module is outside of the scope of FIPS 140.
-- T
On 9/24/18, 7:58 AM, "Fed-talk on behalf of Rowe, Walter (Fed)"
<fed-talk-bounces+tmiller=email@hidden on behalf of
email@hidden> wrote:
CTK is FIPS validated. If you make a ctk-pkcs11, does it imply that your
CDMA access is also FIPS validated when it is not? Does it need a disclaimer
that this is purely for compatibility purposes and does NOT meet FIPS
requirements because it has not been
evaluated?
Walter
--
Walter Rowe, Acting Chief
Infrastructure Services Division
Office of Information Systems Mgmt
NIST / US Department of Commerce
Email: email@hidden <mailto:email@hidden>
Office: 301.975.2885
Mobile: 202.355.4123
On Sep 23, 2018, at 11:45 PM, Blumenthal, Uri - 0553 - MITLL
<email@hidden> wrote:
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).
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
https://na01.safelinks.protection.outlook.com/?url=https://lists.apple.com/mailman/options/fed-talk/walter.rowe%40nist.gov&data=02|01|email@hidden|abd6859255494350638c08d621d040b1|2ab5d82fd8fa4797a93e054655c61dec|1|0|636733575668200396&sdata=P+syg4CQGQGSJaw5D4x2KJG2jwNgPQCujQ+RhlObjzE=&reserved=0
This email sent to email@hidden
_______________________________________________
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