IETF Logo Mail Archive

[plasma] Levels of assurance

"Fitch, Scott C" <scott.c.fitch@lmco.com> Tue, 25 October 2011 18:57 UTC

Return-Path: <scott.c.fitch@lmco.com>
X-Original-To: plasma@ietfa.amsl.com
Delivered-To: plasma@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3DA1F0C3F for <plasma@ietfa.amsl.com>; Tue, 25 Oct 2011 11:57:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 mPJ7OQVs4s8b for <plasma@ietfa.amsl.com>; Tue, 25 Oct 2011 11:57:30 -0700 (PDT)
Received: from mailfo02.lmco.com (mailfo02.lmco.com [192.35.35.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF781F0C3B for <plasma@ietf.org>; Tue, 25 Oct 2011 11:57:30 -0700 (PDT)
Received: from mailgw3a.lmco.com (mailgw3a.lmco.com [192.35.35.7]) by mailfo02.lmco.com (8.14.3/8.14.3) with ESMTP id p9PIvTnZ018659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <plasma@ietf.org>; Tue, 25 Oct 2011 19:57:29 +0100
Received: from emss09g01.ems.lmco.com (relay6.ems.lmco.com [166.17.13.59])by mailgw3a.lmco.com (LM-6) with ESMTP id p9PItEd6028015for <plasma@ietf.org>; Tue, 25 Oct 2011 14:57:29 -0400 (EDT)
Received: from CONVERSION2-DAEMON.lmco.com by lmco.com (PMDF V6.4 #31806) id <0LTM00E01XXIDX@lmco.com> for plasma@ietf.org; Tue, 25 Oct 2011 18:56:30 +0000 (GMT)
Received: from HDXHTPN7.us.lmco.com ([158.188.83.14]) by lmco.com (PMDF V6.4 #31806) with ESMTP id <0LTM0078VXXLKF@lmco.com> for plasma@ietf.org; Tue, 25 Oct 2011 18:56:24 +0000 (GMT)
Received: from HDXDSP11.us.lmco.com ([fe80::c04a:c222:3486:3e3]) by HDXHTPN7.us.lmco.com ([fe80::f1:ff4b:90a4:695%14]) with mapi id 14.01.0289.001; Tue, 25 Oct 2011 12:56:12 -0600
Date: Tue, 25 Oct 2011 18:56:11 +0000
From: "Fitch, Scott C" <scott.c.fitch@lmco.com>
X-Originating-IP: [158.188.95.7]
To: "plasma@ietf.org" <plasma@ietf.org>
Message-id: <DFE85D7EFA640D4886E9A9141AEBCD200A097BE5@HDXDSP11.us.lmco.com>
MIME-version: 1.0
Content-type: text/plain; charset="us-ascii"
Content-language: en-US
Content-transfer-encoding: 7bit
Thread-Topic: Levels of assurance
Thread-Index: AcyTRx6pnTp5VUnTRUe7DOXMw+3LyQ==
Accept-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-10-25_06:2011-10-25, 2011-10-25, 1970-01-01 signatures=0
Subject: [plasma] Levels of assurance
X-BeenThere: plasma@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." <plasma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/plasma>, <mailto:plasma-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/plasma>
List-Post: <mailto:plasma@ietf.org>
List-Help: <mailto:plasma-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/plasma>, <mailto:plasma-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Oct 2011 18:57:31 -0000

Is it necessary to require levels of assurance in the Basic Policy requirements? I definitely think it's appropriate for Advanced Policies. But I wonder whether including levels of assurance in Basic Policies will impede adoption.

Also, the fact that there are multiple LOA frameworks out there makes it difficult to meet the requirement to NOT require a priori bilateral agreements between the sender and recipient for Basic Policies. If the sender and recipient use different LOA scales, then some type of prior agreement must be in place to map the two scales. I don't think plasma wants to get into the business of creating a standard LOA mapping for interoperability.

-Scott

v2.23.0 | Report a Bug | By Email