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: "Wm. Cerniuk" <email@hidden>
- Date: Thu, 31 Dec 2009 00:05:26 -0600
With PGP I hit a "encrypt" button and it just does it. Granted, some
setup required but I have personally documented the setup at the
minutiae level and it can be followed by the average mom without
resulting in questions & confusion.
PGP's interface is very well designed considering it is easy to use
yet can expose mind numbing crypto detail with a couple of clicks.
I would also add that the reassuring click of the 'encryption on'
button is a firm business requirement for any email encryption software.
V/R,
Wm. Cerniuk
703.594.7616
(Sent faster from my iPhone 3Gs)
On Dec 30, 2009, at 6:16 PM, "Blumenthal, Uri - 0662 - MITLL" <email@hidden
> wrote:
Actually the problem with PKI is more complex and deep-rooted. It is
a result of using the architecture designed for much more limited
capabilities. If you attend the AF conference in Ohio next April,
you'll hear more about this point of view.
Regards,
Uri
----- Original Message -----
From: fed-talk-bounces+uri=email@hidden <fed-talk-bounces+uri=email@hidden
>
To: email@hidden <email@hidden>
Sent: Wed Dec 30 17:38:03 2009
Subject: Re: [Fed-Talk] Re: Root Cert on MacBookPro Question
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
_______________________________________________
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