- SmartcardServices-Users - lists.macosforge.org

PIVKey t800
by Jorgensen, Will A 03 Dec '15

03 Dec '15

I have been testing with a PIVKey T800. Supposedly it works fine with the native drivers however it is not recognized. On El Capitan modifying the file so that it is recognized (as recommended by PIVKey) is a pain. My question is, is there a reason why we can’t include the PIVKey identifiers in the smart card services install so that everything just works in El Capitan? Please help me understand what I’m missing. Thanks. __________________________________________________ Will Jorgensen IT Engineer Desktop and Mobile Services Pacific Northwest National Laboratory I want to hear your feedback

2 1

Smartcard logon: password for Login keychain
by Vadim 01 Dec '15

01 Dec '15

Dear Yoann, thank you very much for this simple solution! >> I have setup smartcard logon on OS X Yosemite and now each time I login using smartcard I see pop up dialogue "messages agent wants to use the login keychain. Enter the password". >> I understand that the Login keychain is protected by user's password and usually is is opening by OS X with the password, but now OS X has no my password, it has only PIN for my smart card. >> Is there any solution not to use password to unlock Login keychain? >Yes, you can replace your keychain password by your PIN code. It’s not >a good practice in terms of keychain protection but it will >automatically unlock it at the logon time. >Cheers, >Yoann Best regards, Vadim

1 0

Smartcard logon: password for Login keychain
by Vadim 01 Dec '15

01 Dec '15

Hi all, I have setup smartcard logon on OS X Yosemite and now each time I login using smartcard I see pop up dialogue "messages agent wants to use the login keychain. Enter the password". I understand that the Login keychain is protected by user's password and usually is is opening by OS X with the password, but now OS X has no my password, it has only PIN for my smart card. Is there any solution not to use password to unlock Login keychain? Best regards, Vadzim Khrasko

2 1

Re: [SmartcardServices-Users] [Fed-Talk] Help tracing access to keys/certificates?
by Blumenthal, Uri - 0553 - MITLL 31 Oct '15

31 Oct '15

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

7 8

Re: [SmartcardServices-Users] [Fed-Talk] Help tracing access to keys/certificates?
by Blumenthal, Uri - 0553 - MITLL 30 Oct '15

30 Oct '15

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(a)lists.macosforge.org on behalf of Blumenthal, Uri - 0553 - MITLL" <smartcardservices-users-bounces(a)lists.macosforge.org on behalf of uri(a)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 >

2 1

Re: [SmartcardServices-Users] [Fed-Talk] Help tracing access to keys/certificates?
by Blumenthal, Uri - 0553 - MITLL 30 Oct '15

30 Oct '15

Paul, You don't have to convince me that this stuff is hard. :-) Let's see if we can shed some light on the following immediate practical questions. 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? 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? 3. Assuming PKard.tokend "knows" to need to prompt for the PIN every time, how to make sure Keychain API (and whatever application that uses it) also knows it? And is this even necessary? Or does tokend framework and therefore PKard.tokend keep track of such things, and "figures" whether to prompt the user for a PIN when a digital signature operation is requested from it, without the application being aware of this PIN-prompt interaction? 4. My logs show that with CCC written to NEO, PKard.tokend recognizes this token as PIV. Yet it prompts for a PIN only at the first digital signature request - and subsequent ones do not result in a PIN prompt but rather in an error with the certificate. To actually sign the next email I have to save it in Drafts, close and restart Apple Mail - and then this email will be successfully signed (prompting me for a PIN, of course) and sent. I have to repeat the above dance for the next outgoing digitally signed email... Perhaps you could suggest how to remedy this problem, or at least how to debug it, tracing this issue down to its actual culprit? Thanks! Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. From: Paul Nelson Sent: Thursday, October 29, 2015 16:53 To: Blumenthal, Uri - 0553 - MITLL Cc: Shawn A. Geddis; SmartCardServices-Users Subject: Re: [SmartcardServices-Users] [Fed-Talk] Help tracing access to keys/certificates? Uri, The Tokend framework provides methods for creating access control rules that get associated with objects on a smart card. These rules do (or should) match the intent of the card specification. For example, a CAC only requires a PIN to be sent to the card once before using any private key or reading certain data objects. The card will keep track of its “unlocked” state until the card is powered off. A PIV card and its specifications has different access control rules for its digital signature private key. The card requires the pin to be sent to the card before each APDU using the digital signature private key. It was intended by the PIV spec that the user enter their PIN each time they use the digital signature private key but the language is not specific and the NIST derived credential SP only states that a user needs to take a specific action in order for the private key to be used (that is hard to implement). However, the other private keys and data objects only require the PIN to be sent only once. In reality, smart cards have more than one PIN (see ISO7816-4 7.5.1). A second pin might be used to reset the user pin etc. The challenge for Tokend developers is to try to map the Keychain CSSM objects and acls to the card specification. Unfortunately they don’t always match up, particularly when it comes to the details of when a user must/should enter a PIN. Saving the PIN (caching it) inside the Tokend memory can avert these issues but will break the intention of the card applet designer. There are API for locking and unlocking a keychain but the Tokend must take care to implement what it means be locked or unlocked. Since Tokend is a private framework, you need to study the source code carefully to see how CSSM works. This stuff is hard to figure out and you generally won’t find help from Apple. Paul Thursby Software Systems, Inc. On Oct 29, 2015, at 3:19 PM, Blumenthal, Uri - 0553 - MITLL <uri(a)ll.mit.edu> wrote: 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. Shawn, could you please clarify for me what “Cached PIN” means in the context? Does it mean that the Keychain API assumes that once it passed the PIN to the tokend, either tokend keeps (“caches”) the PIN for a while, or the token itself stays “unlocked” for a while upon receiving the correct PIN? Who decides how long that “for a while” lasts? Is there a mechanism by which tokend can inform Keychain API that the “cached for a while” is over and PIN must be re-entered? How does tokend know whether the token expects a new PIN, or is happy with being unlocked “a while ago”? Thanks! _______________________________________________ SmartcardServices-Users mailing list SmartcardServices-Users(a)lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/smartcardservices-users ‎

