[plasma] Plasma Document Updates

"Jim Schaad" <jimsch@augustcellars.com> Thu, 06 December 2012 20:53 UTC

Return-Path: <jimsch@augustcellars.com>
X-Original-To: plasma@ietfa.amsl.com
Delivered-To: plasma@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403CD21F8925 for <plasma@ietfa.amsl.com>; Thu, 6 Dec 2012 12:53:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mu28eiAKe6oQ for <plasma@ietfa.amsl.com>; Thu, 6 Dec 2012 12:53:14 -0800 (PST)
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 9154021F88CD for <plasma@ietf.org>; Thu, 6 Dec 2012 12:53:14 -0800 (PST)
Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id DD8A038F0B for <plasma@ietf.org>; Thu, 6 Dec 2012 12:53:13 -0800 (PST)
From: Jim Schaad <jimsch@augustcellars.com>
To: plasma@ietf.org
Date: Thu, 06 Dec 2012 12:53:03 -0800
Message-ID: <014001cdd3f3$af7c3940$0e74abc0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac3TfgPXLLtPG003SzOgdHO5bPZNBQ==
Content-Language: en-us
Subject: [plasma] Plasma Document Updates
X-BeenThere: plasma@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." <plasma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/plasma>, <mailto:plasma-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/plasma>
List-Post: <mailto:plasma@ietf.org>
List-Help: <mailto:plasma-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/plasma>, <mailto:plasma-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Dec 2012 20:53:15 -0000

I am currently in the middle of doing a large revision of the two documents
that I am the primary author on.  In the process of doing this update, I
have a few issues that I would like people to comment on.


1.   I am considering changing the element "WS-Token" in
"AuthenticationType".  Since the only place where this is currently being
used is for dealing with role tokens, I believe it would be useful to change
the name of the element to "RoleToken" as this would make it clearer what
goes here. 

2.  In the CMS document I have change the label from being an ASN.1 encoded
string to being the XML encoded string.  However, I am wondering if we
should make this an OCTET STRING which holds the XML encoded string so that
we can allow for compression to occur as an optional method of encoding it.
Does anyone see any problems with this?

 I have been thinking about the suggested on renaming from Ed and looking at
XAML.  I have decided to use Policy and PolicySet as the replacements for
Label/Leaf in this update.  However there are still some things that I have
not really made any conclusions for.

3.  Should we switch from using a simple string, or augment the simple
string, by allowing the XACML PolicyCombiningAlgId URIs this means that
"urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:deny-overrides" and
"and" are the same thing.  There is no equivalent to "except", but it is
also possible this one is a figment of my imagination and there is no real
need for it.   One can do this in XACML by combining default-permit and
default-deny policies but I don't know if it is needed in real life or not.
The benefit of allowing the additional URIs is that there are a set of
policy combining algorithms already defined by XACML that should correspond
to things that are real and it makes it easier to augment the set of
combining strings.  The downside is that URIs are longer than the set of
short strings - does anyone have opinions on this?  The other downside of
using URIs is that the server may need to give the list of supported
combining algorithms to the client or we need to have an error for saying
that a combining algorithm is not supported.

4.  I am still working my way through the ways of specifying policy options
and have not made any decisions for myself let along ones that I would be
willing to impose on the document.  Any other options and opinions that
anyone wants to put in as input, I would be more than willing to get that
input at this time.


Jim