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

[Peter Williams]

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).  Prevention of the unauthorized assumption of issuing authority was a core security objective (if I recall the security claim formalisms, half properly). Whether there is impact from compromise of a ca policy boundary is irrelevant to a compromise event - though obviously impact defines the compromise recovery procedures to be applied in a key manement domain (purge the certs, revoke the authority, deploy crls at endpoints, ... ). Authority compromise  (unauthorized issuing of certs) was a (major, major) violation of the pki security policy claims for the pkis i'm used to. I understand the need to flum this topic, given the need for public confidence, but there are limits. We have to learn from, not cover up, the policy violations that breaking a cipher's strength actually allowed.

I can provide the microsoft security advisory url if one wants on the firm's recommendation  for enterprise pki sites to deploy their own ocsp servers, to mitigate what follows from the (final) lack of suitable strength revealed in the use of a particular cipher (used until the compromise was revealed) by certain cert issuing entities. The problem is that the nature of specifically an "authority compromise" is that it also dilutes the compromise recovery nature of status servers derived from the root list, as false status server authorities can be created ( ie one is relying on pki to recover pki). Unlike govt networks with their ckl infrastructure, ipki is not equipped for systemic compromise recovery (having only crl and ocsp). Arguably, ipki does have windows update, tho, to deploy compensate controls via a mass code push (as earlier used to address another compromise of a ca, when attackers induced an ipki ca to mint fraudulent certs  impersonating certain critical microsoft sites).

The reason for using as example this current-events topic as part of my rationale on rp based cert ctl signalling was/is tied to the need for openid users to have similarly the means to securely communicate with rp parties in the absence of the pki OR OP that introduced the parties. In the case we care about in this thread (https openids), more specifically, a commercial security policy enacted by a medium assurance op would have similar claims and countermeasures as do medium assurance ca entities (concerning authority compromise). Now, users in a uci (vs ttp) theatre must prepare - as did the TTP ca firms for their control domains - for compromise recovery. The CAs and platforms (lke windows) made recovery prep standards (ocsp) whose std management procedures can and do cater for even catestrophic authority compromise.

What the oscp standards in the pki world got it right (and openid rps need to be taking note) was in the ability for end stations (eg rp and user entities) to deploy compromise handling infrastructure outside the authorization framework of the ca. (You don't need a ca issued cert to run your own ocsp server, per ietf standards, intentionally allowing for the very notion of out of band compromise recovery). In the openid case, once an op is no longer deemed trustworthy as enforcing its security policy claims (lets say it starts selling the audit logs myopenid maintains on assertion minting, for trap and trace purposes), there sould, im arguing, be means for users and rp to intercommunicate and quickly rebuild their trust channels with new, more trustworthy op/ax partners based on the vanity url process - without the intercession of the op who has lost suffered a minor (or a major) compromise event. Unlike pkis ( or shib) users in a uci theartre are responsble for their own delegations, their own security, their ability to quickly recover from an op compromise.

If https openids in a uci vision are ever going to address business needs of an organization like the BBC (non criticial infrastucure players with major reputations to protect) its lifecycle management standards must demonstrate that the vendor systems can match what the ipki folks achieved (over 15+ years).

The ipki has come along way from where it started in the IRTF!

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.

-----Original Message-----
From: Eric Norman <ejnorman at doit.wisc.edu>
Sent: Sunday, January 04, 2009 5:05 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 2:36 PM, Peter Williams wrote:

> ·         Now, the suspected compromise of the VeriSign Trust Network
> (or one of its sub brands, rather)

I mention this just in an attempt to impede the proliferation
of false information about the attack discovered this week.  If
someone thinks further discussion is warranted, please chose an
appropriate forum; this isn't it.

Nobody who understands the attack believes that the Verisign
Trust Network was compromised.  No extant certificates are
believed to be forgeries, nor could they be used to create
forgeries.

>  has just this week  taught lots of folks about PKI features not that
> well known previously – how to manually configure the URL of the
> validation service  (OCSP responder), so one can FOR ONESELF run an
> OCSP server which overrides the status service of the trust network.

Having OSCP configured would do nothing to prevent this attack.

Now, what I really wanted to ask.

> ·         So the idea is, rather than useX.509 cross-certification
> (where on CA root signs another CAs root), view the private
> association the RP has with the OP as the means by which a USER
> “cross-certifies” the certificate/CA being delivered  to the RP in a
> positive assertion.

So, Peter, would it satisfy your notion of user-centricity if
every user locally reissued all (what some like to call) root
certificates.  I.e. the user replaces the issuer field and
resigns the TBSCertificate part with that user's most trustworthy
private key, namely, the user's own?

Eric Norman

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