[Fed-Talk] Re: Root Cert on MacBookPro Question
[Fed-Talk] Re: Root Cert on MacBookPro Question
- Subject: [Fed-Talk] Re: Root Cert on MacBookPro Question
- From: Paul Derby <email@hidden>
- Date: Wed, 30 Dec 2009 16:38:25 -0500
On Dec 30, 2009, at 3:03 PM, email@hidden wrote:
> Paul Derby wrote:
>
>> They have these "split" certs one for signing, another for encryption. OS X Mail app recognizes when a signing cert is present, but aborts when the user tries to encrypt.
>
> Again, this is *very* likely because of email address matching issues with Mail.app. Because DoD does not have an enterprise email solution, changes in assignment cause changes in the user's email addresses. DoD components also have the unfortunate tendency to periodically change their email address naming schemes, which doesn't help matters any.
Our challenges are with DoE, not DoD. The problem isn't email name/case matching but the separate signing and encryption certs. Most of the DoE people we deal with don't realize they have two certs and that THEY have to send along the encryption public key if they expect an encrypted message back. Totally confusing to our users on both ends. Whomever the IA/ISSO/security wonk is that decided to enforce split certificates has caused huge amounts of confusion amongst the users we deal with and due to this confusion people tend to avoid encrypting because they can't cope with the challenge of certificate usage on either OS X or Windows XP.
>
> Keeping user certificates in sync with these changes has proven difficult, and is a small part of why the DoD PKI CRL has grown to unreasonable size. Microsoft provides a capability where the email address matching rules can be relaxed in Outlook (this is allowed by the S/MIME RFCs), but Apple and Mozilla (and Lotus and pretty much everyone else implementing S/MIME) do not.
>
> The solution, however, is not in the PKI or in the mail client. The solution is for DoD to get its collective act together and deploy an enterprise email capability, even if it's only a big honkin' forwarder and directory service. This is, I'm happy to say, well underway for Army and Air Force, and starting to happen for the DoD as a whole.
Glad the DoD is doing this. The Federal Government needs to become ONE ENTERPRISE instead of Federal stovepipes. We deal primarily with DoE (National Labs) and DHS. The DHS PIV cards are DHS's way to do what the DoD does with their CAC card. Why the Federal Government needs to call the same thing two different names is part of the confusion. DHS is trying to roll out their PIV card and the underlying support for encryption and digital signatures with Entrust, but the deployment isn't well thought out at all. Just this morning I had to disable Entrust on a Windows XP machine because DHS pushed it out before providing the user with a smart card reader or a PIV card to put in the reader. So when others that have PIV cards and readers send her signed email, Outlook brings up the Entrust interface and the user can't do anything but get frustrated and ask for help.
>
>> That is really tough to debug and the error message that gets generated is pretty worthless.
>
> True. But this is true of many applications and systems for many different things, not just PKI. Microsoft's quintessential "An error has occured while creating an error report" (yes, 'occurred' is misspelt) message comes to mind, but UNIX systems aren't immune to useless error logging either.
Of course UNIX and Windows XP have cryptic, hard to interpret error messages. That's why we push to use OS X on Macs so the user can USE the computer, not FIGHT the computer. And if there is an error, the user expects a user friendly error message when they use OS X. When they user Unix and Windows XP, they expect to be confused and have to call in desk top support.
>
>> In XP you can specify which cert you wish to use. In OS X you can't without getting into terminal mode or messing around exporting and importing to get the order "right" for OS X.
>
> This only an issue at signing if you have more than one *valid* certificate issued with the digital signature key usage bit set for the same sender's email address, or when a recipient has more than one *valid* certificate with the key encipherment or key agreement key usage bits set for the same email address.
>
> While this happens, it's very rare, and is usually the result of an organization trying to use the same S/MIME identity with an internal-only PKI *and* an external-only PKI (e.g., corporate certs for internal use, and Verisign certs for external use, but the same email address in both). This is basically a misunderstanding of the nature of the S/MIME identity being asserted in an S/MIME certificate, and while I grant you that the average user won't understand the difference, the people who deployed such a frankentecture should have known better.
It may be rare in the Mitre environment, but it is common in our environment to have two external issued certs. In the last 2 months we've had to reissue certs to everyone on our project because the CA that issued the certs (Thawte) decided to get out of the cert business and declared all our certs invalid. So for the better part of the upcoming year we have people with 2 certs from twodifferent CAs. WIth OS X it is too much for the user to figure out how to make the second issues, replacement cert the default cert. The implementation in OS X of defaulting to the first installed valid cert really causes user confusion when a second cert is installed and should be used, but the first cert needs to stay on the machine so email can still be decrypted. Users can't cope with this situation, so it falls back on the IT support staff to unravel the mess. Support staff can handle a hand full of users, but not for a large number of users.
>
>> I wish Apple would put some energy into getting cert support up to par with the rest of OS X.
>
> I couldn't agree more.
>
> I will say, however, that IMHO Apple got some PKI UI elements right. The Keychain key storage model is relatively intuitive, and visual cues between trust anchors and non-trust anchor certificates that are very helpful.
>
> Past these, however, security UIs in general are pretty awful, but Apple's not alone here; Mozilla's PSM isn't any better, and Microsoft's abortion of a key storage and handling UIs are better left undiscussed.
>
> I continue to hope for programmers to take a page from the InfoCard UI in Windows and apply the card metaphor to certificates, but so far this has been in vain.
Let me also give KUDOS to Apple for what they've done so far. My post wasn't to criticize what they have done, but to encourage what they should do. Apple has never used Unix variants and Microsoft Windows as their goal for usability, but instead created the best implementation for the others to follow and mimic. Let's hope Apple defines the best user interface and user experience for certificate management and use, too.
>
>> It will also be nice when certs are ubiquitous so that we can lock down receiving email that isn't signed by a white listed sender. That would eliminate most SPAM.
>
> That would be no more effective than whitelisting senders without signatures unless you're also willing to also manage a corresponding whitelist of sender *keys*. The problem here is that keys inevitably change, and lacking a global infrastructure of key management messaging you're very unlikely to find out when that happens.
We already have to manage the public keys so that people can send encrypted messages. Managing the signature keys goes right along with managing the encryption keys. With the signature keys managed appropriately letting the user define a set of email addresses that MUST be signed or they are BOUNCED back to the sender would be a way to get rid of a lot of SPAM that is addressed as if sent by the recipient. Authentication based on identity needs to be understood and used ubiquitously. PKI with authentication tied to a CA chain of trust is the best we have at this time. When most legitimate folks have a good signature tied to a trusted CA then email servers could have an option to reject all email from "whitelisted domains" that do not have a valid signature.
My main point and the reason I responded in agreement with David Emery's posting is that PKI tied to signature and encryption certificates really need an investment in human factors engineering or usability or whatever you want to call it, so that end users can easily manage certs used for signatures and encryption. Apple is the leader in usability and I hope Apple continues to step up and show how certificate management and use can be done right. At the current time OS X and WIndows XP both have unfriendly, crappy implementations in their "mail" and "outlook" email clients. Thunderbird is in there too, with difficult to use and manage certs.
If Apple issued certs to all their employees for encryption and signatures, they would understand quickly the usability deficiencies and be in a great position to improve OS X.
Paul
_______________________________________________
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