Re: [plasma] Advanced Policies

"Jim Schaad" <jimsch@nwlink.com> Sun, 07 August 2011 06:33 UTC

Return-Path: <jimsch@nwlink.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 B46EB21F85A1 for <plasma@ietfa.amsl.com>; Sat, 6 Aug 2011 23:33:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 3kuVHsrdMT-c for <plasma@ietfa.amsl.com>; Sat, 6 Aug 2011 23:33:34 -0700 (PDT)
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 013DD21F85A0 for <plasma@ietf.org>; Sat, 6 Aug 2011 23:33:33 -0700 (PDT)
Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.pacifier.net (Postfix) with ESMTPS id A983A2CA29; Sat, 6 Aug 2011 23:33:55 -0700 (PDT)
From: "Jim Schaad" <jimsch@nwlink.com>
To: "'Fitch, Scott C'" <scott.c.fitch@lmco.com>, <plasma@ietf.org>
References: <001401cc547f$ad8ab430$08a01c90$@nwlink.com> <3AED781EC260354F87ADB219D005398748CF9D124E@HVXMSP1.us.lmco.com>
In-Reply-To: <3AED781EC260354F87ADB219D005398748CF9D124E@HVXMSP1.us.lmco.com>
Date: Sun, 7 Aug 2011 00:08:19 -0700
Message-ID: <002601cc54d0$cb000a50$61001ef0$@nwlink.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHd+jKThac3WKtbttE5e1U+p9QrY5TtrLFw
Content-Language: en-us
Subject: Re: [plasma] Advanced Policies
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, 07 Aug 2011 06:33:34 -0000

Yes, this is a reasonable description.

As with you I am worried that there will be a few people that will be
overwhelmed, but they are going to be the ones who are going to be
overwhelmed in any event by having to do lots of decisions about setting
policies on messages.

Jim


> -----Original Message-----
> From: Fitch, Scott C [mailto:scott.c.fitch@lmco.com]
> Sent: Saturday, August 06, 2011 3:07 PM
> To: 'plasma@ietf.org'.org'; 'jimsch@nwlink.com'
> Subject: RE: [plasma] Advanced Policies
> 
> Ok. I think it's coming together for me, including my other comments on
PEP
> bootstrapping. To test my understanding, the Roles from the PDP could be
> thought of as "policy collections" and the Policies as a pointer to all
the
> resource attributes that the PDP needs to make its access decision. Is
that a
> correct (re)characterization?
> 
> I definitely agree with Trevor about limiting the inputs that a user needs
to
> make, particularly for email, which most users take a ready-fire-aim
approach
> to. So the question that comes to mind is whether there are other uses of
> those attributes outside of plasma that may be helpful in having available
> directly in the message? Document retention/destruction and search are two
> that come to mind.
> 
> Another conderation is the number of individual policies that this
approach
> results in, particularly for organizations that have thousands of active
licenses
> and agreements.
> 
> This is really an architecture allocation question: what component(s) are
> responsible for managing and resolving the individual resource attributes.
It
> needs to be done somewhere, and plasma is recommending the PDP. I'm
> content to have a better understanding (I hope) of the plasma approach for
> the moment. I know Trevor has thought this through a lot and will be quite
> happy to share his views when he get back. Please do correct me if my
> understanding is still off or if you disagree with the considerations
above
> though.
> 
> Scott
> ------
> Sent from my BlackBerry
> 
> ----- Original Message -----
> From: Jim Schaad [mailto:jimsch@nwlink.com]
> Sent: Saturday, August 06, 2011 05:27 PM
> To: Fitch, Scott C; plasma@ietf.org <plasma@ietf.org>
> Subject: EXTERNAL: RE: [plasma] Advanced Policies
> 
> Having separate threads is frequently simpler so I have no objections to
that.
> 
> I really wish Trevor was not on vacation so he could respond.  Instead I
will
> attempt to channel him and try not to get things really wrong.
> 
> Based on previous conversations that I have had with Trevor (including
last
> week at the Plasma side bar), the assumption we are working on is that
users
> are not the brightest of people and things should be made as simple as
> possible for them.   One of the corollaries of this is that options should
> generally not be given to users for configuration purposes.  This means
that
> there is no expectation that a generic ITAR policy would ever exist for a
> company.   Instead you would define a different policy for each of the
ITAR
> export licenses/ projects.
> 
> Thus if you work on aircraft as an engineer, you would choose a role for a
> specific plane and get a small list of policies.  It might be that the
end-user
> would not even see that it was ITAR export controlled, but rather just
that it
> is internal, external for that specific project.
> 
> The more options that make the end user select, the more likely that are
to
> get things wrong has been a basic philosophy that Trevor has espoused
> during
> the design.   Counter arguments would be interesting, but probably better
> after he gets back at the end of the month.
> 
> Jim
> 
> 
> > -----Original Message-----
> > From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On
> > Behalf Of Fitch, Scott C
> > Sent: Thursday, August 04, 2011 2:05 PM
> > To: plasma@ietf.org
> > Subject: [plasma] Advanced Policies
> >
> > (Apologies for all the posts. Just trying to keep the threads separate
> > for
> > commenting.)
> >
> > It's important to acknowledge that many Advanced policies will
> > required information about the message beyond just the Policy
> > identifier. An
> example
> > from the export control world: An email may be governed by the ITAR
> policy,
> > however, access control decisions are made based ITAR and the specific
> > export license or agreement that applies to the message. Simply
> identifying
> > that the document is export controlled doesn't given the PDP enough
> > information to make a grant or deny decision.
> >
> > Stated differently, an access decision is based on attributes about
> > the requester, resource, environment, and action. The plasma scenarios
> > for Advanced Policies should include the ability to convey attributes
> > (labels) about the message (including, but not limited to the policy
> > identifier)
> and
> > attributes about the recipient.
> >
> >
> >
> >
> >
> > Scott Fitch
> > Cyber Architect
> > Lockheed Martin Enterprise Business Services
> >
> >
> > _______________________________________________
> > plasma mailing list
> > plasma@ietf.org
> > https://www.ietf.org/mailman/listinfo/plasma
>