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

Sat Jan 3 19:45:09 UTC 2009

Delete now.  I hope these issues are being addressed in the spec council more formally - over the CX proposal's general contribution to similar problems faced by deployers (vs. library writers).

What is the problem with the status quo in OpenID culture?

The fundamental problem is: I, an association of users, want to run my own CA (like Eddy does, too). Since openid is about UCI and not "e-commerce", the practices that have evolved for PKI/https in e-commerce do not automatically roll over.  Pretend its 1994 again, and there are 2000 ISPs all running 100 modem multiplexors and then a few servers doing website hosting. Isn't this the OP vision? (That ISP model is how US realty is organized and governed.) Or are we just here to induce 6B people to sign up to the mega-powerful US firms: Google, Yahoo, AOL, Live, VeriSign, SixApart (or their Japan/China/Korea subsidiaries)? In the US realty case, that equates to removing the power of membership from towns, and centralizing in the national realtor association. Is this truely the end goal  of this movement? (Nate observes that this seems an inevitability.)

The secondary problem: I the user of a vanity domain for Openid typically cannot sign up to the legal agreements the typical CAs impose (They typically impose projection of copyrights that open source software folks object to "on principle").  I typically also lose independence in my risk management, given the way the timely material disclosure rules are written. This loss of independence exists to satisfy the CA's insurer, and buys me actually nothing; but I lose a lot since the insurer (with whom I have no relationship) can impact my communications capabilities with others, at their whim.

The third problem: If I'm a user with a vanity blogsite/XRI doing openid delegation and even if *I* find it suitable to ascribe to those CA rule of the blogsite/HXRI-proxy, I'm imposing the governance rules of the CAs on all other (cert) using/relying parties coming to my vanity URL - including the copyright notices. That is I'm projecting the governance of a TTP (which is not even the OP!) onto the RPs. I don't want to do that.

Those 3 are all un-UCI. All we did was  move from Facebook rules on contact sharing and Aol rules on IM interworking... to CA rules. All we did was shunt the rule making about user governance around the corner to the next infrastructure player.  It's still not in the user's court (once the secure modes of openid are applied).

The point about the Microsoft rules is that they won't (and don't) put in their WindowsUpdate root distribute list just any CA: they only put folks who have a broad business value to Microsoft. From what Eddy tells me, his CA is not recognized by Windows or Nerdbank therefore (albeit for other reasons that may be going away). That is, Microsoft has a measure of controls over Eddy's ability to run a vanity https openid domain service. At any time, the CA can also disappear from the root list, en masse, at the next patch update cycle. If I am an running a private supply chain, with 3000 nodes, I cannot have my $15 CA suddenly stop the VoATM call setup communications between the 3000 H323 call agents just because Microsoft doesn't like the elements of the CA's policy statement, any longer.

What we surely want for openid discovery is what we have on the web, today. I buy a $50 wifi router from the supermarket along with the bread and milk, turn on its https administration website, import the root on the desktops of the authorized folk who will administer it , then lower the policing level that thence allows https access to the control plane through designated (virtual) interfaces - which is probably means the WAN-side of the NAT in a $50 router.

Now, sites like nerdband HAVE ALREADY shown that openid culture CAN support a bread and milk culture, making it even easier than before to  "securely" distribute that CA (self-signed) cert to my own, per user OP->RP trust network.

