Re: [plasma] why not web portal mail?

Trevor Freeman <> Wed, 13 April 2011 17:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 83932E0892 for <>; Wed, 13 Apr 2011 10:59:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.598
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xKgiDby68Ss4 for <>; Wed, 13 Apr 2011 10:58:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2FF42E07DA for <>; Wed, 13 Apr 2011 10:58:58 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 13 Apr 2011 10:58:57 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 13 Apr 2011 10:58:57 -0700
Received: from ([fe80::7c94:4036:120:c95f]) by ([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: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_E545B914D50B2A4B994F198378B1525D339F03B7DFM1412exchange_"
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [plasma] why not web portal mail?
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

From: Phillip Hallam-Baker []
Sent: Tuesday, April 12, 2011 5:50 PM
To: Trevor Freeman
Cc: Leif Johansson;
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<> policy we might have an infinite series 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 expected 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<> policy or how it relates 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, even undecidable.
[TF] Agreed. The point of Plasma is that process is opaque to the client. All the client should get is a series of references from the server of polices 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 policy and those can be reduced to a small number of fixed 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 need to define obligations on policy binding for derivative 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 specification, 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 the 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 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 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 moved to all sorts of locations. If the policy changed then you cannot track down 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 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 email and 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 which is an incremental improvement on what we have today.

From: Phillip Hallam-Baker [<>]
Sent: Tuesday, April 12, 2011 12:31 PM
To: Trevor Freeman
Cc: Leif Johansson;<>

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 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 <<>> 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:<> [<>] On Behalf Of Leif Johansson
Sent: Tuesday, April 12, 2011 7:21 AM
Subject: Re: [plasma] why not web portal mail?
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
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla -

plasma mailing list<>
plasma mailing list<>