Uri,

BTW, this conversation should have gone through the SmartCardServices-User / SmartCardServices-Dev Mailing Lists to enlighten everyone at once rather than simply between the three of us.

Copying there.
Shawn, how do I check and/or affect the policies on a given keychain wrt. enforcing PIN re-entering upon every operation (or ideally, every signing operation)?

Ultimately, this is enforced by the corresponding Tokend, but by specification should come from the applet on the card.  This has long been a problem with applets used on US Government cards not properly providing policies like this, so Apple had to take an approach of defaulting to allowing “Cached PIN” if not defined.  So, in the case of the PKard.tokend, Thursby would either need to allow users to define a policy, obtain a policy from the card’s applet or take a default stand (such as ‘cache PIN by default) if policy (ACLs) not provided/found on card.

I see.

By any chance, do you happen to know if is this the 

Again, this has been an across the board problem with lack of definition on US Gov cards with the Gov’t expecting the middleware to “do the right thing” which of course they change on a whim, unfortunately.

:-)

BTW, I know of no other users across the whole US Federal Government / Contractors having the issue you are describing here associated with Mail.

To the best of my knowledge, most of the Feds :) use MS Outlook – either whatever version runs on Windows, or Outlook 2011 (or whatever was the previous one) on Mac. So the problem wouldn’t manifest itself – in my experience Outlook 2011 was able to sign outgoing several emails in a row, prompting me for the PIN every time, and signing smoothly without a hitch…



On Oct 29, 2015, at 1:27 PM, Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu> wrote:

Uri,


Send me the Radar #

I submitted the problem, and got back this number: 23316478
 Thanks for the explanation – so the problem is not between an application and tokend, but between Keychain API and tokend. Is there a way to look deeper into that exchange? Some more detailed logging?

How do I check and/or affect the policies on a given keychain wrt. enforcing PIN re-entering upon every operation (or ideally, every signing operation)?

On Oct 29, 2015, at 11:38 AM, Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu> wrote:

Shawn,

Wanted to make sure you see this. It looks like we have a decent idea
what’s wrong with Apple Mail: somehow it does not seem to pass the PIN on
subsequent request to sign outgoing emails, maybe believing that the card
stays “unlocked” for a while.

This would explain why the 1st outgoing digitally signed email succeeds
practically always, the 2nd one - practically always fails, but if you
save the draft and restart Apple Mail - it again succeeds signing it
(because now Apple Mail treats the token as “fresh” and requiring
initialization & unlocking).

Would it be possible for you to pass this info to appropriate people at
Apple who can get this issue looked into, and hopefully fixed???

Thanks!

P.S. I have logs from Thursby PKard.tokend that show the difference of a
successful signing (tokend gets a PIN-authenticate request, performs it,
and then proceeds with the bunch of signing work), and an unsuccessful
signing attempt (tokend gets a bunch of PIN-less requests, nothing else is
going on).

On 10/26/15, 12:30, "uri@ll.mit.edu" <uri@ll.mit.edu> wrote:

Interesting. I'm seeing something similar on Yosemite, with CACKey 0.7.5,
also with PKard-1.6.3, also with PIV.tokend from SmartCardServices 2.0.2.
Which means the problem is likely with Apple Mail rather than with tokend
itself (in this particular case).

‎It looks like Apple Mail "forgets" to ask user for a PIN and treats the
card as if unlocked - and all that tokend gets is a bunch of PIN-less
requests that it does not execute. After Apple Mail restarts, and with
this mail piece from the draft finally asks the user for his PIN - then
(usually) PIN is passed to the tokend and from it to the card, and email
(usually) gets signed and sent. (As we know, *each* signing request
*must* be PIN-authorized; the only way around it is if the app itself
caches the PIN and forwards it with the next requests.)

So again, the problem appears to be between the app (Apple Mail) and the
tokend (most any, except for OpenSC.tokend that just does not work no
matter what).

Which again underscores the need to somehow trace the communications
between Apple Mail and tokend.

How do we get it from Apple???

Alternatively, what is people's experience with MS Outlook 2011 and/or
Thunderbird?

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE
network.
Original Message
From: David Mueller
Sent: Monday, October 26, 2015 11:49
To: Fed Talk
Cc: Blumenthal, Uri - 0553 - MITLL
Subject: Re: [Fed-Talk] Help tracing access to keys/certificates?


On Oct 19, 2015, at 1:22 PM, Blumenthal, Uri - 0553 - MITLL
<uri@ll.mit.edu> wrote:

Was a frequent occurrence with Yosemite; haven’t spent much time with
El
Capitan yet to see if it’s still an issue.

I’m still on Yosemite.

You’re saying maybe El Capitan would be better in that area?

So far I would say that it’s actually worse in El Capitan (including
10.11.1). Rather than getting an error, the message simply fails to send
and is left in my Drafts folder. Closing and reopening Mail still seems
to resolve an issue.

One difference I’ve noticed is that after restarting Mail, I’m prompted
for the CAC PIN to send the signed email, whereas before it would simply
close the outgoing message. So it’s almost like it’s trying to use the
CAC without the PIN.
‎
I’m using CACkey 0.7.5.

- David