Even though nerdbank (i.e. or its actual policy authority, called TTP=GoDaddy) will not work with my vanity URL choice or with eddy's CA service (that Mozilla accepts but MSFT doesnt, apparently), it will work with the myopenid (and whichever policy authority is governing MyOpenID's https communications.) Since openid is "secure" , Nerdbank now has the configuration  power to know talk to my vanity openid site over https (if it wants to). Obviously, that config can be automatic, or not (depending on the risk model and policies of NerdBank. But at least openid trust is in the hands of opendnd entities (NerdBank) -  with no normative role.

From: Andrew Arnott [mailto:andrewarnott at gmail.com]
Sent: Saturday, January 03, 2009 7:08 AM
To: Peter Williams
Cc: Jorgen Thelin; Eddy Nigg (StartCom Ltd.); general at openid.net >> general at openid.net
Subject: Re: [OpenID] The HTTPS in the OpenID (Re: Bug in OpenID RP implementations)

On Sat, Jan 3, 2009 at 4:39 AM, Peter Williams <pwilliams at rapattoni.com<mailto:pwilliams at rapattoni.com>> wrote:

In UCI, the user (all 6 billion of us) decide which OP is good, which CA is good - not Microsoft business analysts.
Peter,
Microsoft leaves all 6 billion of us to choose which CAs are good.  Every Windows OS admin has the freedom to manipulate the list of trusted CAs.  But as with any UCI design, that means that each of those 6B people may have a unique set, and you'll never know for sure whether you cert is signed by a CA that a random one of those 6B choose to trust.

I'm not sure how we got off on EV certs.  You absolutely don't need EV certs to make sure that some random RP will definitely accept the cert.  There are several CAs out there that 99.9% of the browsers and RPs out there trust and they're often quite inexpensive.  What problem am I missing?

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire

On Sat, Jan 3, 2009 at 4:39 AM, Peter Williams <pwilliams at rapattoni.com<mailto:pwilliams at rapattoni.com>> wrote:

"CAs who fail to meet the burden of proof for the broad business value of their offering to Microsoft customers."

The program listed fails UCI test.

In UCI, the user (all 6 billion of us) decide which OP is good, which CA is good - not Microsoft business analysts.

From: general-bounces at openid.net<mailto:general-bounces at openid.net> [mailto:general-bounces at openid.net<mailto:general-bounces at openid.net>] On Behalf Of Jorgen Thelin
Sent: Friday, January 02, 2009 7:13 PM
To: Eddy Nigg (StartCom Ltd.); general at openid.net<mailto:general at openid.net> >> "general at openid.net<mailto:general at openid.net>"

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

While considering these issues, you guys may be interested to see the details of the Microsoft Root Certificate Program.

http://technet.microsoft.com/en-us/library/cc751157.aspx

The Microsoft Root Program lists the details and requirements for the Microsoft Root Certificate Program.

The MS Root Program attempts to establish a minimum baseline for PKI-based security -- to at least warn Windows / IE users before that make some obviously bad decisions around SSL trust - such as warning users before they access sites that use certificates with known weak hash algorithms.

You can see the technical requirements for CAs in the above document that are used by any browsers running on Windows.

 "Identity is easy, but Trust is hard!"

From: general-bounces at openid.net<mailto:general-bounces at openid.net> [mailto:general-bounces at openid.net<mailto:general-bounces at openid.net>] On Behalf Of Eddy Nigg (StartCom Ltd.)
Sent: Friday, January 02, 2009 2:01 PM
To: general at openid.net<mailto:general at openid.net> >> "general at openid.net<mailto:general at openid.net>"
Subject: Re: [OpenID] The HTTPS in the OpenID (Re: Bug in OpenID RP implementations)

On 01/02/2009 10:45 PM, Martin Paljak:

On 02.01.2009, at 15:16, Eddy Nigg (StartCom Ltd.) wrote:

Martin, failures and disclosing them serves the purpose to improve and prevent them. I'm responsible for disclosing one of the listed above, which however doesn't mean that public certification is a total failure. It speaks rather for the dedication and also the ability of the industry to control and improve itself.

Of course disclosure is good. But as you have interests in one CA I have to take your opinion as probably biased ;)

Right! And as such I have an interest that my work isn't de-valued by other CAs. Such is the interest of many CAs and hence there is a real interest that we (CAs) are able to upheld the promises we make as a collective. That's why incidents such as I reported are extremely bad and must not happen. I'm active in different forums out of my biased interest to make and keep PKI reliable.

Disclaimer: Mistakes can happen, negligence must not however.

"Nothing to see here, move along, EV fixes everything". Yes - technically, within the boundaries set by the established CA business, everything is OK and will be even better with EV. But I try to question the existing, current approach of CA-s doing business under the name "trust business". CA-s should deal with certification and users should be dealing with trust issues and decisions. PKI as we know it now is not an implementation I like as a (loud minority) user.

Well, the minority of the Netizens have the ability to make the decisions you like them to make. I'm not sure about you, but how many CP/CPS of CAs have you read recently before making a decision if to trust?

Good question. As "you can do anything with OpenID" I believe it is left open - you can do whatever if you want if you consider it useful.

Sure, that's why we are here, aren't we? :-)

Regards

Signer:

Eddy Nigg, StartCom Ltd.<http://www.startcom.org>

Jabber:

startcom at startcom.org

Blog:

Join the Revolution!<http://blog.startcom.org>

Phone:

+1.213.341.0390

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090103/0a96847d/attachment-0002.htm>