Re: [mmox] OGP scalability concerns
"Meadhbh Hamrick (Infinity)" <infinity@lindenlab.com> Fri, 03 April 2009 00:02 UTC
Return-Path: <infinity@lindenlab.com>
X-Original-To: mmox@core3.amsl.com
Delivered-To: mmox@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E697E3A684C for <mmox@core3.amsl.com>; Thu, 2 Apr 2009 17:02:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.355
X-Spam-Level:
X-Spam-Status: No, score=-3.355 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iM6T4gR8TYA for <mmox@core3.amsl.com>; Thu, 2 Apr 2009 17:02:23 -0700 (PDT)
Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 253033A6D5B for <mmox@ietf.org>; Thu, 2 Apr 2009 17:02:23 -0700 (PDT)
Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 2BCD21414005; Thu, 2 Apr 2009 17:03:25 -0700 (PDT)
Message-Id: <3C59C4AA-CD4F-456D-83B5-35DC9DEAE4A7@lindenlab.com>
From: "Meadhbh Hamrick (Infinity)" <infinity@lindenlab.com>
To: Jason Giglio <gigstaggart@gmail.com>
In-Reply-To: <49D4628B.9050207@gmail.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Thu, 02 Apr 2009 17:03:24 -0700
References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <CD02023C-3E7B-4E76-8429-11035C827E53@lindenlab.com> <49D4628B.9050207@gmail.com>
X-Mailer: Apple Mail (2.930.3)
Cc: "mmox@ietf.org" <mmox@ietf.org>
Subject: Re: [mmox] OGP scalability concerns
X-BeenThere: mmox@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Massively Multi-participant Online Games and Applications <mmox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmox>
List-Post: <mailto:mmox@ietf.org>
List-Help: <mailto:mmox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Apr 2009 00:02:24 -0000
okay... if by "centralized manner" you're talking about something like the global PKI that PEM mandated then yes, let's not talk about that. however. i don't think we were ever talking about that. to date, the proposed use of X.509 has been to identify agent domains to region domains and region domains to each other. i don't think we're proposing the use of client certs for client applications to authenticate themselves to agent domains. or rather... no one's talking about REQUIRING it. as an option, it's perfectly fine, though a touch difficult to manage. trust DOES lose it's meaning when you dilute your CP and CPS to enable universal enrollment. and don't get me started about the weak semantics of key usage in virtually every implementation. however... remember that X.509 / PKIX are used to transport assertions about previously established trust relationships. it is possible for a relying party to map different cert chain trust points to different internal policies. for example, one could have a "high security" CA with a CPS that requires execution of a legally binding agreement and the establishment of a $50,000 bond. then there could be a "low security" CA that only required an email account and a credit card number. when protocol from a peer identified with a cert issued off the high security CA, the relying party (let's assume it's an asset server trying to decide whether a simulator is trusted.) the relying party might then decide... "okay.. it's the high security CA.. i know if he does something untrustworthy i can impound funds from the bond escrow account, so sure.. have some sensitive resources." but if the next peer is identified with a cert from the low security CA, the relying party might decide only to divulge full-perm assets with a creative commons license. so i guess what i'm saying is, we can't ignore the issue of trust, and while things are difficult, it is not outside the realm of possibility we could, in fact, establish a trust management system that communicates assertions about relationships independent of their interpretation. (i.e. - use X.509 in the way it's supposed to be used.) -cheers -meadhbh On Apr 2, 2009, at 12:00 AM, Jason Giglio wrote: > Meadhbh Hamrick (Infinity) wrote: >>>> * There will be millions of worlds in an Internet-scale metaverse, >>>> which makes the concept of interop through trust agreements far too >>>> narrow. Trust loses its meaning entirely when scaled to millions, >>>> becoming mere paperwork or "security theater". >> >> +1. what's your suggestion? > > > My suggestion is that it's not appropriate to talk about client > identity, trust, or authentication as a service to be provided in a > centralized manner. > > The rest of the Internet gets along just fine without it. Sure I can > get a CA to sign something that says I am who I am, but no one much > cares; the rest of the net has routed around the problem of client > identification. I'm not sure why we would need to tackle something so > fundamentally difficult here, when it's not really necessary. > > -Jason
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- [mmox] OGP scalability concerns Hurliman, John
- Re: [mmox] OGP scalability concerns Morgaine
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Charles Krinke
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Charles Krinke
- Re: [mmox] OGP scalability concerns Lawson English
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Charles Krinke
- Re: [mmox] OGP scalability concerns Morgaine
- Re: [mmox] OGP scalability concerns Jason Giglio
- Re: [mmox] OGP scalability concerns Rob Lanphier
- Re: [mmox] OGP scalability concerns Morgaine
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Christian Scholz
- Re: [mmox] OGP scalability concerns Hurliman, John
- Re: [mmox] OGP scalability concerns Christian Scholz
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Christian Scholz
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Charles Krinke
- Re: [mmox] OGP scalability concerns Hurliman, John
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Charles Krinke
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Christian Scholz
- Re: [mmox] OGP scalability concerns Christian Scholz
- Re: [mmox] OGP scalability concerns Christian Scholz
- Re: [mmox] OGP scalability concerns Morgaine
- Re: [mmox] OGP scalability concerns Charles Krinke
- Re: [mmox] OGP scalability concerns Christian Scholz
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Hurliman, John
- Re: [mmox] OGP scalability concerns Christian Scholz