Info Warfare & Security Conference (was Re: [Fed-Talk] Re: Root Cert on MacBookPro Question)
Info Warfare & Security Conference (was Re: [Fed-Talk] Re: Root Cert on MacBookPro Question)
- Subject: Info Warfare & Security Conference (was Re: [Fed-Talk] Re: Root Cert on MacBookPro Question)
- From: "Blumenthal, Uri - 0662 - MITLL" <email@hidden>
- Date: Mon, 4 Jan 2010 11:43:46 -0500
- Acceptlanguage: en-US
- Thread-topic: Info Warfare & Security Conference (was Re: [Fed-Talk] Re: Root Cert on MacBookPro Question)
Here's the conference URL with all the details (dates, location, etc):
http://academic-conferences.org/iciw/iciw2010/iciw10-home.htm
5th International Conference on Information Warfare and Security
The Air Force Institute of Technology,
Wright-Patterson Air Force Base, Ohio, USA
8-9 April 2010
<http://www.afit.edu/> Air Force Institute of Technology
Conference Chair: Dr. Michael Grimaila, Center for Cyberspace Research,
WPAFB, Ohio, USA
Programme Chair: Edwin Leigh Armistead, Edith Cowan University,
Australia
Keynote Speaker: Dr. Michael VanPutte, Defense Advanced Research Projects
Agency (DARPA), USA
"Mission Assurance - Cornerstone of Computer Network Operations"
The Air Force Institute of Technology is delighted to have been chosen to
host for ICIW in 2010. Designated a Technical Center of Excellence
<http://www.afit.edu/about.cfm?article=270&a=news> , our Center for
Cyberspace Research develops Air Force and DoD leaders in cyber operations
through its Masters and PhD programs.
Dayton plays host to significant industrial, aerospace, and
technological/engineering research activity and is known for the many
technical innovations and inventions developed there. Much of this
innovation is due in part to Wright-Patterson Air Force Base
<http://en.wikipedia.org/wiki/Wright-Patterson_Air_Force_Base> and its
place within the community.
This conference is renowned for bringing together a varied group of people
with different perspectives, experiences and knowledge. Conference aims
include helping practitioners find ways of putting research into practice
and enabling researchers to gain an understanding of real-world problems,
needs and aspirations.
We look forward to providing an exciting, worthwhile and intellectually
stimulating conference for academics, researchers and practitioners alike.
Join us in Ohio for ICIW-2010!
Michael Grimaila, Conference Chair
Thanks!
On 1/4/10 10:38 , "Timothy J. Miller" <email@hidden> wrote:
> Which conference?
>
> -- Tim
>
> Blumenthal, Uri - 0662 - MITLL 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
>>
>
--
Regards,
Uri
<Disclaimer>
_______________________________________________
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