From jimsch@nwlink.com Tue Apr 5 10:57:03 2011 Return-Path: X-Original-To: plasma@core3.amsl.com Delivered-To: plasma@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA18528C13E for ; Tue, 5 Apr 2011 10:57:03 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LzN5vBvGuvt for ; Tue, 5 Apr 2011 10:57:03 -0700 (PDT) Received: from new-smtp02.pacifier.net (new-smtp02.pacifier.net [64.255.237.176]) by core3.amsl.com (Postfix) with ESMTP id 6B17D28C136 for ; Tue, 5 Apr 2011 10:57:03 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by new-smtp02.pacifier.net (Postfix) with ESMTPS id C04702CA25 for ; Tue, 5 Apr 2011 10:58:45 -0700 (PDT) From: "James Schaad" To: Date: Tue, 5 Apr 2011 11:23:38 -0700 Message-ID: <00ba01cbf3be$9acdde70$d0699b50$@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: AcvzvYROYBKQoWPqREi/HzJy+oayZg== Content-Language: en-us Subject: [plasma] Plasma Use Cases X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.9 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, 05 Apr 2011 17:57:04 -0000 I have been thinking about use cases, as well have having a couple of discussions since the BOF meeting at Prague. I think that among other things I would like to see use cases divided into three different classes, but I want to see multiple cases potentially come out of each of the classes. Class #1 - The Email usage case: These are the cases that I want to have the Plasma discussions focus on initially. These are the cases which are currently (and too briefly) covered in the current requirements draft. Class #2 - The "easy" extension cases: This class would include the simple things that people like PHB brought up at the BOF. These would include the ability to do some other simple things. For example any CMS encrypted file could use all of the things that are covered in class #1, since S/MIME is built on top of CMS, but these would require that new or additional UI be established in something other than a simple mail client. For example to encrypt and decrypt files might involve changes/extensions either to a file system, a file browser or a user application (such as Microsoft Word). Class #3 - The "hard" extension cases: There were some questions about how this could be looked at as a framework rather than as something that is only for S/MIME or CMS. Examples of this range as far as how could this be extended into PGP or the new WOES framework. I think this set of items is much more fuzzy, but it seemed to have a large number of people who were suggesting things along this line. If that is so then I would like to get some of these usage cases nailed down in more detail. Jim From trevorf@exchange.microsoft.com Wed Apr 6 12:32:03 2011 Return-Path: X-Original-To: plasma@core3.amsl.com Delivered-To: plasma@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48CDF3A6973 for ; Wed, 6 Apr 2011 12:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.998 X-Spam-Level: X-Spam-Status: No, score=-108.998 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuzO4HySgscj for ; Wed, 6 Apr 2011 12:31:42 -0700 (PDT) Received: from mail.exchange.microsoft.com (mail1.exchange.microsoft.com [131.107.1.17]) by core3.amsl.com (Postfix) with ESMTP id F0C433A63EB for ; Wed, 6 Apr 2011 12:31:36 -0700 (PDT) Received: from df-h14-01.exchange.corp.microsoft.com (157.54.78.139) by DF-G14-01.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 6 Apr 2011 12:33:21 -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.1.289.8; Wed, 6 Apr 2011 12:33:20 -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.01.0218.012; Wed, 6 Apr 2011 12:33:20 -0700 From: Trevor Freeman To: "plasma@ietf.org" Thread-Topic: why not web portal mail? Thread-Index: Acv0kXrWGetxV1fRTF6d/JQ0xrOecQ== Date: Wed, 6 Apr 2011 19:33:19 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_E545B914D50B2A4B994F198378B1525D2F49734FDFM1412exchange_" MIME-Version: 1.0 Subject: [plasma] why not web portal mail? X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 19:32:03 -0000 --_000_E545B914D50B2A4B994F198378B1525D2F49734FDFM1412exchange_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stephen Farrell asked why not use Web portal mail? Why do we need to develo= p plasma? I don't think we concisely answered that question in the BoF and it is an i= mportant data point. The web portal mail products are used where there is no way to securely del= iver sensitive mail to a recipient outside the sender's organization. The m= essage is held within the sender's organization and a notification email is= sent to the recipient. The notification email contains a HTTPS URI to the= original message with the sensitive content. This model work Ok if it is bilateral communication e.g. doctor-patient whe= re you want to reply to the sender. This has been deployed with my healthca= re provider and we can exchange messages. However the notification email = are very generic by design so it hard to find specific messages in your inb= ox other than by date and time sent. It also means useful features like inb= ox search don't work as you only have the notification message in your inbo= x. This model fails totally if it's multilateral communication where you want = to reply all or forward to messages. The message never leaves the originato= rs organization so you cannot originate new message as if it were from a re= cipient's organization. This means for business to business scenario it wou= ld hinder the use of email for collaboration. With these limitations I think it's clear that that plasma offers some sign= ificant benefits over web portal email. Dr Trevor Freeman Senior Security Strategist End to End Trust Team Microsoft Trustworthy Computing --_000_E545B914D50B2A4B994F198378B1525D2F49734FDFM1412exchange_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stephen Farrell asked why not use Web portal mail? W= hy do we need to develop plasma?

 

I don’t think we concisely answered that quest= ion in the BoF and it is an important data point.

 

The web portal mail products are used where there is= no way to securely deliver sensitive mail to a recipient outside the sende= r’s organization. The message is held within the sender’s organ= ization and a notification email is sent to the recipient.  The notification email contains a HTTPS URI to the origin= al message with the sensitive content.  

 

This model work Ok if it is bilateral communication = e.g. doctor-patient where you want to reply to the sender. This has been de= ployed with my healthcare provider and we can exchange messages.  &nbs= p;However the notification email are very generic by design so it hard to find specific messages in your inbox other than by= date and time sent. It also means useful features like inbox search don= 217;t work as you only have the notification message in your inbox.

 

This model fails totally if it’s multilateral = communication where you want to reply all or forward to messages. The messa= ge never leaves the originators organization so you cannot originate new me= ssage as if it were from a recipient’s organization. This means for business to business scenario it would hinder the use of em= ail for collaboration.

 

With these limitations I think it’s clear that= that plasma offers some significant benefits over web portal email.

 

Dr Trevor Freema= n  Senior Secur= ity Strategist

End to= End Trust Team

Microsoft Trustworth= y Computing  

 

--_000_E545B914D50B2A4B994F198378B1525D2F49734FDFM1412exchange_-- From jimsch@nwlink.com Fri Apr 8 11:00:31 2011 Return-Path: X-Original-To: plasma@core3.amsl.com Delivered-To: plasma@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CD6B3A69F4 for ; Fri, 8 Apr 2011 11:00:31 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qN0qHXn4qbc9 for ; Fri, 8 Apr 2011 11:00:30 -0700 (PDT) Received: from new-smtp01.pacifier.net (new-smtp01.pacifier.net [64.255.237.177]) by core3.amsl.com (Postfix) with ESMTP id 132563A68E0 for ; Fri, 8 Apr 2011 11:00:28 -0700 (PDT) Received: from TITUS (176.120.168.69.static.onlinenw.com [69.168.120.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by new-smtp01.pacifier.net (Postfix) with ESMTPS id 8691B2CA58 for ; Fri, 8 Apr 2011 11:02:14 -0700 (PDT) From: "James Schaad" To: Date: Fri, 8 Apr 2011 11:27:24 -0700 Message-ID: <004e01cbf61a$9ba167a0$d2e436e0$@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: Acv2D4Oy18LYwI0kTOyX2t+XCNIyYg== Content-Language: en-us Subject: [plasma] Plasma Use Cases - B2B X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 08 Apr 2011 18:00:31 -0000 Going back to the set of use cases in the draft. I am going to propose a greater set of cases that need to be looked at. Since I am still of the opinion that ABFAB provides a good architecture to build on, the terminology that I am going to use is what I consider to be the best ABFAB terms (they sometimes get themselves mixed up by multiple naming). Cases: 1. Everybody is located in one location Sender, Receiver (both subjects), RP and IdP are logically in the same location. In this case normal ABFAB processing works as everybody can easily understand what is being asked for and there is a single set of attributes that would be defined for usage. In addition to using the IdP w/EAP to get identity information, it would be avoid talking to the IdP in some situations either because of a prior communication w/ the RP. Additionally one could see the identification operation being done by the use of a locally assigned ticket when accessing the current domain (i.e. a Kerberos ticket or authenticated RPC). It would also be possible to use PKI rather than EAP as the authentication feature w/ the use of attribute certificates. 2. Sender and Receiver at different locations Location A - Sender, RP, IdP_A Location B - Receiver, IdP_B The IdPs are run by the same organization, and thus will have the same basic information. The IdPs might in fact be replications of each other (on the assumption that a person from location B should be able to login at location A). Issues that need to be address in this case are: a) What happens if the attributes that can be attested by the different IdPs are different? b) What happens if the IdPs are currently out of sync? c) What logic is needed to identify the other IdP if needed. Does this need to be supported by AAA or not? 3. Sender and Receiver at different locations - different IdP systems Location A - Sender, RP, IdP_A Location B - Receiver, IdP_B The IdPs are run by different organizations, but they have some type of basic federation infrastructure which establishes both a trust relationship as well as a policy mapping system for policy decisions. This is the classic ABFAB case. 4. Sender and Receiver at different locations - multiple RPs Location A - Sender, RP_a, IdP_A Location B - Receiver, RP_b, IdP_B In this case it is assumed that each RP is a replicate of the other (although with different keys) and that the same policy code is installed on both system. If the IdPs are not replicates, then it is assumed that the policy module at each location understand the necessary mapping of attributes. The RP_a would include lock boxes for both RP_a and RP_b in the message so that works seamlessly. In some cases the sender and receiver could be in different companies. In this case there would be questions if RP_b was under the control of company A or company B. In the first case we keep the same set of legal and fiscal liabilities - i.e. the PDP is still under the control of company A. In the second case the information release would under the control of company B which might cause problems, but would be more acceptable from a system maintenance point. (Keeping the RP_b in a DMZ might deal with some of these issues.) 5. Sender and Receiver at different locations - receiver does not have its own IdP. Location A - Sender, RP, IdP_A, IdP_external Location B - Receiver In this case there is an agreement between the two entities, but it is not a federation arrangement. Instead an IdP is provided by the sender's organization to a set of individuals external to the location by which those individuals can identify themselves to the RP. Are there other B2B cases that people can think of? Jim From stephen.farrell@cs.tcd.ie Fri Apr 8 11:32:16 2011 Return-Path: X-Original-To: plasma@core3.amsl.com Delivered-To: plasma@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B72E3A6972 for ; Fri, 8 Apr 2011 11:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.288 X-Spam-Level: X-Spam-Status: No, score=-106.288 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwNADoHRWss3 for ; Fri, 8 Apr 2011 11:32:13 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by core3.amsl.com (Postfix) with ESMTP id 735F13A695D for ; Fri, 8 Apr 2011 11:32:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 5644C3E4084; Fri, 8 Apr 2011 19:33:56 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1302287635; bh=7CqNUfZ++34pD6 +y0LjIWQcdO1UvV9O8vNSs9J0Jj+o=; b=NL5Qxx8tE/DXq0NP+2rjMNtHtnMnzZ kxtcehf/JWeJ328rLmvk3z6VbLeo74suE7Xv3nCy1DmgOXOa7NM0dxaRGTCv9/z7 dUwGeFqDW/qbEGIi9oS0ARBR4VtP120XxgeWO6rL90hLElaveKho5rIBypuEmfzx ClP/ELOjfcZwH1boSdUp2ZC2MmGGNi68ekZDBmA+oUTeR5H7QKF45wbUlt3PHVoK STSi4VNCrnWClmkkfP6mej8pzWqKBqAhAZlXE7fWLDL4feobv6PRj0C1E8Nfq3CW MP1YJdH8wCJukTwg6qXeSdJendRABxX++BhmPK3bSWTgvLtM9cpUW2/Q== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id ZKC7yPh09tsl; Fri, 8 Apr 2011 19:33:55 +0100 (IST) Received: from [10.87.48.3] (unknown [86.45.62.72]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id E82F33E406B; Fri, 8 Apr 2011 19:33:54 +0100 (IST) Message-ID: <4D9F5512.5070506@cs.tcd.ie> Date: Fri, 08 Apr 2011 19:33:54 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Trevor Freeman References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "plasma@ietf.org" Subject: Re: [plasma] why not web portal mail? X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 08 Apr 2011 18:32:16 -0000 Hi Trevor, On 06/04/11 20:33, Trevor Freeman wrote: > Stephen Farrell asked why not use Web portal mail? Why do we need to > develop plasma? > > I don’t think we concisely answered that question in the BoF and it is > an important data point. Thanks for trying now. > The web portal mail products are used where there is no way to securely > deliver sensitive mail to a recipient outside the sender’s organization. > The message is held within the sender’s organization and a notification > email is sent to the recipient. The notification email contains a HTTPS > URI to the original message with the sensitive content. Right. > This model work Ok if it is bilateral communication e.g. doctor-patient > where you want to reply to the sender. This has been deployed with my > healthcare provider and we can exchange messages. Well, its also works fine for announcements, i.e. 1:N messages. > However the > notification email are very generic by design so it hard to find > specific messages in your inbox other than by date and time sent. It > also means useful features like inbox search don’t work as you only have > the notification message in your inbox. True. However, does that mean that you'd expect the UA search function to be plasma-aware? If not, then won't the sensitive information be vulnerable in whatever search DB the UA uses? Maybe that's a question of defining the trust boundaries for this, but given that the search may be on an IMAP server its possibly complicated doing that in a secure way. > This model fails totally if it’s multilateral communication where you > want to reply all or forward to messages. Hmm. So that'd imply that forwarding etc. is an important part of the proposed work? It strikes me that that's one of the weakest aspects of generic s/mime (just from personal experience, its not something I've gone out of my way to test). There'd also be some pretty complex policy calculations to make to figure out what can be forwarded to whom, I assume, so this seems like a fairly complex area. > The message never leaves the > originators organization so you cannot originate new message as if it > were from a recipient’s organization. This means for business to > business scenario it would hinder the use of email for collaboration. I don't get that at all. But never mind. > With these limitations I think it’s clear that that plasma offers some > significant benefits over web portal email. Not that clear to me I'm afraid. While you're arguing for plasma on this basis, to judge those arguments people would need some kind of evidence that's a good bit better than just an assertion. But I'm sure you guys are working on that. S. > > > > *Dr Trevor Freeman* Senior Security Strategist > > *End to End Trust Team* > ** > > *Microsoft Trustworthy > Computing* > > > > > > _______________________________________________ > plasma mailing list > plasma@ietf.org > https://www.ietf.org/mailman/listinfo/plasma From trevorf@exchange.microsoft.com Mon Apr 11 17:02:26 2011 Return-Path: X-Original-To: plasma@ietfc.amsl.com Delivered-To: plasma@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5AC0BE0714 for ; Mon, 11 Apr 2011 17:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxBR12Z7jrge for ; Mon, 11 Apr 2011 17:02:20 -0700 (PDT) Received: from mail.exchange.microsoft.com (mail1.exchange.microsoft.com [131.107.1.17]) by ietfc.amsl.com (Postfix) with ESMTP id A39E5E0673 for ; Mon, 11 Apr 2011 17:02:16 -0700 (PDT) Received: from df-h14-02.exchange.corp.microsoft.com (157.54.78.140) by DF-G14-01.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 14.1.218.12; Mon, 11 Apr 2011 17:02:15 -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.1.289.8; Mon, 11 Apr 2011 17:02:15 -0700 Received: from DF-M14-11.exchange.corp.microsoft.com ([fe80::cc46:3da5:bed6:8dfc]) by PIO-MLT-05.exchange.corp.microsoft.com ([fe80::d940:e316:1daa:5e6a%10]) with mapi id 14.01.0218.012; Mon, 11 Apr 2011 17:02:14 -0700 From: Trevor Freeman To: Stephen Farrell Thread-Topic: [plasma] why not web portal mail? Thread-Index: Acv0kXrWGetxV1fRTF6d/JQ0xrOecQBxLT4AAJFdkKA= Date: Tue, 12 Apr 2011 00:02:14 +0000 Message-ID: References: <4D9F5512.5070506@cs.tcd.ie> In-Reply-To: <4D9F5512.5070506@cs.tcd.ie> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.101] Content-Type: multipart/alternative; boundary="_000_E545B914D50B2A4B994F198378B1525D339D558ADFM1411exchange_" MIME-Version: 1.0 Cc: "plasma@ietf.org" Subject: Re: [plasma] why not web portal mail? 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, 12 Apr 2011 00:02:26 -0000 --_000_E545B914D50B2A4B994F198378B1525D339D558ADFM1411exchange_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Steve, -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] Sent: Friday, April 08, 2011 11:34 AM To: Trevor Freeman Cc: plasma@ietf.org Subject: Re: [plasma] why not web portal mail? Hi Trevor, On 06/04/11 20:33, Trevor Freeman wrote: > Stephen Farrell asked why not use Web portal mail? Why do we need to > develop plasma? > > I don't think we concisely answered that question in the BoF and it is > an important data point. Thanks for trying now. > The web portal mail products are used where there is no way to > securely deliver sensitive mail to a recipient outside the sender's organ= ization. > The message is held within the sender's organization and a > notification email is sent to the recipient. The notification email > contains a HTTPS URI to the original message with the sensitive content. Right. > This model work Ok if it is bilateral communication e.g. > doctor-patient where you want to reply to the sender. This has been deplo= yed with my > healthcare provider and we can exchange messages. Well, its also works fine for announcements, i.e. 1:N messages. [TF] Agreed. > However the > notification email are very generic by design so it hard to find > specific messages in your inbox other than by date and time sent. It > also means useful features like inbox search don't work as you only > have the notification message in your inbox. True. However, does that mean that you'd expect the UA search function to b= e plasma-aware? If not, then won't the sensitive information be vulnerable = in whatever search DB the UA uses? Maybe that's a question of defining the trust boundaries for this, but give= n that the search may be on an IMAP server its possibly complicated doing t= hat in a secure way. [TF] Yes I expect search engines to become Plasma aware just as search engi= nes have become aware of other encrypted content types. The search engine d= oes not necessary need unrestricted access to content and the content index= ed is by definition potentially sensitive so have to be controlled. However= that process is a local UA process so is not in scope for Plasma. However = the fact that all the user content is in their inbox makes it a tractable p= roblem. > This model fails totally if it's multilateral communication where you > want to reply all or forward to messages. Hmm. So that'd imply that forwarding etc. is an important part of the propo= sed work? It strikes me that that's one of the weakest aspects of generic s= /mime (just from personal experience, its not something I've gone out of my= way to test). There'd also be some pretty complex policy calculations to m= ake to figure out what can be forwarded to whom, I assume, so this seems li= ke a fairly complex area. [TF] Not just forwarding - reply all is just as important as we have demons= trated with this thread. One of the value propositions for email is the fle= xible, multiparty nature of the asynchronous communication whereby groups o= f individuals can be part of a conversation and any recipient can participa= te in the thread or can spawn new threads just as we are doing here. The ob= jective that Plasma brings is the desire to maintain a degree of policy enf= orcement to the process when the content of the message is either sensitive= or regulated. What if, as part of my reply, I wanted to inject some inform= ation which was Microsoft confidential and was being shared under respectiv= e non-disclosure agreements? The aim of Plasma would be to allow me to add = a policy check before the decryption key to my reply was disclosed to recip= ients to ensure every recipient was in an organization which had a current = legal agreement in place. This message is using a distribution list managed= outside my organization so I cannot determine the exact list of recipients= at send time. If the mail list was an S/MIME MLA I could protect the confi= dentiality of the information so only plasma mail list subscribers can read= the content but this does not satisfy the policy requirements of determini= ng if there is a legal agreement in place. > The message never leaves the > originators organization so you cannot originate new message as if it > were from a recipient's organization. This means for business to > business scenario it would hinder the use of email for collaboration. I don't get that at all. But never mind. [TF] I think it's a critical reason for why Plasma. Consider the scenario = where this thread becomes sensitive as I suggested above and I was to use a= web portal for this reply. That portal would be hosted on a Microsoft corp= orate server since I invoked the sensitivity clause and you would have rece= ived a notification email instead of the actual email. If you were to furth= er reply all or forward that messages the origination point for that messag= e would be from a Microsoft corporate server. The Microsoft server would in= turn send out an email notification with a FROM address of stephen.farrell= @cs.tcd.ie with a url of https:\\mail.mic= rosoft.com\??? This seems a highly dubious pattern which matches the pattern used by phish= ers and spammers. How could you expect Microsoft to be authoritative for se= nding mail as someone from Trinity College Dublin to all the recipients on = the distribution list? What is the scenario was reversed and we used a web portal in your domain a= nd I still wanted to add some Microsoft sensitive information to the thread= . How would your portal know what my corporate rulers were if I were to rep= ly all? > With these limitations I think it's clear that that plasma offers some > significant benefits over web portal email. Not that clear to me I'm afraid. While you're arguing for plasma on this basis, to judge those arguments peo= ple would need some kind of evidence that's a good bit better than just an = assertion. But I'm sure you guys are working on that. [TF] Yes that is what dialog is about:) S. > > > > *Dr Trevor Freeman* Senior Security Strategist > > *End to End Trust Team* > ** > > *Microsoft Trustworthy > Computing* > > > > > > _______________________________________________ > plasma mailing list > plasma@ietf.org > https://www.ietf.org/mailman/listinfo/plasma --_000_E545B914D50B2A4B994F198378B1525D339D558ADFM1411exchange_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Steve,

 

