<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><span id="OLK_SRC_BODY_SECTION"><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Uri,<div class=""><br class=""></div><div class="">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.</div></div></div></blockquote></span><div><br></div><div>Copying there.</div><span id="OLK_SRC_BODY_SECTION"><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><font color="#000000" class="">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)?</font></div></div></blockquote></div><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class="">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.</div></div></div></div></div></blockquote></span><div><br></div><div>I see.</div><div><br></div><div>By any chance, do you happen to know if is this the </div><div><br></div><span id="OLK_SRC_BODY_SECTION"><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">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.</div></div></div></div></blockquote></span><div><br></div><div>:-)</div><div><br></div><span id="OLK_SRC_BODY_SECTION"><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">BTW, I know of no other users across the whole US Federal Government / Contractors having the issue you are describing here associated with Mail.</div></div></blockquote></span><div><br></div><div>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…</div><div><br></div><div><br></div><div><br></div><span id="OLK_SRC_BODY_SECTION"><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div><blockquote type="cite" class=""><div class="">On Oct 29, 2015, at 1:27 PM, Blumenthal, Uri - 0553 - MITLL <<a href="mailto:uri@ll.mit.edu" class="">uri@ll.mit.edu</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif;" class=""><span id="OLK_SRC_BODY_SECTION" class=""><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;" class="" type="cite"><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Uri,<div class=""><br class=""></div><div class=""><a href="https://bugreport.apple.com/" class="">https://bugreport.apple.com/</a></div><div class=""><br class=""></div><div class="">Send me the Radar #</div></div></div></blockquote></span><div class=""><br class=""></div><div class="">I submitted the problem, and got back this number: <span style="font-family: Helvetica, Arial, sans-serif; font-size: 20px; font-weight: bold; background-color: rgb(255, 255, 255);" class="">23316478</span></div></div></div></blockquote></div></div></div></blockquote></span><span id="OLK_SRC_BODY_SECTION"><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif;" class=""><div class=""> 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?</div><div class=""><br class=""></div><div class="">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)?</div><div class=""><br class=""></div><span id="OLK_SRC_BODY_SECTION" class=""><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;" class="" type="cite"><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class="">On Oct 29, 2015, at 11:38 AM, Blumenthal, Uri - 0553 - MITLL <<a href="mailto:uri@ll.mit.edu" class="">uri@ll.mit.edu</a>> wrote:<br class=""><br class="">Shawn,<br class=""><br class="">Wanted to make sure you see this. It looks like we have a decent idea<br class="">what’s wrong with Apple Mail: somehow it does not seem to pass the PIN on<br class="">subsequent request to sign outgoing emails, maybe believing that the card<br class="">stays “unlocked” for a while.<br class=""><br class="">This would explain why the 1st outgoing digitally signed email succeeds<br class="">practically always, the 2nd one - practically always fails, but if you<br class="">save the draft and restart Apple Mail - it again succeeds signing it<br class="">(because now Apple Mail treats the token as “fresh” and requiring<br class="">initialization & unlocking).<br class=""><br class="">Would it be possible for you to pass this info to appropriate people at<br class="">Apple who can get this issue looked into, and hopefully fixed???<br class=""><br class="">Thanks!<br class=""><br class="">P.S. I have logs from Thursby PKard.tokend that show the difference of a<br class="">successful signing (tokend gets a PIN-authenticate request, performs it,<br class="">and then proceeds with the bunch of signing work), and an unsuccessful<br class="">signing attempt (tokend gets a bunch of PIN-less requests, nothing else is<br class="">going on).<br class=""><br class="">On 10/26/15, 12:30, "<a href="mailto:uri@ll.mit.edu" class="">uri@ll.mit.edu</a>" <<a href="mailto:uri@ll.mit.edu" class="">uri@ll.mit.edu</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">Interesting. I'm seeing something similar on Yosemite, with CACKey 0.7.5,<br class="">also with PKard-1.6.3, also with PIV.tokend from SmartCardServices 2.0.2.<br class="">Which means the problem is likely with Apple Mail rather than with tokend<br class="">itself (in this particular case).<br class=""><br class="">It looks like Apple Mail "forgets" to ask user for a PIN and treats the<br class="">card as if unlocked - and all that tokend gets is a bunch of PIN-less<br class="">requests that it does not execute. After Apple Mail restarts, and with<br class="">this mail piece from the draft finally asks the user for his PIN - then<br class="">(usually) PIN is passed to the tokend and from it to the card, and email<br class="">(usually) gets signed and sent. (As we know, *each* signing request<br class="">*must* be PIN-authorized; the only way around it is if the app itself<br class="">caches the PIN and forwards it with the next requests.)<br class=""><br class="">So again, the problem appears to be between the app (Apple Mail) and the<br class="">tokend (most any, except for OpenSC.tokend that just does not work no<br class="">matter what).<br class=""><br class="">Which again underscores the need to somehow trace the communications<br class="">between Apple Mail and tokend.<br class=""><br class="">How do we get it from Apple???<br class=""><br class="">Alternatively, what is people's experience with MS Outlook 2011 and/or<br class="">Thunderbird?<br class=""><br class="">Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE<br class="">network.<br class="">Original Message<br class="">From: David Mueller<br class="">Sent: Monday, October 26, 2015 11:49<br class="">To: Fed Talk<br class="">Cc: Blumenthal, Uri - 0553 - MITLL<br class="">Subject: Re: [Fed-Talk] Help tracing access to keys/certificates?<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Oct 19, 2015, at 1:22 PM, Blumenthal, Uri - 0553 - MITLL<br class=""><<a href="mailto:uri@ll.mit.edu" class="">uri@ll.mit.edu</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">Was a frequent occurrence with Yosemite; haven’t spent much time with<br class="">El<br class="">Capitan yet to see if it’s still an issue.<br class=""></blockquote><br class="">I’m still on Yosemite.<br class=""><br class="">You’re saying maybe El Capitan would be better in that area?<br class=""></blockquote><br class="">So far I would say that it’s actually worse in El Capitan (including<br class="">10.11.1). Rather than getting an error, the message simply fails to send<br class="">and is left in my Drafts folder. Closing and reopening Mail still seems<br class="">to resolve an issue.<br class=""><br class="">One difference I’ve noticed is that after restarting Mail, I’m prompted<br class="">for the CAC PIN to send the signed email, whereas before it would simply<br class="">close the outgoing message. So it’s almost like it’s trying to use the<br class="">CAC without the PIN.<br class=""><br class="">I’m using CACkey 0.7.5.<br class=""><br class="">- David<br class=""></blockquote></blockquote><br class=""></div></div></div></blockquote></span></div></div></blockquote></div><br class=""></div></div></blockquote></span></body></html>