Re: [plasma] Delegation scenario
"Skedd, Richard (UK)" <Richard.Skedd@baesystems.com> Tue, 06 December 2011 13:56 UTC
Return-Path: <Richard.Skedd@baesystems.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 8110A21F8B3F for <plasma@ietfa.amsl.com>;
Tue, 6 Dec 2011 05:56:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.48
X-Spam-Level:
X-Spam-Status: No,
score=0.48 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FRT_ROLEX=3.878,
HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4]
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 7TPsFmH0v5lp for
<plasma@ietfa.amsl.com>; Tue, 6 Dec 2011 05:56:05 -0800 (PST)
Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by
ietfa.amsl.com (Postfix) with ESMTP id 8706B21F8B3D for <plasma@ietf.org>;
Tue, 6 Dec 2011 05:56:04 -0800 (PST)
X-IronPort-AV: E=Sophos; i="4.71,306,1320624000"; d="scan'208,217";
a="174797255"
Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by
Baemasodc001ir.sharelnk.net with ESMTP; 06 Dec 2011 13:56:03 +0000
Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193])
by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id
pB6Du26M015812; Tue, 6 Dec 2011 13:56:03 GMT
Received: from GLKMS2105.GREENLNK.NET ([10.15.184.96]) by
glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675);
Tue, 6 Dec 2011 13:56:02 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01CCB41E.CA6893E4"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 6 Dec 2011 13:56:02 -0000
Message-ID: <CB55784F96DEBE4B972015A2587A1DA002D2DA2B@GLKMS2105.GREENLNK.NET>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Delegation scenario
thread-index: AcyTPvJuZ6lTqdglQi+54J/v8g5UNQCWpMtQByQ9/MAAe836IA==
From: "Skedd, Richard (UK)" <Richard.Skedd@baesystems.com>
To: "Fitch, Scott C" <scott.c.fitch@lmco.com>,
"Trevor Freeman" <trevorf@exchange.microsoft.com>, <plasma@ietf.org>
X-OriginalArrivalTime: 06 Dec 2011 13:56:02.0804 (UTC)
FILETIME=[CA9A7340:01CCB41E]
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: Tue, 06 Dec 2011 13:56:08 -0000
Plasma certainly provides an opportunity to take an approach that would be preferable to that which we end up doing today. A few thoughts to add to Scott's: Although we typically describe this as a delegation scenario, I would describe it as one case of a shared mailbox scenario. There are a number of these but I don't think that the relationships between the members of the team using the shared mailbox are important for plasma. This could equally apply to members of a design team, a family or a medical practice. Messages will arrive in the mailbox. Access to an individual message is dependent upon the sensitivity of the message and the privileges of the user accessing the mailbox. Privileges are assigned for a period which may itself be dependent on certain conditions. There are many examples: - Executive - has an assistant that is authorised for company proprietary whilst she holds her position but not personal - Manager - has a colleague that is authorised for project x information whilst the worker is on vacation but not project y - Engineer - is one of five on the team that are authorised for proprietary information from company a whilst they hold their positions but not company b - Father - has two daughters that are authorised for notices about school events whilst they are students at the school but not an appointment with a doctor - Doctor - has a number of nurses that are authorised for messages about the doctor's patients whilst they are on duty and assigned to work with the doctor but not practice management information The impact of this capability on how we choose to establish and manage e-mail addresses is another thread of discussion ... Regards Richard Skedd Strategy Manager - Office of the CIO T: +44 117 918 8034 (vnet 7658 8034) M: +44 780 171 8260 (vnet 777118260) BAE Systems plc Registered Office: 6 Carlton Gardens, London, SW1Y 5AD, UK Registered in England & Wales No: 1470151 From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of Fitch, Scott C Sent: 04 December 2011 02:21 To: Trevor Freeman; plasma@ietf.org Subject: Re: [plasma] Delegation scenario *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet. Keep this in mind if you answer this message. 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] On Behalf Of Fitch, Scott C Sent: Tuesday, October 25, 2011 10:57 AM To: 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 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ********************************************************************
- [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)