-----Original Message-----
From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
Sent: Friday, April 08, 2011 11:34 AM
To: Trevor Freeman
Cc: plasma@ietf.org
Subject: Re: [plasma] why not web portal mail?

 

 

Hi Trevor,

 

On 06/04/11 20:33, Trevor Freeman wrote:

> Stephen Farrell asked why not use Web portal= mail? Why do we need to

> develop plasma?

>

> I don’t think we concisely answered th= at question in the BoF and it is

> an important data point.

 

Thanks for trying now.

 

> The web portal mail products are used where = there is no way to

> securely deliver sensitive mail to a recipie= nt outside the sender’s organization.

> The message is held within the sender’= s organization and a

> notification email is sent to the recipient.=   The notification email

> contains a HTTPS URI to the original message= with the sensitive content.

 

Right.

 

> This model work Ok if it is bilateral commun= ication e.g.

> doctor-patient where you want to reply to th= e sender. This has been deployed with my

> healthcare provider and we can exchange mess= ages.  

 

Well, its also works fine for announcements, i.e.= 1:N messages.

 

[TF] Agreed.

 

> However the

> notification email are very generic by desig= n so it hard to find

> specific messages in your inbox other than b= y date and time sent. It

> also means useful features like inbox search= don’t work as you only

> have the notification message in your inbox.=

 

True. However, does that mean that you'd expect t= he UA search function to be plasma-aware? If not, then won't the sensitive = information be vulnerable in whatever search DB the UA uses?

Maybe that's a question of defining the trust bou= ndaries for this, but given that the search may be on an IMAP server its po= ssibly complicated doing that in a secure way.

 

 

[TF] Yes I expect sea= rch engines to become Plasma aware just as search engines have become aware= of other encrypted content types. The search engine does not necessary nee= d unrestricted access to content and the content indexed is by definition potentially sensitive so have to be c= ontrolled. However that process is a local UA process so is not in scope fo= r Plasma. However the fact that all the user content is in their inbox make= s it a tractable problem.

 

> This model fails totally if it’s multi= lateral communication where you

> want to reply all or forward to messages.

 

