Re: [Fed-Talk] CAC-Issues with Apple Mail since macOS 10.12.3 (Sierra)
Re: [Fed-Talk] CAC-Issues with Apple Mail since macOS 10.12.3 (Sierra)
- Subject: Re: [Fed-Talk] CAC-Issues with Apple Mail since macOS 10.12.3 (Sierra)
- From: Paul Nelson <email@hidden>
- Date: Tue, 25 Apr 2017 09:31:44 -0500
From the smart card user perspective, signing an e-mail shows the card holder intent with a high level of assurance and should take precedence over other factors when evaluating a message validity.
That said, mail clients usually treat all PKI credentials the same so the trust of a smart card credential (very very hard to clone) is treated the same as for a lower assurance “soft” certificate (easy to clone, steal, etc). Even if a government issued smart card is stolen and abused, the abuser would have access to the original e-mail account making the e-mail sender not useful. However, if a soft cert is stolen surreptitiously, e-mail can be sent from a different e-mail account and then the e-mail address of the sender would be an important indicator that something is wrong.
A real world example of this is the DoD/DISA Purebred derived credential. A Purebred credential is “derived” from a user’s CAC but has different policies so that software and users can tell it operates at a lower level of assurance (LOA). On an iOS device, the Purebred credential can be stored in an application’s keychain. Unless the user or enterprise properly resets an iOS device (that might trickle down from a high level command) the keychain credential remains even if the application is deleted and re-installed (you might consider this a bug, but it prevents user trauma if they accidentally delete an app). To be safe, the original Purebred credential should be revoked and the phone properly wiped. If this doesn’t happen the new user of the phone might be able to use the original Purebred credential without the knowledge of the original credential holder.
Since there is no really industry standard for how to mark the level of assurance of a credential in an X509 cert, Mail client software can’t make assumptions about the risks involved in validating a signed message.
Paul
Thursby Software Systems, Inc.
> On Apr 25, 2017, at 9:13 AM, Blumenthal, Uri - 0553 - MITLL <email@hidden> wrote:
>
> The issue is - what our who is the primary subject that the certificate "certifies", what are the other attributes, and whether they are all equally important from validation point of view (I claim they're not).
>
> Subject's Distinguished Name should be of primary importance (unless you're certain who created this email, there's no point in continuing). Second to it is the Issuer - as the whole point of certifications is having an entity you're willing to trust vouching for identities. Expiration DTG and validity...
>
> Email address(es) in my view of the world would come last - because (usually) I (and others) couldn't care less what email provider/account my correspondent used to get that S/MIME-protected piece of information to me. Some overzealous applications incorrectly elevate it to the primary identifier status. In an ideal world it wouldn't hurt. In reality, it often does (for two reasons: need to send from a different account, and Issuer goofs. Needles to say, I've seen plenty of both).
>
> The correct behavior, as has already been stated here, is to (a) validate the signature - abort if fails, (b) validate certificate chain - abort if fails, (c) compare email addresses - *inform* if they don't match (in some cases it may matter, in most cases it doesn't - and in any case it should be the user's decision).
>
> Regards,
> Uri
>
> Sent from my iPhone
>
>> On Apr 25, 2017, at 08:59, Lamb, John (NIH/NIDCD) [C] <email@hidden> wrote:
>>
>> Jason,
>>
>> It is not a dumb question at all. Since the email is encrypted using the public key of the recipient, and the recipient has the private key, it makes sense for the email to then be decrypted. In this instance, it is appropriate to also display that there is a mismatch in the signing certificate and the “from:” address.
>>
>> Thank you,
>>
>> John Lamb
>> Desktop Manager | NIDCD ISMB | LCG Contractor
>> National Institute on Deafness and Other Communication Disorders
>> 240-688-7017
>> email@hidden <http://email@hidden/>
>> http://www.nidcd.nih.gov
>>
>> On 4/24/17, 6:46 PM, "Levine, Jason (NIH/NCI) [E]" <email@hidden> wrote:
>>
>> I apologize for what might be a dumb question, but why would ANY email client successfully, or even want to, decrypt an email where the From: address is different from the address in the signing/encrypting certificate? This seems wrong on many levels.
>>
>> Jason
>>
>>> On Apr 24, 2017, at 5:37 PM, Basil Decina <email@hidden> wrote:
>>>
>>> Forgive the blast but don’t know if anyone has hit the following…
>>>
>>> 1) Apple Mail under macOS Sierra 10.12.4 (and previously 10.12.3) can’t easily open CAC-signed (or encrypted) e-mail if the sender (“From:”) address is different than the address that signed/encrypted the message (the address in the CAC PKI cert). It literally takes 30 minutes (I timed it) to view/open such messages. If I drag the message to Outlook under Windows (under VMware), it opens quickly. If I try to drag it to Outlook under macOS, it hangs Outlook.
>>>
>>> This is problematic with all new messages but also in re-building/re-indexing existing messages. (It took me over 400 hours to re-index my mailboxes — ouch!)
>>>
>>> I removed all my DoD Root CA certs and re-installed them — no luck.
>>>
>>> 2) Nested mailboxes are now “disappearing” from list. They are still in "~/Library/Mail/V4” but are no longer listed inside mail.app — they disappeared over a period of days/weeks.
>>>
>>> I think the two issues are related.
>>>
>>> Has anyone hit anything similar ?
>>>
>>> Thanks, Basil
>>>
>>> _______________________________________________
>>> 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
>> _______________________________________________
>> 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
>>
>> _______________________________________________
>> 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
> _______________________________________________
> 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
_______________________________________________
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