Easy client cert installation

[Joseph A Holsten]

Anyone heard of people working on a sane UX for installing ssl certs
in browsers, like what people are working on for openid and oauth? Or
is there some other some encrypted (not merely authenticated) protocol
with a decent browser ux flow?

--
Joseph Holsten
http://josephholsten.com
mailto:jos...@josephholsten.com
tel:+1-918-948-6747

[Stephen Paul Weber]

I'm certainly very interested in this tech.  The only thing being that browsers have to be changed to improve this UX. Are there specific parts of the flow you'd like to see improved?

Sent from my Android phone

[Joseph A Holsten]

I got this question from a fellow via ardvark, and he phrased it
'Something like "Take this cert". "OK" and it is imported in the
browser.'

Of course, I can't even make Safari use client certs and I know the
difference between DER and BER encodings.

It seems that TLS defines a message for pushing the Server Certificate
chain to the client[1], and for requesting the Client Certificate, but
I can't see a way to push a private key + cert. So there may not be a
way to do this yet. And this is so not within scope of the hammer
disco stack.

For prototyping this, I assume Firefox and Chromium are options.
Webkit uses the system wide keychain, so that's probably a no-go.


1: 7.4.2 Server Certificate http://tools.ietf.org/html/rfc5246#section-7.4.2
2: 7.4.4 Certificate Request http://tools.ietf.org/html/rfc5246#section-7.4.4

[Stephen Paul Weber]

I use Firefox for my clent side certs. My friend uses Safari.  In ff it's mostly click link, click yes, done.  In safari you download the file and click it, which imports it to keychain.

Not surewhat IE does.

I'd reccomend getting a CAcert.org account so you can play with this.

Sent from my Android phone

On Nov 10, 2009 12:42 PM, "Joseph A Holsten" <jos...@josephholsten.com> wrote:


I got this question from a fellow via ardvark, and he phrased it
'Something like "Take this cert". "OK" and it is imported in the
browser.'

Of course, I can't even make Safari use client certs and I know the
difference between DER and BER encodings.

It seems that TLS defines a message for pushing the Server Certificate
chain to the client[1], and for requesting the Client Certificate, but
I can't see a way to push a private key + cert. So there may not be a
way to do this yet. And this is so not within scope of the hammer
disco stack.

For prototyping this, I assume Firefox and Chromium are options.
Webkit uses the system wide keychain, so that's probably a no-go.


1: 7.4.2 Server Certificate http://tools.ietf.org/html/rfc5246#section-7.4.2
2: 7.4.4 Certificate Request http://tools.ietf.org/html/rfc5246#section-7.4.4

On Nov 10, 2009, at 9:07 AM, Stephen Paul Weber wrote: > I'm certainly very interested in this tec...

[Chris Messina]

This is how you do it in OS X:

http://docs.info.apple.com/article.html?path=Mac/10.4/en/mh1779.html

It's not that bad, really — and Apple prefers to manage certs at the OS level.

This is a constant struggle that I'm confronting — where should certs and identity exist? In the OS or the browser? How do you make them portable? How do you bring your account to your Xbox, iPhone, or Blu-Ray player?

I think client-side certs can certainly help and make things more convenient... but I've not gotten my head around making them portable for real humans yet.

Chris

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Diso Project" group.
To post to this group, send email to diso-p...@googlegroups.com
To unsubscribe from this group, send email to diso-project...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/diso-project?hl=en
-~----------~----~----~----~------~----~------~--~---

--
Chris Messina
Open Web Advocate

Personal: http://factoryjoe.com
Follow me on Twitter: http://twitter.com/chrismessina

Citizen Agency: http://citizenagency.com
Diso Project: http://diso-project.org
OpenID Foundation: http://openid.net

This email is:   [ ] shareable    [X] ask first   [ ] private

[Peter Saint-Andre]

