Ridley, First - apologies for mis-attribution.  Regarding your points on NEO: true, it doesn't seem to be fully PIV-compliant‎ - but that shouldn't matter in the context of the problem I'm having/describing, because in that aspect at least (requirement to use PIN for every DSK operation) NEO is 100% conformant, as I've learned from my own experience.  So the problem is not that NEO would allow unprotected DSK operations forbidden by NIST (which BTW  NEO doesn't) - the problem is that OS X or Keychain API or PKard.tokend are trying to perform an unprotected DSK operation on NEO contrary to what PIV standard says.‎ I am trying to (a) figure out why, and (b) how to remedy this. I fully concur on the other Apple Mail problems you described. Seen/had those, and a bunch more. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.   Original Message   From: Disiena, Ridley (MSFC-IS60)[EAST] Sent: Friday, October 30, 2015 12:05 To: Blumenthal, Uri - 0553 - MITLL; Miller, Timothy J.; Paul Nelson Cc: Shawn A. Geddis; SmartCardServices-Users Subject: Re: [SmartcardServices-Users] [Fed-Talk] Help tracing access to keys/certificates? ‎ Since the Yubikey PIV applet has not been validated by NIST and no testing artifacts are available, I would not assume the applet is compliant. It could very well be to spec, just stating that without an audit trail that may be something that needs confirmed. Also, there are several generations of PIV, it is possible that it is an older PIV applet type with legacy specifications. The Yubikey page only specifies 800-73, it does not specify which generation. It does appear from the yubikey piv-tool documentation that the 9C DSK slot is set to PIN always, there should be a way to confirm that. Normally with card applets that have gone through NIST testing you can assume is working properly, not sure that is the case here. I can confirm Apple Mail with FIPS 201-2 compliant PIV card it does prompt for PIN on each DSK usage with PIV.tokend and OpenSC, I can't comment on the non-open source tokends. BTW, that workaround was not my suggestion, I have not seen the particular issue your are describing. I have seen numerous long standing issues with Apple Mail and signing and encryption. Sometimes the buttons for signing and encryption just stop functioning even though they appear, or sometimes they don't even appear, restarting the application can resolve it. Other issues are that intermittently messages are not properly shown as being an encrypted and or signed message despite being SMIME and having been decrypted; this can be hazardous since without inspecting the raw source a recipient has no idea that the message contents were encrypted and a reply will, by default, not be set to encrypt. Mail also defaults to SHA-1 for DSK signing with no option to request a higher algorithm, which is fortunate for PIV.tokend since it can't support higher than SHA-1. Even if you reply to a SHA-521 signed email, Mail only signs the reply with SHA-1, even if the tokend is capable of SHA-2 algorithms. In contrast Outlook will allow user control of the signing algorithm, although sending will fail if the algorithm is not supported by the tokend. Also, Mail incorrectly indicates opaquely signed messages are encrypted, when in fact they are only signed, they are just not in the legacy clear-text signing format. There are addition issues, those are just the top of my list. -Ridley Also, that attribution wasn't correct. On 10/30/15, 10:13 AM, "smartcardservices-users-bounces@lists.macosforge.org on behalf of Blumenthal, Uri - 0553 - MITLL" <smartcardservices-users-bounces@lists.macosforge.org on behalf of uri@ll.mit.edu> wrote:

Timothy,

The way I understand your response, if the card is recognized as a PIV token ?- then the "tokend framework" (whatever it is) should know to prompt for a PIN at every DSK operation, without any extra "nudging".

I am also using Paul's software (PKard.tokend), because I also need CAC support in addition to other (PIV) smart cards.

I am trying to understand why the tokend log? shows that the card is recognized as PIV, yet Apple Mail fails to sign any but the first outgoing email, and I have to resort to Ridley's work-around (hope attribution is correct) to send more than one signed email. The work-around is: uncheck "Sign", save in Drafts, restart Apple Mail, try again. This behavior suggests that somewhere in the system (tokend? Keychain API? Something else?) there's confusion about token's state - and the system "forgets" to prompt for a PIN before the next DSK operation.

I'd like to find out (if possible) what component is failing, and (more importantly) what can be done (especially by me) to alleviate this problem. ? Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. Original Message From: Miller, Timothy J. Sent: Friday, October 30, 2015 09:49 To: Blumenthal, Uri - 0553 - MITLL; Paul Nelson Cc: Shawn A. Geddis; SmartCardServices-Users Subject: RE: [SmartcardServices-Users] [Fed-Talk] Help tracing access to keys/certificates? ?

...

1. We know that at least some cards expect PIN at any Digital Signature private key operation. I don't know whether PKard.tokend is ready to accommodate those cards - and if it is, how it determines whether ?it needs to get the PIN again and pass it to the card, or the card considers itself still "unlocked" and doesn't need PIN again. Is it when the tokend classifies the inserted token as PIV? Maybe you could clarify this?

All PIV DSKs require the VERIFY APDU immediately prior to the DSK key operation. Key container access rule are pretty clearly spelled out in SP 800-73-4 Part 1. See table 4b. And yes, PIV.tokend supports these cards. I have two, and they work fine. (That said I personally use Paul's software 'cause I also have a CAC and need to use the GSC-IS model for some operations, so having a tokend that implements both models is muy convienient :).

See also NIST IR 7863, particularly the section on key caching. Paul's statement that PIV middleware must always collect the PIN for a DSK operation was the original intent of the spec, but has since been modified since it was found to be really inconvenient in practice.

...

2. Is there a mechanism by which I (as a user, or as a person who can write data objects to the card) could tell PKard.tokend or Keychain that a given PIV token requires new PIN for every digital signature private key operation? Is there anything on the card itself that would convey this message to PKard.tolend? And why doesn't it happen automatically as soon as tokend determines that the inserted token is PIV? ? See above. If you're using the DSK conditional element, it's required to be subject to the PIN-Always rule, which is enforced by the PIV card app, so there's nothing you should need to do at personalization other than populate the PIV card application with the right key reference value.

Also, while the CCC is a mandatory object, it's only there for GSC-IS interop. If you're not using the GSC-IS model, then the CCC can be empty *except* for the data model value. See SP 800-73-4 Part 1, Sec 3.1.

-- T