From ietf@augustcellars.com Wed Aug 3 19:24:29 2011 Return-Path: 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 8A96921F874A; Wed, 3 Aug 2011 19:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auuDJhgaVLDG; Wed, 3 Aug 2011 19:24:29 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id EEB0311E80BE; Wed, 3 Aug 2011 19:24:28 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 2F3D02CA64; Wed, 3 Aug 2011 19:24:41 -0700 (PDT) From: "Jim Schaad" To: References: <20110804021935.31037.48432.idtracker@ietfa.amsl.com> In-Reply-To: <20110804021935.31037.48432.idtracker@ietfa.amsl.com> Date: Wed, 3 Aug 2011 19:58:46 -0700 Message-ID: <005f01cc5252$6ed6ab60$4c840220$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQC3pAGtK7/84McoI5riLyxIww0dIJc1W8Hg Content-Language: en-us X-Mailman-Approved-At: Wed, 03 Aug 2011 19:30:08 -0700 Cc: abfab@ietf.org, smime@ietf.org Subject: [plasma] FW: New Version Notification for draft-freeman-message-access-control-req-02.txt X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 02:24:29 -0000 Please note there is a new version of this document posted. Trevor and = I did not get finished doing all of the updates that I thought were = necessary before he went on vacation, but we did get much farther = towards a document I would consider acceptable. Please review the document with strong focus on the use cases, the model = and the requirements. Please feel free to send comments to me and Trevor, but please remove = the abfab and smime mailing lists and just leave the plasma list in your = mail. I am sending this mail to a wider set of people to try and get = more reviews. Thanks Jim -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Wednesday, August 03, 2011 7:20 PM To: ietf@augustcellars.com Cc: ppatterson@carillon.ca; ietf@augustcellars.com; = trevorf@microsoft.com Subject: New Version Notification for = draft-freeman-message-access-control-req-02.txt A new version of I-D, draft-freeman-message-access-control-req-02.txt = has been successfully submitted by Jim Schaad and posted to the IETF = repository. Filename: draft-freeman-message-access-control-req Revision: 02 Title: Requirements for Message Access Control Creation date: 2011-08-03 WG ID: Individual Submission Number of pages: 33 Abstract: There are many situations where organizations want to protect information with robust access control, either for implementation of intellectual property right protections, enforcement of information contractual confidentiality agreements or because of externally imposed legal regulations. The Enhanced Security Services (ESS) for S/MIME defines an access control mechanism which is enforced by the recipient's client after decryption of the message. The ESS = mechanism therefore is dependent on the correct access policy configuration of every recipient's client. This mechanism also provides full = access to the data to all recipients prior to the access control check which is considered to be inadequate for due to the difficulty in demonstrating policy compliance. This document lays out the deficiencies of the current ESS security label, and presents requirements for new model for doing access control to messages where the access check is performed prior to message content decryption. This new model also does not require policy configuration on the client to simplify deployment and compliance verification. The proposed model additionally provides a method where non-X.509 certificate credentials can be used for encryption/decryption of S/MIME messages. = =20 The IETF Secretariat From scott.c.fitch@lmco.com Thu Aug 4 13:56:56 2011 Return-Path: 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 7C40A21F875C for ; Thu, 4 Aug 2011 13:56:56 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rru7mvJspzEX for ; Thu, 4 Aug 2011 13:56:56 -0700 (PDT) Received: from mailfo01.lmco.com (mailfo01.lmco.com [192.31.106.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDD521F8752 for ; Thu, 4 Aug 2011 13:56:56 -0700 (PDT) Received: from mailgw1a.lmco.com (ppalertrelay.lmco.com [192.31.106.7]) by mailfo01.lmco.com (8.14.3/8.14.3) with ESMTP id p74KvBT2016965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 4 Aug 2011 21:57:11 +0100 Received: from emss07g01.ems.lmco.com (relay5.ems.lmco.com [166.29.2.16])by mailgw1a.lmco.com (LM-6) with ESMTP id p74KvBxU020914for ; Thu, 4 Aug 2011 14:57:11 -0600 (MDT) Received: from CONVERSION2-DAEMON.lmco.com by lmco.com (PMDF V6.4 #31805) id <0LPF00F018VBJV@lmco.com> for plasma@ietf.org; Thu, 04 Aug 2011 20:57:11 +0000 (GMT) Received: from hvxhtpn2.us.lmco.com ([158.186.148.31]) by lmco.com (PMDF V6.4 #31805) with ESMTP id <0LPF00EW48USHY@lmco.com> for plasma@ietf.org; Thu, 04 Aug 2011 20:57:06 +0000 (GMT) Received: from HVXMSP1.us.lmco.com ([158.186.148.20]) by hvxhtpn2.us.lmco.com ([158.186.148.31]) with mapi; Thu, 04 Aug 2011 16:57:01 -0400 Date: Thu, 04 Aug 2011 16:57:00 -0400 From: "Fitch, Scott C" To: "plasma@ietf.org" Message-id: <3AED781EC260354F87ADB219D005398748CE6E40DD@HVXMSP1.us.lmco.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Thread-Topic: PEP Bootstrapping Thread-Index: AcxS6Kpc0m214kCwTEuhM0dUX5InQw== Accept-Language: en-US acceptlanguage: 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-08-04_05:2011-08-04, 2011-08-04, 1970-01-01 signatures=0 Subject: [plasma] PEP Bootstrapping X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 20:56:56 -0000 I understand the importance of "bootstrapping" the Content Creation PEP. However, I'm not sure it's appropriate for the PDP to tell it its roles as outlined in v02. It seems to me that role (and other related information about the author) would come from the PIP and be delivered to the PDP as part of the initial bootstrap and authentication process. At that point, the PDP could reply with the set of policies available to the user. Retrieving the list of policies is itself essentially another access control decision (i.e., what types of data is this user allowed to publish?). So it seems to make sense to follow the PEP/PIP/PDP model in this interaction too. It also allows for more flexibility in determining what policies to assign to the user, beyond just Role-based access control decisions. Scott Fitch Cyber Architect Lockheed Martin Enterprise Business Services From scott.c.fitch@lmco.com Thu Aug 4 14:04:28 2011 Return-Path: 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 EA25611E8078 for ; Thu, 4 Aug 2011 14:04:28 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yI-8+0iLzRRD for ; Thu, 4 Aug 2011 14:04:28 -0700 (PDT) Received: from mailfo01.lmco.com (mailfo01.lmco.com [192.31.106.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8AD11E8077 for ; Thu, 4 Aug 2011 14:04:28 -0700 (PDT) Received: from mailgw1a.lmco.com (ppalertrelay.lmco.com [192.31.106.7]) by mailfo01.lmco.com (8.14.3/8.14.3) with ESMTP id p74L4hn7025642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 4 Aug 2011 22:04:44 +0100 Received: from emss07g01.ems.lmco.com (relay5.ems.lmco.com [166.29.2.16])by mailgw1a.lmco.com (LM-6) with ESMTP id p74L4hSI024822for ; Thu, 4 Aug 2011 15:04:43 -0600 (MDT) Received: from CONVERSION2-DAEMON.lmco.com by lmco.com (PMDF V6.4 #31805) id <0LPF00A0197VIC@lmco.com> for plasma@ietf.org; Thu, 04 Aug 2011 21:04:43 +0000 (GMT) Received: from hvxhtpn1.us.lmco.com ([158.186.148.30]) by lmco.com (PMDF V6.4 #31805) with ESMTP id <0LPF00E8B97OHY@lmco.com> for plasma@ietf.org; Thu, 04 Aug 2011 21:04:38 +0000 (GMT) Received: from HVXMSP1.us.lmco.com ([158.186.148.20]) by hvxhtpn1.us.lmco.com ([158.186.148.30]) with mapi; Thu, 04 Aug 2011 17:04:37 -0400 Date: Thu, 04 Aug 2011 17:04:36 -0400 From: "Fitch, Scott C" To: "plasma@ietf.org" Message-id: <3AED781EC260354F87ADB219D005398748CE6E40FD@HVXMSP1.us.lmco.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Thread-Topic: Advanced Policies Thread-Index: AcxS6UmRuScoFAg+Sb2nWEWAV+gK5Q== Accept-Language: en-US acceptlanguage: 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-08-04_05:2011-08-04, 2011-08-04, 1970-01-01 signatures=0 Subject: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 21:04:29 -0000 (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 From scott.c.fitch@lmco.com Thu Aug 4 13:37:37 2011 Return-Path: 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 12FA721F84D3 for ; Thu, 4 Aug 2011 13:37:37 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFu+StoBMqbB for ; Thu, 4 Aug 2011 13:37:36 -0700 (PDT) Received: from mailfo01.lmco.com (mailfo01.lmco.com [192.31.106.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8937021F84B6 for ; Thu, 4 Aug 2011 13:37:36 -0700 (PDT) Received: from mailgw1a.lmco.com (ppalertrelay.lmco.com [192.31.106.7]) by mailfo01.lmco.com (8.14.3/8.14.3) with ESMTP id p74Kbpsp023650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 4 Aug 2011 21:37:51 +0100 Received: from emss02g01.ems.lmco.com (relay2.ems.lmco.com [166.29.2.54])by mailgw1a.lmco.com (LM-6) with ESMTP id p74Kbpc1012514for ; Thu, 4 Aug 2011 14:37:51 -0600 (MDT) Received: from CONVERSION2-DAEMON.lmco.com by lmco.com (PMDF V6.4 #31805) id <0LPF00E017YV5Z@lmco.com> for plasma@ietf.org; Thu, 04 Aug 2011 20:37:51 +0000 (GMT) Received: from hvxhtpn5.us.lmco.com ([158.186.148.34]) by lmco.com (PMDF V6.4 #31805) with ESMTP id <0LPF007JP7YPTI@lmco.com> for plasma@ietf.org; Thu, 04 Aug 2011 20:37:37 +0000 (GMT) Received: from HVXMSP1.us.lmco.com ([158.186.148.20]) by hvxhtpn5.us.lmco.com ([158.186.148.34]) with mapi; Thu, 04 Aug 2011 16:37:37 -0400 Date: Thu, 04 Aug 2011 16:37:36 -0400 From: "Fitch, Scott C" To: "plasma@ietf.org" Message-id: <3AED781EC260354F87ADB219D005398748CE6E4076@HVXMSP1.us.lmco.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Thread-Topic: Security Boundary Inspection - outgoing messages Thread-Index: AcxS5MG+6UZR93WDRcaB0KoMCtIIVg== Accept-Language: en-US acceptlanguage: 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-08-04_05:2011-08-04, 2011-08-04, 1970-01-01 signatures=0 X-Mailman-Approved-At: Thu, 04 Aug 2011 15:31:52 -0700 Subject: [plasma] Security Boundary Inspection - outgoing messages X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 20:41:30 -0000 A scenario that is missing from the v02 of the document is the ability to scan outgoing messages. Plasma offers a huge improvement over current S/MIME implementations. This capability is definitely of interest to organizations who want to know what information is leaving their security boundaries via email. I recommend adding it as an additional scenario to the document and would be willing to help write it up if needed. Scott Fitch Cyber Architect Lockheed Martin Enterprise Business Services From jimsch@nwlink.com Fri Aug 5 22:21:08 2011 Return-Path: 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 0949411E807B for ; Fri, 5 Aug 2011 22:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFO-NX3SrY1l for ; Fri, 5 Aug 2011 22:21:07 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 6951E11E8070 for ; Fri, 5 Aug 2011 22:21:07 -0700 (PDT) Received: from TITUS (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp3.pacifier.net (Postfix) with ESMTPS id 24CFF38F1C; Fri, 5 Aug 2011 22:21:11 -0700 (PDT) From: "Jim Schaad" To: "'Fitch, Scott C'" , References: <3AED781EC260354F87ADB219D005398748CE6E40DD@HVXMSP1.us.lmco.com> In-Reply-To: <3AED781EC260354F87ADB219D005398748CE6E40DD@HVXMSP1.us.lmco.com> Date: Fri, 5 Aug 2011 22:54:11 -0700 Message-ID: <01b301cc53fd$77d3c3e0$677b4ba0$@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: AQG1jhaiBOeJsxyktgY5x8rTEqnVJpU82+3A Content-Language: en-us Subject: Re: [plasma] PEP Bootstrapping X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 05:21:08 -0000 > -----Original Message----- > From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On > Behalf Of Fitch, Scott C > Sent: Thursday, August 04, 2011 1:57 PM > To: plasma@ietf.org > Subject: [plasma] PEP Bootstrapping > > I understand the importance of "bootstrapping" the Content Creation PEP. > However, I'm not sure it's appropriate for the PDP to tell it its roles as > outlined in v02. It seems to me that role (and other related information > about the author) would come from the PIP and be delivered to the PDP as > part of the initial bootstrap and authentication process. At that point, the > PDP could reply with the set of policies available to the user. The model is operating under the impression that the "roles" an entity can assume is based not on configuration, but on application of policy information. This means that it is not a configured property, which would make it appropriate for a PIP but is computed based on the properties obtained from the PIP and the policy configuration in the PDP. Does this make sense? Is there something we can do to make this more clear? > > Retrieving the list of policies is itself essentially another access control > decision (i.e., what types of data is this user allowed to publish?). So it seems > to make sense to follow the PEP/PIP/PDP model in this interaction too. It also > allows for more flexibility in determining what policies to assign to the user, > beyond just Role-based access control decisions. > I believe this is what the document currently says. Do you see a need for changes here? Jim > > Scott Fitch > Cyber Architect > Lockheed Martin Enterprise Business Services > > > _______________________________________________ > plasma mailing list > plasma@ietf.org > https://www.ietf.org/mailman/listinfo/plasma From jimsch@nwlink.com Fri Aug 5 22:26:19 2011 Return-Path: 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 E49F621F874B for ; Fri, 5 Aug 2011 22:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUqKx5duTFIP for ; Fri, 5 Aug 2011 22:26:19 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA4621F874A for ; Fri, 5 Aug 2011 22:26:12 -0700 (PDT) Received: from TITUS (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.pacifier.net (Postfix) with ESMTPS id 2E0CA2CA3E; Fri, 5 Aug 2011 22:26:28 -0700 (PDT) From: "Jim Schaad" To: "'Fitch, Scott C'" , References: <3AED781EC260354F87ADB219D005398748CE6E4076@HVXMSP1.us.lmco.com> In-Reply-To: <3AED781EC260354F87ADB219D005398748CE6E4076@HVXMSP1.us.lmco.com> Date: Fri, 5 Aug 2011 22:59:43 -0700 Message-ID: <01b401cc53fe$32ea0d60$98be2820$@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: AQEZIJHBH4p619w8LwMxiZ58fbHzTZZ1urfw Content-Language: en-us Subject: Re: [plasma] Security Boundary Inspection - outgoing messages X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 05:26:20 -0000 Do you feel this needs to be a separate scenario, or can we just include it as part of the current e-mail pipelineing section and discussion transitions across boundaries in both directionsl Jim > -----Original Message----- > From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On > Behalf Of Fitch, Scott C > Sent: Thursday, August 04, 2011 1:38 PM > To: plasma@ietf.org > Subject: [plasma] Security Boundary Inspection - outgoing messages > > A scenario that is missing from the v02 of the document is the ability to scan > outgoing messages. Plasma offers a huge improvement over current S/MIME > implementations. This capability is definitely of interest to organizations who > want to know what information is leaving their security boundaries via email. > I recommend adding it as an additional scenario to the document and would > be willing to help write it up if needed. > > > Scott Fitch > Cyber Architect > Lockheed Martin Enterprise Business Services > > > _______________________________________________ > plasma mailing list > plasma@ietf.org > https://www.ietf.org/mailman/listinfo/plasma From jimsch@nwlink.com Sat Aug 6 13:52:59 2011 Return-Path: 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 52D2821F8538 for ; Sat, 6 Aug 2011 13:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kaVTEMPtGWP for ; Sat, 6 Aug 2011 13:52:58 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id CB31A21F8520 for ; Sat, 6 Aug 2011 13:52:58 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp4.pacifier.net (Postfix) with ESMTPS id 9701238F16; Sat, 6 Aug 2011 13:53:19 -0700 (PDT) From: "Jim Schaad" To: "'Fitch, Scott C'" , References: <3AED781EC260354F87ADB219D005398748CE6E40FD@HVXMSP1.us.lmco.com> In-Reply-To: <3AED781EC260354F87ADB219D005398748CE6E40FD@HVXMSP1.us.lmco.com> Date: Sat, 6 Aug 2011 14:27:40 -0700 Message-ID: <001401cc547f$ad8ab430$08a01c90$@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: AQG0Ugg4WZY2wNlSixXTMHoIU8crx5U/VwWA 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 20:52:59 -0000 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 From scott.c.fitch@lmco.com Sat Aug 6 14:38:32 2011 Return-Path: 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 9700621F8519 for ; Sat, 6 Aug 2011 14:38:32 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dybgpFzA7fJw for ; Sat, 6 Aug 2011 14:38:32 -0700 (PDT) Received: from mailfo02.lmco.com (mailfo02.lmco.com [192.35.35.12]) by ietfa.amsl.com (Postfix) with ESMTP id 07C7321F8505 for ; Sat, 6 Aug 2011 14:38:31 -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 p76LcpfV025852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 6 Aug 2011 22:38:52 +0100 Received: from emss09g01.ems.lmco.com (relay6.ems.lmco.com [166.17.13.59])by mailgw3a.lmco.com (LM-6) with ESMTP id p76LcpKQ026139for ; Sat, 6 Aug 2011 17:38:51 -0400 (EDT) Received: from CONVERSION2-DAEMON.lmco.com by lmco.com (PMDF V6.4 #31806) id <0LPJ0050104R5P@lmco.com> for plasma@ietf.org; Sat, 06 Aug 2011 21:38:51 +0000 (GMT) Received: from hvxhtpn3.us.lmco.com ([158.186.148.32]) by lmco.com (PMDF V6.4 #31806) with ESMTP id <0LPJ0075L04MWH@lmco.com> for plasma@ietf.org; Sat, 06 Aug 2011 21:38:46 +0000 (GMT) Received: from HVXMSP1.us.lmco.com ([158.186.148.20]) by hvxhtpn3.us.lmco.com ([158.186.148.32]) with mapi; Sat, 06 Aug 2011 17:38:46 -0400 Date: Sat, 06 Aug 2011 17:38:45 -0400 From: "Fitch, Scott C" In-reply-to: <01b401cc53fe$32ea0d60$98be2820$@nwlink.com> To: "'plasma@ietf.org'" Message-id: <3AED781EC260354F87ADB219D005398748CF9D124D@HVXMSP1.us.lmco.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: 7BIT Thread-Topic: [plasma] Security Boundary Inspection - outgoing messages Thread-Index: AQEZIJHBH4p619w8LwMxiZ58fbHzTZZ1urfwgAEGleM= Accept-Language: en-US acceptlanguage: 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-08-06_04:2011-08-06, 2011-08-06, 1970-01-01 signatures=0 Subject: Re: [plasma] Security Boundary Inspection - outgoing messages X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 21:38:32 -0000 I think it makes sense to include in the same section as inbound inspection. Though plasma makes outbound inspection much easier over traditional s/mime, it doesn't help inbound spam filtering. Yes, partner enterprises or large ISPs may (pre)authorize messages goings to each other (which helps with malware proliferation). But I doubt that any spammer would be so kind. So we'll still have to rely heavily on other techniques for inbound messages. ------ Sent from my BlackBerry ----- Original Message ----- From: Jim Schaad [mailto:jimsch@nwlink.com] Sent: Saturday, August 06, 2011 01:59 AM To: Fitch, Scott C; plasma@ietf.org Subject: EXTERNAL: RE: [plasma] Security Boundary Inspection - outgoing messages Do you feel this needs to be a separate scenario, or can we just include it as part of the current e-mail pipelineing section and discussion transitions across boundaries in both directionsl Jim > -----Original Message----- > From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On > Behalf Of Fitch, Scott C > Sent: Thursday, August 04, 2011 1:38 PM > To: plasma@ietf.org > Subject: [plasma] Security Boundary Inspection - outgoing messages > > A scenario that is missing from the v02 of the document is the ability to scan > outgoing messages. Plasma offers a huge improvement over current S/MIME > implementations. This capability is definitely of interest to organizations who > want to know what information is leaving their security boundaries via email. > I recommend adding it as an additional scenario to the document and would > be willing to help write it up if needed. > > > Scott Fitch > Cyber Architect > Lockheed Martin Enterprise Business Services > > > _______________________________________________ > plasma mailing list > plasma@ietf.org > https://www.ietf.org/mailman/listinfo/plasma From scott.c.fitch@lmco.com Sat Aug 6 15:06:20 2011 Return-Path: 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 2E07E21F85EE for ; Sat, 6 Aug 2011 15:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.181 X-Spam-Level: X-Spam-Status: No, score=-9.181 tagged_above=-999 required=5 tests=[AWL=-1.418, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpNq2X7fayGN for ; Sat, 6 Aug 2011 15:06:19 -0700 (PDT) Received: from mailfo02.lmco.com (mailfo02.lmco.com [192.35.35.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6218921F85B9 for ; Sat, 6 Aug 2011 15:06:18 -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 p76M6dof015404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 6 Aug 2011 23:06:39 +0100 Received: from emss04g01.ems.lmco.com (relay4.ems.lmco.com [166.17.13.122])by mailgw3a.lmco.com (LM-6) with ESMTP id p76M6dnq000359; Sat, 6 Aug 2011 18:06:39 -0400 (EDT) Received: from CONVERSION2-DAEMON.lmco.com by lmco.com (PMDF V6.4 #31806) id <0LPJ007011F34A@lmco.com>; Sat, 06 Aug 2011 22:06:39 +0000 (GMT) Received: from hvxhtpn2.us.lmco.com ([158.186.148.31]) by lmco.com (PMDF V6.4 #31806) with ESMTP id <0LPJ00B051EYPP@lmco.com>; Sat, 06 Aug 2011 22:06:34 +0000 (GMT) Received: from HVXMSP1.us.lmco.com ([158.186.148.20]) by hvxhtpn2.us.lmco.com ([158.186.148.31]) with mapi; Sat, 06 Aug 2011 18:06:33 -0400 Date: Sat, 06 Aug 2011 18:06:33 -0400 From: "Fitch, Scott C" In-reply-to: <001401cc547f$ad8ab430$08a01c90$@nwlink.com> To: "'plasma@ietf.org'" , "'jimsch@nwlink.com'" Message-id: <3AED781EC260354F87ADB219D005398748CF9D124E@HVXMSP1.us.lmco.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: 7BIT Thread-Topic: [plasma] Advanced Policies Thread-Index: AQG0Ugg4WZY2wNlSixXTMHoIU8crx5U/VwWAgAEPH9c= Accept-Language: en-US acceptlanguage: 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-08-06_04:2011-08-06, 2011-08-06, 1970-01-01 signatures=0 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 22:06:20 -0000 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 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 From jimsch@nwlink.com Sat Aug 6 23:33:34 2011 Return-Path: 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 ; 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 ; 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 ; 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" To: "'Fitch, Scott C'" , 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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'; '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 > 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 > From RNATALE@mitre.org Sun Aug 7 15:41:34 2011 Return-Path: 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 B839321F8866 for ; Sun, 7 Aug 2011 15:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 uQtETD7Zo1v3 for ; Sun, 7 Aug 2011 15:41:34 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2364321F884E for ; Sun, 7 Aug 2011 15:41:34 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C6D6221B150E for ; Sun, 7 Aug 2011 18:41:57 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C0B2621B0285 for ; Sun, 7 Aug 2011 18:41:57 -0400 (EDT) Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Sun, 7 Aug 2011 18:41:57 -0400 From: "Natale, Bob" To: "plasma@ietf.org" Date: Sun, 7 Aug 2011 18:41:56 -0400 Thread-Topic: plasma foundation reading Thread-Index: AcxVUyShF1EpNjuYS2COA+7uhjna5A== Message-ID: <17969D855F28964C88D177D45B6CDF1105743A5CCF@IMCMBX2.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01CC5531.9DB0A620" MIME-Version: 1.0 Subject: [plasma] plasma foundation reading X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2011 22:41:34 -0000 ------=_NextPart_000_0000_01CC5531.9DB0A620 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I would like to come up to speed on plasma ... can someone please provide me with a pointer to the document store or specific documents ... apologies if this is a lame request, I did a quick search at IETF.org (very quick) and saw some bits and pieces ... I can work with that if there is no more systematic alternative. The recent threads relating to aspects of policy-based management appear to intersect with a number of projects and industry standardization efforts I am working on ... and I'd like to be better informed about plasma fundamentals before jumping in as an active participant. Thanks, BobN ------=_NextPart_000_0000_01CC5531.9DB0A620 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKujCCA2Qw ggJMoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwWjESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQL ExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJDAiBgNVBAMTG01JVFJFIENvcnBvcmF0aW9uIFJvb3Qg Q0EtMTAeFw0wNjA2MDEwNDAwMDBaFw0xODA2MDEwNDAwMDBaMFoxEjAQBgNVBAoTCW1pdHJlLm9y ZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQwIgYDVQQDExtNSVRSRSBDb3Jwb3Jh dGlvbiBSb290IENBLTEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCva1qWPZiEJv5v MtCbjt0cTu0Nbn15Q1cKqQBXKi8VSH9zZPmPxfWizJJ7JSqFJ5/sLUz3NsnUVjpLYBdFcxNXnOLj XtmDPFOewm5T98NZc9wRRCiDzt4f8qsHFI19ShPiK3cN5UqtJf+i66QVLA1S6CNL6o2eGAsAl5Wn xwOh2BfcWU5fNlHDVc9KKAlDDWpHjC2LLHAUbLP4ZzMIJKcLgLKFMtgM2AEfaSHzmi7WUdUHRCtC blrF7qzPsy/jBLFrr8VcX+mb7saq95pEOilgcix0/naW7kJfM5ph7UBB+S1O/OhH+ZjQ4MjWnwE8 A/YDrQx1OVLAOi29Bsho/l8lAgMBAAGjNTAzMBIGA1UdEwEB/wQIMAYBAf8CAQMwHQYDVR0OBBYE FMdwUQDYTf7kAdRolsU9n5qX/nQvMA0GCSqGSIb3DQEBBQUAA4IBAQAa+fVfCljimBlcfWwkfJXu XNKWun9xloFKjnq6SPGgAIKi5LUDil60a0NaNGoGSO3I1xzYt7ncayh21qXulcVTDFqubSJdv51a HTuJYcYUX72LN/gSq03UVLBCJzYm7ZLUlkb2YLo7xUeZ3coLFcT5AHR36kjG4cYHqXgH0liBl8jx pN0gwgaci4sgPLUj1w4t8zoKH+zxGFwXwTP/P+etQqiJZ5T00fLLm5kz9mmnxxmmIvUGNdsCAhGh dnF24pcrR43LNgyOBJ9DPUHBNq3kUQRO48WBKxBxflOtKzsICx/HEtIABcZn7deADHcY9spULZfB nQYdEpyz5tgh7Y2qMIIDZjCCAk6gAwIBAgICWOIwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1JVFJF IENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0xMTA3MjkyMDI3MTNaFw0xMjA2MDMxNzEzMjJa MFkxEjAQBgNVBAoMCW1pdHJlLm9yZzEPMA0GA1UECwwGUGVvcGxlMRcwFQYKCZImiZPyLGQBAQwH cm5hdGFsZTEZMBcGA1UEAwwQTmF0YWxlIFJvYmVydCBDLjCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAxcodhl7C03Tq1KgkR/oNlClQgCaM+HDDDcRQ+IFekO1rrCTFRTPpIwCAift0dCTVVZO8 9AZbeDx/32UFI8WM5Cmjn+kaYo5ko3myMqvsB6Pwq6ofHg5qrC9GKHqKFViHNvlzgPJb4pP2ftFh xepA+BMxdMFgcvm7cpUmxJ/GVrMCAwEAAaOBtzCBtDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0OBBYE FEuup7JNkqrhZG934GKRLJ9Rw9HrMB8GA1UdIwQYMBaAFIe0D0iNYjNCwS1RGkgewp67CrGtMEQG A1UdHwQ9MDswOaA3oDWGM2h0dHA6Ly93d3cubWl0cmUub3JnL3RlY2gvbWlpL3BraS9jYTFfbWl0 cmVfb3JnLmNybDAcBgNVHREEFTATgRFybmF0YWxlQG1pdHJlLm9yZzANBgkqhkiG9w0BAQUFAAOC AQEAsNy2jsBcXyHgS09PV7hh3PtYr8SfVjyX4trIRkk9+vtQ83YrY9BkYVoiROnep+9VHXgdNNVy as2ch7VSrmfS5qhGkh8pO4yYLQ+DQEFOgNo1OdmXWhitC4P40kNC6ikfeKJc5gh+1ZMpvW9V9W3C xHbsVwBriwDduJxpdyP0rPVpDPDuLQi1ss/+v6umm8SRUHHaEjLA6656o18EwiPTa17OnLmePolJ Nmi17ok9/loo9Jjtp7cGzKOIPYWqMJXWUK/SJKd8HW/pfHq/tSQQHgwXU3zq4Z+a/BG7dlie79yl QKj5L1uWWNwiTzYjVERXRyfV+/hilIyvV3CudmFHFTCCA+QwggLMoAMCAQICAQUwDQYJKoZIhvcN AQEFBQAwWjESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3Jp dHkxJDAiBgNVBAMTG01JVFJFIENvcnBvcmF0aW9uIFJvb3QgQ0EtMTAeFw0wNjA2MDMxNzEzMjJa Fw0xMjA2MDMxNzEzMjJaMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNh dGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTEwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDI8HtWXRCCqBC3S7xDZ25Gzt5lQ+eGV+Uo8U8x cYb6KoakiZizqd9sU+yfSrwWqSUWyb9QRXYklDdztKvB+up70KsJtUWHvrU7Fkjt+dRaJRqw0/Yg 0bX1oB+tDwigmwAS0bMd4hpxL4zkI3gLTJ9QLoKkFlNz1mV2MtRq28mvjTsrWL7taetGwxUqEgJ+ CaI79eJVH1h5fLN5GoWsvLpi0kIm4l3RBF/Aq0pGl6TmhTrsjOvsKUcO08mztQ5OMxgFLZ9PPO0L 7DA5Onr4DdlsTKa5BwBlHCYaSNUF7ZHwyJfbpHTYiKDP73TdkAv/pum/HQOeSuVHZQWvUoEZ8GqZ AgMBAAGjgbEwga4wEgYDVR0TAQH/BAgwBgEB/wIBAjAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYE FIe0D0iNYjNCwS1RGkgewp67CrGtMB8GA1UdIwQYMBaAFMdwUQDYTf7kAdRolsU9n5qX/nQvMEgG A1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly93d3cubWl0cmUub3JnL3RlY2gvbWlpL3BraS9yb290Y2Ex X21pdHJlX29yZy5jcmwwDQYJKoZIhvcNAQEFBQADggEBAE1ubuuuKezdIgI9u15f2pI3X5EkKWqL H+nDcgB7u7rQsrRX2NVn0TZr5zQxmJKiN1zBTmtfEjY4jbDAh/rBUGjvqMg5z4iJBGUL5Xxhq0aa iJuo//xYM/OW539ZADOSOtTae6Hwp3Ikb6fWQf/rvvYtutrYIiTya7wXKl5oHk/a4gnN0T48ajzZ mLJTrzS6SIn3IXpSYRe5yIHvu0ZAFHEyXp4/MisCtCd/jxKYGEUPldgutq546IbsT4DMP32KDUzp YdzFZe2ncMitWoT8NmvXjo0loJaqD02gTXhyakSWWelYu0ueflQFgn5AKjOZt7VIlc47KdnRXEyc Z2Hs2qAxggMCMIIC/gIBATBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlm aWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTEC AljiMAkGBSsOAwIaBQCgggH1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTExMDgwNzIyNDEyN1owIwYJKoZIhvcNAQkEMRYEFHv/dzzZ9kh97sYeqzrQVJeaBZJhMHIG CSsGAQQBgjcQBDFlMGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0 ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICWOIw dAYLKoZIhvcNAQkQAgsxZaBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlm aWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTEC AljiMIGrBgkqhkiG9w0BCQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG 9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFA MA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZI AWUDBAIBMA0GCSqGSIb3DQEBAQUABIGABRr9zL5LgGwi4Jc29+OUN3eVIoMK2QssYxl3zAgwHGZD 4dhBqIkIoY9ouIAtDw8gb9H7Mo3cn3fNtas1UZR1H/4ej9XvI5VOsnVwr5Nd3J7U/lw0vCFu9AHt w9Mxb2HHHM80kUkeu/pSBMD6nAxQmYX9xF+PDguy4aCDKYyjh/MAAAAAAAA= ------=_NextPart_000_0000_01CC5531.9DB0A620-- From jimsch@nwlink.com Sun Aug 7 16:45:56 2011 Return-Path: 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 4C45E21F8879 for ; Sun, 7 Aug 2011 16:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.374 X-Spam-Level: X-Spam-Status: No, score=-3.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 7z8dpAtCuIT1 for ; Sun, 7 Aug 2011 16:45:55 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id C900021F8877 for ; Sun, 7 Aug 2011 16:45:55 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp4.pacifier.net (Postfix) with ESMTPS id 0594138EA2; Sun, 7 Aug 2011 16:46:19 -0700 (PDT) From: "Jim Schaad" To: "'Natale, Bob'" , References: <17969D855F28964C88D177D45B6CDF1105743A5CCF@IMCMBX2.MITRE.ORG> In-Reply-To: <17969D855F28964C88D177D45B6CDF1105743A5CCF@IMCMBX2.MITRE.ORG> Date: Sun, 7 Aug 2011 17:20:49 -0700 Message-ID: <004b01cc5561$073f4f40$15bdedc0$@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: AQI/c3VqpdS49Io8NB6AZ3qdusoFyJQr2rnQ Content-Language: en-us Subject: Re: [plasma] plasma foundation reading X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2011 23:45:56 -0000 The current documents that we are working with are https://datatracker.ietf.org/doc/draft-freeman-message-access-control-req https://datatracker.ietf.org/doc/draft-schaad-eps-smime/ https://datatracker.ietf.org/doc/draft-schaad-eps-trust/ We will shortly be republishing all of these documents with the plasma keyword in the file name. Jim > -----Original Message----- > From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On > Behalf Of Natale, Bob > Sent: Sunday, August 07, 2011 3:42 PM > To: plasma@ietf.org > Subject: [plasma] plasma foundation reading > > Hi, > > I would like to come up to speed on plasma ... can someone please provide > me with a pointer to the document store or specific documents ... apologies > if this is a lame request, I did a quick search at IETF.org (very quick) and saw > some bits and pieces ... I can work with that if there is no more systematic > alternative. > > The recent threads relating to aspects of policy-based management appear > to intersect with a number of projects and industry standardization efforts I > am working on ... and I'd like to be better informed about plasma > fundamentals before jumping in as an active participant. > > Thanks, > BobN From jimsch@nwlink.com Tue Aug 9 12:57:44 2011 Return-Path: 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 5CC1F5E8008; Tue, 9 Aug 2011 12:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 xoWRgghEYmmE; Tue, 9 Aug 2011 12:57:43 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id C1A655E8007; Tue, 9 Aug 2011 12:57:22 -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 037DA2CA49; Tue, 9 Aug 2011 12:57:51 -0700 (PDT) From: "Jim Schaad" To: , Date: Tue, 9 Aug 2011 13:32:30 -0700 Message-ID: <009b01cc56d3$78424940$68c6dbc0$@nwlink.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AcxW0y5cmTtvKj8iR5uKl/3SVogstw== Subject: [plasma] New draft of interest X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 19:57:44 -0000 People may be interested in the following draft. It places a security label into an email message as a rfc5322 (rfc822, rfc2822) header record. http://tools.ietf.org/html/draft-zeilenga-email-seclabel-01.html From trevorf@exchange.microsoft.com Wed Aug 24 14:22:43 2011 Return-Path: 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 A2FD621F8D65 for ; Wed, 24 Aug 2011 14:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.226 X-Spam-Level: X-Spam-Status: No, score=-110.226 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 6FhKLXkHkTQ5 for ; Wed, 24 Aug 2011 14:22:42 -0700 (PDT) Received: from mail.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id C8E6D21F8D59 for ; Wed, 24 Aug 2011 14:22:35 -0700 (PDT) Received: from df-h14-01.exchange.corp.microsoft.com (157.54.78.139) by DF-G14-02.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 14.2.202.2; Wed, 24 Aug 2011 14:23:47 -0700 Received: from PIO-MLT-05.exchange.corp.microsoft.com (157.54.94.22) by DF-H14-01.exchange.corp.microsoft.com (157.54.78.139) with Microsoft SMTP Server (TLS) id 14.2.202.4; Wed, 24 Aug 2011 14:23:46 -0700 Received: from DF-M14-12.exchange.corp.microsoft.com ([fe80::7c94:4036:120:c95f]) by PIO-MLT-05.exchange.corp.microsoft.com ([fe80::d940:e316:1daa:5e6a%10]) with mapi id 14.02.0202.002; Wed, 24 Aug 2011 14:23:46 -0700 From: Trevor Freeman To: Jim Schaad , "'Fitch, Scott C'" , "plasma@ietf.org" Thread-Topic: [plasma] PEP Bootstrapping Thread-Index: AcxS6Kpc0m214kCwTEuhM0dUX5InQwBT0VyAA5m5bJA= Date: Wed, 24 Aug 2011 21:23:45 +0000 Message-ID: References: <3AED781EC260354F87ADB219D005398748CE6E40DD@HVXMSP1.us.lmco.com> <01b301cc53fd$77d3c3e0$677b4ba0$@nwlink.com> In-Reply-To: <01b301cc53fd$77d3c3e0$677b4ba0$@nwlink.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.103] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [plasma] PEP Bootstrapping X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 21:22:43 -0000 Hi Scott, I think both the set of roles a user is able to assume and the set of polic= es a role can assert should follow the same PIP\PDP\PAP model.=20 The PDP needs a set of information to compile the list of roles and the set= of polices for each role. That information comes from either a local PIP = or as claims from remote PIP which the PDP trusts. The PDP can be aggregati= ng information here from different PIPs e.g. multiple PIP can assert differ= ent policies belong to a role. Equally under the same model I would expect the PAP to publish policy about= other aspects of its policies such as who can use a policy or what the pol= icy can be applied to, which the PDP would enforce.=20 The model is trying to ensure clean separation of responsibilities, informa= tion points publish "factual" information, policy comes from policy authori= ties and decisions and made by decision makes based on the policy and infor= mation presented.=20 Trevor -----Original Message----- From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of= Jim Schaad Sent: Friday, August 05, 2011 10:54 PM To: 'Fitch, Scott C'; plasma@ietf.org Subject: Re: [plasma] PEP Bootstrapping > -----Original Message----- > From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On=20 > Behalf Of Fitch, Scott C > Sent: Thursday, August 04, 2011 1:57 PM > To: plasma@ietf.org > Subject: [plasma] PEP Bootstrapping >=20 > I understand the importance of "bootstrapping" the Content Creation PEP. > However, I'm not sure it's appropriate for the PDP to tell it its=20 > roles as outlined in v02. It seems to me that role (and other related=20 > information about the author) would come from the PIP and be delivered=20 > to the PDP as part of the initial bootstrap and authentication=20 > process. At that point, the > PDP could reply with the set of policies available to the user. The model is operating under the impression that the "roles" an entity can = assume is based not on configuration, but on application of policy informat= ion. This means that it is not a configured property, which would make it = appropriate for a PIP but is computed based on the properties obtained from= the PIP and the policy configuration in the PDP. =20 Does this make sense? Is there something we can do to make this more clear= ? >=20 > Retrieving the list of policies is itself essentially another access control > decision (i.e., what types of data is this user allowed to publish?).=20 > So it seems > to make sense to follow the PEP/PIP/PDP model in this interaction too.=20 > It also > allows for more flexibility in determining what policies to assign to=20 > the user, > beyond just Role-based access control decisions. >=20 I believe this is what the document currently says. Do you see a need for = changes here? Jim >=20 > Scott Fitch > Cyber Architect > Lockheed Martin Enterprise Business Services >=20 >=20 > _______________________________________________ > plasma mailing list > plasma@ietf.org > https://www.ietf.org/mailman/listinfo/plasma _______________________________________________ plasma mailing list plasma@ietf.org https://www.ietf.org/mailman/listinfo/plasma From trevorf@exchange.microsoft.com Wed Aug 24 16:21:22 2011 Return-Path: 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 56C1A21F8C74 for ; Wed, 24 Aug 2011 16:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.35 X-Spam-Level: X-Spam-Status: No, score=-110.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 lflRcJYX-cVn for ; Wed, 24 Aug 2011 16:21:20 -0700 (PDT) Received: from mail.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 87AFB21F8C58 for ; Wed, 24 Aug 2011 16:21:20 -0700 (PDT) Received: from df-h14-01.exchange.corp.microsoft.com (157.54.78.139) by DF-G14-02.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 14.2.202.2; Wed, 24 Aug 2011 16:22:31 -0700 Received: from PIO-MLT-06.exchange.corp.microsoft.com (157.54.94.24) by DF-H14-01.exchange.corp.microsoft.com (157.54.78.139) with Microsoft SMTP Server (TLS) id 14.2.202.4; Wed, 24 Aug 2011 16:22:31 -0700 Received: from DF-M14-12.exchange.corp.microsoft.com ([fe80::7c94:4036:120:c95f]) by PIO-MLT-06.exchange.corp.microsoft.com ([fe80::d57f:521a:3ae6:c130%10]) with mapi id 14.02.0202.002; Wed, 24 Aug 2011 16:22:31 -0700 From: Trevor Freeman To: "Fitch, Scott C" , "'plasma@ietf.org'" , "'jimsch@nwlink.com'" Thread-Topic: [plasma] Advanced Policies Thread-Index: AcxS6UmRuScoFAg+Sb2nWEWAV+gK5QB0Q4wAAAFbpYADeSvQEA== Date: Wed, 24 Aug 2011 23:22:30 +0000 Message-ID: References: <001401cc547f$ad8ab430$08a01c90$@nwlink.com> <3AED781EC260354F87ADB219D005398748CF9D124E@HVXMSP1.us.lmco.com> In-Reply-To: <3AED781EC260354F87ADB219D005398748CF9D124E@HVXMSP1.us.lmco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.103] Content-Type: multipart/alternative; boundary="_000_E545B914D50B2A4B994F198378B1525D394DC150DFM1412exchange_" MIME-Version: 1.0 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 23:21:22 -0000 --_000_E545B914D50B2A4B994F198378B1525D394DC150DFM1412exchange_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Scott, To slightly misquote Arnold "I am back" Yes you are on the mark that a role represents a collection of policies and= each policy is represented by a unique pointer. Different projects which a= re covered by different licenses would be represented by different policies= . This model is trying to achieve two objectives 1. Make the end user choice a simple as possible even in complex env= ironments so they can pull the trigger with a little fuss a possible and st= ill get the right result 2. Not open up a can of PEP interoperability woopass that optional pa= rameters would invoke. By presenting a two level hierarchy (each user has a set of roles and each = role has a set of policies) you can in effect present a large number of com= binations of parameters to the end user without their knowledge about the d= etails of the combination or making the client more complex. It would be go= od feedback to have some estimate of the number of permutations a user woul= d be allowed to assert. This model is trading client simplicity for server complexity. I hear what = you saying about the number of instances of polices you need to create unde= r this model most of whom would have very similar rules. However I do see t= hat as a tractable problem for PAP implementations with many similarities t= o code reuse. You are saying there are a relatively small number of policy = rule sets which you want to use across a large number of instances of polic= y. As a corporation, we have standard terms and conditions for contracts wh= ich we use across thousands of contracts which all result in access to diff= erent sets of corporate assets. You need a policy authoring tool which ref= lects that reality much like we want a developer to use shared libraries fo= r common operations. Under this model a generic set of ITAR rules could exi= st as an abstract policy much like an abstract class in code, which could b= e reused across multiple instances of program policies. Trevor -----Original Message----- From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of= Fitch, Scott C Sent: Saturday, August 06, 2011 3:07 PM To: 'plasma@ietf.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 t= hought 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 app= roach to. So the question that comes to mind is whether there are other use= s of those attributes outside of plasma that may be helpful in having avail= able 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 l= icenses and agreements. This is really an architecture allocation question: what component(s) are r= esponsible for managing and resolving the individual resource attributes. I= t needs to be done somewhere, and plasma is recommending the PDP. I'm conte= nt to have a better understanding (I hope) of the plasma approach for the m= oment. 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 understand= ing 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 > Subject: EXTERNAL: RE: [plasma] Advanced Policies Having separate threads is frequently simpler so I have no objections to th= at. I really wish Trevor was not on vacation so he could respond. Instead I wi= ll 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 use= rs 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 tha= t 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 duri= ng 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:pla= sma-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 _______________________________________________ plasma mailing list plasma@ietf.org https://www.ietf.org/mailman/listinfo/plasma --_000_E545B914D50B2A4B994F198378B1525D394DC150DFM1412exchange_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Scott,

 

To slightly misquote Arnold "I am back"=

 

Yes you are on the mark that a role represents a = collection of policies and each policy is represented by a unique pointer. = Different projects which are covered by different licenses would be represe= nted by different policies. This model is trying to achieve two objectives

 

1.       Make the end  user choice a simple as possible even in complex environment= s so they can pull the trigger with a little fuss a possible and still get = the right result

2.       Not open up a can of PEP interoperability wo= opass that optional parameters would invoke.

 

By presenting a two level hierarchy (each user ha= s a set of roles and each role has a set of policies) you can in effect pre= sent a large number of combinations of parameters to the end user without t= heir knowledge about the details of the combination or making the client more complex. It would be good feedba= ck to have some estimate of the number of permutations a user would be allo= wed to assert.

 

This model is trading client simplicity for serve= r complexity. I hear what you saying about the number of instances of polic= es you need to create under this model most of whom would have very similar= rules. However I do see that as a tractable problem for PAP implementations with many similarities to code r= euse. You are saying there are a relatively small number of policy rule set= s which you want to use across a large number of instances of policy. As a = corporation, we have standard terms and conditions for contracts which we use across thousands of contracts wh= ich all result in access to different sets of corporate assets.  You need a policy authoring t= ool which reflects that reality much like we want a developer to use shared= libraries for common operations. Under this model a generic set of ITAR ru= les could exist as an abstract policy much like an abstract class in code, which could be reused across multiple inst= ances of program policies.

 

Trevor

 

-----Original Message-----
From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of= Fitch, Scott C
Sent: Saturday, August 06, 2011 3:07 PM
To: 'plasma@ietf.org'; 'jimsch@nwlink.com'
Subject: Re: [plasma] Advanced Policies

 

Ok. I think it's coming together for me, includin= g my other comments on PEP bootstrapping. To test my understanding, the Rol= es from the PDP could be thought of as "policy collections" and t= he Policies as a pointer to all the resource attributes that the PDP needs to make its access decision. Is that a corre= ct (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 w= hether there are other uses of those attributes outside of plasma that may be helpful in having available direc= tly in the message? Document retention/destruction and search are two that = come to mind.

 

Another conderation is the number of individual p= olicies that this approach results in, particularly for organizations that = have thousands of active licenses and agreements.

 

This is really an architecture allocation questio= n: what component(s) are responsible for managing and resolving the individ= ual resource attributes. It needs to be done somewhere, and plasma is recom= mending the PDP. I'm content to have a better understanding (I hope) of the plasma approach for the moment. I k= now 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 sti= ll 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 <plasm= a@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 co= uld respond.  Instead I will attempt to channel him and try not to get things real= ly wrong.

 

Based on previous conversations that I have had w= ith 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 sho= uld 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 w= ould ever exist for a

company. &n= bsp; Instead you would define a different policy for each of the ITA= R

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.<= span style=3D"mso-spacerun:yes">  It might be that the end-user would not even see that it was ITAR ex= port controlled, but rather just that it is internal, external for that spe= cific project.

 

The more options that make the end user select, t= he more likely that are to get things wrong has been a basic philosophy tha= t Trevor has espoused during

the design. = ;  Counter arguments would be interesting, but probably better<= o:p>

after he gets back at the end of the month.<= /o:p>

 

Jim

 

 

> -----Original Message-----

> From: plasma-bounces@ietf.org [mailto:plasma-bounces@i= etf.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 Adva= nced policies will

> required information about the message beyon= d 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 b= ased 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 ba= sed on attributes about

> the requester, resource, environment, and ac= tion. The plasma scenarios

> for Advanced Policies should include the abi= lity to convey attributes

> (labels) about the message (including, but n= ot limited to the policy

> identifier)

and

> attributes about the recipient.

>

>

>

>

>

> Scott Fitch

> Cyber Architect

> Lockheed Martin Enterprise Business Services=

>

>

> ____________________________________________= ___

> plasma mailing list

> plasma@iet= f.org

> h= ttps://www.ietf.org/mailman/listinfo/plasma

 

 

_______________________________________________

plasma mailing list

plasma@ietf.org=

https://www.ietf.org/mailman/listinfo/plasma

--_000_E545B914D50B2A4B994F198378B1525D394DC150DFM1412exchange_-- From trevorf@exchange.microsoft.com Thu Aug 25 10:55:56 2011 Return-Path: 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 4985721F8C6B for ; Thu, 25 Aug 2011 10:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.412 X-Spam-Level: X-Spam-Status: No, score=-110.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 26MhnFpyEzGQ for ; Thu, 25 Aug 2011 10:55:55 -0700 (PDT) Received: from mail.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id A511A21F8862 for ; Thu, 25 Aug 2011 10:55:55 -0700 (PDT) Received: from df-h14-02.exchange.corp.microsoft.com (157.54.78.140) by DF-G14-02.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 14.2.202.2; Thu, 25 Aug 2011 10:57:09 -0700 Received: from PIO-MLT-05.exchange.corp.microsoft.com (157.54.94.22) by DF-H14-02.exchange.corp.microsoft.com (157.54.78.140) with Microsoft SMTP Server (TLS) id 14.2.202.4; Thu, 25 Aug 2011 10:57:09 -0700 Received: from DF-M14-12.exchange.corp.microsoft.com ([fe80::7c94:4036:120:c95f]) by PIO-MLT-05.exchange.corp.microsoft.com ([fe80::d940:e316:1daa:5e6a%10]) with mapi id 14.02.0202.002; Thu, 25 Aug 2011 10:57:08 -0700 From: Trevor Freeman To: "Fitch, Scott C" , "'plasma@ietf.org'" Thread-Topic: [plasma] Security Boundary Inspection - outgoing messages Thread-Index: AcxS5MG+6UZR93WDRcaB0KoMCtIIVgBU/PyAACDLnYADpLd88A== Date: Thu, 25 Aug 2011 17:57:08 +0000 Message-ID: References: <01b401cc53fe$32ea0d60$98be2820$@nwlink.com> <3AED781EC260354F87ADB219D005398748CF9D124D@HVXMSP1.us.lmco.com> In-Reply-To: <3AED781EC260354F87ADB219D005398748CF9D124D@HVXMSP1.us.lmco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.103] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [plasma] Security Boundary Inspection - outgoing messages X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 17:55:56 -0000 Hi Scott, I think we can raise the bar here wrt spammers. I think it reasonable to pu= blish policy if you require inbound inspection as a default. You can always= set an exception for supersensitive content but you don't need to publish = that. Plasma does allow the mail agent to establish the authenticity of the= data without decryption because we will have a detached signature on the o= utside. If someone sends to a domain who publishes the policy for inbound i= nspection as a default and they don't permit access or the receiver doesn't= like the domain where the email comes from it then the receiver can reject= or drop the email. We will call that out in the security considerations.=20 Trevor -----Original Message----- From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of= Fitch, Scott C Sent: Saturday, August 06, 2011 2:39 PM To: 'plasma@ietf.org' Subject: Re: [plasma] Security Boundary Inspection - outgoing messages I think it makes sense to include in the same section as inbound inspection= . Though plasma makes outbound inspection much easier over traditional s/mi= me, it doesn't help inbound spam filtering. Yes, partner enterprises or lar= ge ISPs may (pre)authorize messages goings to each other (which helps with = malware proliferation). But I doubt that any spammer would be so kind. So w= e'll still have to rely heavily on other techniques for inbound messages.=20 ------ Sent from my BlackBerry ----- Original Message ----- From: Jim Schaad [mailto:jimsch@nwlink.com] Sent: Saturday, August 06, 2011 01:59 AM To: Fitch, Scott C; plasma@ietf.org Subject: EXTERNAL: RE: [plasma] Security Boundary Inspection - outgoing mes= sages Do you feel this needs to be a separate scenario, or can we just include it= as part of the current e-mail pipelineing section and discussion transitio= ns across boundaries in both directionsl Jim > -----Original Message----- > From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On=20 > Behalf Of Fitch, Scott C > Sent: Thursday, August 04, 2011 1:38 PM > To: plasma@ietf.org > Subject: [plasma] Security Boundary Inspection - outgoing messages >=20 > A scenario that is missing from the v02 of the document is the ability=20 > to scan > outgoing messages. Plasma offers a huge improvement over current=20 > S/MIME implementations. This capability is definitely of interest to organizations who > want to know what information is leaving their security boundaries via email. > I recommend adding it as an additional scenario to the document and=20 > would be willing to help write it up if needed. >=20 >=20 > Scott Fitch > Cyber Architect > Lockheed Martin Enterprise Business Services >=20 >=20 > _______________________________________________ > plasma mailing list > plasma@ietf.org > https://www.ietf.org/mailman/listinfo/plasma _______________________________________________ plasma mailing list plasma@ietf.org https://www.ietf.org/mailman/listinfo/plasma