Re: [plasma] Delegation scenario
"Fitch, Scott C" <scott.c.fitch@lmco.com> Sun, 04 December 2011 02:21 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 A6C901F0C35 for <plasma@ietfa.amsl.com>; Sat, 3 Dec 2011 18:21:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.72
X-Spam-Level:
X-Spam-Status: No, score=-6.72 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ROLEX=3.878, HTML_MESSAGE=0.001, 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 6X2iQJgzXS3E for <plasma@ietfa.amsl.com>; Sat, 3 Dec 2011 18:21:14 -0800 (PST)
Received: from mailfo02.lmco.com (mailfo02.lmco.com [192.35.35.12]) by ietfa.amsl.com (Postfix) with ESMTP id DF8F221F8D10 for <plasma@ietf.org>; Sat, 3 Dec 2011 18:21:13 -0800 (PST)
Received: from emss07g01.ems.lmco.com ([166.29.2.16]) by mailfo02.lmco.com (8.14.3/8.14.3) with ESMTP id pB42L8De002656; Sun, 4 Dec 2011 02:21:08 GMT
Received: from CONVERSION2-DAEMON.lmco.com by lmco.com (PMDF V6.4 #31805) id <0LVN00601QJ5S5@lmco.com>; Sun, 04 Dec 2011 02:21:05 +0000 (GMT)
Received: from HDXHTPN6.us.lmco.com ([158.188.83.13]) by lmco.com (PMDF V6.4 #31805) with ESMTP id <0LVN002NJQJ0M1@lmco.com>; Sun, 04 Dec 2011 02:21:00 +0000 (GMT)
Received: from HDXDSP11.us.lmco.com ([fe80::c04a:c222:3486:3e3]) by HDXHTPN6.us.lmco.com ([fe80::1db3:a00c:a3c9:9df6%14]) with mapi id 14.01.0355.002; Sat, 03 Dec 2011 19:21:00 -0700
Date: Sun, 04 Dec 2011 02:20:58 +0000
From: "Fitch, Scott C" <scott.c.fitch@lmco.com>
In-reply-to: <E545B914D50B2A4B994F198378B1525D42750872@DF-M14-11.exchange.corp.microsoft.com>
X-Originating-IP: [158.188.95.10]
To: Trevor Freeman <trevorf@exchange.microsoft.com>, "plasma@ietf.org" <plasma@ietf.org>
Message-id: <DFE85D7EFA640D4886E9A9141AEBCD2010DAA7CF@HDXDSP11.us.lmco.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_uhqKlULc896n1TmotPYXCw)"
Content-language: en-US
Thread-Topic: Delegation scenario
Thread-Index: AcyTPvJuZ6lTqdglQi+54J/v8g5UNQCWpMtQByQ9/MA=
Accept-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
References: <DFE85D7EFA640D4886E9A9141AEBCD200A097B8A@HDXDSP11.us.lmco.com> <E545B914D50B2A4B994F198378B1525D42750872@DF-M14-11.exchange.corp.microsoft.com>
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110, 1.0.211, 0.0.0000 definitions=2011-12-04_01:2011-12-02, 2011-12-04, 1970-01-01 signatures=0
Subject: Re: [plasma] Delegation scenario
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: Sun, 04 Dec 2011 02:21:17 -0000
Trevor, et al-
Sorry it took me so long to reply on this. Anyway, I can see two scenarios, and two ways that a Plasma implementation could met the requirements.
The first delegation scenario is a persistent delegation such as between a Boss and an Administrative assistant. In this case, the Admin gets to read (most of) the Boss's email.
The second scenario is temporary delegation, such as assigning a role to an individual while on vacation. In this case, the delegate only has access to the messages while the delegator is on vacation.
As for ways the Plasma addresses this, it can either be done through the access rules (e.g., Boss's assigned Administrative Assistant is allowed to read company proprietary information, but not personal information) or through the assertions provided to the PDP at access request (e.g., Delegate has Role X, which meets the criteria for reading the message).
In both cases, these approaches are greatly preferable to PKI-based S/MIME, which usually involves sharing private keys, removing all granularity for access.
Let me know if that's enough to go on.
-Scott
Scott Fitch
Cyber Architect
scott.c.fitch@lmco.com
From: Trevor Freeman [mailto:trevorf@exchange.microsoft.com]
Sent: Friday, October 28, 2011 1:48 PM
To: Fitch, Scott C; plasma@ietf.org
Subject: EXTERNAL: RE: Delegation scenario
That is a good observation. If you give a brief outline on how you see a scenario changing for delegation and I will incorporate that into the next version.
From: plasma-bounces@ietf.org<mailto:plasma-bounces@ietf.org> [mailto:plasma-bounces@ietf.org]<mailto:[mailto:plasma-bounces@ietf.org]> On Behalf Of Fitch, Scott C
Sent: Tuesday, October 25, 2011 10:57 AM
To: plasma@ietf.org<mailto:plasma@ietf.org>
Subject: [plasma] Delegation scenario
Plasma also opens up the opportunity to support delegation in a much more sustainable and elegant manner than current PKI-based S/MIME. I'd like to see that called out as a scenario in Section 3. Others have similar thoughts?
-Scott
- [plasma] Delegation scenario Fitch, Scott C
- Re: [plasma] Delegation scenario Trevor Freeman
- Re: [plasma] Delegation scenario Fitch, Scott C
- Re: [plasma] Delegation scenario Skedd, Richard (UK)