Re: [plasma] why not web portal mail?

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 <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
> 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/