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