Re: [Uri-review] Initial inquiry into URI proposal (nym)

DataPacRat <datapacrat@gmail.com> Wed, 26 June 2013 06:59 UTC

Return-Path: <datapacrat@gmail.com>
X-Original-To: uri-review@ietfa.amsl.com
Delivered-To: uri-review@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8723E21E811A for <uri-review@ietfa.amsl.com>; Tue, 25 Jun 2013 23:59:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82lYSVDBCSil for <uri-review@ietfa.amsl.com>; Tue, 25 Jun 2013 23:59:19 -0700 (PDT)
Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 5106121E80B4 for <uri-review@ietf.org>; Tue, 25 Jun 2013 23:59:19 -0700 (PDT)
Received: by mail-wg0-f53.google.com with SMTP id y10so10169673wgg.20 for <uri-review@ietf.org>; Tue, 25 Jun 2013 23:59:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dXfAeNGtdWbvfoU/FJYv+V+Wu9gCt57rk69C3HW58x8=; b=QDwb93VnZEhKcEkwdwymIZ6cPmzj7o8+b7wPyvsPQoZhiYwIAvHzpC+WZ5THNwlqSI qdLCF4s3us+sPfJYmaJ0kjdjGUd8uDW9NDMCw6OnAv6c0NQ3t8Nt4HoK6fmzTGrOTR4u rgdrG10F9/RUHSAZS7nwewcm1QLgOiVBfnHv8nWdlk1uqDO5HHrf9+JnXzm6xlZ2Ugs5 L3OepYH23VvZBK0mxoO+7qhdzeFdlTpR4xNK25N8xrnImZOSmTjciMF+HQqjopTGf+JB W0q4UGXq18a+0iyyKmKbpU1OBXiD1h6+qug+vmPrh/7YHcK7Chbv44/e1h6oNk7INTem kFOw==
MIME-Version: 1.0
X-Received: by 10.180.36.36 with SMTP id n4mr11524502wij.0.1372229958454; Tue, 25 Jun 2013 23:59:18 -0700 (PDT)
Received: by 10.194.243.193 with HTTP; Tue, 25 Jun 2013 23:59:18 -0700 (PDT)
In-Reply-To: <CAB5WduAWR+cxuMDfCsrs1az19=0gX10sbnkqSKnifePgD4=4Lg@mail.gmail.com>
References: <CAB5WduCMF+HMyHPFU1bJkOcbzpyAM063XvCM-uDn2zGAoZkFEg@mail.gmail.com> <C68CB012D9182D408CED7B884F441D4D3471E4101A@nambxv01a.corp.adobe.com> <CAB5WduCz4nRSeMUVKnjmUNEDxzRB54khCiU2-1sqCYr1TKLSFA@mail.gmail.com> <CAB5WduAmmMkwBs5fU4Nzz1S8mTqn_oBp+7j0APSOib51OVSdTA@mail.gmail.com> <C68CB012D9182D408CED7B884F441D4D347221DBE6@nambxv01a.corp.adobe.com> <CAB5WduBfMNnTx1sj2C14vkZRJ+9bibxY=Ee4c6K0KwJF4FQpuw@mail.gmail.com> <C68CB012D9182D408CED7B884F441D4D347221DC55@nambxv01a.corp.adobe.com> <CAB5WduAWR+cxuMDfCsrs1az19=0gX10sbnkqSKnifePgD4=4Lg@mail.gmail.com>
Date: Wed, 26 Jun 2013 02:59:18 -0400
Message-ID: <CAB5WduCvMZWu0wLt4Lu2RLTRHtyQv77s4ymy4wtcP9e1OOxvSA@mail.gmail.com>
From: DataPacRat <datapacrat@gmail.com>
To: Larry Masinter <masinter@adobe.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "uri-review@ietf.org" <uri-review@ietf.org>
Subject: Re: [Uri-review] Initial inquiry into URI proposal (nym)
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/uri-review>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jun 2013 06:59:20 -0000

In order to try to evoke whatever constructive criticism might be
found here, I'll try one last time to offer an explanation of why I
think nym has useful potential. Should no such suggestions be
forthcoming, well, I'll have at least given my best shot here.


The problem:

The Certificate Authority (CA) model of authentication on the web is
broken, in ways both several and serious. There are far too many CAs
who are supposed to be trustworthy but aren't; fraudulent certificates
are known to have been issued; man-in-the-middle attacks have been
done. One of the main reasons for such problems seems to stem from a
fundamental assumption of the security model used: a CA is either
trusted, or it isn't.

The web-of-trust model offered by PGP/GnuPG improves on those
assumptions slightly, by offering an additional level of moderate
trust - if enough moderately trusted authorities all support a
certificate or key as being connected to a digital identity, then that
key is assumed to be accurate. Statistical analysis of a large
population of keys allows for somewhat more complicated key
verification, but tends to be impractical for the individual user.


A possible solution, or at least potential improvement:

There's a whole host of mathematics to support the idea that when
faced with an incomplete set of evidence about any fact (such as
whether a key is tied to an individual), the best possible solution is
to use Bayesian analysis. This involves measuring confidences, and
updating them as new evidence is learned, in a particular fashion. (
http://yudkowsky.net/rational/bayes is one introduction to this math.)

The purpose of nym is to leverage as many of the available and
existing technologies as possible, in order to allow a user to apply
Bayesian reasoning to identity verification, as easily as possible;
without being tied to any particular piece of software. The output of
one set of Bayesian reasoning, asserted by a particular authority, can
be used as the input for anyone else's Bayesian analysis. Thus,
instead of the mere two levels of 'trusted' or 'untrusted' used by
CAs, or the three levels used by PGP, users can use an infinite number
of shades of gray to describe exactly how likely it really is that a
given key represents a given individual.



I've run through a few drafts, adding and deleting details; but I
think the above covers all the core points without getting bogged
down.

I'm unaware of any existing solution to the above problem that meets
the described requirements. It would be reasonably simple to cobble
together a piece of software to, for example, replace GnuPG's
web-of-trust model with a Bayesian function; but that would only solve
a small piece of the problem, for one particular group of
keys/identities. However, putting together a URI, which is designed to
point to the abstract identity pointed at by a particular email
address or social media profile, seems to be at least as within the
spirit of URIs in general as tag: is; and offers the potential for
interacting with any form of encryption software, existing or
yet-to-be-written (in much the way that ftp: and telnet: did when
http: came along).



If you feel that the core problem isn't important enough for a URI to
be used as a solution, that's one possible discussion. If you feel
that using a URI is an inappropriate way to solve it, that's another
possible discussion. And if you feel that some URI may be a good idea,
but my initial ideas for nym: are bad, that's yet another possible
discussion. But if you do reply, I would greatly appreciate if you
would, at the very least, let me know at which point you feel nym:
fails, instead of simply offering a generic 'it's a bad idea' without
any specifics. The former sort of response offers something to build
upon, even if it's to build an entirely different solution; the latter
is hard to distinguish from a personal opinion which may or may not be
relevant to the issue at hand.


I look forward to my ideas being torn apart in as much detail as possible.



Thank you for your time,
--
DataPacRat
"May accuracy triumph over victory."