Hmm. So that'd imply that forwarding etc. is an i= mportant part of the proposed work? It strikes me that that's one of the we= akest aspects of generic s/mime (just from personal experience, its not som= ething I've gone out of my way to test). There'd also be some pretty complex policy calculations to make to = figure out what can be forwarded to whom, I assume, so this seems like a fa= irly complex area.

 

 

[TF] Not just forward= ing - reply all is just as important as we have demonstrated with this thre= ad. One of the value propositions for email is the flexible, multiparty nat= ure of the asynchronous communication whereby groups of individuals can be part of a conversation and any recipi= ent can participate in the thread or can spawn new threads just as we are d= oing here. The objective that Plasma brings is the desire to maintain a deg= ree of policy enforcement to the process when the content of the message is either sensitive or regulated. = What if, as part of my reply, I wanted to inject some information which was= Microsoft confidential and was being shared under respective non-disclosur= e agreements? The aim of Plasma would be to allow me to add a policy check before the decryption key to my= reply was disclosed to recipients to ensure every recipient was in an orga= nization which had a current legal agreement in place. This message is usin= g a distribution list managed outside my organization so I cannot determine the exact list of recipients at send= time. If the mail list was an S/MIME MLA I could protect the confidentiali= ty of the information so only plasma mail list subscribers can read the con= tent but this does not satisfy the policy requirements of determining if there is a legal agreement in place.=

 

> The message never leaves the

> originators organization so you cannot origi= nate new message as if it

> were from a recipient’s organization. = This means for business to

> business scenario it would hinder the use of= email for collaboration.

 

I don't get that at all. But never mind.

 

 

[TF] I think it’= ;s a critical reason for why Plasma.  Consider the scenario where this= thread becomes sensitive as I suggested above and I was to use a web porta= l for this reply. That portal would be hosted on a Microsoft corporate server since I invoked the sensitivity clause and yo= u would have received a notification email instead of the actual email. If = you were to further reply all or forward that messages the origination poin= t for that message would be from a Microsoft corporate server. The Microsoft server would in turn send out = an email notification with a FROM address of stephen.farrell@cs.tcd.ie = with a url of https:\\mail.microsoft.com\???

This seems a highly d= ubious pattern which matches the pattern used by phishers and spammers. How= could you expect Microsoft to be authoritative for sending mail as someone= from Trinity College Dublin to all the recipients on the distribution list?

 

What is the scenario = was reversed and we used a web portal in your domain and I still wanted to = add some Microsoft sensitive information to the thread. How would your port= al know what my corporate rulers were if I were to reply all?

 

 

> With these limitations I think it’s cl= ear that that plasma offers some

> significant benefits over web portal email.<= o:p>

 

Not that clear to me I'm afraid.

 

While you're arguing for plasma on this basis, to= judge those arguments people would need some kind of evidence that's a goo= d bit better than just an assertion. But I'm sure you guys are working on t= hat.

 

[TF] Yes that is what= dialog is aboutJ<= /span>

 

S.

 

>

> 

>

> *Dr Trevor Freeman*  Senior Security St= rategist

>

> *End to End Trust Team*

> <http://www.microsoft.com/mscorp/twc/endtoendtrust/default.msp= x>**

>

> *Microsoft Trustworthy

> Computing*<http://www.microsoft.com/mscorp/twc/default.mspx>

>

> 

>

>

>

> ____________________________________________= ___

> plasma mailing list

> plasma@ietf.org

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

--_000_E545B914D50B2A4B994F198378B1525D339D558ADFM1411exchange_-- From stephen.whitlock@boeing.com Tue Apr 12 06:31:03 2011 Return-Path: X-Original-To: plasma@ietfc.amsl.com Delivered-To: plasma@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 38DD8E07A5 for ; Tue, 12 Apr 2011 06:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ep3DA5v81XDf for ; Tue, 12 Apr 2011 06:30:56 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfc.amsl.com (Postfix) with ESMTP id 889ACE078C for ; Tue, 12 Apr 2011 06:30:56 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p3CDUcaC029601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Apr 2011 06:30:38 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p3CDUbVA011924; Tue, 12 Apr 2011 08:30:37 -0500 (CDT) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p3CDUb80011914 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 12 Apr 2011 08:30:37 -0500 (CDT) Received: from XCH-NW-14V.nw.nos.boeing.com ([130.247.25.103]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Tue, 12 Apr 2011 06:30:37 -0700 From: "Whitlock, Stephen" To: Trevor Freeman , Stephen Farrell Date: Tue, 12 Apr 2011 06:30:34 -0700 Thread-Topic: [plasma] why not web portal mail? Thread-Index: Acv0kXrWGetxV1fRTF6d/JQ0xrOecQBxLT4AAJFdkKAAHnfScA== Message-ID: References: <4D9F5512.5070506@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A52A947C0EAA7F459D9469C8C887C33E2A5EC351D3XCHNW14Vnwnos_" MIME-Version: 1.0 Cc: "plasma@ietf.org" Subject: Re: [plasma] why not web portal mail? 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, 12 Apr 2011 13:31:03 -0000 --_000_A52A947C0EAA7F459D9469C8C887C33E2A5EC351D3XCHNW14Vnwnos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So, would Plasma allow me to create/modify a set of allowed recipients to a= conversation conducted over a public network by just changing policies on = the messages? And would this work across different vendor's e-mail systems? Steve W From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of= Trevor Freeman Sent: Monday, April 11, 2011 5:02 PM To: Stephen Farrell Cc: plasma@ietf.org Subject: Re: [plasma] why not web portal mail? Hi Steve, -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] Sent: Friday, April 08, 2011 11:34 AM To: Trevor Freeman Cc: plasma@ietf.org Subject: Re: [plasma] why not web portal mail? Hi Trevor, On 06/04/11 20:33, Trevor Freeman wrote: > Stephen Farrell asked why not use Web portal mail? Why do we need to > develop plasma? > > I don't think we concisely answered that question in the BoF and it is > an important data point. Thanks for trying now. > The web portal mail products are used where there is no way to > securely deliver sensitive mail to a recipient outside the sender's organ= ization. > The message is held within the sender's organization and a > notification email is sent to the recipient. The notification email > contains a HTTPS URI to the original message with the sensitive content. Right. > This model work Ok if it is bilateral communication e.g. > doctor-patient where you want to reply to the sender. This has been deplo= yed with my > healthcare provider and we can exchange messages. Well, its also works fine for announcements, i.e. 1:N messages. [TF] Agreed. > However the > notification email are very generic by design so it hard to find > specific messages in your inbox other than by date and time sent. It > also means useful features like inbox search don't work as you only > have the notification message in your inbox. True. However, does that mean that you'd expect the UA search function to b= e plasma-aware? If not, then won't the sensitive information be vulnerable = in whatever search DB the UA uses? Maybe that's a question of defining the trust boundaries for this, but give= n that the search may be on an IMAP server its possibly complicated doing t= hat in a secure way. [TF] Yes I expect search engines to become Plasma aware just as search engi= nes have become aware of other encrypted content types. The search engine d= oes not necessary need unrestricted access to content and the content index= ed is by definition potentially sensitive so have to be controlled. However= that process is a local UA process so is not in scope for Plasma. However = the fact that all the user content is in their inbox makes it a tractable p= roblem. > This model fails totally if it's multilateral communication where you > want to reply all or forward to messages. Hmm. So that'd imply that forwarding etc. is an important part of the propo= sed work? It strikes me that that's one of the weakest aspects of generic s= /mime (just from personal experience, its not something I've gone out of my= way to test). There'd also be some pretty complex policy calculations to m= ake to figure out what can be forwarded to whom, I assume, so this seems li= ke a fairly complex area. [TF] Not just forwarding - reply all is just as important as we have demons= trated with this thread. One of the value propositions for email is the fle= xible, multiparty nature of the asynchronous communication whereby groups o= f individuals can be part of a conversation and any recipient can participa= te in the thread or can spawn new threads just as we are doing here. The ob= jective that Plasma brings is the desire to maintain a degree of policy enf= orcement to the process when the content of the message is either sensitive= or regulated. What if, as part of my reply, I wanted to inject some inform= ation which was Microsoft confidential and was being shared under respectiv= e non-disclosure agreements? The aim of Plasma would be to allow me to add = a policy check before the decryption key to my reply was disclosed to recip= ients to ensure every recipient was in an organization which had a current = legal agreement in place. This message is using a distribution list managed= outside my organization so I cannot determine the exact list of recipients= at send time. If the mail list was an S/MIME MLA I could protect the confi= dentiality of the information so only plasma mail list subscribers can read= the content but this does not satisfy the policy requirements of determini= ng if there is a legal agreement in place. > The message never leaves the > originators organization so you cannot originate new message as if it > were from a recipient's organization. This means for business to > business scenario it would hinder the use of email for collaboration. I don't get that at all. But never mind. [TF] I think it's a critical reason for why Plasma. Consider the scenario = where this thread becomes sensitive as I suggested above and I was to use a= web portal for this reply. That portal would be hosted on a Microsoft corp= orate server since I invoked the sensitivity clause and you would have rece= ived a notification email instead of the actual email. If you were to furth= er reply all or forward that messages the origination point for that messag= e would be from a Microsoft corporate server. The Microsoft server would in= turn send out an email notification with a FROM address of stephen.farrell= @cs.tcd.ie with a url of https:\\mail.mic= rosoft.com\??? This seems a highly dubious pattern which matches the pattern used by phish= ers and spammers. How could you expect Microsoft to be authoritative for se= nding mail as someone from Trinity College Dublin to all the recipients on = the distribution list? What is the scenario was reversed and we used a web portal in your domain a= nd I still wanted to add some Microsoft sensitive information to the thread= . How would your portal know what my corporate rulers were if I were to rep= ly all? > With these limitations I think it's clear that that plasma offers some > significant benefits over web portal email. Not that clear to me I'm afraid. While you're arguing for plasma on this basis, to judge those arguments peo= ple would need some kind of evidence that's a good bit better than just an = assertion. But I'm sure you guys are working on that. [TF] Yes that is what dialog is about:) S. > > > > *Dr Trevor Freeman* Senior Security Strategist > > *End to End Trust Team* > ** > > *Microsoft Trustworthy > Computing* > > > > > > _______________________________________________ > plasma mailing list > plasma@ietf.org > https://www.ietf.org/mailman/listinfo/plasma --_000_A52A947C0EAA7F459D9469C8C887C33E2A5EC351D3XCHNW14Vnwnos_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

So, would Plasma allow me to create/modify a set of allowed r= ecipients to a conversation conducted over a public network by just changin= g policies on the messages? And would this work across different vendorR= 17;s e-mail systems?

 

Steve W

 

From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org= ] On Behalf Of Trevor Freeman
Sent: Monday, April 11, 2011= 5:02 PM
To: Stephen Farrell
Cc: plasma@ietf.org
= Subject: Re: [plasma] why not web portal mail?

 

= Hi Steve,

 

-----Original Message-----
From: Stephen Farrell [mail= to:stephen.farrell@cs.tcd.ie]
Sent: Friday, April 08, 2011 11:34 AM
= To: Trevor Freeman
Cc: plasma@ietf.org
Subject: Re: [plasma] why not = web portal mail?

 

 

Hi Tr= evor,

 

On 06/04/11 20:33, Trevor Freeman wrote:

> Stephen Farrell asked why not use Web portal mail?= Why do we need to

> develop plas= ma?

>

> I don’t think we concisely answered that question in = the BoF and it is

> an important = data point.

 

Thanks for trying now.

 

> The web portal mail= products are used where there is no way to

> securely deliver sensitive mail to a recipient outside the sen= der’s organization.

> The me= ssage is held within the sender’s organization and a

<= p class=3DMsoPlainText>> notification email is sent to the recipient.&nb= sp; The notification email

> cont= ains a HTTPS URI to the original message with the sensitive content.

 

Right.

 

> This model work Ok if it is bilateral communication e= .g.

> doctor-patient where you wa= nt to reply to the sender. This has been deployed with my

> healthcare provider and we can exchange messages.=   

 

Well, its also works fine for announcements, i.e. 1:N= messages.

 

[TF] Agreed.

&nbs= p;

> However the

> notification email are very generic by design so it ha= rd to find

> specific messages in= your inbox other than by date and time sent. It

> also means useful features like inbox search don’t = work as you only

> have the notif= ication message in your inbox.

&= nbsp;

True. However, does that mean that y= ou'd expect the UA search function to be plasma-aware? If not, then won't t= he sensitive information be vulnerable in whatever search DB the UA uses?

Maybe that's a question of defining th= e trust boundaries for this, but given that the search may be on an IMAP se= rver its possibly complicated doing that in a secure way.

 

 

[TF] Yes I expec= t search engines to become Plasma aware just as search engines have become = aware of other encrypted content types. The search engine does not necessar= y need unrestricted access to content and the content indexed is by definit= ion potentially sensitive so have to be controlled. However that process is= a local UA process so is not in scope for Plasma. However the fact that al= l the user content is in their inbox makes it a tractable problem.

 

> This model fails totally if it’s multilateral communicati= on where you

> want to reply all = or forward to messages.

 

Hmm. So that'd imply that forwarding etc. i= s an important part of the proposed work? It strikes me that that's one of = the weakest aspects of generic s/mime (just from personal experience, its n= ot something I've gone out of my way to test). There'd also be some pretty = complex policy calculations to make to figure out what can be forwarded to = whom, I assume, so this seems like a fairly complex area.

 

 

[TF] Not just fo= rwarding - reply all is just as important as we have demonstrated with this= thread. One of the value propositions for email is the flexible, multipart= y nature of the asynchronous communication whereby groups of individuals ca= n be part of a conversation and any recipient can participate in the thread= or can spawn new threads just as we are doing here. The objective that Pla= sma brings is the desire to maintain a degree of policy enforcement to the = process when the content of the message is either sensitive or regulated. W= hat if, as part of my reply, I wanted to inject some information which was = Microsoft confidential and was being shared under respective non-disclosure= agreements? The aim of Plasma would be to allow me to add a policy check b= efore the decryption key to my reply was disclosed to recipients to ensure = every recipient was in an organization which had a current legal agreement = in place. This message is using a distribution list managed outside my orga= nization so I cannot determine the exact list of recipients at send time. I= f the mail list was an S/MIME MLA I could protect the confidentiality of th= e information so only plasma mail list subscribers can read the content but= this does not satisfy the policy requirements of determining if there is a= legal agreement in place.

 

> The message never leaves the=

> originators organization so you= cannot originate new message as if it

> were from a recipient’s organization. This means for business= to

> business scenario it would = hinder the use of email for collaboration.

 

I don't get that at all.= But never mind.

 

 

[TF] I think it’s a critical reason for why Plasma.=  Consider the scenario where this thread becomes sensitive as I sugge= sted above and I was to use a web portal for this reply. That portal would = be hosted on a Microsoft corporate server since I invoked the sensitivity c= lause and you would have received a notification email instead of the actua= l email. If you were to further reply all or forward that messages the orig= ination point for that message would be from a Microsoft corporate server. = The Microsoft server would in turn send out an email notification with a FR= OM address of stephen.farrell@= cs.tcd.ie with a url of https:\\mail.microsoft.com\???

This seems a highl= y dubious pattern which matches the pattern used by phishers and spammers. = How could you expect Microsoft to be authoritative for sending mail as some= one from Trinity College Dublin to all the recipients on the distribution l= ist?

 

What is the scenario was reversed and we used a web portal in your = domain and I still wanted to add some Microsoft sensitive information to th= e thread. How would your portal know what my corporate rulers were if I wer= e to reply all?

 

&nbs= p;

> With these limitations I think it&= #8217;s clear that that plasma offers some

> significant benefits over web portal email.

 

Not that cl= ear to me I'm afraid.

 

While you're arguing for plasma on this basis= , to judge those arguments people would need some kind of evidence that's a= good bit better than just an assertion. But I'm sure you guys are working = on that.

 

[TF] Yes that is what dialog is aboutJ=

 

S.

 <= /p>

>

>=  

>

> *Dr Trevor Freeman*  Senior Security Strategist

>

> *End to End Trust Team*

&g= t; <http://www.mic= rosoft.com/mscorp/twc/endtoendtrust/default.mspx>**

>

&g= t; *Microsoft Trustworthy

> Comput= ing*<http://www.microsoft.com/ms= corp/twc/default.mspx>

= >

> 

>

>

>

> _______________________________________________

> plasma mailing list

> plasma@ietf.org

> https://www.ietf.o= rg/mailman/listinfo/plasma

= --_000_A52A947C0EAA7F459D9469C8C887C33E2A5EC351D3XCHNW14Vnwnos_-- From leifj@mnt.se Tue Apr 12 07:21:31 2011 Return-Path: X-Original-To: plasma@ietfc.amsl.com Delivered-To: plasma@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6E29AE07D5 for ; Tue, 12 Apr 2011 07:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXzf8oMZqoLc for ; Tue, 12 Apr 2011 07:21:30 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfc.amsl.com (Postfix) with ESMTP id 7EB2DE07C2 for ; Tue, 12 Apr 2011 07:21:30 -0700 (PDT) Received: from [130.240.93.191] (pub93-191.pub.luth.se [130.240.93.191]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p3CELPap024822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 12 Apr 2011 16:21:28 +0200 (CEST) Message-ID: <4DA45FE5.3020102@mnt.se> Date: Tue, 12 Apr 2011 16:21:25 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: plasma@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [plasma] why not web portal mail? 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, 12 Apr 2011 14:21:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/06/2011 09:33 PM, Trevor Freeman wrote: > Stephen Farrell asked why not use Web portal mail? Why do we need to develop plasma? Maybe that question is easier to answer if we consider plasma for XMPP and not just for email. There are important differences between XMPP and email that make it much more challenging to build web-only versions of the XMPP. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2kX+UACgkQ8Jx8FtbMZndeOwCcC1BQafbUXYLHJZKxsuAcV8eS 6ukAnA0JGhMsLdmh+WG+GqEUoVMWj7+e =5lPF -----END PGP SIGNATURE----- From hallam@gmail.com Tue Apr 12 08:13:28 2011 Return-Path: X-Original-To: plasma@ietfc.amsl.com Delivered-To: plasma@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3472CE07FF for ; Tue, 12 Apr 2011 08:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRxno5kGR4AB for ; Tue, 12 Apr 2011 08:13:26 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id BAAEBE07EF for ; Tue, 12 Apr 2011 08:13:26 -0700 (PDT) Received: by vxg33 with SMTP id 33so6134327vxg.31 for ; Tue, 12 Apr 2011 08:13:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=h8p0KOaMX5Ch3ySQuM9MGae19EtkkIuYhlGldWVZmVc=; b=niY0dZuS3BK26wQ6JyVG82pgBM2Nf5ve2MVBl0bv0OtBKsWxziFVrVePXG6g1mSG/A SQJfGmTACfNS7+qDIOmMqvkj7BBm9LCZhDArHesTvC1MNQoZtxP18T8nMMS0Mrle4Fs2 4hFDvhOe/lQTGO6E0fVlXEoCP8lp+nOtht89E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xBv0blxRcefkqvzfeIeGPvzJZJVlN+JEhBleD3pv2t8m+q52VC37HcYSSh5tHmEGmP gvGH/0LxU5iifrullm4VBgA7WO99qkmnE5qVLlHMpXv22O9iPdSA24zF0OA3uuNhHrN4 2JO9a4w3QNOIVu8rWQ2HG8VaNwONQjQuUVZrI= MIME-Version: 1.0 Received: by 10.52.159.132 with SMTP id xc4mr1280540vdb.229.1302621204965; Tue, 12 Apr 2011 08:13:24 -0700 (PDT) Received: by 10.52.166.230 with HTTP; Tue, 12 Apr 2011 08:13:24 -0700 (PDT) In-Reply-To: <4DA45FE5.3020102@mnt.se> References: <4DA45FE5.3020102@mnt.se> Date: Tue, 12 Apr 2011 11:13:24 -0400 Message-ID: From: Phillip Hallam-Baker To: Leif Johansson Content-Type: multipart/alternative; boundary=bcaec53f920b33369f04a0ba2260 Cc: plasma@ietf.org Subject: Re: [plasma] why not web portal mail? 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, 12 Apr 2011 15:13:28 -0000 --bcaec53f920b33369f04a0ba2260 Content-Type: text/plain; charset=ISO-8859-1 I don't think it actually helps to artificially narrow the scope of the use cases. The real use cases here are of the form 'Alice wants to protect her information against unintended disclosure'. It may make sense to restrict the initial detailed specification to a single protocol, but the architecture has to be designed with the general case in mind from the start. Otherwise we end up with a hack that enables policy to be used with SMTP based email but nothing else. My experience is that special case protocols start off more complex and become even more so over time than proposals that start from the general case. FTP is actually a far more involved protocol than HTTP with far more features and complexity. But HTTP is actually the more flexible protocol because of that (try layering your Web Service over FTP and let me know how it works for you). Insisting on generality forces people to give up their special case hacks and results in a cleaner result. The starting point as I see it should be an identifier for security policies. Make it easy for the end user to specify that document X is under control of policy Y. Since we want the policy identifiers to be easy to remember and want an infinite registry space of them, this results in the user presentation looking something like: policyname#example.com And it is convenient to also have a URI form. policy:example.com/policyname We thus have separate forms of the identifier for human readability and machine readability. It is pretty easy to see that anyone who wants to define policies can do so by registering a domain name. Also we have a fairly clear mapping from the DNS to the some sort of policy service. The policy service is of course going to be some sort of Web Service that we discover by means of the DNS. We may well have a separate mechanism (e.g. CA certs) for establishing trust. But that is something to defer to much later. Given a web service to support the security policy management protocol we can now interrogate it to ask queries of the form 'how do I apply policy X to object Y in the context of operation Z'. So we have an architecture that is completely general and can in theory be used to support any protocol whatsoever without special casing. The next question is going to be whether the policy enforcement is going to be discretionary or mandatory (yeah, I know the terms are polluted, but I can't think of better words). The traditional approach to CRM has been to try to design systems where the data is protected with cryptography and there is no way for the end user to evade the controls. That is desirable in some cases but not if it limits the scope of the policy language to features that can be enforced cryptographically. I think that the enforcement mechanism for a policy should itself be a policy issue. So just like an auth scheme that allows username password for low security sites and requires 2 factor for banking sites, we might have a policy mechanism that might allow data controlled by a low restriction security policy to be passed with an 'advisory' note while top secret documents would be exchanged encrypted. Now as far as deployment incentives go, I think the big one for me would be to have a mechanism that would make S/MIME actually work as an email mechanism which at the moment it does not. None of the clients implement an effective cert discovery mechanism by default and so most mail is sent without S/MIME. So I would look at ways to combine the policy mechanism with the cert discovery mechanism. If PLASMA ends up being another option on a protocol with unusable implementations, there is not much point. On Tue, Apr 12, 2011 at 10:21 AM, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/06/2011 09:33 PM, Trevor Freeman wrote: > > Stephen Farrell asked why not use Web portal mail? Why do we need to > develop plasma? > > Maybe that question is easier to answer if we consider plasma for XMPP > and not just for email. There are important differences between XMPP > and email that make it much more challenging to build web-only versions > of the XMPP. > > Cheers Leif > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk2kX+UACgkQ8Jx8FtbMZndeOwCcC1BQafbUXYLHJZKxsuAcV8eS > 6ukAnA0JGhMsLdmh+WG+GqEUoVMWj7+e > =5lPF > -----END PGP SIGNATURE----- > _______________________________________________ > plasma mailing list > plasma@ietf.org > https://www.ietf.org/mailman/listinfo/plasma > -- Website: http://hallambaker.com/ --bcaec53f920b33369f04a0ba2260 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't think it actually helps to artificially narrow the scope of the= use cases.

The real use cases here are of the form '= ;Alice wants to protect her information against unintended disclosure'.= =A0

It may make sense to restrict the initial detailed spec= ification to a single protocol, but the architecture has to be designed wit= h the general case in mind from the start. Otherwise we end up with a hack = that enables policy to be used with SMTP based email but nothing else.

My experience is that special case protocols start off = more complex and become even more so over time than proposals that start fr= om the general case. FTP is actually a far more involved protocol than HTTP= with far more features and complexity. But HTTP is actually the more flexi= ble protocol because of that (try layering your Web Service over FTP and le= t me know how it works for you). Insisting on generality forces people to g= ive up their special case hacks and results in a cleaner result.


The starting point as I see it should be= an identifier for security policies. Make it easy for the end user to spec= ify that document X is under control of policy Y. Since we want the policy = identifiers to be easy to remember and want an infinite registry space of t= hem, this results in the user presentation looking something like:

policyname#example.com



We thus have separate forms of the identifier for human= readability and machine readability.


It is pretty easy to see that anyone who wants to define policies can do= so by registering a domain name. Also we have a fairly clear mapping from = the DNS to the some sort of policy service.


The policy service is of course going to= be some sort of Web Service that we discover by means of the DNS. We may w= ell have a separate mechanism (e.g. CA certs) for establishing trust. But t= hat is something to defer to much later.

Given a web service to support the security policy mana= gement protocol we can now interrogate it to ask queries of the form 'h= ow do I apply policy X to object Y in the context of operation Z'.

So we have an architecture that is completely general a= nd can in theory be used to support any protocol whatsoever without special= casing.


The next question is going= to be whether the policy enforcement is going to be discretionary or manda= tory (yeah, I know the terms are polluted, but I can't think of better = words).

The traditional approach to CRM has been to try to desi= gn systems where the data is protected with cryptography and there is no wa= y for the end user to evade the controls. That is desirable in some cases b= ut not if it limits the scope of the policy language to features that can b= e enforced cryptographically.

I think that the enforcement mechanism for a policy sho= uld itself be a policy issue. So just like an auth scheme that allows usern= ame password for low security sites and requires 2 factor for banking sites= , we might have a policy mechanism that might allow data controlled by a lo= w restriction security policy to be passed with an 'advisory' note = while top secret documents would be exchanged encrypted.


Now as far as deployment incentives go, = I think the big one for me would be to have a mechanism that would make S/M= IME actually work as an email mechanism which at the moment it does not. No= ne of the clients implement an effective cert discovery mechanism by defaul= t and so most mail is sent without S/MIME.

So I would look at ways to combine the policy mechanism= with the cert discovery mechanism.=A0

If PLASMA e= nds up being another option on a protocol with unusable implementations, th= ere is not much point.=A0



On Tue, Apr 12, 2011= at 10:21 AM, Leif Johansson <leifj@mnt.se> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/06/2011 09:33 PM, Trevor Freeman wrote:
> Stephen Farrell asked why not use Web portal mail? Why do we need to d= evelop plasma?

Maybe that question is easier to answer if we consider plasma for XMP= P
and not just for email. There are important differences between XMPP
and email that make it much more challenging to build web-only versions
of the XMPP.

=A0 =A0 =A0 =A0Cheers Leif
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2kX+UACgkQ8Jx8FtbMZndeOwCcC1BQafbUXYLHJZKxsuAcV8eS
6ukAnA0JGhMsLdmh+WG+GqEUoVMWj7+e
=3D5lPF
-----END PGP SIGNATURE-----
_________________________________________= ______
plasma mailing list
plasma@ietf.org
= https://www.ietf.org/mailman/listinfo/plasma



--
Website: http://hallambaker.com/

--bcaec53f920b33369f04a0ba2260-- From leifj@mnt.se Tue Apr 12 08:33:43 2011 Return-Path: X-Original-To: plasma@ietfc.amsl.com Delivered-To: plasma@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 390D2E07AE for ; Tue, 12 Apr 2011 08:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Et3+zPtPcFyd for ; Tue, 12 Apr 2011 08:33:42 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfc.amsl.com (Postfix) with ESMTP id 2FEE0E07EA for ; Tue, 12 Apr 2011 08:33:42 -0700 (PDT) Received: from [130.240.93.191] (pub93-191.pub.luth.se [130.240.93.191]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p3CFXZvp004957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Apr 2011 17:33:38 +0200 (CEST) Message-ID: <4DA470CF.5030001@mnt.se> Date: Tue, 12 Apr 2011 17:33:35 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <4DA45FE5.3020102@mnt.se> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: plasma@ietf.org Subject: Re: [plasma] why not web portal mail? 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, 12 Apr 2011 15:33:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/12/2011 05:13 PM, Phillip Hallam-Baker wrote: > I don't think it actually helps to artificially narrow the scope of the use > cases. > so basically you agree with me ;-) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2kcM8ACgkQ8Jx8FtbMZndBHwCeLTIOkVK4y7Lk9Analglb3JAv 7GYAoL8zb4iv6Qj/OWlG1iXKnXTcs7JX =vkXj -----END PGP SIGNATURE----- From trevorf@exchange.microsoft.com Tue Apr 12 11:36:55 2011 Return-Path: X-Original-To: plasma@ietfc.amsl.com Delivered-To: plasma@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 72715E0857 for ; Tue, 12 Apr 2011 11:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yiBGRf005h5 for ; Tue, 12 Apr 2011 11:36:47 -0700 (PDT) Received: from mail.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by ietfc.amsl.com (Postfix) with ESMTP id 185F4E067F for ; Tue, 12 Apr 2011 11:36:47 -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.1.218.12; Tue, 12 Apr 2011 11:36:46 -0700 Received: from df-mlt-02.exchange.corp.microsoft.com (157.54.94.20) by DF-H14-01.exchange.corp.microsoft.com (157.54.78.139) with Microsoft SMTP Server (TLS) id 14.1.289.8; Tue, 12 Apr 2011 11:36:46 -0700 Received: from DF-M14-11.exchange.corp.microsoft.com ([fe80::cc46:3da5:bed6:8dfc]) by DF-MLT-02.exchange.corp.microsoft.com ([157.54.94.20]) with mapi id 14.01.0218.012; Tue, 12 Apr 2011 11:36:45 -0700 From: Trevor Freeman To: "Whitlock, Stephen" , Stephen Farrell Thread-Topic: [plasma] why not web portal mail? Thread-Index: Acv0kXrWGetxV1fRTF6d/JQ0xrOecQBxLT4AAJFdkKAAHnfScAAJ++0Q Date: Tue, 12 Apr 2011 18:36:44 +0000 Message-ID: References: <4D9F5512.5070506@cs.tcd.ie> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.104] Content-Type: multipart/alternative; boundary="_000_E545B914D50B2A4B994F198378B1525D339D7F15DFM1411exchange_" MIME-Version: 1.0 Cc: "plasma@ietf.org" Subject: Re: [plasma] why not web portal mail? 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, 12 Apr 2011 18:36:55 -0000 --_000_E545B914D50B2A4B994F198378B1525D339D7F15DFM1411exchange_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The degree to which the send wants to retain control over the policies on s= ubsequent messages is a policy for the sender. So far I have seen three typ= es of binding for subsequent messages. 1. None. This is the case where the need to bind policy ended on deli= very to the recipient. This is the case with scenarios like business to con= sumer where it's the consumer's data e.g. a statement or health record. 2. Append allowed. This is where the original policies are preserved = and subsequent messages could have a policy appended (a logical policy AND)= . This is the case with scenarios like replay all for business to business = where the subsequent message has the original content plus some new content= . The user replaying to the original message needs to add their policy beca= use they added some sensitive or regulated content. 3. Alternate allowed. This is where the original policies are preserv= ed and subsequent messages could have an alternate policy applied (a logica= l policy OR). This is the case with forwarded business to business where th= e originator is delegating to the recipients the ability to provide an equi= valent policy for its community of interest. The first is easy to deliver since it has no expectations on the client. Th= e latter two are a higher bar and put some level of trust in the client. In= these case over time you will likely want some claim about the state of he= alth of the client before you release the decryption key. From: Whitlock, Stephen [mailto:stephen.whitlock@boeing.com] Sent: Tuesday, April 12, 2011 6:31 AM To: Trevor Freeman; Stephen Farrell Cc: plasma@ietf.org Subject: RE: [plasma] why not web portal mail? So, would Plasma allow me to create/modify a set of allowed recipients to a= conversation conducted over a public network by just changing policies on = the messages? And would this work across different vendor's e-mail systems? Steve W From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of= Trevor Freeman Sent: Monday, April 11, 2011 5:02 PM To: Stephen Farrell Cc: plasma@ietf.org Subject: Re: [plasma] why not web portal mail? Hi Steve, -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] Sent: Friday, April 08, 2011 11:34 AM To: Trevor Freeman Cc: plasma@ietf.org Subject: Re: [plasma] why not web portal mail? Hi Trevor, On 06/04/11 20:33, Trevor Freeman wrote: > Stephen Farrell asked why not use Web portal mail? Why do we need to > develop plasma? > > I don't think we concisely answered that question in the BoF and it is > an important data point. Thanks for trying now. > The web portal mail products are used where there is no way to > securely deliver sensitive mail to a recipient outside the sender's organ= ization. > The message is held within the sender's organization and a > notification email is sent to the recipient. The notification email > contains a HTTPS URI to the original message with the sensitive content. Right. > This model work Ok if it is bilateral communication e.g. > doctor-patient where you want to reply to the sender. This has been deplo= yed with my > healthcare provider and we can exchange messages. Well, its also works fine for announcements, i.e. 1:N messages. [TF] Agreed. > However the > notification email are very generic by design so it hard to find > specific messages in your inbox other than by date and time sent. It > also means useful features like inbox search don't work as you only > have the notification message in your inbox. True. However, does that mean that you'd expect the UA search function to b= e plasma-aware? If not, then won't the sensitive information be vulnerable = in whatever search DB the UA uses? Maybe that's a question of defining the trust boundaries for this, but give= n that the search may be on an IMAP server its possibly complicated doing t= hat in a secure way. [TF] Yes I expect search engines to become Plasma aware just as search engi= nes have become aware of other encrypted content types. The search engine d= oes not necessary need unrestricted access to content and the content index= ed is by definition potentially sensitive so have to be controlled. However= that process is a local UA process so is not in scope for Plasma. However = the fact that all the user content is in their inbox makes it a tractable p= roblem. > This model fails totally if it's multilateral communication where you > want to reply all or forward to messages. Hmm. So that'd imply that forwarding etc. is an important part of the propo= sed work? It strikes me that that's one of the weakest aspects of generic s= /mime (just from personal experience, its not something I've gone out of my= way to test). There'd also be some pretty complex policy calculations to m= ake to figure out what can be forwarded to whom, I assume, so this seems li= ke a fairly complex area. [TF] Not just forwarding - reply all is just as important as we have demons= trated with this thread. One of the value propositions for email is the fle= xible, multiparty nature of the asynchronous communication whereby groups o= f individuals can be part of a conversation and any recipient can participa= te in the thread or can spawn new threads just as we are doing here. The ob= jective that Plasma brings is the desire to maintain a degree of policy enf= orcement to the process when the content of the message is either sensitive= or regulated. What if, as part of my reply, I wanted to inject some inform= ation which was Microsoft confidential and was being shared under respectiv= e non-disclosure agreements? The aim of Plasma would be to allow me to add = a policy check before the decryption key to my reply was disclosed to recip= ients to ensure every recipient was in an organization which had a current = legal agreement in place. This message is using a distribution list managed= outside my organization so I cannot determine the exact list of recipients= at send time. If the mail list was an S/MIME MLA I could protect the confi= dentiality of the information so only plasma mail list subscribers can read= the content but this does not satisfy the policy requirements of determini= ng if there is a legal agreement in place. > The message never leaves the > originators organization so you cannot originate new message as if it > were from a recipient's organization. This means for business to > business scenario it would hinder the use of email for collaboration. I don't get that at all. But never mind. [TF] I think it's a critical reason for why Plasma. Consider the scenario = where this thread becomes sensitive as I suggested above and I was to use a= web portal for this reply. That portal would be hosted on a Microsoft corp= orate server since I invoked the sensitivity clause and you would have rece= ived a notification email instead of the actual email. If you were to furth= er reply all or forward that messages the origination point for that messag= e would be from a Microsoft corporate server. The Microsoft server would in= turn send out an email notification with a FROM address of stephen.farrell= @cs.tcd.ie with a url of https:\\mail.mic= rosoft.com\??? This seems a highly dubious pattern which matches the pattern used by phish= ers and spammers. How could you expect Microsoft to be authoritative for se= nding mail as someone from Trinity College Dublin to all the recipients on = the distribution list? What is the scenario was reversed and we used a web portal in your domain a= nd I still wanted to add some Microsoft sensitive information to the thread= . How would your portal know what my corporate rulers were if I were to rep= ly all? > With these limitations I think it's clear that that plasma offers some > significant benefits over web portal email. Not that clear to me I'm afraid. While you're arguing for plasma on this basis, to judge those arguments peo= ple would need some kind of evidence that's a good bit better than just an = assertion. But I'm sure you guys are working on that. [TF] Yes that is what dialog is about:) S. > > > > *Dr Trevor Freeman* Senior Security Strategist > > *End to End Trust Team* > ** > > *Microsoft Trustworthy > Computing* > > > > > > _______________________________________________ > plasma mailing list > plasma@ietf.org > https://www.ietf.org/mailman/listinfo/plasma --_000_E545B914D50B2A4B994F198378B1525D339D7F15DFM1411exchange_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The degree to which= the send wants to retain control over the policies on subsequent messages = is a policy for the sender. So far I have seen three types of binding for s= ubsequent messages.

1.       None. T= his is the case where the need to bind policy ended on delivery to the reci= pient. This is the case with scenarios like business to consumer where it&#= 8217;s the consumer’s data e.g. a statement or health record.

2.       Append = allowed. This is where the original policies are preserved and subsequent m= essages could have a policy appended (a logical policy AND). This is the ca= se with scenarios like replay all for business to business where the subsequent message has the original con= tent plus some new content. The user replaying to the original message need= s to add their policy because they added some sensitive or regulated conten= t.

3.       Alterna= te allowed. This is where the original policies are preserved and subsequen= t messages could have an alternate policy applied (a logical policy OR). Th= is is the case with forwarded business to business where the originator is delegating to the recipients the abili= ty to provide an equivalent policy for its community of interest.

The first is easy t= o deliver since it has no expectations on the client. The latter two are a = higher bar and put some level of trust in the client. In these case over ti= me you will likely want some claim about the state of health of the client before you release the decryption key. <= o:p>

 

From: Whitlock= , Stephen [mailto:stephen.whitlock@boeing.com]
Sent: Tuesday, April 12, 2011 6:31 AM
To: Trevor Freeman; Stephen Farrell
Cc: plasma@ietf.org
Subject: RE: [plasma] why not web portal mail?

 

So, would Plasma allow= me to create/modify a set of allowed recipients to a conversation conducte= d over a public network by just changing policies on the messages? And woul= d this work across different vendor’s e-mail systems?

 

Steve W

 

From: plasma-b= ounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of Trevor Freeman
Sent: Monday, April 11, 2011 5:02 PM
To: Stephen Farrell
Cc: plasma@ietf.org
Subject: Re: [plasma] why not web portal mail?

 

Hi Steve,

 

-----Original Message-----
From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
Sent: Friday, April 08, 2011 11:34 AM
To: Trevor Freeman
Cc: plasma@ietf.org
Subject: Re: [plasma] why not web portal mail?

 

 

Hi Trevor,

 

On 06/04/11 20:33, Trevor Freeman wrote:

> Stephen Farrell asked why not use Web portal= mail? Why do we need to

> develop plasma?

>

> I don’t think we concisely answered th= at question in the BoF and it is

> an important data point.

 

Thanks for trying now.

 

> The web portal mail products are used where = there is no way to

> securely deliver sensitive mail to a recipie= nt outside the sender’s organization.

> The message is held within the sender’= s organization and a

> notification email is sent to the recipient.=   The notification email

> contains a HTTPS URI to the original message= with the sensitive content.

 

Right.

 

> This model work Ok if it is bilateral commun= ication e.g.

> doctor-patient where you want to reply to th= e sender. This has been deployed with my

> healthcare provider and we can exchange mess= ages.  

 

Well, its also works fine for announcements, i.e.= 1:N messages.

 

[TF] Agreed.

 

> However the

> notification email are very generic by desig= n so it hard to find

> specific messages in your inbox other than b= y date and time sent. It

> also means useful features like inbox search= don’t work as you only

> have the notification message in your inbox.=

 

True. However, does that mean that you'd expect t= he UA search function to be plasma-aware? If not, then won't the sensitive = information be vulnerable in whatever search DB the UA uses?

Maybe that's a question of defining the trust bou= ndaries for this, but given that the search may be on an IMAP server its po= ssibly complicated doing that in a secure way.

 

 

[TF] Yes I expect sea= rch engines to become Plasma aware just as search engines have become aware= of other encrypted content types. The search engine does not necessary nee= d unrestricted access to content and the content indexed is by definition potentially sensitive so have to be c= ontrolled. However that process is a local UA process so is not in scope fo= r Plasma. However the fact that all the user content is in their inbox make= s it a tractable problem.

 

> This model fails totally if it’s multi= lateral communication where you

> want to reply all or forward to messages.

 

Hmm. So that'd imply that forwarding etc. is an i= mportant part of the proposed work? It strikes me that that's one of the we= akest aspects of generic s/mime (just from personal experience, its not som= ething I've gone out of my way to test). There'd also be some pretty complex policy calculations to make to = figure out what can be forwarded to whom, I assume, so this seems like a fa= irly complex area.

 

 

[TF] Not just forward= ing - reply all is just as important as we have demonstrated with this thre= ad. One of the value propositions for email is the flexible, multiparty nat= ure of the asynchronous communication whereby groups of individuals can be part of a conversation and any recipi= ent can participate in the thread or can spawn new threads just as we are d= oing here. The objective that Plasma brings is the desire to maintain a deg= ree of policy enforcement to the process when the content of the message is either sensitive or regulated. = What if, as part of my reply, I wanted to inject some information which was= Microsoft confidential and was being shared under respective non-disclosur= e agreements? The aim of Plasma would be to allow me to add a policy check before the decryption key to my= reply was disclosed to recipients to ensure every recipient was in an orga= nization which had a current legal agreement in place. This message is usin= g a distribution list managed outside my organization so I cannot determine the exact list of recipients at send= time. If the mail list was an S/MIME MLA I could protect the confidentiali= ty of the information so only plasma mail list subscribers can read the con= tent but this does not satisfy the policy requirements of determining if there is a legal agreement in place.=

 

> The message never leaves the

> originators organization so you cannot origi= nate new message as if it

> were from a recipient’s organization. = This means for business to

> business scenario it would hinder the use of= email for collaboration.

 

I don't get that at all. But never mind.

 

 

[TF] I think it’= ;s a critical reason for why Plasma.  Consider the scenario where this= thread becomes sensitive as I suggested above and I was to use a web porta= l for this reply. That portal would be hosted on a Microsoft corporate server since I invoked the sensitivity clause and yo= u would have received a notification email instead of the actual email. If = you were to further reply all or forward that messages the origination poin= t for that message would be from a Microsoft corporate server. The Microsoft server would in turn send out = an email notification with a FROM address of stephen.farrell@cs.tcd.ie = with a url of https:\\mail.microsoft.com\???

This seems a highly d= ubious pattern which matches the pattern used by phishers and spammers. How= could you expect Microsoft to be authoritative for sending mail as someone= from Trinity College Dublin to all the recipients on the distribution list?

 

What is the scenario = was reversed and we used a web portal in your domain and I still wanted to = add some Microsoft sensitive information to the thread. How would your port= al know what my corporate rulers were if I were to reply all?

 

 

> With these limitations I think it’s cl= ear that that plasma offers some

> significant benefits over web portal email.<= o:p>

 

Not that clear to me I'm afraid.

 

While you're arguing for plasma on this basis, to= judge those arguments people would need some kind of evidence that's a goo= d bit better than just an assertion. But I'm sure you guys are working on t= hat.

 

[TF] Yes that is what= dialog is aboutJ<= /span>

 

S.

 

>

> 

>

> *Dr Trevor Freeman*  Senior Security St= rategist

>

> *End to End Trust Team*

> <http://www.microsoft.com/mscorp/twc/endtoendtrust/default.msp= x>**

>

> *Microsoft Trustworthy

> Computing*<http://www.microsoft.com/mscorp/twc/default.mspx>

>

> 

>

>

>

> ____________________________________________= ___

> plasma mailing list

> plasma@ietf.org

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

--_000_E545B914D50B2A4B994F198378B1525D339D7F15DFM1411exchange_-- From trevorf@exchange.microsoft.com Tue Apr 12 11:41:48 2011 Return-Path: X-Original-To: plasma@ietfc.amsl.com Delivered-To: plasma@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EB280E067F for ; Tue, 12 Apr 2011 11:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scnAWLKbBTkF for ; Tue, 12 Apr 2011 11:41:48 -0700 (PDT) Received: from mail.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by ietfc.amsl.com (Postfix) with ESMTP id DEB61E07D5 for ; Tue, 12 Apr 2011 11:41:47 -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.1.218.12; Tue, 12 Apr 2011 11:41:47 -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.1.289.8; Tue, 12 Apr 2011 11:41:47 -0700 Received: from DF-M14-11.exchange.corp.microsoft.com ([fe80::cc46:3da5:bed6:8dfc]) by PIO-MLT-05.exchange.corp.microsoft.com ([fe80::d940:e316:1daa:5e6a%10]) with mapi id 14.01.0218.012; Tue, 12 Apr 2011 11:41:47 -0700 From: Trevor Freeman To: Leif Johansson , "plasma@ietf.org" Thread-Topic: [plasma] why not web portal mail? Thread-Index: Acv0kXrWGetxV1fRTF6d/JQ0xrOecQExhkeAAAW7cdA= Date: Tue, 12 Apr 2011 18:41:46 +0000 Message-ID: References: <4DA45FE5.3020102@mnt.se> In-Reply-To: <4DA45FE5.3020102@mnt.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [plasma] why not web portal mail? 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, 12 Apr 2011 18:41:49 -0000 If you consider XMPP case it is easier because there is no expectation of d= ata persistence. It's a synchronous protocol where all parties are online t= ogether exchanging information and that information is not persisted one th= e session is ended. -----Original Message----- From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of= Leif Johansson Sent: Tuesday, April 12, 2011 7:21 AM To: plasma@ietf.org Subject: Re: [plasma] why not web portal mail? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/06/2011 09:33 PM, Trevor Freeman wrote: > Stephen Farrell asked why not use Web portal mail? Why do we need to deve= lop plasma? Maybe that question is easier to answer if we consider plasma for XMPP and = not just for email. There are important differences between XMPP and email = that make it much more challenging to build web-only versions of the XMPP. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2kX+UACgkQ8Jx8FtbMZndeOwCcC1BQafbUXYLHJZKxsuAcV8eS 6ukAnA0JGhMsLdmh+WG+GqEUoVMWj7+e =3D5lPF -----END PGP SIGNATURE----- _______________________________________________ plasma mailing list plasma@ietf.org https://www.ietf.org/mailman/listinfo/plasma From hallam@gmail.com Tue Apr 12 12:31:31 2011 Return-Path: X-Original-To: plasma@ietfc.amsl.com Delivered-To: plasma@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 10413E0890 for ; Tue, 12 Apr 2011 12:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.679 X-Spam-Level: X-Spam-Status: No, score=-2.679 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZyPLxdzzc5Z for ; Tue, 12 Apr 2011 12:31:30 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id E2BC2E0824 for ; Tue, 12 Apr 2011 12:31:29 -0700 (PDT) Received: by vxg33 with SMTP id 33so6396393vxg.31 for ; Tue, 12 Apr 2011 12:31:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=//nhcB0R2EEVREluAMiH7jp9h5mPNiliJbQSJiB5RLU=; b=X9aIcLylDqqb4fE+DvKpwQeANtGy+AqnUJOsFdzU4QBY8Pcvv/Slv9VHroddqD03We ZyHdnIVrhL21kxupKno3+nawExW8QfGG1yWLvPePnBXEdgM4Q75beqaJpeIkwnuICIyu kNULkXBWJC01EPgApwfWaTFSLUjYj1sUbE3Xk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SqcLJ9Qzyqe1JJnt4HzxCApuVRCnByB8yekodtOolL/ORP5aXayEZiwXXf7c3uOW/3 jBGrmXLizXVEjhCPFqQIzf3T9gQQW69Bfnb07qR8/byo/67YywOUUZQPIl9byMsdCmcR AApIYgW1ZzzSy8tdFWmBgObqEePn6PpgcaBIc= MIME-Version: 1.0 Received: by 10.52.176.36 with SMTP id cf4mr1984860vdc.29.1302636689169; Tue, 12 Apr 2011 12:31:29 -0700 (PDT) Received: by 10.52.166.230 with HTTP; Tue, 12 Apr 2011 12:31:29 -0700 (PDT) In-Reply-To: References: <4DA45FE5.3020102@mnt.se> Date: Tue, 12 Apr 2011 15:31:29 -0400 Message-ID: From: Phillip Hallam-Baker To: Trevor Freeman Content-Type: multipart/alternative; boundary=bcaec5171ea7211eac04a0bdbdd5 Cc: "plasma@ietf.org" Subject: Re: [plasma] why not web portal mail? 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, 12 Apr 2011 19:31:31 -0000 --bcaec5171ea7211eac04a0bdbdd5 Content-Type: text/plain; charset=ISO-8859-1 If we consider the Word, Excel and Diplomatic cables examples, the data is static and to be controlled under a policy regardless of what channels it might be transferred or transmitted through. The protocol requirement here in my view is to enable applications to determine how to apply the security policy identified as X to the data object Y. On Tue, Apr 12, 2011 at 2:41 PM, Trevor Freeman < trevorf@exchange.microsoft.com> wrote: > If you consider XMPP case it is easier because there is no expectation of > data persistence. It's a synchronous protocol where all parties are online > together exchanging information and that information is not persisted one > the session is ended. > > -----Original Message----- > From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf > Of Leif Johansson > Sent: Tuesday, April 12, 2011 7:21 AM > To: plasma@ietf.org > Subject: Re: [plasma] why not web portal mail? > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/06/2011 09:33 PM, Trevor Freeman wrote: > > Stephen Farrell asked why not use Web portal mail? Why do we need to > develop plasma? > > Maybe that question is easier to answer if we consider plasma for XMPP and > not just for email. There are important differences between XMPP and email > that make it much more challenging to build web-only versions of the XMPP. > > Cheers Leif > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk2kX+UACgkQ8Jx8FtbMZndeOwCcC1BQafbUXYLHJZKxsuAcV8eS > 6ukAnA0JGhMsLdmh+WG+GqEUoVMWj7+e > =5lPF > -----END PGP SIGNATURE----- > _______________________________________________ > 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 > -- Website: http://hallambaker.com/ --bcaec5171ea7211eac04a0bdbdd5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If we consider the Word, Excel and Diplomatic cables examples, the data is = static and to be controlled under a policy regardless of what channels it m= ight be transferred or transmitted through.

The protocol= requirement here in my view is to enable applications to determine how to = apply the security policy identified as X to the data object Y.


On Tue, Apr 12, 2011 at 2:41 PM, Tr= evor Freeman <trevorf@exchange.microsoft.com> wrote:
If you consider XMPP case it is easier because there is no expectation of d= ata persistence. It's a synchronous protocol where all parties are onli= ne together exchanging information and that information is not persisted on= e the session is ended.

-----Original Message-----
From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.or= g] On Behalf Of Leif Johansson
Sent: Tuesday, April 12, 2011 7:21 AM
To: plasma@ietf.org
Subject: Re: [plasma] why not web portal mail?

-----BEGIN PGP SIGNED MESSAGE-----<= br> Hash: SHA1

On 04/06/2011 09:33 PM, Trevor Freeman wrote:
> Stephen Farrell asked why not use Web portal mail? Why do we need to d= evelop plasma?

Maybe that question is easier to answer if we consider plasma for XMPP and = not just for email. There are important differences between XMPP and email = that make it much more challenging to build web-only versions of the XMPP.<= br>
=A0 =A0 =A0 =A0Cheers Leif
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2kX+UACgkQ8Jx8FtbMZndeOwCcC1BQafbUXYLHJZKxsuAcV8eS
6ukAnA0JGhMsLdmh+WG+GqEUoVMWj7+e
=3D5lPF
-----END PGP SIGNATURE-----
_______________________________________________
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



--
Website: http://hallambaker.com/

--bcaec5171ea7211eac04a0bdbdd5-- From leifj@mnt.se Tue Apr 12 13:55:26 2011 Return-Path: X-Original-To: plasma@ietfc.amsl.com Delivered-To: plasma@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5719CE093F for ; Tue, 12 Apr 2011 13:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2DS6rCRNSvZ for ; Tue, 12 Apr 2011 13:55:25 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfc.amsl.com (Postfix) with ESMTP id 4E461E0933 for ; Tue, 12 Apr 2011 13:55:25 -0700 (PDT) Received: from [172.20.10.2] ([2.67.94.19]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p3CKtDI8004856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Apr 2011 22:55:20 +0200 (CEST) Message-ID: <4DA4BC30.7060308@mnt.se> Date: Tue, 12 Apr 2011 22:55:12 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Trevor Freeman References: <4DA45FE5.3020102@mnt.se> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "plasma@ietf.org" Subject: Re: [plasma] why not web portal mail? 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, 12 Apr 2011 20:55:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/12/2011 08:41 PM, Trevor Freeman wrote: > If you consider XMPP case it is easier because there is no expectation of data persistence. It's a synchronous protocol where all parties are online together exchanging information and that information is not persisted one the session is ended. Ah no most XMPP deployments does store-and-forward (offline messages I think its called). Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2kvDAACgkQ8Jx8FtbMZnfongCgu7sduGW6QTtVvMT92BQ9sBlg TZ4AoI+LlDt54aLH3Uq/f5dZPRd04rVY =q8qS -----END PGP SIGNATURE----- From stpeter@stpeter.im Tue Apr 12 13:56:53 2011 Return-Path: X-Original-To: plasma@ietfc.amsl.com Delivered-To: plasma@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0E27BE0933 for ; Tue, 12 Apr 2011 13:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.229 X-Spam-Level: X-Spam-Status: No, score=-102.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDiHUgfN4VGJ for ; Tue, 12 Apr 2011 13:56:52 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by ietfc.amsl.com (Postfix) with ESMTP id 57914E092F for ; Tue, 12 Apr 2011 13:56:52 -0700 (PDT) Received: from dhcp-64-101-72-245.cisco.com (dhcp-64-101-72-245.cisco.com [64.101.72.245]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0168440D20; Tue, 12 Apr 2011 14:59:48 -0600 (MDT) Message-ID: <4DA4BC92.6070701@stpeter.im> Date: Tue, 12 Apr 2011 14:56:50 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Leif Johansson References: <4DA45FE5.3020102@mnt.se> <4DA4BC30.7060308@mnt.se> In-Reply-To: <4DA4BC30.7060308@mnt.se> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050103050102010708010206" Cc: "plasma@ietf.org" Subject: Re: [plasma] why not web portal mail? 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, 12 Apr 2011 20:56:53 -0000 This is a cryptographically signed message in MIME format. --------------ms050103050102010708010206 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4/12/11 2:55 PM, Leif Johansson wrote: > On 04/12/2011 08:41 PM, Trevor Freeman wrote: >> If you consider XMPP case it is easier because there is no expectation= of data persistence. It's a synchronous protocol where all parties are o= nline together exchanging information and that information is not persist= ed one the session is ended. >=20 > Ah no most XMPP deployments does store-and-forward (offline messages I > think its called). Correct: http://xmpp.org/extensions/xep-0160.html Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms050103050102010708010206 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQx MjIwNTY1MFowIwYJKoZIhvcNAQkEMRYEFPyAVBSexylCtISZa1G2tAndGLLTMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBbSGhhGSjm5k8/SKGuXnyjMf9mAhuxFy2E0Nivt/xn4VxbN/IRYu/Moxb3 l+vtYzt95P7u/uwWapQtzA+TskNKDp7X8/2wkPqumrmuSFScsj42rB4SxL2VNYur9cUZ/2uC iVNuaz17m1Ca1Zc6uutVEkg1FTE6k7CMaMxzUawX2jLvJojV6ZH9PDY+m8E2BgvRqGxk+3zG cTPQ/r81s35IyJDoLZkad88/59rgNLTc+R/0VovpYDVTxaxX0q1uB3GaEkbUtpnFeYj5xGZA TfkNnq+wl16TXuCR43PxDgnYSZATYWXA4Te76gw+NbTgS/MhMsdB/juc971TKcWr2HW7AAAA AAAA --------------ms050103050102010708010206-- From trevorf@exchange.microsoft.com Tue Apr 12 15:52:29 2011 Return-Path: X-Original-To: plasma@ietfc.amsl.com Delivered-To: plasma@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C145FE087D for ; Tue, 12 Apr 2011 15:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jfYwiU1IefN for ; Tue, 12 Apr 2011 15:52:26 -0700 (PDT) Received: from mail.exchange.microsoft.com (mail1.exchange.microsoft.com [131.107.1.17]) by ietfc.amsl.com (Postfix) with ESMTP id 2C6EFE091B for ; Tue, 12 Apr 2011 15:52:26 -0700 (PDT) Received: from df-h14-01.exchange.corp.microsoft.com (157.54.78.139) by DF-G14-01.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 12 Apr 2011 15:52:25 -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.1.289.8; Tue, 12 Apr 2011 15:52:25 -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.01.0218.012; Tue, 12 Apr 2011 15:52:25 -0700 From: Trevor Freeman To: Phillip Hallam-Baker Thread-Topic: [plasma] why not web portal mail? Thread-Index: AQHL+Ug51oJEPZwodEWIarS6m5uzOpRa0X0w Date: Tue, 12 Apr 2011 22:52:24 +0000 Message-ID: References: <4DA45FE5.3020102@mnt.se> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.101] Content-Type: multipart/alternative; boundary="_000_E545B914D50B2A4B994F198378B1525D339DC3C2DFM1412exchange_" MIME-Version: 1.0 Cc: "plasma@ietf.org" Subject: Re: [plasma] why not web portal mail? 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, 12 Apr 2011 22:52:29 -0000 --_000_E545B914D50B2A4B994F198378B1525D339DC3C2DFM1412exchange_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Policy does not distinguish in what form the data is held. So information p= ersisted in email is subject to the same policy as the same information per= sisted in a word document. Yes we have to bind data to some set of policies. The semantics for email a= nd documents are the same. Overall the Alice case you cited is too simple. A more realist example is Alice has some data and wants to apply policy X and Y to her data Bob has some data and wants to apply policy Z to his data Policies X, Y and Z each defines a set of authorized recipients. Alice and Bob's data had become comingled so now policies X Y and Z have to= be enforced. In an ideal world we would want to identify Alice's and Bob's data and bind= it to its respective polices. In a less than perfect world we may enforce access at the container level w= hich is an incremental improvement on what we have today. From: Phillip Hallam-Baker [mailto:hallam@gmail.com] Sent: Tuesday, April 12, 2011 12:31 PM To: Trevor Freeman Cc: Leif Johansson; plasma@ietf.org Subject: Re: [plasma] why not web portal mail? If we consider the Word, Excel and Diplomatic cables examples, the data is = static and to be controlled under a policy regardless of what channels it m= ight be transferred or transmitted through. The protocol requirement here in my view is to enable applications to deter= mine how to apply the security policy identified as X to the data object Y. On Tue, Apr 12, 2011 at 2:41 PM, Trevor Freeman > wrote: If you consider XMPP case it is easier because there is no expectation of d= ata persistence. It's a synchronous protocol where all parties are online t= ogether exchanging information and that information is not persisted one th= e session is ended. -----Original Message----- From: plasma-bounces@ietf.org [mailto:plasm= a-bounces@ietf.org] On Behalf Of Leif Johan= sson Sent: Tuesday, April 12, 2011 7:21 AM To: plasma@ietf.org Subject: Re: [plasma] why not web portal mail? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/06/2011 09:33 PM, Trevor Freeman wrote: > Stephen Farrell asked why not use Web portal mail? Why do we need to deve= lop plasma? Maybe that question is easier to answer if we consider plasma for XMPP and = not just for email. There are important differences between XMPP and email = that make it much more challenging to build web-only versions of the XMPP. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2kX+UACgkQ8Jx8FtbMZndeOwCcC1BQafbUXYLHJZKxsuAcV8eS 6ukAnA0JGhMsLdmh+WG+GqEUoVMWj7+e =3D5lPF -----END PGP SIGNATURE----- _______________________________________________ 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 -- Website: http://hallambaker.com/ --_000_E545B914D50B2A4B994F198378B1525D339DC3C2DFM1412exchange_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Policy does not distin= guish in what form the data is held. So information persisted in email is s= ubject to the same policy as the same information persisted in a word document.

 

Yes we have to bind da= ta to some set of policies. The semantics for email and documents are the s= ame.

 

Overall the Alice case= you cited is too simple. A more realist example is

 

Alice has some data and wants to apply policy X and Y to her data

Bob has some data and wants to apply policy Z to his data

 

Policies X, Y and Z each defines a set of authorized recipients.<= /o:p>

 

Alice and Bob’s data had become comingled so now policies X Y an= d Z have to be enforced.

 

In an ideal world we w= ould want to identify Alice’s and Bob’s data and bind it to its= respective polices.

 

In a less than perfect= world we may enforce access at the container level which is an incremental= improvement on what we have today.

 

 

From: Phillip = Hallam-Baker [mailto:hallam@gmail.com]
Sent: Tuesday, April 12, 2011 12:31 PM
To: Trevor Freeman
Cc: Leif Johansson; plasma@ietf.org
Subject: Re: [plasma] why not web portal mail?

 

If we consider the Word, Excel and Diplomatic cables= examples, the data is static and to be controlled under a policy regardles= s of what channels it might be transferred or transmitted through.

 

The protocol requirement here in my view is to enabl= e applications to determine how to apply the security policy identified as = X to the data object Y.

 

On Tue, Apr 12, 2011 at 2:41 PM, Trevor Freeman <= trevorf@exchange.microsof= t.com> wrote:

If you consider XMPP case it is easier because there= is no expectation of data persistence. It's a synchronous protocol where a= ll parties are online together exchanging information and that information = is not persisted one the session is ended.


-----Original Message-----
From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.or= g] On Behalf Of Leif Johansson
Sent: Tuesday, April 12, 2011 7:21 AM
To: plasma@ietf.org
Subject: Re: [plasma] why not web portal mail?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/06/2011 09:33 PM, Trevor Freeman wrote:
> Stephen Farrell asked why not use Web portal mail? Why do we need to d= evelop plasma?

Maybe that question is easier to answer if we consider plasma for XMPP and = not just for email. There are important differences between XMPP and email = that make it much more challenging to build web-only versions of the XMPP.<= br>
       Cheers Leif
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2kX+UACgkQ8Jx8FtbMZndeOwCcC1BQafbUXYLHJZKxsuAcV8eS
6ukAnA0JGhMsLdmh+WG+GqEUoVMWj7+e
=3D5lPF
-----END PGP SIGNATURE-----
_______________________________________________
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




--
Website: http://hallambaker.com/

--_000_E545B914D50B2A4B994F198378B1525D339DC3C2DFM1412exchange_-- From trevorf@exchange.microsoft.com Tue Apr 12 16:11:11 2011 Return-Path: X-Original-To: plasma@ietfc.amsl.com Delivered-To: plasma@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0DF20E0951 for ; Tue, 12 Apr 2011 16:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgfdXePM40wL for ; Tue, 12 Apr 2011 16:11:09 -0700 (PDT) Received: from mail.exchange.microsoft.com (mail1.exchange.microsoft.com [131.107.1.17]) by ietfc.amsl.com (Postfix) with ESMTP id 700CDE094D for ; Tue, 12 Apr 2011 16:11:09 -0700 (PDT) Received: from df-h14-02.exchange.corp.microsoft.com (157.54.78.140) by DF-G14-01.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 12 Apr 2011 16:11:08 -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.1.289.8; Tue, 12 Apr 2011 16:11:08 -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.01.0218.012; Tue, 12 Apr 2011 16:11:08 -0700 From: Trevor Freeman To: Peter Saint-Andre , Leif Johansson Thread-Topic: [plasma] why not web portal mail? Thread-Index: Acv0kXrWGetxV1fRTF6d/JQ0xrOecQExhkeAAAW7cdAACAVCAAAADpoAAAqOW3A= Date: Tue, 12 Apr 2011 23:11:08 +0000 Message-ID: References: <4DA45FE5.3020102@mnt.se> <4DA4BC30.7060308@mnt.se> <4DA4BC92.6070701@stpeter.im> In-Reply-To: <4DA4BC92.6070701@stpeter.im> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.101] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "plasma@ietf.org" Subject: Re: [plasma] why not web portal mail? 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, 12 Apr 2011 23:11:11 -0000 SSByZWFsaXplIGF0IHRoZSBwaHlzaWNhbCBsZXZlbCB3aXRoIElNIGl0IHVzZXMgYSBzZXF1ZW5j ZSBvZiBtZXNzYWdlcyB3aGljaCBoYXJlIHJlbGF5ZWQgc2VydmVyIHRvIHNlcnZlci4gSnVzdCBh cyB3aXRoIFZvSVAsIGFuIGF1ZGlvIHN0cmVhbSBpcyBwYWNrYWdlZCBhcyBhIHNlcXVlbmNlIG9m IElQIHBhY2tldHMuIEhvd2V2ZXIgdGhlcmUgaXMgbm8gY29uY2VwdCBvZiBsb25nIHRlcm0gcGVy c2lzdGVuY2Ugb2YgaW5mb3JtYXRpb24gb3V0c2lkZSBvZiB0aGUgSU0gc2Vzc2lvbiAoSSBhbSBp Z25vcmluZyBhdWRpdGluZykuIEkgZG9u4oCZdCBoYXZlIGFuIElNIGluYm94Lg0KDQpUaGUgY2xv c2VzdCBJIGNhbiBnZXQgaXMgaWYgSSBwZXJzaXN0IG15IElNIGhpc3RvcnkgSSB3b3VsZCBpbnZv a2UgdGhlIHBvbGljeSBidXQgaXQncyBub3QgaW50dWl0aXZlIEkgd291bGQgc3Bhd24gbW9yZSBp bSBzZXNzaW9ucyBiYXNlZCBvbiB0aGF0IGFzIEkgd291bGQgZm9yd2FyZCBvciByZXBseSBhbGwg d2l0aCBlbWFpbC4gDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBQZXRlciBT YWludC1BbmRyZSBbbWFpbHRvOnN0cGV0ZXJAc3RwZXRlci5pbV0gDQpTZW50OiBUdWVzZGF5LCBB cHJpbCAxMiwgMjAxMSAxOjU3IFBNDQpUbzogTGVpZiBKb2hhbnNzb24NCkNjOiBUcmV2b3IgRnJl ZW1hbjsgcGxhc21hQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3BsYXNtYV0gd2h5IG5vdCB3ZWIg cG9ydGFsIG1haWw/DQoNCk9uIDQvMTIvMTEgMjo1NSBQTSwgTGVpZiBKb2hhbnNzb24gd3JvdGU6 DQo+IE9uIDA0LzEyLzIwMTEgMDg6NDEgUE0sIFRyZXZvciBGcmVlbWFuIHdyb3RlOg0KPj4gSWYg eW91IGNvbnNpZGVyIFhNUFAgY2FzZSBpdCBpcyBlYXNpZXIgYmVjYXVzZSB0aGVyZSBpcyBubyBl eHBlY3RhdGlvbiBvZiBkYXRhIHBlcnNpc3RlbmNlLiBJdCdzIGEgc3luY2hyb25vdXMgcHJvdG9j b2wgd2hlcmUgYWxsIHBhcnRpZXMgYXJlIG9ubGluZSB0b2dldGhlciBleGNoYW5naW5nIGluZm9y bWF0aW9uIGFuZCB0aGF0IGluZm9ybWF0aW9uIGlzIG5vdCBwZXJzaXN0ZWQgb25lIHRoZSBzZXNz aW9uIGlzIGVuZGVkLg0KPiANCj4gQWggbm8gbW9zdCBYTVBQIGRlcGxveW1lbnRzIGRvZXMgc3Rv cmUtYW5kLWZvcndhcmQgKG9mZmxpbmUgbWVzc2FnZXMgSQ0KPiB0aGluayBpdHMgY2FsbGVkKS4N Cg0KQ29ycmVjdDoNCg0KaHR0cDovL3htcHAub3JnL2V4dGVuc2lvbnMveGVwLTAxNjAuaHRtbA0K DQpQZXRlcg0KDQotLSANClBldGVyIFNhaW50LUFuZHJlDQpodHRwczovL3N0cGV0ZXIuaW0vDQoN Cg0KDQo= From hallam@gmail.com Tue Apr 12 17:50:01 2011 Return-Path: X-Original-To: plasma@ietfc.amsl.com Delivered-To: plasma@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8B547E0687 for ; Tue, 12 Apr 2011 17:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.675 X-Spam-Level: X-Spam-Status: No, score=-2.675 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0PnQvY1CFIo for ; Tue, 12 Apr 2011 17:50:00 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id ED369E067D for ; Tue, 12 Apr 2011 17:49:59 -0700 (PDT) Received: by vxg33 with SMTP id 33so102764vxg.31 for ; Tue, 12 Apr 2011 17:49:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=axD9N58QV4S0A4P5PGHtWXXKp9iVJbWkxHVYEtNpMKE=; b=A6YFYYxlA6aWkdlFuJW04SMtQihgn6l7aSarlTY0NGWhTFQLKIlM06gdj2xJ7cYACY cc8OvXW7AbRFfUV/+AlMEb4YoYNttBLbEYq5GvA+ERszEQugU9ufKgDtfQWTyNOx4Eno ZXsbcHhgn4RuBYmWcd3QUBlh2A3TJYZfE3kz0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=w5YUnUanDLvDDKskcEdOIhoVFcIcd10+5xDhfVWHNrLvO4G2d9MXviO3SL6E0lMsjH 4kWoCPYgTFbdiKd55QMyM7uAWtizurNF8x4PNC0BjR6VwOjHXK+ZKdPP8Sw4oGh/W790 iMV7/wWHNX+2gaW3o3E4Jrut8Ii08qWmWNSlM= MIME-Version: 1.0 Received: by 10.52.176.36 with SMTP id cf4mr2382432vdc.29.1302655799274; Tue, 12 Apr 2011 17:49:59 -0700 (PDT) Received: by 10.52.166.230 with HTTP; Tue, 12 Apr 2011 17:49:58 -0700 (PDT) In-Reply-To: References: <4DA45FE5.3020102@mnt.se> Date: Tue, 12 Apr 2011 20:49:58 -0400 Message-ID: From: Phillip Hallam-Baker To: Trevor Freeman Content-Type: multipart/alternative; boundary=bcaec5171ea72e2b6404a0c23041 Cc: "plasma@ietf.org" Subject: Re: [plasma] why not web portal mail? 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, 13 Apr 2011 00:50:01 -0000 --bcaec5171ea72e2b6404a0c23041 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Agreed, but not actually an issue. If we have a collection of data in a database that is controlled under the secret#example.com policy we might have an infinite series of permutations and subsets that could be drawn from the database. We don't need to standardize the expression of the secret#example.com polic= y or how it relates to the dataset. There might be constraints in there of th= e form 'fans of Lady Gaga can only download a maximum of 1000 items', there might be propositions that are nondeterministic, even undecidable. All an application ever needs to deal with is the consequences of that policy and those can be reduced to a small number of fixed actions plus 'call back for further instructions'. There will have to be a policy language of course. But the policy language itself does not need to be part of the standard. Its like the .NET specification, the byte code and the APIs are standard, but that infrastructure can support a vast array of languages. What we need in the PLASMA standard is the range of moves used to implement the policy. That is good in two ways, first it is more general and a better architecture, second it avoids the worst thickets of patent trolldom which obsess about the idea of moving the policy itself round with the data being controlled. That is a necessary approach for copyright enforcement which ha= d to support offline devices and physical media once upon a time but not for content management in general. On Tue, Apr 12, 2011 at 6:52 PM, Trevor Freeman < trevorf@exchange.microsoft.com> wrote: > *Policy does not distinguish in what form the data is held. So > information persisted in email is subject to the same policy as the same > information persisted in a word document. * > > * * > > *Yes we have to bind data to some set of policies. The semantics for emai= l > and documents are the same. * > > * * > > *Overall the Alice case you cited is too simple. A more realist example i= s > * > > * * > > *Alice has some data and wants to apply policy X and Y to her data * > > *Bob has some data and wants to apply policy Z to his data* > > * * > > *Policies X, Y and Z each defines a set of authorized recipients.* > > * * > > *Alice and Bob=92s data had become comingled so now policies X Y and Z ha= ve > to be enforced.* > > * * > > *In an ideal world we would want to identify Alice=92s and Bob=92s data a= nd > bind it to its respective polices. * > > * * > > *In a less than perfect world we may enforce access at the container leve= l > which is an incremental improvement on what we have today. * > > * * > > * * > > *From:* Phillip Hallam-Baker [mailto:hallam@gmail.com] > *Sent:* Tuesday, April 12, 2011 12:31 PM > *To:* Trevor Freeman > *Cc:* Leif Johansson; plasma@ietf.org > > *Subject:* Re: [plasma] why not web portal mail? > > > > If we consider the Word, Excel and Diplomatic cables examples, the data i= s > static and to be controlled under a policy regardless of what channels it > might be transferred or transmitted through. > > > > The protocol requirement here in my view is to enable applications to > determine how to apply the security policy identified as X to the data > object Y. > > > > On Tue, Apr 12, 2011 at 2:41 PM, Trevor Freeman < > trevorf@exchange.microsoft.com> wrote: > > If you consider XMPP case it is easier because there is no expectation of > data persistence. It's a synchronous protocol where all parties are onlin= e > together exchanging information and that information is not persisted one > the session is ended. > > > -----Original Message----- > From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf > Of Leif Johansson > Sent: Tuesday, April 12, 2011 7:21 AM > To: plasma@ietf.org > Subject: Re: [plasma] why not web portal mail? > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/06/2011 09:33 PM, Trevor Freeman wrote: > > Stephen Farrell asked why not use Web portal mail? Why do we need to > develop plasma? > > Maybe that question is easier to answer if we consider plasma for XMPP an= d > not just for email. There are important differences between XMPP and emai= l > that make it much more challenging to build web-only versions of the XMPP= . > > Cheers Leif > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk2kX+UACgkQ8Jx8FtbMZndeOwCcC1BQafbUXYLHJZKxsuAcV8eS > 6ukAnA0JGhMsLdmh+WG+GqEUoVMWj7+e > =3D5lPF > -----END PGP SIGNATURE----- > _______________________________________________ > 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 > > > > > -- > Website: http://hallambaker.com/ > --=20 Website: http://hallambaker.com/ --bcaec5171ea72e2b6404a0c23041 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Agreed, but not actually an issue.

If we have a collecti= on of data in a database that is controlled under the secret#example.com policy we might have an infinite series of= permutations and subsets that could be drawn from the database.

We don't need to standardize the expression of the = secret#example.com policy or how it rela= tes to the dataset. There might be constraints in there of the form 'fa= ns of Lady Gaga can only download a maximum of 1000 items', there might= be propositions that are nondeterministic, even undecidable.


All an application ever needs to deal wi= th is the consequences of that policy and those can be reduced to a small n= umber of fixed actions plus 'call back for further instructions'.

There will have to be a policy language of course. But = the policy language itself does not need to be part of the standard. Its li= ke the .NET specification, the byte code and the APIs are standard, but tha= t infrastructure can support a vast array of languages.

What we need in the PLASMA standard is the range of mov= es used to implement the policy.


Th= at is good in two ways, first it is more general and a better architecture,= second it avoids the worst thickets of patent trolldom which obsess about = the idea of moving the policy itself round with the data being controlled. = That is a necessary approach for copyright enforcement which had to support= offline devices and physical media once upon a time but not for content ma= nagement in general.


On Tue, Apr 12, 201= 1 at 6:52 PM, Trevor Freeman <trevorf@exchange.microsoft.com> wro= te:

Po= licy does not distinguish in what form the data is held. So information per= sisted in email is subject to the same policy as the same information persi= sted in a word document.

= =A0

Ye= s we have to bind data to some set of policies. The semantics for email and= documents are the same.

= =A0

Ov= erall the Alice case you cited is too simple. A more realist example is

=A0

Alice has some data and wants to apply policy X an= d Y to her data

Bob has some data and wants to apply policy Z to h= is data

=A0

Policies X, Y and Z each defines a set of authoriz= ed recipients.

=A0

Alice and Bob=92s data had become comingled so now= policies X Y and Z have to be enforced.

=A0

In= an ideal world we would want to identify Alice=92s and Bob=92s data and bi= nd it to its respective polices.

= =A0

In= a less than perfect world we may enforce access at the container level whi= ch is an incremental improvement on what we have today.

= =A0

=A0

From:= Phillip Hallam-Baker [mailto:hallam@gmail.com]
Sent: Tuesday, April 12, 2011 12:31 PM
To: Trevor Freeman
Cc: Leif Johansson; plasma@ietf.org


Subject: Re: [plasma] why not web portal mail?

=A0

If we consider the Word, Excel and Diplomatic cables= examples, the data is static and to be controlled under a policy regardles= s of what channels it might be transferred or transmitted through.

=A0

The protocol requirement here in my view is to enabl= e applications to determine how to apply the security policy identified as = X to the data object Y.

=A0

On Tue, Apr 12, 2011 at 2:41 PM, Trevor Freeman <= trevorf= @exchange.microsoft.com> wrote:

If you consider XMPP case it is easier because there= is no expectation of data persistence. It's a synchronous protocol whe= re all parties are online together exchanging information and that informat= ion is not persisted one the session is ended.


-----Original Message-----
From: plasma-b= ounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of Leif Johansson
Sent: Tuesday, April 12, 2011 7:21 AM
To: plasma@ietf.org
Subject: Re: [plasma] why not web portal mail?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/06/2011 09:33 PM, Trevor Freeman wrote:
> Stephen Farrell asked why not use Web portal mail? Why do we need to d= evelop plasma?

Maybe that question is easier to answer if we consider plasma for XMPP and = not just for email. There are important differences between XMPP and email = that make it much more challenging to build web-only versions of the XMPP.<= br>
=A0 =A0 =A0 =A0Cheers Leif
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2kX+UACgkQ8Jx8FtbMZndeOwCcC1BQafbUXYLHJZKxsuAcV8eS
6ukAnA0JGhMsLdmh+WG+GqEUoVMWj7+e
=3D5lPF
-----END PGP SIGNATURE-----
_______________________________________________
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




--
Website: http://halla= mbaker.com/




--
Website: http://hallambaker.com/

--bcaec5171ea72e2b6404a0c23041-- From leifj@mnt.se Wed Apr 13 01:22:35 2011 Return-Path: X-Original-To: plasma@ietfc.amsl.com Delivered-To: plasma@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 073B3E06A5 for ; Wed, 13 Apr 2011 01:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jD2M4nGMd-gC for ; Wed, 13 Apr 2011 01:22:34 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfc.amsl.com (Postfix) with ESMTP id 080EAE069F for ; Wed, 13 Apr 2011 01:22:33 -0700 (PDT) Received: from [130.240.93.191] (pub93-191.pub.luth.se [130.240.93.191]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p3D8MOMm028605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Apr 2011 10:22:27 +0200 (CEST) Message-ID: <4DA55D40.8040306@mnt.se> Date: Wed, 13 Apr 2011 10:22:24 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Trevor Freeman References: <4DA45FE5.3020102@mnt.se> <4DA4BC30.7060308@mnt.se> <4DA4BC92.6070701@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "plasma@ietf.org" Subject: Re: [plasma] why not web portal mail? 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, 13 Apr 2011 08:22:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/13/2011 01:11 AM, Trevor Freeman wrote: > I realize at the physical level with IM it uses a sequence of messages which hare relayed server to server. Just as with VoIP, an audio stream is packaged as a sequence of IP packets. However there is no concept of long term persistence of information outside of the IM session (I am ignoring auditing). I don’t have an IM inbox. > > The closest I can get is if I persist my IM history I would invoke the policy but it's not intuitive I would spawn more im sessions based on that as I would forward or reply all with email. Yes you do! XEP-0060 is exactly your XMPP inbox. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2lXUAACgkQ8Jx8FtbMZnei6QCeNXQ5S0rMvwkoEQxkhjr1OEPh j+wAn1dkalg+lZBnxzbhbJUVrwmIpE9e =WnBF -----END PGP SIGNATURE----- From trevorf@exchange.microsoft.com Wed Apr 13 10:08:35 2011 Return-Path: X-Original-To: plasma@ietfc.amsl.com Delivered-To: plasma@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A3576E075D for ; Wed, 13 Apr 2011 10:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xr7PUvsLPiqG for ; Wed, 13 Apr 2011 10:08:34 -0700 (PDT) Received: from mail.exchange.microsoft.com (mail1.exchange.microsoft.com [131.107.1.17]) by ietfc.amsl.com (Postfix) with ESMTP id A1FE3E0705 for ; Wed, 13 Apr 2011 10:08:34 -0700 (PDT) Received: from df-h14-01.exchange.corp.microsoft.com (157.54.78.139) by DF-G14-01.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 13 Apr 2011 10:08:33 -0700 Received: from df-mlt-02.exchange.corp.microsoft.com (157.54.94.20) by DF-H14-01.exchange.corp.microsoft.com (157.54.78.139) with Microsoft SMTP Server (TLS) id 14.1.289.8; Wed, 13 Apr 2011 10:08:33 -0700 Received: from DF-M14-12.exchange.corp.microsoft.com ([fe80::7c94:4036:120:c95f]) by DF-MLT-02.exchange.corp.microsoft.com ([157.54.94.20]) with mapi id 14.01.0218.012; Wed, 13 Apr 2011 10:08:33 -0700 From: Trevor Freeman To: Leif Johansson Thread-Topic: [plasma] why not web portal mail? Thread-Index: Acv0kXrWGetxV1fRTF6d/JQ0xrOecQExhkeAAAW7cdAACAVCAAAADpoAAAqOW3AADWMXAAADqikA Date: Wed, 13 Apr 2011 17:08:32 +0000 Message-ID: References: <4DA45FE5.3020102@mnt.se> <4DA4BC30.7060308@mnt.se> <4DA4BC92.6070701@stpeter.im> <4DA55D40.8040306@mnt.se> In-Reply-To: <4DA55D40.8040306@mnt.se> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "plasma@ietf.org" Subject: Re: [plasma] why not web portal mail? 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, 13 Apr 2011 17:08:35 -0000 T2sgdGhlbiBJIGRvbuKAmXQgZ2V0IHRoZSB1c2UgY2FzZS4gDQoNCkNhbiB5b3UgZGVzY3JpYmUg d2hlbiBhIHVzZXIgd291bGQgZG8gc3VjaCBhIHRoaW5nIGFuZCB3aGF0IGFyZSB0aGV5IHRyeWlu ZyB0byBhY2NvbXBsaXNoPyANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExl aWYgSm9oYW5zc29uIFttYWlsdG86bGVpZmpAbW50LnNlXSANClNlbnQ6IFdlZG5lc2RheSwgQXBy aWwgMTMsIDIwMTEgMToyMiBBTQ0KVG86IFRyZXZvciBGcmVlbWFuDQpDYzogUGV0ZXIgU2FpbnQt QW5kcmU7IHBsYXNtYUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtwbGFzbWFdIHdoeSBub3Qgd2Vi IHBvcnRhbCBtYWlsPw0KDQotLS0tLUJFR0lOIFBHUCBTSUdORUQgTUVTU0FHRS0tLS0tDQpIYXNo OiBTSEExDQoNCk9uIDA0LzEzLzIwMTEgMDE6MTEgQU0sIFRyZXZvciBGcmVlbWFuIHdyb3RlOg0K PiBJIHJlYWxpemUgYXQgdGhlIHBoeXNpY2FsIGxldmVsIHdpdGggSU0gaXQgdXNlcyBhIHNlcXVl bmNlIG9mIG1lc3NhZ2VzIHdoaWNoIGhhcmUgcmVsYXllZCBzZXJ2ZXIgdG8gc2VydmVyLiBKdXN0 IGFzIHdpdGggVm9JUCwgYW4gYXVkaW8gc3RyZWFtIGlzIHBhY2thZ2VkIGFzIGEgc2VxdWVuY2Ug b2YgSVAgcGFja2V0cy4gSG93ZXZlciB0aGVyZSBpcyBubyBjb25jZXB0IG9mIGxvbmcgdGVybSBw ZXJzaXN0ZW5jZSBvZiBpbmZvcm1hdGlvbiBvdXRzaWRlIG9mIHRoZSBJTSBzZXNzaW9uIChJIGFt IGlnbm9yaW5nIGF1ZGl0aW5nKS4gSSBkb27igJl0IGhhdmUgYW4gSU0gaW5ib3guDQo+IA0KPiBU aGUgY2xvc2VzdCBJIGNhbiBnZXQgaXMgaWYgSSBwZXJzaXN0IG15IElNIGhpc3RvcnkgSSB3b3Vs ZCBpbnZva2UgdGhlIHBvbGljeSBidXQgaXQncyBub3QgaW50dWl0aXZlIEkgd291bGQgc3Bhd24g bW9yZSBpbSBzZXNzaW9ucyBiYXNlZCBvbiB0aGF0IGFzIEkgd291bGQgZm9yd2FyZCBvciByZXBs eSBhbGwgd2l0aCBlbWFpbC4gDQoNClllcyB5b3UgZG8hIFhFUC0wMDYwIGlzIGV4YWN0bHkgeW91 ciBYTVBQIGluYm94Lg0KLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdu dVBHIHYxLjQuMTAgKEdOVS9MaW51eCkNCkNvbW1lbnQ6IFVzaW5nIEdudVBHIHdpdGggTW96aWxs YSAtIGh0dHA6Ly9lbmlnbWFpbC5tb3pkZXYub3JnLw0KDQppRVlFQVJFQ0FBWUZBazJsWFVBQUNn a1E4Sng4RnRiTVpuZWk2UUNlTlhRNVMwck12d2tvRVF4a2hqcjFPRVBoDQpqK3dBbjFka2FsZyts WkJueHpiaGJKVVZyd21JcEU5ZQ0KPVduQkYNCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0K From trevorf@exchange.microsoft.com Wed Apr 13 10:59:04 2011 Return-Path: X-Original-To: plasma@ietfc.amsl.com Delivered-To: plasma@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 83932E0892 for ; Wed, 13 Apr 2011 10:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKgiDby68Ss4 for ; Wed, 13 Apr 2011 10:58:58 -0700 (PDT) Received: from mail.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by ietfc.amsl.com (Postfix) with ESMTP id 2FF42E07DA for ; Wed, 13 Apr 2011 10:58:58 -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.1.218.12; Wed, 13 Apr 2011 10:58:57 -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.1.289.8; Wed, 13 Apr 2011 10:58:57 -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.01.0218.012; Wed, 13 Apr 2011 10:58:56 -0700 From: Trevor Freeman To: Phillip Hallam-Baker Thread-Topic: [plasma] why not web portal mail? Thread-Index: AQHL+Ug51oJEPZwodEWIarS6m5uzOpRa0X0wgACatwCAAKSbQA== Date: Wed, 13 Apr 2011 17:58:56 +0000 Message-ID: References: <4DA45FE5.3020102@mnt.se> In-Reply-To: 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_E545B914D50B2A4B994F198378B1525D339F03B7DFM1412exchange_" MIME-Version: 1.0 Cc: "plasma@ietf.org" Subject: Re: [plasma] why not web portal mail? 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, 13 Apr 2011 17:59:04 -0000 --_000_E545B914D50B2A4B994F198378B1525D339F03B7DFM1412exchange_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Phillip Hallam-Baker [mailto:hallam@gmail.com] Sent: Tuesday, April 12, 2011 5:50 PM To: Trevor Freeman Cc: Leif Johansson; plasma@ietf.org Subject: Re: [plasma] why not web portal mail? Agreed, but not actually an issue. If we have a collection of data in a database that is controlled under the = secret#example.com policy we might have an infinite ser= ies of permutations and subsets that could be drawn from the database. [TF] I do think we need to store the logic tree of how the policies are exp= ected to be combined. I have come across scenarios where the policies are a= logical AND as well as scenarios where the policies are a logical OR. That= needs to be persisted with the data. We don't need to standardize the expression of the secret#example.com policy or how it relates to the dataset. There might be cons= traints in there of the form 'fans of Lady Gaga can only download a maximum= of 1000 items', there might be propositions that are nondeterministic, eve= n undecidable. [TF] Agreed. The point of Plasma is that process is opaque to the client. A= ll the client should get is a series of references from the server of polic= es the user can assert which amounts to a list of stings. We need a machine= readable sting and a sting for the user. All an application ever needs to deal with is the consequences of that poli= cy and those can be reduced to a small number of fixed actions plus 'call b= ack for further instructions'. [TF] Yes I think we only need define a few standard actions such as sign th= e thing. We also need to define obligations on policy binding for derivativ= e data. In some cases you can change it or remove it, other you can append = to it, etc. There will have to be a policy language of course. But the policy language = itself does not need to be part of the standard. Its like the .NET specific= ation, the byte code and the APIs are standard, but that infrastructure can= support a vast array of languages. [TF] Defiantly don't need to standardize the policy language in Plasma. We = only need to standardize the reference to the policy itself. We may want to= standardize discovery of keys. The round trip to the plasma server is time= consuming which is not a problem for the client but is for a server. If I = want to preauthorize access to the email e.g. an AV scanning service for th= e domain, then we need to find their keys before we send the email. What we need in the PLASMA standard is the range of moves used to implement= the policy. [TF] If by that you mean how to I interact with the policy server and what = does it expect me to do, yes. That is good in two ways, first it is more general and a better architectur= e, second it avoids the worst thickets of patent trolldom which obsess abou= t the idea of moving the policy itself round with the data being controlled= . That is a necessary approach for copyright enforcement which had to suppo= rt offline devices and physical media once upon a time but not for content = management in general. [TF] Embedding the policy with the data is a bad idea became it presents an= unsolvable maintenance problem. Data has a habit of getting copied and mov= ed to all sorts of locations. If the policy changed then you cannot track d= own every copy. On Tue, Apr 12, 2011 at 6:52 PM, Trevor Freeman > wrote: Policy does not distinguish in what form the data is held. So information p= ersisted in email is subject to the same policy as the same information per= sisted in a word document. Yes we have to bind data to some set of policies. The semantics for email a= nd documents are the same. Overall the Alice case you cited is too simple. A more realist example is Alice has some data and wants to apply policy X and Y to her data Bob has some data and wants to apply policy Z to his data Policies X, Y and Z each defines a set of authorized recipients. Alice and Bob's data had become comingled so now policies X Y and Z have to= be enforced. In an ideal world we would want to identify Alice's and Bob's data and bind= it to its respective polices. In a less than perfect world we may enforce access at the container level w= hich is an incremental improvement on what we have today. From: Phillip Hallam-Baker [mailto:hallam@gmail.com] Sent: Tuesday, April 12, 2011 12:31 PM To: Trevor Freeman Cc: Leif Johansson; plasma@ietf.org Subject: Re: [plasma] why not web portal mail? If we consider the Word, Excel and Diplomatic cables examples, the data is = static and to be controlled under a policy regardless of what channels it m= ight be transferred or transmitted through. The protocol requirement here in my view is to enable applications to deter= mine how to apply the security policy identified as X to the data object Y. On Tue, Apr 12, 2011 at 2:41 PM, Trevor Freeman > wrote: If you consider XMPP case it is easier because there is no expectation of d= ata persistence. It's a synchronous protocol where all parties are online t= ogether exchanging information and that information is not persisted one th= e session is ended. -----Original Message----- From: plasma-bounces@ietf.org [mailto:plasm= a-bounces@ietf.org] On Behalf Of Leif Johan= sson Sent: Tuesday, April 12, 2011 7:21 AM To: plasma@ietf.org Subject: Re: [plasma] why not web portal mail? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/06/2011 09:33 PM, Trevor Freeman wrote: > Stephen Farrell asked why not use Web portal mail? Why do we need to deve= lop plasma? Maybe that question is easier to answer if we consider plasma for XMPP and = not just for email. There are important differences between XMPP and email = that make it much more challenging to build web-only versions of the XMPP. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2kX+UACgkQ8Jx8FtbMZndeOwCcC1BQafbUXYLHJZKxsuAcV8eS 6ukAnA0JGhMsLdmh+WG+GqEUoVMWj7+e =3D5lPF -----END PGP SIGNATURE----- _______________________________________________ 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 -- Website: http://hallambaker.com/ -- Website: http://hallambaker.com/ --_000_E545B914D50B2A4B994F198378B1525D339F03B7DFM1412exchange_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: Phillip = Hallam-Baker [mailto:hallam@gmail.com]
Sent: Tuesday, April 12, 2011 5:50 PM
To: Trevor Freeman
Cc: Leif Johansson; plasma@ietf.org
Subject: Re: [plasma] why not web portal mail?

 

Agreed, but not actually an issue.

 

 

We don't need to standardize the expression of the s= ecret#example.com policy or how it relat= es to the dataset. There might be constraints in there of the form 'fans of= Lady Gaga can only download a maximum of 1000 items', there might be propositions that are nondeterministic, eve= n undecidable.

[TF] = Agreed. The point of Plasma is that pr= ocess is opaque to the client. All the client should get is a series of references from the server of polices the user can assert whic= h amounts to a list of stings. We need a machine readable sting and a sting= for the user.

 

All an application ever needs to deal with is the co= nsequences of that policy and those can be reduced to a small number of fix= ed actions plus 'call back for further instructions'.

[TF] Yes I think we= only need define a few standard actions such as sign the thing. We also ne= ed to define obligations on policy binding for derivative data. In some cases you can change it or remove it, other you can append t= o it, etc.

 

There will have to be a policy language of course. B= ut the policy language itself does not need to be part of the standard. Its= like the .NET specification, the byte code and the APIs are standard, but = that infrastructure can support a vast array of languages.

[TF] Defiantly don&= #8217;t need to standardize the policy language in Plasma. We only need to = standardize the reference to the policy itself. We may want to standardize discovery of keys. The round trip to the plasma server is time= consuming which is not a problem for the client but is for a server. If I = want to preauthorize access to the email e.g. an AV scanning service for th= e domain, then we need to find their keys before we send the email.

 

What we need in the PLASMA standard is the range of = moves used to implement the policy.

[TF] = If by that you mean how to I interact = with the policy server and what does it expect me to do, yes.

 

That is good in two ways, first it is more general a= nd a better architecture, second it avoids the worst thickets of patent tro= lldom which obsess about the idea of moving the policy itself round with th= e data being controlled. That is a necessary approach for copyright enforcement which had to support offline = devices and physical media once upon a time but not for content management = in general.

[TF] Embedding the = policy with the data is a bad idea became it presents an unsolvable mainten= ance problem. Data has a habit of getting copied and moved to all sorts of locations. If the policy changed then you cannot track dow= n every copy.

 

 

On Tue, Apr 12, 2011 at 6:52 PM, Trevor Freeman <= trevorf@exchange.microsof= t.com> wrote:

Policy does not = distinguish in what form the data is held. So information persisted in emai= l is subject to the same policy as the same information persisted in a word document.

 

Yes we have to b= ind data to some set of policies. The semantics for email and documents are= the same.

 

Overall the Alic= e case you cited is too simple. A more realist example is

 

Alice has some data and w= ants to apply policy X and Y to her data

Bob has some data and wan= ts to apply policy Z to his data

 

Policies X, Y and Z each = defines a set of authorized recipients.

 

Alice and Bob’s dat= a had become comingled so now policies X Y and Z have to be enforced.

 

In an ideal worl= d we would want to identify Alice’s and Bob’s data and bind it = to its respective polices.

 

In a less than p= erfect world we may enforce access at the container level which is an incre= mental improvement on what we have today.

 

 =

From: Phillip Hallam-Baker [mailto:hallam@gmail.com]
Sent: Tuesday, April 12, 2011 12:31 PM
To: Trevor Freeman
Cc: Leif Johansson; plasma@ietf.org


Subject: Re: [plasma] why not web portal mail?

 

If we consider the Word, Excel and Diplomatic cables examples, the= data is static and to be controlled under a policy regardless of what chan= nels it might be transferred or transmitted through.

 

The protocol requirement here in my view is to enable applications= to determine how to apply the security policy identified as X to the data = object Y.

 

On Tue, Apr 12, 2011 at 2:41 PM, Trevor Freeman <trevorf@exchange.micr= osoft.com> wrote:

If you consider XMPP case it is easier because there is no expecta= tion of data persistence. It's a synchronous protocol where all parties are= online together exchanging information and that information is not persisted one the session is ended.=


-----Original Message-----
From: plasma-b= ounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of Leif Johansson
Sent: Tuesday, April 12, 2011 7:21 AM
To: plasma@ietf.org
Subject: Re: [plasma] why not web portal mail?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/06/2011 09:33 PM, Trevor Freeman wrote:
> Stephen Farrell asked why not use Web portal mail? Why do we need to d= evelop plasma?

Maybe that question is easier to answer if we consider plasma for XMPP and = not just for email. There are important differences between XMPP and email = that make it much more challenging to build web-only versions of the XMPP.<= br>
       Cheers Leif
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2kX+UACgkQ8Jx8FtbMZndeOwCcC1BQafbUXYLHJZKxsuAcV8eS
6ukAnA0JGhMsLdmh+WG+GqEUoVMWj7+e
=3D5lPF
-----END PGP SIGNATURE-----
_______________________________________________
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




--
Website: http://halla= mbaker.com/




--
Website: http://hallambaker.com/

--_000_E545B914D50B2A4B994F198378B1525D339F03B7DFM1412exchange_-- From leifj@mnt.se Wed Apr 13 14:14:44 2011 Return-Path: X-Original-To: plasma@ietfc.amsl.com Delivered-To: plasma@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5B75EE081F for ; Wed, 13 Apr 2011 14:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ritoZl-5Qy7A for ; Wed, 13 Apr 2011 14:14:43 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfc.amsl.com (Postfix) with ESMTP id 7A4EEE06EA for ; Wed, 13 Apr 2011 14:14:43 -0700 (PDT) Received: from [172.20.10.2] ([2.68.206.93]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p3DLEUvG019369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Apr 2011 23:14:35 +0200 (CEST) Message-ID: <4DA61235.2050708@mnt.se> Date: Wed, 13 Apr 2011 23:14:29 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Trevor Freeman References: <4DA45FE5.3020102@mnt.se> <4DA4BC30.7060308@mnt.se> <4DA4BC92.6070701@stpeter.im> <4DA55D40.8040306@mnt.se> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "plasma@ietf.org" Subject: Re: [plasma] why not web portal mail? 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, 13 Apr 2011 21:14:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/13/2011 07:08 PM, Trevor Freeman wrote: > Ok then I don’t get the use case. > > Can you describe when a user would do such a thing and what are they trying to accomplish? OK I'll try to spell it out... The point I was trying to make is and was that the same requirements and UCs that apply to email apply equally well to XMPP. The fact that XMPP _has_ store-and-forward capabilities doesn't mean it is _exactly_ the same thing as email. I believe the difficulty of building web-only XMPP clients and the fact that plasma-like capabilities are probably equally useful for XMPP as for email is a response to Stephens question "Why not build a web-applications?". Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2mEjUACgkQ8Jx8FtbMZneNrACdG2X3BpzxwMIUKaA8E3SyTJ48 SccAn3kI1ThX3MisHpoRkoQC/x16yMi4 =G2Zh -----END PGP SIGNATURE----- From trevorf@exchange.microsoft.com Fri Apr 15 10:00:00 2011 Return-Path: X-Original-To: plasma@ietfc.amsl.com Delivered-To: plasma@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3500313001A for ; Fri, 15 Apr 2011 10:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3rC63cOd3Zz for ; Fri, 15 Apr 2011 09:59:56 -0700 (PDT) Received: from mail.exchange.microsoft.com (mail1.exchange.microsoft.com [131.107.1.17]) by ietfc.amsl.com (Postfix) with ESMTP id EA4FF130062 for ; Fri, 15 Apr 2011 09:59:52 -0700 (PDT) Received: from df-h14-01.exchange.corp.microsoft.com (157.54.78.139) by DF-G14-01.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 14.1.218.12; Fri, 15 Apr 2011 09:59:51 -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.1.289.8; Fri, 15 Apr 2011 09:59:51 -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.01.0218.012; Fri, 15 Apr 2011 09:59:51 -0700 From: Trevor Freeman To: Leif Johansson Thread-Topic: [plasma] why not web portal mail? Thread-Index: Acv0kXrWGetxV1fRTF6d/JQ0xrOecQExhkeAAAW7cdAACAVCAAAADpoAAAqOW3AADWMXAAADqikAABdMzYAATLOGMA== Date: Fri, 15 Apr 2011 16:59:51 +0000 Message-ID: References: <4DA45FE5.3020102@mnt.se> <4DA4BC30.7060308@mnt.se> <4DA4BC92.6070701@stpeter.im> <4DA55D40.8040306@mnt.se> <4DA61235.2050708@mnt.se> In-Reply-To: <4DA61235.2050708@mnt.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.104] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "plasma@ietf.org" Subject: Re: [plasma] why not web portal mail? 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: Fri, 15 Apr 2011 17:00:00 -0000 TGVpZiwNCg0KSSBhbSBzdXJlIFBsYXNtYSBpcyBhcHBsaWNhYmxlIHRvIFhNUFAuDQoNClRoZSBx dWVzdGlvbiBJIGFtIHRyeWluZyB0byBhbnN3ZXIgaW4gbXkgbWluZCBpcyB3aGF0IGlzIGhhcHBp bmcgdG8gdGhlIGRhdGEuIFdoaWxlIHRoZXJlIGFyZSBhIGxvdCBvZiBzaW1pbGFyaXRpZXMsIHRo ZXkgYXJlIG5vdCBpZGVudGljYWwgc28gd2UgY2FuIHRvIGxvb2sgYXQgdGhlIGV4cGVjdGVkIGJl aGF2aW9yIG9mIHRoZSBjbGllbnQgd3J0IHRoZSBkYXRhLiBXaGlsZSBJTSBleGNoYW5nZXMgZGF0 YSBJIGRvbuKAmXQgc2VlIGluIGN1cnJlbnQgY2xpZW50cyB0aGUgY29tbWluZ2xpbmcgYW5kIHJl dXNlIG9mIGRhdGEgeW91IGdldCB3aXRoIGVtYWlsLiBUaGF0IHNob3VsZCBiZSBnb29kbmVzcyBm b3IgWE1QUCBiZWNhdXNlIHRoZSBjb21wbGljYXRpb25zIGZvciBlbWFpbCBsaWUgaW4gdGhpcyBj b21pbmdsaW5nIGFuZCByZXVzZS4gDQoNCklmIHlvdSBjYW4gd3JpdGUgdXAgYSB1c2UgY2FzZSBm b3Igbm9uLXN0b3JlIGFuZCBmb3J3YXJkIGFzIHdlbGwgYXMgc3RvcmUgYW5kIGZvcndhcmQgSSBj YW4gaW5jb3Jwb3JhdGUgdGhlbSBpbnRvIHRoZSByZXF1aXJlbWVudHMgZG9jLiANCg0KVGhhbmtz IA0KDQpUcmV2b3INCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExlaWYgSm9o YW5zc29uIFttYWlsdG86bGVpZmpAbW50LnNlXSANClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTMs IDIwMTEgMjoxNCBQTQ0KVG86IFRyZXZvciBGcmVlbWFuDQpDYzogUGV0ZXIgU2FpbnQtQW5kcmU7 IHBsYXNtYUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtwbGFzbWFdIHdoeSBub3Qgd2ViIHBvcnRh bCBtYWlsPw0KDQotLS0tLUJFR0lOIFBHUCBTSUdORUQgTUVTU0FHRS0tLS0tDQpIYXNoOiBTSEEx DQoNCk9uIDA0LzEzLzIwMTEgMDc6MDggUE0sIFRyZXZvciBGcmVlbWFuIHdyb3RlOg0KPiBPayB0 aGVuIEkgZG9u4oCZdCBnZXQgdGhlIHVzZSBjYXNlLiANCj4gDQo+IENhbiB5b3UgZGVzY3JpYmUg d2hlbiBhIHVzZXIgd291bGQgZG8gc3VjaCBhIHRoaW5nIGFuZCB3aGF0IGFyZSB0aGV5IHRyeWlu ZyB0byBhY2NvbXBsaXNoPyANCg0KT0sgSSdsbCB0cnkgdG8gc3BlbGwgaXQgb3V0Li4uDQoNClRo ZSBwb2ludCBJIHdhcyB0cnlpbmcgdG8gbWFrZSBpcyBhbmQgd2FzIHRoYXQgdGhlIHNhbWUgcmVx dWlyZW1lbnRzIGFuZCBVQ3MgdGhhdCBhcHBseSB0byBlbWFpbCBhcHBseSBlcXVhbGx5IHdlbGwg dG8gWE1QUC4gVGhlIGZhY3QgdGhhdCBYTVBQIF9oYXNfIHN0b3JlLWFuZC1mb3J3YXJkIGNhcGFi aWxpdGllcyBkb2Vzbid0IG1lYW4gaXQgaXMgX2V4YWN0bHlfIHRoZSBzYW1lIHRoaW5nIGFzIGVt YWlsLg0KDQpJIGJlbGlldmUgdGhlIGRpZmZpY3VsdHkgb2YgYnVpbGRpbmcgd2ViLW9ubHkgWE1Q UCBjbGllbnRzIGFuZCB0aGUgZmFjdCB0aGF0IHBsYXNtYS1saWtlIGNhcGFiaWxpdGllcyBhcmUg cHJvYmFibHkgZXF1YWxseSB1c2VmdWwgZm9yIFhNUFAgYXMgZm9yIGVtYWlsIGlzIGEgcmVzcG9u c2UgdG8gU3RlcGhlbnMgcXVlc3Rpb24gIldoeSBub3QgYnVpbGQgYSB3ZWItYXBwbGljYXRpb25z PyIuDQoNCglDaGVlcnMgTGVpZg0KLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNp b246IEdudVBHIHYxLjQuMTAgKEdOVS9MaW51eCkNCkNvbW1lbnQ6IFVzaW5nIEdudVBHIHdpdGgg TW96aWxsYSAtIGh0dHA6Ly9lbmlnbWFpbC5tb3pkZXYub3JnLw0KDQppRVlFQVJFQ0FBWUZBazJt RWpVQUNna1E4Sng4RnRiTVpuZU5yQUNkRzJYM0Jwenh3TUlVS2FBOEUzU3lUSjQ4DQpTY2NBbjNr STFUaFgzTWlzSHBvUmtvUUMveDE2eU1pNA0KPUcyWmgNCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUt LS0tLQ0K From trevorf@exchange.microsoft.com Tue Apr 19 14:19:13 2011 Return-Path: X-Original-To: plasma@ietfc.amsl.com Delivered-To: plasma@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7A4ECE081F for ; Tue, 19 Apr 2011 14:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqro6Bffq0bI for ; Tue, 19 Apr 2011 14:19:12 -0700 (PDT) Received: from mail.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by ietfc.amsl.com (Postfix) with ESMTP id 162A4E086D for ; Tue, 19 Apr 2011 14:19:09 -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.1.218.12; Tue, 19 Apr 2011 14:19:08 -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.1.289.8; Tue, 19 Apr 2011 14:19:08 -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.01.0218.012; Tue, 19 Apr 2011 14:19:08 -0700 From: Trevor Freeman To: "plasma@ietf.org" Thread-Topic: Plasma and File protection Question Thread-Index: Acv+12enYPbxA8mtTICquFGvp+a95A== Date: Tue, 19 Apr 2011 21:19:07 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.101] Content-Type: multipart/alternative; boundary="_000_E545B914D50B2A4B994F198378B1525D33A0036DDFM1412exchange_" MIME-Version: 1.0 Subject: [plasma] Plasma and File protection Question 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, 19 Apr 2011 21:19:13 -0000 --_000_E545B914D50B2A4B994F198378B1525D33A0036DDFM1412exchange_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Having agreed that files and are the conceptually the same as email from a = policy access control perspective, there is one important distinction. Email has a standard mechanism to define multiple parts of a message to rep= resent different aspects of the message i.e. MIME. We don't have that for files so we don't have a simple generic way to attac= h the extra metadata to a file. Some standard file formats have specific extension mechanisms we can use e.= g. OOXML which would allow you to define a way to attach the plasma metadat= a to the file type in question. Alternatively there exist generic file container standards what can hold an= y combination of files and data e.g. OPC which would provide a generic solu= tion for any file type. If we were to expand files for consideration with Plasma, which would be th= e best first step, a specific solution like OOXML or a generic solution suc= h as OPC? Dr Trevor Freeman Senior Security Strategist End to End Trust Team Microsoft Trustworthy Computing --_000_E545B914D50B2A4B994F198378B1525D33A0036DDFM1412exchange_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Having agreed that files and are the conceptually th= e same as email from a policy access control perspective, there is one impo= rtant distinction.

 

Email has a standard mechanism to define multiple pa= rts of a message to represent different aspects of the message i.e. MIME.

 

We don’t have that for files so we don’t= have a simple generic way to attach the extra metadata to a file.

 

Some standard file formats have specific extension m= echanisms we can use e.g. OOXML which would allow you to define a way to at= tach the plasma metadata to the file type in question.

 

Alternatively there exist generic file container sta= ndards what can hold any combination of files and data e.g. OPC which would= provide a generic solution for any file type.

 

If we were to expand files for consideration with Pl= asma, which would be the best first step, a specific solution like OOXML or= a generic solution such as OPC?

 

Dr Trevor Freema= n  Senior Secur= ity Strategist

End to End Trust Team<= /b>

Microsoft Trustworthy Computing  

 

--_000_E545B914D50B2A4B994F198378B1525D33A0036DDFM1412exchange_-- From stephen.farrell@cs.tcd.ie Tue Apr 19 14:39:59 2011 Return-Path: X-Original-To: plasma@ietfc.amsl.com Delivered-To: plasma@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C3CB3E0861 for ; Tue, 19 Apr 2011 14:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2s6Wg9dnxzW6 for ; Tue, 19 Apr 2011 14:39:58 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfc.amsl.com (Postfix) with ESMTP id 816D8E07A4 for ; Tue, 19 Apr 2011 14:39:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 0E95E171C1D; Tue, 19 Apr 2011 22:39:57 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1303249196; bh=1NoP74F/JunFhz AkAYzOFMBxPK8U/WcYd5x3y88KgRw=; b=1dLd4bpl5/ymeIgktTDw4Y3wUKjbNO ugyUneq4LyklcPl9E3pUh3CTQ93tKayz3zpCcM8sFvPxYXOdbA9Zc0M0hzS6X/Y+ Jjxu8faO9ryBdGQ6Zzu+3Qkq1yHS3uEwR0bqtvHOmDlT2SzjibGIyuEO4QLOeqL3 TNYpADkfT/inMgGiYig7DUFAe+70RO/0k7whGsV/0XXRtrGnTqTA2ZDqzwEcpUWw t2ZWDk2y0P+XA6Ry9ExgJ2YE+x1PqWaGr+RcaT0q8M1RhyGBBonXjo+xmeO5DbCT /n9iv+fDBRvnlRHjKh0mQspe9avXDRZlB4VndqDmI8J24DIustrv3big== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id cWxV5PV-O+fN; Tue, 19 Apr 2011 22:39:56 +0100 (IST) Received: from [10.87.48.10] (unknown [86.42.177.204]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 75FF2171C1B; Tue, 19 Apr 2011 22:39:56 +0100 (IST) Message-ID: <4DAE012B.9030809@cs.tcd.ie> Date: Tue, 19 Apr 2011 22:39:55 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Trevor Freeman References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "plasma@ietf.org" Subject: Re: [plasma] Plasma and File protection Question 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, 19 Apr 2011 21:40:00 -0000 I've no idea what OPC is but I'd have thought that OOXML would likely be controversial - or have all the word processing types made up since the OOXML/ODF kerfuffle [1] of a few years ago? S. [1] http://en.wikipedia.org/wiki/Office_Open_XML#Standardization_process On 19/04/11 22:19, Trevor Freeman wrote: > Having agreed that files and are the conceptually the same as email from > a policy access control perspective, there is one important distinction. > > > > Email has a standard mechanism to define multiple parts of a message to > represent different aspects of the message i.e. MIME. > > > > We don’t have that for files so we don’t have a simple generic way to > attach the extra metadata to a file. > > > > Some standard file formats have specific extension mechanisms we can use > e.g. OOXML which would allow you to define a way to attach the plasma > metadata to the file type in question. > > > > Alternatively there exist generic file container standards what can hold > any combination of files and data e.g. OPC which would provide a generic > solution for any file type. > > > > If we were to expand files for consideration with Plasma, which would be > the best first step, a specific solution like OOXML or a generic > solution such as OPC? > > > > *Dr Trevor Freeman* Senior Security Strategist > > *End to End Trust Team > * > > *Microsoft Trustworthy > Computing* > > > > > > _______________________________________________ > plasma mailing list > plasma@ietf.org > https://www.ietf.org/mailman/listinfo/plasma From trevorf@exchange.microsoft.com Tue Apr 19 16:13:37 2011 Return-Path: X-Original-To: plasma@ietfc.amsl.com Delivered-To: plasma@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E4718E081E for ; Tue, 19 Apr 2011 16:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4k5Uju09KQU for ; Tue, 19 Apr 2011 16:13:35 -0700 (PDT) Received: from mail.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by ietfc.amsl.com (Postfix) with ESMTP id B5C95E06F9 for ; Tue, 19 Apr 2011 16:13:34 -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.1.218.12; Tue, 19 Apr 2011 16:13:34 -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.1.289.8; Tue, 19 Apr 2011 16:13:33 -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.01.0218.012; Tue, 19 Apr 2011 16:13:32 -0700 From: Trevor Freeman To: Stephen Farrell Thread-Topic: [plasma] Plasma and File protection Question Thread-Index: Acv+12enYPbxA8mtTICquFGvp+a95AAPZcuAAAwRLoA= Date: Tue, 19 Apr 2011 23:13:31 +0000 Message-ID: References: <4DAE012B.9030809@cs.tcd.ie> In-Reply-To: <4DAE012B.9030809@cs.tcd.ie> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.100] Content-Type: multipart/alternative; boundary="_000_E545B914D50B2A4B994F198378B1525D33A00438DFM1412exchange_" MIME-Version: 1.0 Cc: "plasma@ietf.org" Subject: Re: [plasma] Plasma and File protection Question 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, 19 Apr 2011 23:13:38 -0000 --_000_E545B914D50B2A4B994F198378B1525D33A00438DFM1412exchange_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OPC =3D Open Packaging Convention; it's the official standard name for zip = files. The attraction of an OPC solution is you can protect anything just as you c= an zip anything so it would generate a universal solution. Both OOXML and ODF are widely used standards with multi-vendor support. T= he reason to cited them as examples is that they have a documented file for= mat with extension points we could use to build a solution. I doubt the OOXML\ODF thing will go away just like pkix has cmc and cmp:) Would you consider OPC a more neutral solution? -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] Sent: Tuesday, April 19, 2011 2:40 PM To: Trevor Freeman Cc: plasma@ietf.org Subject: Re: [plasma] Plasma and File protection Question I've no idea what OPC is but I'd have thought that OOXML would likely be co= ntroversial - or have all the word processing types made up since the OOXML= /ODF kerfuffle [1] of a few years ago? S. [1] http://en.wikipedia.org/wiki/Office_Open_XML#Standardization_process On 19/04/11 22:19, Trevor Freeman wrote: > Having agreed that files and are the conceptually the same as email > from a policy access control perspective, there is one important distinct= ion. > > > > Email has a standard mechanism to define multiple parts of a message > to represent different aspects of the message i.e. MIME. > > > > We don't have that for files so we don't have a simple generic way to > attach the extra metadata to a file. > > > > Some standard file formats have specific extension mechanisms we can > use e.g. OOXML which would allow you to define a way to attach the > plasma metadata to the file type in question. > > > > Alternatively there exist generic file container standards what can > hold any combination of files and data e.g. OPC which would provide a > generic solution for any file type. > > > > If we were to expand files for consideration with Plasma, which would > be the best first step, a specific solution like OOXML or a generic > solution such as OPC? > > > > *Dr Trevor Freeman* Senior Security Strategist > > *End to End Trust Team > * > > *Microsoft Trustworthy > Computing* > > > > > > _______________________________________________ > plasma mailing list > plasma@ietf.org > https://www.ietf.org/mailman/listinfo/plasma --_000_E545B914D50B2A4B994F198378B1525D33A00438DFM1412exchange_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

OPC =3D Open Packaging Convention; it’s the= official standard name for zip files.

 

The attraction of an OPC solution is you can prot= ect anything just as you can zip anything so it would generate a universal = solution.

 

Both OOXML and ODF are widely used standards with= multi-vendor support.   The reason to cited them as examples is = that they have a documented file format with extension points we could use = to build a solution.

 

I doubt the OOXML\ODF thing will go away just lik= e pkix has cmc and cmpJ

 

Would you consider OPC a more neutral solution?

 

-----Original Message-----
From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
Sent: Tuesday, April 19, 2011 2:40 PM
To: Trevor Freeman
Cc: plasma@ietf.org
Subject: Re: [plasma] Plasma and File protection Question

 

 

I've no idea what OPC is but I'd have thought tha= t OOXML would likely be controversial - or have all the word processing typ= es made up since the OOXML/ODF kerfuffle [1] of a few years ago?=

 

S.

 

[1] http://en.wikipedia.o= rg/wiki/Office_Open_XML#Standardization_process

 

On 19/04/11 22:19, Trevor Freeman wrote:

> Having agreed that files and are the concept= ually the same as email

> from a policy access control perspective, th= ere is one important distinction.

>

> 

>

> Email has a standard mechanism to define mul= tiple parts of a message

> to represent different aspects of the messag= e i.e. MIME.

>

> 

>

> We don’t have that for files so we don= ’t have a simple generic way to

> attach the extra metadata to a file.

>

> 

>

> Some standard file formats have specific ext= ension mechanisms we can

> use e.g. OOXML which would allow you to defi= ne a way to attach the

> plasma metadata to the file type in question= .

>

> 

>

> Alternatively there exist generic file conta= iner standards what can

> hold any combination of files and data e.g. = OPC which would provide a

> generic solution for any file type.

>

> 

>

> If we were to expand files for consideration= with Plasma, which would

> be the best first step, a specific solution = like OOXML or a generic

> solution such as OPC?

>

> 

>

> *Dr Trevor Freeman*  Senior Security St= rategist

>

> *End to End Trust Team

> <http://www.microsoft.com/mscorp/twc/endtoendtrust/default.msp= x>*

>

> *Microsoft Trustworthy

> Computing<http://www.microsoft.com/mscorp/twc/default.mspx>*

>

> 

>

>

>

> ____________________________________________= ___

> plasma mailing list

> plasma@ietf.org

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

--_000_E545B914D50B2A4B994F198378B1525D33A00438DFM1412exchange_-- From stephen.farrell@cs.tcd.ie Tue Apr 19 16:29:32 2011 Return-Path: X-Original-To: plasma@ietfc.amsl.com Delivered-To: plasma@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 359B0E0857 for ; Tue, 19 Apr 2011 16:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhA49uY1JqCt for ; Tue, 19 Apr 2011 16:29:31 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfc.amsl.com (Postfix) with ESMTP id E2B60E075C for ; Tue, 19 Apr 2011 16:29:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E01DA171C1E; Wed, 20 Apr 2011 00:29:29 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1303255769; bh=bZMGtfirRkBWFI z0zXh7O1IecbWaot9hrPrXwhPQXQY=; b=G5ivGNJ+ZvGu5C7mI8u5uLsHwNBEUv Ji2tacEtjZWKtpbpGPeQU82npAdXHc3AVpYcRw78pEOANSyeRuIhR2qFSKAmsxhF iDZdlma6GqeugjzVgwGXykIk/g1a4E2S+15XhBf9nmh3+VZMFh3UWnv/0DR2llav h5NH+k8vDM9nyUhEQLl4ECai83+97i9EjjNKi1WvsJOYoQJh0qaOhdfnpbLjd4Cj EwTmIxIv/s2UpX2sJaYrZ9mMJLu73+SdEJXfxo0M6StayKNxXibT2bin/tJkyX2U qA6/A4V4sfqDEDImocmr07RA4RKnhRNQStdztmOrtcw665/6rdCfOEiw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id zgzGaWYPOa67; Wed, 20 Apr 2011 00:29:29 +0100 (IST) Received: from [10.87.48.10] (unknown [86.42.177.204]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 3A322171C1B; Wed, 20 Apr 2011 00:29:29 +0100 (IST) Message-ID: <4DAE1AD5.6080909@cs.tcd.ie> Date: Wed, 20 Apr 2011 00:29:25 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Trevor Freeman References: <4DAE012B.9030809@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "plasma@ietf.org" Subject: Re: [plasma] Plasma and File protection Question 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, 19 Apr 2011 23:29:32 -0000 Hi Trevor, I don't have a real preference/opinion myself except that a credible proposal here should have real support from various sources, optimally including the open-source community. S. On 20/04/11 00:13, Trevor Freeman wrote: > OPC = Open Packaging Convention; it’s the official standard name for zip > files. > > The attraction of an OPC solution is you can protect anything just as > you can zip anything so it would generate a universal solution. > > Both OOXML and ODF are widely used standards with multi-vendor support. > The reason to cited them as examples is that they have a documented > file format with extension points we could use to build a solution. > > I doubt the OOXML\ODF thing will go away just like pkix has cmc and cmpJ > > Would you consider OPC a more neutral solution? > > > > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Tuesday, April 19, 2011 2:40 PM > To: Trevor Freeman > Cc: plasma@ietf.org > Subject: Re: [plasma] Plasma and File protection Question > > > > > > I've no idea what OPC is but I'd have thought that OOXML would likely be > controversial - or have all the word processing types made up since the > OOXML/ODF kerfuffle [1] of a few years ago? > > > > S. > > > > [1] http://en.wikipedia.org/wiki/Office_Open_XML#Standardization_process > > > > On 19/04/11 22:19, Trevor Freeman wrote: > >> Having agreed that files and are the conceptually the same as email > >> from a policy access control perspective, there is one important > distinction. > >> > >> > >> > >> Email has a standard mechanism to define multiple parts of a message > >> to represent different aspects of the message i.e. MIME. > >> > >> > >> > >> We don’t have that for files so we don’t have a simple generic way to > >> attach the extra metadata to a file. > >> > >> > >> > >> Some standard file formats have specific extension mechanisms we can > >> use e.g. OOXML which would allow you to define a way to attach the > >> plasma metadata to the file type in question. > >> > >> > >> > >> Alternatively there exist generic file container standards what can > >> hold any combination of files and data e.g. OPC which would provide a > >> generic solution for any file type. > >> > >> > >> > >> If we were to expand files for consideration with Plasma, which would > >> be the best first step, a specific solution like OOXML or a generic > >> solution such as OPC? > >> > >> > >> > >> *Dr Trevor Freeman* Senior Security Strategist > >> > >> *End to End Trust Team > >> * > >> > >> *Microsoft Trustworthy > >> Computing* > >> > >> > >> > >> > >> > >> _______________________________________________ > >> plasma mailing list > >> plasma@ietf.org > >> https://www.ietf.org/mailman/listinfo/plasma > From hallam@gmail.com Tue Apr 19 17:14:26 2011 Return-Path: X-Original-To: plasma@ietfc.amsl.com Delivered-To: plasma@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 09EE0E075C for ; Tue, 19 Apr 2011 17:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.242 X-Spam-Level: X-Spam-Status: No, score=-3.242 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Uls2PtWe7y9 for ; Tue, 19 Apr 2011 17:14:24 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id C264FE0715 for ; Tue, 19 Apr 2011 17:14:24 -0700 (PDT) Received: by vws12 with SMTP id 12so207191vws.31 for ; Tue, 19 Apr 2011 17:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=C/8MmWxzSxTMX9w5sbi6kmMmXTqZZcah9w+XHtx547U=; b=uQqmQOFspWc36Uf+BuMuzM+pgidzoYqebyvVY92jcqNVCsiO9vSPPDfss0ypPxZyk+ VfE3pWJTuNaPRIcNPD3q/Yy8VQr31D9NJVtGuIUy26jFTR5V2N4Qdhvl2cKWUmSB1qop b9Ck5G2S3gz76gHQ54SD91i842UpxZZpFTN4I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=v6qVnRqN3qYrk+sypsligC3+oXb0x16ErcnkAgF/ZL2seGGmmo/d/ZbtFA7LkecfLu X71wlrqxwCSj2dJ+sQv57q0paDHISm8AybfoGnyB3XS6TZTSEtRO+/rAKGZytu7BR0+K fSshPrwWtsi5fF1unVNhZYeTP1/YtxOx/bjdI= MIME-Version: 1.0 Received: by 10.52.186.102 with SMTP id fj6mr5983493vdc.205.1303258464247; Tue, 19 Apr 2011 17:14:24 -0700 (PDT) Received: by 10.52.161.3 with HTTP; Tue, 19 Apr 2011 17:14:24 -0700 (PDT) In-Reply-To: References: <4DAE012B.9030809@cs.tcd.ie> Date: Tue, 19 Apr 2011 20:14:24 -0400 Message-ID: From: Phillip Hallam-Baker To: Trevor Freeman Content-Type: multipart/alternative; boundary=bcaec5489df3cfde6704a14e8100 Cc: "plasma@ietf.org" Subject: Re: [plasma] Plasma and File protection Question 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, 20 Apr 2011 00:14:26 -0000 --bcaec5489df3cfde6704a14e8100 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable OPC sounds like an appropriate container then. On Tue, Apr 19, 2011 at 7:13 PM, Trevor Freeman < trevorf@exchange.microsoft.com> wrote: > OPC =3D Open Packaging Convention; it=92s the official standard name for= zip > files. > > > > The attraction of an OPC solution is you can protect anything just as you > can zip anything so it would generate a universal solution. > > > > Both OOXML and ODF are widely used standards with multi-vendor support. > The reason to cited them as examples is that they have a documented fil= e > format with extension points we could use to build a solution. > > > > I doubt the OOXML\ODF thing will go away just like pkix has cmc and cmpJ > > > > Would you consider OPC a more neutral solution? > > > > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Tuesday, April 19, 2011 2:40 PM > To: Trevor Freeman > Cc: plasma@ietf.org > Subject: Re: [plasma] Plasma and File protection Question > > > > > > I've no idea what OPC is but I'd have thought that OOXML would likely be > controversial - or have all the word processing types made up since the > OOXML/ODF kerfuffle [1] of a few years ago? > > > > S. > > > > [1] http://en.wikipedia.org/wiki/Office_Open_XML#Standardization_process > > > > On 19/04/11 22:19, Trevor Freeman wrote: > > > Having agreed that files and are the conceptually the same as email > > > from a policy access control perspective, there is one important > distinction. > > > > > > > > > > > > Email has a standard mechanism to define multiple parts of a message > > > to represent different aspects of the message i.e. MIME. > > > > > > > > > > > > We don=92t have that for files so we don=92t have a simple generic way = to > > > attach the extra metadata to a file. > > > > > > > > > > > > Some standard file formats have specific extension mechanisms we can > > > use e.g. OOXML which would allow you to define a way to attach the > > > plasma metadata to the file type in question. > > > > > > > > > > > > Alternatively there exist generic file container standards what can > > > hold any combination of files and data e.g. OPC which would provide a > > > generic solution for any file type. > > > > > > > > > > > > If we were to expand files for consideration with Plasma, which would > > > be the best first step, a specific solution like OOXML or a generic > > > solution such as OPC? > > > > > > > > > > > > *Dr Trevor Freeman* Senior Security Strategist > > > > > > *End to End Trust Team > > > * > > > > > > *Microsoft Trustworthy > > > Computing* > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > --=20 Website: http://hallambaker.com/ --bcaec5489df3cfde6704a14e8100 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable OPC sounds like an appropriate container then.


On Tue, Apr 19, 2011 at 7:13 PM, Trevor Freeman <trevorf@exchange.mi= crosoft.com> wrote:

OPC =3D Open Packaging Convention; it=92s the official standard name for= zip files.

=A0

The attraction of an OPC solution is you can protect anything just as yo= u can zip anything so it would generate a universal solution.

=A0

Both OOXML and ODF are widely used standards with multi-vendor support. = =A0=A0The reason to cited them as examples is that they have a documented f= ile format with extension points we could use to build a solution.

=A0

I doubt the OOXML\ODF thing will go away just like pkix has cmc and cmp<= span style=3D"font-family:Wingdings">J

=A0

Would you consider OPC a more neutral solution?

=A0

-----Original Message-----
From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
Sent: Tuesday, April 19, 2011 2:40 PM
To: Trevor Freeman
Cc: plasma@ietf.org
Subject: Re: [plasma] Plasma and File protection Question

=A0

=A0

I've no idea what OPC is but I'd have thought that OOXML would l= ikely be controversial - or have all the word processing types made up sinc= e the OOXML/ODF kerfuffle [1] of a few years ago?

=A0

S.

=A0

[1] http://en.wikipedia.o= rg/wiki/Office_Open_XML#Standardization_process

=A0

On 19/04/11 22:19, Trevor Freeman wrote:

> Having agreed that files and are the conceptually the same as email

> from a policy access control perspective, there is one important di= stinction.

>

>=A0

>

> Email has a standard mechanism to define multiple parts of a messag= e

> to represent different aspects of the message i.e. MIME.

>

>=A0

>

> We don=92t have that for files so we don=92t have a simple generic = way to

> attach the extra metadata to a file.

>

>=A0

>

> Some standard file formats have specific extension mechanisms we ca= n

> use e.g. OOXML which would allow you to define a way to attach the

> plasma metadata to the file type in question.

>

>=A0

>

> Alternatively there exist generic file container standards what can

> hold any combination of files and data e.g. OPC which would provide= a

> generic solution for any file type.

>

>=A0

>

> If we were to expand files for consideration with Plasma, which wou= ld

> be the best first step, a specific solution like OOXML or a generic

> solution such as OPC?

>

>=A0

>

> *Dr Trevor Freeman*=A0 Senior Security Strategist

>

> *End to End Trust Team

> <http://www.microsoft.com/mscorp/twc/endtoendtrust/default.mspx>*

>

> *Microsoft Trustworthy

> Computing<http://www.microsoft.com/mscorp/twc/default.mspx>*

>

>=A0

>

>

>

> _______________________________________________

> 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




--
Website: http://hallambaker.com/

--bcaec5489df3cfde6704a14e8100-- From alexey.melnikov@isode.com Fri Apr 22 09:07:21 2011 Return-Path: X-Original-To: plasma@ietfc.amsl.com Delivered-To: plasma@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4C592E07AD for ; Fri, 22 Apr 2011 09:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7LjzsZq6c7q for ; Fri, 22 Apr 2011 09:07:20 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfc.amsl.com (Postfix) with ESMTP id C1B20E07A1 for ; Fri, 22 Apr 2011 09:07:20 -0700 (PDT) Received: from [188.29.6.68] (188.29.6.68.threembb.co.uk [188.29.6.68]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 22 Apr 2011 17:07:18 +0100 Message-ID: <4DB1A790.30704@isode.com> Date: Fri, 22 Apr 2011 17:06:40 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: "plasma@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [plasma] Minutes for the PLASMA BOF in Prague 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: Fri, 22 Apr 2011 16:07:21 -0000 Hi, Your somewhat disorganized BOF co-chair couldn't remember who took the minutes. Can the person send them to me directly? Thanks, Alexey