[OpenID] The HTTPS in the OpenID (Re: Bug in OpenID RP implementations)
Peter Williams
pwilliams at rapattoni.com
Mon Jan 5 04:16:24 UTC 2009
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
More information about the general
mailing list