[OpenID] The HTTPS in the OpenID (Re: Bug in OpenID RP implementations)

[Peter Williams]

So no. I don't expect users to have signing keys that mint xcerts or ctls. In the nearly 8 years since windows 2000, hardly even security vendors in the know have applied ctls (probably because they required admin rights to mint).

I do expect users, since its already part of openid notion set, to be able put a vanity site's public key cert in an ax attribute (or have the (deemed trustworty) op pick it up from url pointing to their vanity site(s)) and show its digest(s) dring registration (just like mozilla does for consumer solutions, today, storing it in a mozilla file (rather than at the op)).

A cert is a very convenient package of course, as billions of pcs have consumer tools to process the data format when configuing ssl server trust. Its various control extensions are important to interworking effectivess.

I just don't want to buy certs from the usual parties. I personally made 3 of the roots that (audited!) public ca folks use, and I know how incompetent I am at crypto and pki! I think I really want to buy one from eddy seeing as he is trying really hard at uci openid (but his ca doesn't work at nerdbank).

Nothing in my original argument about ctls driving htps vanity discovery really cares a hoot about any non compromise of an actual ca security policy. Its example was used to develop the material and supporting rationale. With my writing skills, im sure I failed.

The central issue is that unless users have vanity urls with delegations urls, they cannot recover access to the rp when said op is compromised (since it controls the xrds that the rp uses). In such case, They have to be able to signal their rp to NOW goto their own xrds, to work around the op that provisoned the openid that must now be unlinked from their rp account.

Another way (dependent on rp programming) is of course to have muitple openids account-linked at the sp (as plaxo does). Tas very uci, and is a varian of te multiple nym idea., applid to surviviability. One uses the fallback pre linked op.2 then, when the op.1 is no longer trustworthy, to ten purge hopenids of the (not) compromised ops.

Another way to unlink an openid at an rp is do local rp login, using its locally generated uid/password. All 15 of them.

-----Original Message-----
From: Peter Williams <pwilliams at rapattoni.com>
Sent: Sunday, January 04, 2009 8:16 PM
To: Eric Norman <ejnorman at doit.wisc.edu>; OpenID List <general at openid.net>
Subject: Re: [OpenID] The HTTPS in the OpenID (Re: Bug in OpenID RP implementations)


Eric

Are you comfortable with the truth of the following wording:

"This attack method could allow an attacker to generate additional digital certificates with different content that have the same digital signature as an original certificate."

Ae you telling me that no exploitation of that attack method actually occurred, as expressed above?

That is: noone "generate(d) additional digital certificates with different content that have the same digital signature as an original certificate."

If so I hereby apologise.

-----Original Message-----
From: Eric Norman <ejnorman at doit.wisc.edu>
Sent: Sunday, January 04, 2009 7:13 PM
To: OpenID List <general at openid.net>
Subject: Re: [OpenID] The HTTPS in the OpenID (Re: Bug in OpenID RP implementations)


On Jan 4, 2009, at 8:36 PM, Peter Williams wrote:

>
> On a https thread we are allowed this topic. The whole topic is really
> about trust networking, with a non-ttp bent (in favor of a uci bent).
> What we learned (all of us, this week) is that trust networking needs
> lifecycle management. Its not about prevention (your critique): its
> about recovery.
>
> Insertion of an unauthorized ca into a pki was a compromise event in
> the itsec claims about the pkis I learned from (in the days before the
> term pki was even coined).

No such compromise event happened.

> On uci... and peters notions. If openid movement just equals shib2
> movement on what uci means, one might as well just use shib2/saml2
> (its the same websso detergent, "now with added uci!").
>
> On your question, its irrelevant to me at this high level juncture
> whether the op asserion is a proxy for user cross certification of
> the ca public key, or the user does it with a personal signing key
> (per actual existing x509 procedures, and entrust pki principles). One
> is doable today with openid auth 2.0 (with tiny shift by willing rp
> entities wanting to address vanity https domains), the other require
> yet more pki - which has been a miserable failure (even after 15 years
> of trying) in other client areas contigent on mass adoption by ipki
> users. We also don't even really need openid or saml (pr ws fed), if
> huge numbers of folks have signing keys and therefore ssl client certs
> and messaging signed-token making power. ssl brings websso for free,
> lets recal. 'ut what we would lose are properties of the very nice uci
> vision (aka user-defined, per RP, release controls for attributes).
> These are control properties specific to the openid design concept,
> and which shows excellent signs of rapidly scaling p to handle ~6
> billion users.

My question to you could have been answered with a yes or no.
I don't know which way you answered it.

I read what you were saying elsewhere that "user centric" meant
(among other things) that users could control their own trust
anchors.  I suggested a way that this could be done that would
reduce the number of trust anchors that need to be protected.

Eric Norman

_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general
_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general