Re: [Fed-Talk] Re: Root Cert on MacBookPro Question
Re: [Fed-Talk] Re: Root Cert on MacBookPro Question
- Subject: Re: [Fed-Talk] Re: Root Cert on MacBookPro Question
- From: email@hidden
- Date: Wed, 30 Dec 2009 17:38:03 -0500
Paul's message raises a good point. No matter how technically oriented
someone on this list may be, the average user is not. The average user
wants to hit the "send" button and have the message get to the other end
without any additional intervention. A user might be willing to check a
box that says "sign" or "encrypt", but that's about it. Technically
oriented individuals often criticize the lack of savvy of the average
user, but we should be building applications for that person. We should
be building for 50th percentile, not 90th. And there's no reason that
security protocols shouldn't be as easy.
Steve Jobs received much ridicule for sticking with the one-button mouse
for so long. But his insistence was based on the average user simply
being confused by that second button. And as much as IT staff may try
to teach someone about the context-sensitive menu, most people didn't,
and still don't, get it. Like it or not, people want simplicity that
works.
The problem with PKI, certificates, and most security implementations is
that they are often not very easy or simple; one cannot just press a
button to send an encrypted document and have it readable on the other
end. And honestly, there's no legitimate reason why it shouldn't be
that simple. Apple (and all other IT companies for that matter), should
be looking to build in the maximum security that requires the minimum of
user intervention. Security should be simple AND robust. We need not
sacrifice one for the other.
It should just work. And if it doesn't, it's not the user's fault or
problem; it's IT's. IT needs to build a more foolproof mouse trap.
Joe
From: Paul Derby <email@hidden>
To: email@hidden
Cc: Ron Police <email@hidden>
Date: 12/30/2009 16:39
Subject: [Fed-Talk] Re: Root Cert on MacBookPro Question
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
_______________________________________________
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