On 11/12/09 10:28 AM, Chris Messina wrote:
> This is how you do it in OS X:
>
> http://docs.info.apple.com/article.html?path=Mac/10.4/en/mh1779.html
>
> It's not that bad, really — and Apple prefers to manage certs at the OS
> level.
>
> This is a constant struggle that I'm confronting — where should certs
> and identity exist? In the OS or the browser? How do you make them
> portable? How do you bring your account to your Xbox, iPhone, or Blu-Ray
> player?
>
> I think client-side certs can certainly help and make things more
> convenient... but I've not gotten my head around making them portable
> for real humans yet.

I use certificate login on some websites, but I also use the same
certificate for signing email (and maybe at some point I'll use it for
IM login, too). IMHO the browser is not a keychain. That doesn't mean
any of this is easy, yet...

Peter

--
Peter Saint-Andre
https://stpeter.im/

[Joseph A Holsten]

I was reviewing the OAuth draft again, and wondered if OAuth + TLS
using a standard server cert really handles the client authentication
+ encryption problem in as secure a fashion as client certs. Would it
make more sense to just improve OAuth in the browser?

I also wonder if there's value in an OAuth keychain. It's certainly
not the way OAuth was intended to be used, but I know the Apple
keychain has some ability to limit which apps can use which keys.

If browsers start having OAuth support, they're definitely going to
need a secure store for those OAuth tokens, so my malicious app
doesn't just dig through your Firefox config for access to tokens.
draft-hammer-oauth-05 §4.7 is server specific, and §4.8 only
recommends to hide the client credentials. Maybe I should mention that
on some OAuth list? Any idea which is the right one?
--
j

[Stephen Paul Weber]

Seems the wrong way to go about it: fixing UX by using new tech in a redundant way.

Also, oAuth really does solve a different problem,

Sent from my Android phone

On Nov 17, 2009 3:08 AM, "Joseph A Holsten" <jos...@josephholsten.com> wrote:

On Nov 12, 2009, at 3:42 PM, Peter Saint-Andre wrote: > On 11/12/09 10:28 AM, Chris Messina wrote: >...

I was reviewing the OAuth draft again, and wondered if OAuth + TLS
using a standard server cert really handles the client authentication
+ encryption problem in as secure a fashion as client certs. Would it
make more sense to just improve OAuth in the browser?

I also wonder if there's value in an OAuth keychain. It's certainly
not the way OAuth was intended to be used, but I know the Apple
keychain has some ability to limit which apps can use which keys.

If browsers start having OAuth support, they're definitely going to
need a secure store for those OAuth tokens, so my malicious app
doesn't just dig through your Firefox config for access to tokens.
draft-hammer-oauth-05 §4.7 is server specific, and §4.8 only
recommends to hide the client credentials. Maybe I should mention that
on some OAuth list?  Any idea which is the right one?
--
j

--

You received this message because you are subscribed to the Google Groups "Diso Project" group. To ...

For more options, visit this group at http://groups.google.com/group/diso-project?hl=.

[Chris Messina]

It's not a bad point to bring up, and yes, eventually the browser and OS are going to need to change if we're going to have a chance against phishing (while preserving the openness of the web).

