Subject: [plasma] FW: New Version Notification for draft-schaad-plasma-service-04.txt

From: "Jim Schaad" <[email-masked]>
Date: Fri, 11 Jan 2013 17:16:57 -0800

New draft has finally be posted.

Note - this draft has changed a great number of things, but has not yet addressed the options for policy questions..  I am still trying to get my mind around what needs to be done in all of the different locations and what it means for schema to try and get it all correct.  Sorry I haven't gotten that far.

I think that most of the issues people have raised other than that are included.  The examples at the end are generated from my current code base and I believe reflect both the schema and the text of the draft.  I have not however done a recent read through of all of the text to make sure that this is a correct statement.  The schema should be correct as I did use a schema verify tool and came up with only one schema violation in the examples.  That is the inclusion of an id attribute in the xacml:Request element.  This is not legal according to the xacml schema.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, January 11, 2013 5:13 PM
> To: [email-masked]
> Subject: New Version Notification for draft-schaad-plasma-service-04.txt
> 
> 
> A new version of I-D, draft-schaad-plasma-service-04.txt
> has been successfully submitted by Jim Schaad and posted to the IETF
> repository.
> 
> Filename:	 draft-schaad-plasma-service
> Revision:	 04
> Title:		 Plasma Service Trust Processing
> Creation date:	 2013-01-11
> WG ID:		 Individual Submission
> Number of pages: 68
> URL:             http://www.ietf.org/internet-drafts/draft-schaad-plasma-
> service-04.txt
> Status:          http://datatracker.ietf.org/doc/draft-schaad-plasma-service
> Htmlized:        http://tools.ietf.org/html/draft-schaad-plasma-service-04
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-schaad-plasma-service-04
> 
> Abstract:
>    RFC TBD describes a new model and set of requirements to implement a
>    labeling system on Cryptographic Message Syntax (CMS) objects where
>    the entity in charge of doing the label enforcement is under the
>    control of a central authority rather than the recipient of the
>    object.
> 
>    This document describes a protocol to be used by senders and
>    recipients of CMS objects to communicate with a centralized label
>    enforcement server.  The document outlines how a client will get the
>    set of labels or policies that it can use for sending messages,
>    composes a secure CMS object with a label on it and gets the
>    necessary keys to decrypt a CMS object from the server.  This
>    document is designed to be used with RFC TBD2 which describes the
>    extensions used in CMS objects to hold the label information.
> 
> 
> 
> 
> The IETF Secretariat