RE: [Fed-Talk] Re: Safari prompting for Cert selection
RE: [Fed-Talk] Re: Safari prompting for Cert selection
- Subject: RE: [Fed-Talk] Re: Safari prompting for Cert selection
- From: "Mueller, David S CIV SSC San Diego, 2872" <email@hidden>
- Date: Sun, 6 Jul 2008 11:44:34 -0700
- Thread-topic: [Fed-Talk] Re: Safari prompting for Cert selection
Title: RE: [Fed-Talk] Re: Safari prompting for Cert selection
Sean,
I just tried setting an identity preference for infosec.navy.mil and it didn't work. I tried both the ID and the email certs. This leads to one of two possible conclusions:
1. It still doesn't work right.
2. I didn't have the identity preference set correctly. If this is the case, then it exposes a problem with manually creating identity preferences, and that is the need to know the correct authentication URL, as you pointed out in your earlier email. The problem is, how is the average user supposed to find out this URL?
I have a couple of thoughts on how to fix the problem. One, go back to the 10.5.2 way of doing things. It seemed to work well enough in the majority of cases, and I can't recall any specific cases of not being able to authenticate with the certificate correctly. Same goes for Firefox's automatic certificate selection, and I started using Firefox with CAC around the time Fedora Core 5 was current. IE6 on Windows always seemed to me to be the worst at doing this, having to constantly select the correct cert (I don't believe IE6 has any sort of automatic selection mechanism; if it does it's pretty well hidden) as opposed to Firefox and Safari automagically working.
The other option I can think of would bring up the certificate selection dialog box on "optional" configured servers, not just "required". An additional button to provide no certificate and recording this as an identity preference would seem to provide whatever perceived benefits this new selection method provides and still provide a better user experience for those of us that use client certs.
I think it's a bit of a misconception that DoD is using "optional" to provide a transition mechanism from username/password to CAC. In the case of the Navy Infosec site, there is no username/password option, a CAC is required. From what it looks like to me, they use the optional configuration so that if no CAC is supplied, they can provide contact info for the help desk as well as links to download the Windows client software (ActivClient and the DoD root certificate package).
- David
-----Original Message-----
From: fed-talk-bounces+david.s.mueller=email@hidden on behalf of Shawn A. Geddis
Sent: Fri 7/4/2008 12:43 PM
To: Boyd Fletcher
Cc: Fed Talk
Subject: [Fed-Talk] Re: Safari prompting for Cert selection
Subject changed to properly reflect this ongoing discussion....
On Jul 3, 2008, at 10:49 AM, Boyd Fletcher wrote:
> I guess what a meant was that there should be a way in Safari to
> force the ID pref to be set and allow it to be modified. Though the
> auto prompting is good, if it fails or the user selects the wrong
> value there needs to be a way to change it without using Key Chain
> (which is a bit daunting for the average user).
There is. If the user selected the wrong certificate (probably trying
each one until one works) when prompted by Safari and that certificate
was not accepted either then the user is prompted again, until one
selected is accepted by the server. This is all based, of course, on
the assumption the server is configured as *required* for Client-
Authentication with certificates.
The challenge that most of you are having are with sites that are
configured as _optional_ where, right now, a manual configuration of
an Identity Preference is required - yes, using Keychain Access.
We are looking at being able to handle the _optional_ case in the
future.
> Actually it would be nice if Safari had a interface to access
> passwords like FireFox does and add the ability to set Certs as well.
There is a fundamental difference between FireFox's Security/PKI model
and that which is leveraged by Safari.
/* Shawn's personal rant on this point follows */
FireFox is a complete stand-a-lone application which requires that all
of its Certs / Trust / Settings be performed within the application -
hence the _need_ to prompt _within_ the application for Passwords /
Certs. This means that even if you already have the Certs / Passwords
managed by Mac OS X, you have to duplicate your effort to tell FireFox
what to do with the exact same information. Might be nice for
Applications like FireFox to integrate with the OS they are running on
and take better advantage of the OS Security / PKI services rather
than needing to duplicate those same services. I am a little
surprised that so many IT folks who are "Central Management" focused
prefer an application that makes no effort in OS integration and
requires redundant effort to manage. Maintaining good Security is
hard enough without duplicating the required efforts. In my opinion,
It is very dangerous to be pushing all of the security decision into
the application that runs in user space. It is much safer and better
practice to rely on the security enforcement of the OS.
Mac OS X provides a System-wide architecture for this which can be set
_once_ and safely relied on by ever single application that leverages
the corresponding Sec* APIs. Not only that, Applications do not need
to attempt to get into the security game and try to do security --
which frequently is one of their last concerns. Safari is relying, as
it should, on the Security / Certificate management of the OS. That
said, the OS is performing all of the Certificate parsing, chain-of-
trust validation, confirming proper key usage, etc.
/* Thus ends Shawn's personal rant on this point :-) */
Now back to our previously scheduled programming...
- Shawn
_____________________________________________________
Shawn Geddis ? Security Consulting Engineer ? Apple Enterprise
_______________________________________________
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