I think it's also going to be come crazy complicated to try to keep track of who is authorized against whom, with what permissions, for how long... etc. It's going to be a nightmare (it's bad enough within my Facebook account already, and I rarely if ever install apps!).

Extending the keychain to support "authorizations" as well as authentication credentials is not a bad idea, actually. While the purposes of the protocols are different — for most users, they have no idea what it means to hand over their password vs click an "allow" button.

The greatest challenge in all of this is making data access somewhat or semi-portable.

For example, I really don't want to have to authorize all my many services again and again every time I use a new device (or use a friend's device when I've left mine at home).

Consequently, it would seem, we will need to adopt some kind of proxied identity-in-the-cloud (with offline sync) model if we're going to make progress in this respect.

It's essentially how credit cards and ATMs work — though of course I imagine there are a lot more legal stipulations that govern such electronic commerce. In any case, they figured it out for money — we just need to figure it out for friends and data capital.

Chris

--

You received this message because you are subscribed to the Google Groups "Diso Project" group.

To post to this group, send email to diso-p...@googlegroups.com.
To unsubscribe from this group, send email to diso-project...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/diso-project?hl=.

[Peter Saint-Andre]

On 11/17/09 1:08 AM, Joseph A Holsten wrote:
> On Nov 12, 2009, at 3:42 PM, Peter Saint-Andre wrote:
>> On 11/12/09 10:28 AM, Chris Messina wrote:
>>> This is how you do it in OS X:
>>>
>>> http://docs.info.apple.com/article.html?path=Mac/10.4/en/mh1779.html
>>>
>>> It's not that bad, really — and Apple prefers to manage certs at
>>> the OS
>>> level.
>>>
>>> This is a constant struggle that I'm confronting — where should certs
>>> and identity exist? In the OS or the browser? How do you make them
>>> portable? How do you bring your account to your Xbox, iPhone, or
>>> Blu-Ray
>>> player?
>>>
>>> I think client-side certs can certainly help and make things more
>>> convenient... but I've not gotten my head around making them portable
>>> for real humans yet.
>> I use certificate login on some websites, but I also use the same
>> certificate for signing email (and maybe at some point I'll use it for
>> IM login, too). IMHO the browser is not a keychain. That doesn't mean
>> any of this is easy, yet...
>
> I was reviewing the OAuth draft again, and wondered if OAuth + TLS
> using a standard server cert really handles the client authentication
> + encryption problem in as secure a fashion as client certs. Would it
> make more sense to just improve OAuth in the browser?

I still see OAuth as about authorization / delegation, not authentication.

> I also wonder if there's value in an OAuth keychain. It's certainly
> not the way OAuth was intended to be used, but I know the Apple
> keychain has some ability to limit which apps can use which keys.

And how many people use that? :)

> If browsers start having OAuth support, they're definitely going to
> need a secure store for those OAuth tokens, so my malicious app
> doesn't just dig through your Firefox config for access to tokens.

Good point.

> draft-hammer-oauth-05 §4.7 is server specific, and §4.8 only
> recommends to hide the client credentials. Maybe I should mention that
> on some OAuth list? Any idea which is the right one?

https://www.ietf.org/mailman/listinfo/oauth (please)

[Joseph A Holsten]

Re: proxied identity-in-the-cloud, haven't all the recent examples of
this been failures? 1password dropped their online sync product, and
myVidoop never had a real API for their keychain.

Is this something that should be build into some open-mesh-dashboard,
diso plugin, or the like? It seems a bit unusual for a wordpress
plugin, but that was always my favorite tool in vidoop's openid
provider.

Would it make sense to start with the cloud/web client bit or the
local store/client integration bit first? My instinct is to make the
web bit compelling first since picking a client to integrate with
limits the market, and there's almost no competition with web
keychains. It's also an excuse to push forward on OpenID hybrid and
XRD provisioning.
--
j

[Robert]

This does seem to be chicken-egg.  I definitely agree with Chris, the browser is not the keychain, though this doesn't mean inherent support cannot be built into the client, i.e., Smart Client -- in other words, I'm now convinced (this is kind of 180 for me) the greater load of discovery should take place in the cloud, but phishing and other protections and aids can certainly be preconditioned.

Frankly, after last week's WordCamp, it occurred to me that the infrastructure hasn't really been there anyway, even though we have mega-social networks like Facebook, etc.  The buzz this year was all about BuddyPress, to your point about WordPress.  WordPress on the one hand seems inadequate -- it doesn't lend itself as entirely pliable to an open stack model (or hammer stack?  what does that even mean?)

The BuddyPress dev community and the platform, on the other hand, fits the model perfectly, so the infrastructure is forthcoming, for multiple social networking endpoints -- the communities haven't all cropped up, but I imagine they will -- and BuddyPress has the stack on it's radar.  I'm working with a fellow in Poland to help piece some of it together, as well communicating with the lead developers.  We're hanging out a lot these days in #diso on IRC freenode, and we've setup a site to actually implement as many necessary components as possible.  If anyone is so inclined, head on over: http://disodev.org/  We're specifically geared toward BuddyPress, but have a generalized aim as well.

w00t!