2 1

[Fed-Talk] Help tracing access to keys/certificates?
by david.lloyd＠fsmail.net 30 Oct '15

30 Oct '15

Hi, Paul wrote: "Unfortunately they don’t always match up, particularly when it comes to the details of when a user must/should enter a PIN. Saving the PIN (caching it) inside the Tokend memory can avert these issues but will break the intention of the card applet designer." In general as an application author, it is necessary to ensure that any call to a smart card can require that a PIN be re-entered. Almost any event can cause a smart card to be suddenly locked. In practise this isn't always the case with third-party apps - have you considered a mode where you report yourself as a TYPE-II reader and perform the PIN prompt from within the drier stack rather than hoping that the application can handle the GUI display? This is how Windows handles the situation - the CSP pops up PIN prompts, not the application. Regards, David

1 0

Building the piv.tokend project
by david.lloyd＠fsmail.net 30 Oct '15

30 Oct '15

Hi, I was asked for some pointers on building the PIV.tokend project… (1) Check out the code svn checkout https://svn.macosforge.org/repository/smartcardservices (2) Launch Xcode and open trunk/Tokend.xcodeproj Switch from World to PIV (3) Build the code - choose “Update to recommended settings: (4) Open the build settings for Tokend: - switch C++ Standard library to: stdc++ (GNU c++) (5) Create the SecurityPieces/Frameworks directory and link to OpenSC.tokend/build get the OpenSC.tokend source code - note the frameworks in the build directory git clone https://github.com/OpenSC/OpenSC.tokend.git mkdir /usr/local/SecurityPieces/Frameworks ln -s Frameworks to OpenSC.tokend/build (6) Build again Token.h line 189 rename one of the two hKeys to something else. (7) Linking: rename tokend.framework/toked_debug to tokend …so that the linker finds it, or figure out why this happens! (8) Copy output PIV.tokend/Contents/MacOS/PIV_debug over /Library/Secuity/tokend/Contents/MacOS/PIV Job done! Hope that helps...

1 0

Re: [SmartcardServices-Users] [Fed-Talk] Help tracing access to keys/certificates?
by Blumenthal, Uri - 0553 - MITLL 29 Oct '15

29 Oct '15

>> 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. Shawn, could you please clarify for me what “Cached PIN” means in the context? Does it mean that the Keychain API assumes that once it passed the PIN to the tokend, either tokend keeps (“caches”) the PIN for a while, or the token itself stays “unlocked” for a while upon receiving the correct PIN? Who decides how long that “for a while” lasts? Is there a mechanism by which tokend can inform Keychain API that the “cached for a while” is over and PIN must be re-entered? How does tokend know whether the token expects a new PIN, or is happy with being unlocked “a while ago”? Thanks!

2 1

Re: [SmartcardServices-Users] [Fed-Talk] Help tracing access to keys/certificates?
by Blumenthal, Uri - 0553 - MITLL 29 Oct '15

29 Oct '15

> 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(a)ll.mit.edu> >> wrote: >> >>> Uri, >>> >>> https://bugreport.apple.com/ >>> >>> 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(a)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(a)ll.mit.edu" <uri(a)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(a)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 >>> >

1 0