Re: [ltans] "Proof Source Provider" - new term for use in describing trust chains in document hierarchies

Bill Russell <brussell@pericore.com> Tue, 15 September 2009 15:28 UTC

Return-Path: <brussell@pericore.com>
X-Original-To: ltans@core3.amsl.com
Delivered-To: ltans@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F55C3A6A47 for <ltans@core3.amsl.com>; Tue, 15 Sep 2009 08:28:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.893
X-Spam-Level:
X-Spam-Status: No, score=-3.893 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
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 aMgyb7F-rTUy for <ltans@core3.amsl.com>; Tue, 15 Sep 2009 08:28:40 -0700 (PDT)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id DEF113A6976 for <ltans@ietf.org>; Tue, 15 Sep 2009 08:28:36 -0700 (PDT)
Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n8FFTCWV003804 for <ietf-ltans@imc.org>; Tue, 15 Sep 2009 08:29:23 -0700 (MST) (envelope-from brussell@pericore.com)
Received: from BH001.mail.lan ([10.110.21.101]) by mx1.myoutlookonline.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Sep 2009 11:29:11 -0400
Received: from HUB010.mail.lan ([10.110.17.10]) by BH001.mail.lan with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Sep 2009 11:29:10 -0400
Received: from HUB014.mail.lan (10.110.17.14) by HUB010.mail.lan (10.110.17.10) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 15 Sep 2009 11:29:10 -0400
Received: from MAILR003.mail.lan ([10.110.18.20]) by HUB014.mail.lan ([10.110.17.14]) with mapi; Tue, 15 Sep 2009 11:29:09 -0400
From: Bill Russell <brussell@pericore.com>
To: Todd Glassey <tglassey@earthlink.net>, "ietf-ltans@imc.org" <ietf-ltans@imc.org>
Date: Tue, 15 Sep 2009 11:28:18 -0400
Thread-Topic: [ltans] "Proof Source Provider" - new term for use in describing trust chains in document hierarchies
Thread-Index: Aco2GUT70hCyaDTSTWCXJVyouNjoZA==
Message-ID: <9DCCF5807745F9438462F1F6A66CADA403203A35D5@MAILR003.mail.lan>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginalArrivalTime: 15 Sep 2009 15:29:10.0072 (UTC) FILETIME=[4572E380:01CA3619]
X-Mailman-Approved-At: Tue, 15 Sep 2009 08:34:13 -0700
Subject: Re: [ltans] "Proof Source Provider" - new term for use in describing trust chains in document hierarchies
X-BeenThere: ltans@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: LTANS Working Group <ltans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ltans>, <mailto:ltans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ltans>
List-Post: <mailto:ltans@ietf.org>
List-Help: <mailto:ltans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ltans>, <mailto:ltans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Sep 2009 15:28:41 -0000

We (Pericore) already use that term to express digitally signed authorizations. Also, Corestreet uses that term in one of their products. I think the term is overloaded and should not be used as you propose.

-----Original Message-----
From: "Todd Glassey" <tglassey@earthlink.net>
To: "ietf-ltans@imc.org" <ietf-ltans@imc.org>
Sent: 9/15/09 11:17 AM
Subject: [ltans] "Proof Source Provider" - new term for use in describing trust chains in document hierarchies

Folks -
I want to propose a new term for describing certain relationships in a 
network model. The term is  "Proof Source Provider" or PSP and it means 
some service which is providing a trust-anchor for some other process or 
the like. The PSP is the party or system which provides the oversight 
and process control for an TRUST-ANCHOR - the component of the trust 
element which ties the specific content to that trust element. The Term 
Trust Anchor (now widely in use in Secure DNS) was coined in PKIX 
several years ago but is critically valuable now in other areas and we 
should embrace both it and the idea of the Proof Source Provider and the 
Proof Source they use to cerate admissibility for the evidence.

It (PSP)  pertains then to auditing trust relationships and their 
ability to convey policy and control over a larger methodology and is a 
key part of relational trust models which are propagated across multiple 
technologies and would be used in LTANS Security and other key processes.

Why this is important is that systems and processes which we would build 
from these technologies would also perform functions in the real world 
which would have legal implications and so the ability to represent 
trust-anchor processes in the records created would admissible in global 
courts. This nomenclature provides a resource for this and other uses.

Todd Glassey


_______________________________________________
ltans mailing list
ltans@ietf.org
https://www.ietf.org/mailman/listinfo/ltans