Re: [plasma] Clarification of how client applications handle the LockBox in client in <plasma:GetCMSToken> elements

Trevor Freeman <trevorf@exchange.microsoft.com> Thu, 03 January 2013 19:14 UTC

Return-Path: <trevorf@exchange.microsoft.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 6751421F8CC8 for <plasma@ietfa.amsl.com>; Thu, 3 Jan 2013 11:14:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.51
X-Spam-Level:
X-Spam-Status: No, score=-100.51 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_65=0.6, USER_IN_WHITELIST=-100]
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 kttqCnkcXthL for <plasma@ietfa.amsl.com>; Thu, 3 Jan 2013 11:14:25 -0800 (PST)
Received: from NA01-SN2-obe.outbound.o365filtering.com (na01-sn2-obe.ptr.o365filtering.com [157.55.158.27]) by ietfa.amsl.com (Postfix) with ESMTP id C8FE621F8A67 for <plasma@ietf.org>; Thu, 3 Jan 2013 11:14:05 -0800 (PST)
Received: from BY2SR01CA102.namsdf01.sdf.exchangelabs.com (10.255.93.147) by BY2SR01MB608.namsdf01.sdf.exchangelabs.com (10.255.93.167) with Microsoft SMTP Server (TLS) id 15.0.601.0; Thu, 3 Jan 2013 19:13:52 +0000
Received: from SN2FFOFD004.ffo.gbl (157.55.158.24) by BY2SR01CA102.outlook.office365.com (10.255.93.147) with Microsoft SMTP Server (TLS) id 15.0.601.3 via Frontend Transport; Thu, 3 Jan 2013 19:13:52 +0000
Received: from hybrid.exchange.microsoft.com (131.107.1.17) by SN2FFOFD004.mail.o365filtering.com (10.111.201.41) with Microsoft SMTP Server (TLS) id 15.0.596.1 via Frontend Transport; Thu, 3 Jan 2013 19:13:51 +0000
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.3.118.0; Thu, 3 Jan 2013 11:12:27 -0800
Received: from PIO-MLT-06.exchange.corp.microsoft.com (157.54.94.24) by DF-H14-02.exchange.corp.microsoft.com (157.54.78.140) with Microsoft SMTP Server (TLS) id 14.3.118.0; Thu, 3 Jan 2013 11:12:27 -0800
Received: from DF-M14-10.exchange.corp.microsoft.com ([fe80::b076:a99f:3049:4c76]) by PIO-MLT-06.exchange.corp.microsoft.com ([fe80::d57f:521a:3ae6:c130%10]) with mapi id 14.03.0118.000; Thu, 3 Jan 2013 11:12:27 -0800
From: Trevor Freeman <trevorf@exchange.microsoft.com>
To: Ed Simon <Ed.Simon@titus.com>, Jim Schaad <ietf@augustcellars.com>, "plasma@ietf.org" <plasma@ietf.org>
Thread-Topic: [plasma] Clarification of how client applications handle the LockBox in client in <plasma:GetCMSToken> elements
Thread-Index: AQHNyFx6QAEfHVE3SUizATOKHQdq7Jf7HC6sgAD9dYCAAs3ZgIA4UiaAgAApIICAAA2ogIAAwKfw
Date: Thu, 3 Jan 2013 19:12:26 +0000
Message-ID: <3020AC5E95452D43B5D8D0FB02F881D3162B90@DF-M14-10.exchange.corp.microsoft.com>
References: <DCD8C7A5A8B3E844AA2E2CBE327CDC92013DA1E7@E10MB3.tituscorp.local> <DCD8C7A5A8B3E844AA2E2CBE327CDC92013DB34F@E10MB3.tituscorp.local>, <014401cdcb92$21497b60$63dc7220$@augustcellars.com>, <DCD8C7A5A8B3E844AA2E2CBE327CDC92013DBE78@E10MB3.tituscorp.local> <DCD8C7A5A8B3E844AA2E2CBE327CDC92013E5BD9@E10MB3.tituscorp.local>, <004901cde936$b054ddb0$10fe9910$@augustcellars.com> <DCD8C7A5A8B3E844AA2E2CBE327CDC92013E5C75@E10MB3.tituscorp.local>
In-Reply-To: <DCD8C7A5A8B3E844AA2E2CBE327CDC92013E5C75@E10MB3.tituscorp.local>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.94.18]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.1.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464002)(377454001)(51704002)(4396001)(876001)(46102001)(33656001)(74662001)(44976002)(47446002)(51856001)(23726001)(15202345002)(74502001)(59766001)(47736001)(49866001)(76482001)(47976001)(56816002)(54316002)(55846006)(56776001)(5343635001)(5343655001)(16406001)(77982001)(50986001)(50466001)(54356001)(47776002)(53806001)(46406002)(31966008)(44824002); DIR:OUT; SFP:; SCL:1; SRVR:BY2SR01MB608; H:hybrid.exchange.microsoft.com; LANG:en;
X-Forefront-PRVS: 071518EF63
X-OriginatorOrg: DuplicateDomain-6c178e33-aecb-4786-8220-9afceeddbaf3.exchange.microsoft.com
Subject: Re: [plasma] Clarification of how client applications handle the LockBox in client in <plasma:GetCMSToken> elements
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, 03 Jan 2013 19:14:45 -0000

Plasma is policy expression neutral. It is a mechanism to control access to data.  The policy which controls the access which was defined by the sender may require a list of recipients for the data in questions. I don't see how a PIP would know who the recipients are for a message. 

The sender calling GetCMSKey would know if the set of recipients is required from the role token and can specify the list of 822 recipients to the Plasma server in the request. However a recipient calling GetMessageKey can only pass in attributes as SAML attributes. A Plasma server may use BAE to establish the email address of the requestor e.g. the request contains a DN and the plasma server used the DN to look up the email attribute from a PIP. Alternatively the Plasma server can reply with an indeterminate response requesting the email attribute in which case the client needs to get a SAML token with the requested attribute from its PIP. 

The defining distinction is that the list of recipients by the sender is self-asserted whereas the email address of the recipient is not. 

>From a server perspective it is simpler if all the attributes in a request is a single place. A server is going to search the supplied attributes for the data it needs. It will not care if there is more there than it needs. You don't need to tie the attributes to a specific policy. 

PLASMA does not, by design, require that the authenticating party be implicitly considered also as a recipient. The authenticating party may be an agent acting on behalf of the recipient - in which case there is minimal value in their authentication. 

Trevor

-----Original Message-----
From: Ed Simon [mailto:Ed.Simon@titus.com] 
Sent: Wednesday, January 2, 2013 3:04 PM
To: Jim Schaad; Trevor Freeman; plasma@ietf.org
Subject: RE: [plasma] Clarification of how client applications handle the LockBox in client in <plasma:GetCMSToken> elements

If a XACML policy includes, inter alia, a rule that requiring a that only recipients may read an email, then the XACML will require either that the access subject be specified in the XACML request (as I have said below) or that the identity of the access subject be accessible through a PIP; XACML, to my recollection, makes no automatic assumption that the authenticating party is the access subject party. If PLASMA is to require that the authenticating party be implicitly considered also as a XACML access subject, then PLASMA needs to be explicit about that and perhaps describe the means through which that is to be accomplished wrt XACML -- would it not?

I do not see why it would be difficult for client apps to specify who the access-requesting email recipient is through XACML attributes in the GetCMSKey PLASMA request. That seems to me the easiest, most robust approach for both clients apps and policy servers.

My preference is for PLASMA to say that email recipients are to be specified as XACML access subjects in the XACML request part (as is the normal case with XACML). If it is also deemed necessary to support the XACML PIP approach, we can do that too. 

Ed

________________________________________
From: Jim Schaad [ietf@augustcellars.com]
Sent: Wednesday, January 02, 2013 17:15
To: Ed Simon; 'Trevor Freeman'; plasma@ietf.org
Subject: RE: [plasma] Clarification of how client applications handle the LockBox in client in <plasma:GetCMSToken> elements

It would appear to me that not allowing for the identities asserted during the process of doing the authentication not being a default set of access subject attributes would be incorrect and would make life much harder.

For a simple policy one would still need to have a check that the access subject attribute asserted by the client is allowed for the set of known identities for the subject.  While this makes sense if the policy is going to explicitly allow for impersonation, I think it is an unneeded burden on policy writers for the simplest of policies.

Why would disagree with assuming that the party named is the same as the access subject unless a different access subject is explicitly stated by the client?

Jim


> -----Original Message-----
> From: Ed Simon [mailto:Ed.Simon@titus.com]
> Sent: Wednesday, January 02, 2013 11:48 AM
> To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> Subject: RE: [plasma] Clarification of how client applications handle 
> the LockBox in client in <plasma:GetCMSToken> elements
>
> Following my prior email (see below), on the GetCMSKey side, any user- 
> specified policy options (such as the list of recipients), which were
captured
> in the LockBox during the GetCMSToken call, would be evaluated against 
> the XACML attributes specified in the GetCMSKey request. For example, 
> a specific recipient would be specified through a XACML access subject 
> (or perhaps XACML recipient subject) attribute. (Note that I would 
> disagree
with
> assuming the party named, if any, in the authentication token is
necessarily
> an access subject or recipient subject).
>
> Thoughts?
>
> Ed
> ________________________________________
> From: Ed Simon
> Sent: Tuesday, November 27, 2012 18:43
> To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> Subject: RE: [plasma] Clarification of how client applications handle 
> the LockBox in client in <plasma:GetCMSToken> elements
>
> Reworking the example, I've replaced <Leaf> with 
> <Policy>/<PolicyOptions> (re-using the PolicyType structure defined 
> for the GetRolesToken; but
using
> the PolicyID attribute and replacing the PolicyType <Name> element 
> with <FriendlyName> (as per SAML)). It seems to me we the 
> specification's text may not be quite clear on the distinction between 
> the use of Policy(s) and Label/Leaf; it seems to me that Label/Leaf in 
> GetCMSToken could be
logically
> replaced with the GetRolesToken PolicyType structure, though in a 
> GetCMSToken request, the policy options would be specified by the 
> sender (whereas in GetRolesToken, the <PolicyOptions> specifies what 
> the sender needs to specify).
>
> For composite policies, I would rename the GetCMSToken <Label> 
> structure with <PolicyCombiner AlgorithmId="...">, thus completing the 
> policy- oriented semantics and naming style.
>
> The above paragraphs may answer Jim's first question.
>
> The answer to the second question is that if the sender is specifying
policy
> options, which will later need to be used, on a GetCMSKey request from 
> a recipient, then because the PLASMA server is stateless wrt specific 
> messages, those options will need to be carried in the LockBox payload 
> of the message. I suggest, and I think Jim was hinting he was 
> considering
this a
> few weeks ago, that the content of the LockBox (labels/policies, 
> namedRecipients, defaultRecipients, CEK, ...) be specified in terms of 
> XML rather than ASN.1 and the ASN.1 LockBox be declared as UTF8String 
> so it
can
> hold the XML contents (ASN.1 structures such a ASN.1 RecipientInfo(s)
could
> be stored as base64-encoded within the XML).
>
> Here's the latest rework of the example...
>
> >>>
>   <Request xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
> CombinedDecision="false" ReturnPolicyIdList="false">
>
>     <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-
> category:action">
>       <Attribute AttributeId="urn:plasma:action-id"
IncludeInResult="false">
>         <AttributeValue
> DataType="http://www.w3.org/2001/XMLSchema#string">GetCMSToken</
> AttributeValue>
>       </Attribute>
>     </Attributes>
>     <Attributes Category="urn:ietf:plasma:data">
>       <Attribute AttributeId="urn:plasma:data-id" IncludeInResult="false">
>         <AttributeValue
> DataType="http://www.w3.org/2001/XMLSchema#string">
>           <GetCMSToken xmlns="urn:ietf:schema:plasma:1.0">
>             <Policy
PolicyId="urn:example:policies:only-allow-these-recipients-to-
> decrypt-this-email">
>               <FriendlyName>Only Allow These Recipients To Decrypt 
> this Email</FriendlyName>
>               <PolicyOptions>
>
>               <!-- Specify parameters to the protection policy that 
> the
user has
> specified here (note switch back to XACML namespace in this example, 
> but contents of <PolicyParameters> could by in any namespace) -->
>
>     <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-
> category:access-subject"
> xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
>       <Attribute
AttributeId=""urn:oasis:names:tc:xacml:1.0:subject:subject-
> id"" IncludeInResult="false">
>         <AttributeValue DataType="urn:oasis:names:tc:xacml:1.0:data-
> type:rfc822Name">Alice@example.org</AttributeValue>
>       </Attribute>
>       <Attribute
AttributeId=""urn:oasis:names:tc:xacml:1.0:subject:subject-
> id"" IncludeInResult="false">
>         <AttributeValue DataType="urn:oasis:names:tc:xacml:1.0:data-
> type:rfc822Name">Bob@example.org</AttributeValue>
>       </Attribute>
>       <Attribute
AttributeId=""urn:oasis:names:tc:xacml:1.0:subject:subject-
> id"" IncludeInResult="false">
>         <AttributeValue DataType="urn:oasis:names:tc:xacml:1.0:data-
> type:rfc822Name">Carl@example.org</AttributeValue>
>       </Attribute>
>     </Attributes>
>
>               </PolicyOptions>
>             </Policy>
>             <Hash>
>               <DigestMethod xmlns="http://www.w3.org/2000/09/xmldsig#"
> Algorithm ="http://www.w3.org/2001/04/xmlenc#sha256"/>
>               <DigestValue
> xmlns="http://www.w3.org/2000/09/xmldsig#">hrQkL07h1qZhPhgLXKlL0dV
> eFLAbUVy0no05EGDzK2Q=</DigestValue>
>             </Hash>
>             <CEK>1BF2BEB249EE8EF2CB373E9800AC6F01</CEK>
>           </GetCMSToken>
>         </AttributeValue>
>       </Attribute>
>     </Attributes>
>
>     <!-- Specify XACML attributes that may be used to determine 
> whether
the
> user can execute the GetCMSToken request as regular XACML attributes 
> (example below) -->
>
>     <Attributes 
> Category="urn:example:attributes-for-determining-whether-
> this-XACML-request-will-be-permitted">
>       <Attribute AttributeId="urn:example:something-1"
> IncludeInResult="false">
>         <AttributeValue DataType="urn:example:something-1-
> format">SomethingSomethingSomethingSomething</AttributeValue>
>       </Attribute>
>       <Attribute AttributeId="urn:example:something-2"
> IncludeInResult="false">
>         <AttributeValue DataType="urn:example:something-2-
>
format">asldkjfalskdjf32434534543dfjalkscxvkljzv2309080kjlkjlkj</AttributeV
> alue>
>       </Attribute>
>     </Attributes>
>
>   </Request>
> <<<
>
> Ed
> ________________________________________
> From: Jim Schaad [ietf@augustcellars.com]
> Sent: Sunday, November 25, 2012 23:54
> To: Ed Simon; 'Trevor Freeman'; plasma@ietf.org
> Subject: RE: [plasma] Clarification of how client applications handle 
> the LockBox in client in <plasma:GetCMSToken> elements
>
> Ed,
>
> I agree with most of this, however there are two things
>
> 1.  Currently one can place an arbitrary structure inside of the Leaf
element.
> Do you believe that is insufficient or do we really need to have the 
> extra layer of the <PolicyParameters> element added?
>
> 2.  At the end you say that there is a needed change to the LockBox
element.
> I am not clear what this change would be.  Is it the 
> <PolicyParameters> element above or something else?
>
> Jim
>
>
> > -----Original Message-----
> > From: Ed Simon [mailto:Ed.Simon@titus.com]
> > Sent: Sunday, November 25, 2012 2:15 PM
> > To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> > Subject: RE: [plasma] Clarification of how client applications 
> > handle the LockBox in client in <plasma:GetCMSToken> elements
> >
> > Upon pondering this further, I think it is important to distinguish
> between
> > attributes that act as parameters to the policy the user wishes to 
> > enforce
> for
> > the message/document and those attributes used by the PLASMA server
> to
> > permit/deny the GetCMSToken request.
> >
> > For attributes that are policy parameters, these should be specified 
> > as
> part of
> > the PLASMA <GetCMSToken> element inside the <Leaf> child element 
> > (which identifies the policy the user selects to govern the 
> > message/document (should <Leaf> be renamed to <Policy> perhaps?)).
> >
> > For attributes that are used to determine whether the user can 
> > perform a GetCMSToken request, these should be specified outside the 
> > PLASMA <GetCMSToken> element.
> >
> > Reworking my prior example to reflect this design...
> >
> > >>>
> >   <Request xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
> > CombinedDecision="false" ReturnPolicyIdList="false">
> >
> >     <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-
> > category:action">
> >       <Attribute AttributeId="urn:plasma:action-id"
> IncludeInResult="false">
> >         <AttributeValue
> >
> DataType="http://www.w3.org/2001/XMLSchema#string">GetCMSToken</
> > AttributeValue>
> >       </Attribute>
> >     </Attributes>
> >     <Attributes Category="urn:ietf:plasma:data">
> >       <Attribute AttributeId="urn:plasma:data-id"
IncludeInResult="false">
> >         <AttributeValue
> > DataType="http://www.w3.org/2001/XMLSchema#string">
> >           <GetCMSToken xmlns="urn:ietf:schema:plasma:1.0">
> >             <Leaf
> PolicyId="urn:example:policies:only-allow-these-recipients-to-
> > decrypt-this-email">
> >               <PolicyParameters>
> >
> >               <!-- Specify parameters to the protection policy that 
> > the
> user has
> > specified here (note switch back to XACML namespace in this example, 
> > but contents of <PolicyParameters> could by in any namespace) -->
> >
> >     <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-
> > category:access-subject"
> > xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
> >       <Attribute
> AttributeId=""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > id"" IncludeInResult="false">
> >         <AttributeValue DataType="urn:oasis:names:tc:xacml:1.0:data-
> > type:rfc822Name">Alice@example.org</AttributeValue>
> >       </Attribute>
> >       <Attribute
> AttributeId=""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > id"" IncludeInResult="false">
> >         <AttributeValue DataType="urn:oasis:names:tc:xacml:1.0:data-
> > type:rfc822Name">Bob@example.org</AttributeValue>
> >       </Attribute>
> >       <Attribute
> AttributeId=""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > id"" IncludeInResult="false">
> >         <AttributeValue DataType="urn:oasis:names:tc:xacml:1.0:data-
> > type:rfc822Name">Carl@example.org</AttributeValue>
> >       </Attribute>
> >     </Attributes>
> >
> >               </PolicyParameters>
> >             </Leaf>
> >             <Hash>
> >               <DigestMethod xmlns="http://www.w3.org/2000/09/xmldsig#"
> > Algorithm ="http://www.w3.org/2001/04/xmlenc#sha256"/>
> >               <DigestValue
> >
> xmlns="http://www.w3.org/2000/09/xmldsig#">hrQkL07h1qZhPhgLXKlL0dV
> > eFLAbUVy0no05EGDzK2Q=</DigestValue>
> >             </Hash>
> >             <CEK>1BF2BEB249EE8EF2CB373E9800AC6F01</CEK>
> >           </GetCMSToken>
> >         </AttributeValue>
> >       </Attribute>
> >     </Attributes>
> >
> >     <!-- Specify XACML attributes that may be used to determine 
> > whether
> the
> > user can execute the GetCMSToken request as regular XACML attributes 
> > (example below) -->
> >
> >     <Attributes
> > Category="urn:example:attributes-for-determining-whether-
> > this-XACML-request-will-be-permitted">
> >       <Attribute AttributeId="urn:example:something-1"
> > IncludeInResult="false">
> >         <AttributeValue DataType="urn:example:something-1-
> > format">SomethingSomethingSomethingSomething</AttributeValue>
> >       </Attribute>
> >       <Attribute AttributeId="urn:example:something-2"
> > IncludeInResult="false">
> >         <AttributeValue DataType="urn:example:something-2-
> >
>
format">asldkjfalskdjf32434534543dfjalkscxvkljzv2309080kjlkjlkj</AttributeV
> > alue>
> >       </Attribute>
> >     </Attributes>
> >
> >   </Request>
> > <<<
> >
> > Because of the stateless nature of PLASMA, there would also need to 
> > be a corresponding change to PLASMA-defined LockBox structure for 
> > the label/policy in order to store the policy parameter information.
> >
> > Ed
> > ________________________________________
> > From: plasma-bounces@ietf.org [plasma-bounces@ietf.org] on behalf of 
> > Ed Simon [Ed.Simon@titus.com]
> > Sent: Wednesday, November 21, 2012 21:52
> > To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> > Subject: Re: [plasma] Clarification of how client applications 
> > handle the LockBox in client in <plasma:GetCMSToken> elements
> >
> > I propose, as a strawman proposal, that when policies require the 
> > sender's recipient list, they should be specified through XACML 
> > access-subject attributes, NOT PLASMA-specific attributes (e.g. 
> > within <plasma:GetCMSToken>). My position would be that PLASMA 
> > should only supplement XACML's pre-defined attributes where 
> > necessary, not create PLASMA-specified attributes where existing 
> > XACML-specified attributes are already defined and are sufficient. 
> > Hence my position at the moment is I would NOT change the current 
> > PLASMA semantics of <plasma:Recipient> which is specifically for 
> > specifying a lockbox for a recipient (though I
> agree
> > with Jim that the name of the element should be changed to 
> > <LockBoxes> to avoid confusion) and, instead indicate in the 
> > specification, that when a
> policy
> > processing depends on knowing the list of recipients, that those
> recipients
> > be specified through a XACML <Attributes> category for subjects 
> > which specifies the recipients through XACML access-subject att  ributes.
> >
> > Besides a list of recipients, I can imagine other policy-specific
> information that
> > could be used in a GetCMSToken request. Like the list of recipients, 
> > such policy-specific information would also be included through
> > non-PLASMA- specific, XACML attributes.
> >
> > For example, a XACML request for GetCMSToken which needs to specify 
> > the list of recipients and other info could look like this...
> >
> >   <Request xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
> > CombinedDecision="false" ReturnPolicyIdList="false">
> >     <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-
> > category:action">
> >       <Attribute AttributeId="urn:plasma:action-id"
> IncludeInResult="false">
> >         <AttributeValue
> >
> DataType="http://www.w3.org/2001/XMLSchema#string">GetCMSToken</
> > AttributeValue>
> >       </Attribute>
> >     </Attributes>
> >     <Attributes Category="urn:ietf:plasma:data">
> >       <Attribute AttributeId="urn:plasma:data-id"
IncludeInResult="false">
> >         <AttributeValue
> > DataType="http://www.w3.org/2001/XMLSchema#string">
> >           <GetCMSToken xmlns="urn:ietf:schema:plasma:1.0">
> >             <Leaf
> PolicyId="urn:example:policies:only-allow-recipients-to-decrypt-
> > this-email"/>
> >             <Hash>
> >               <DigestMethod xmlns="http://www.w3.org/2000/09/xmldsig#"
> > Algorithm ="http://www.w3.org/2001/04/xmlenc#sha256"/>
> >               <DigestValue
> >
> xmlns="http://www.w3.org/2000/09/xmldsig#">hrQkL07h1qZhPhgLXKlL0dV
> > eFLAbUVy0no05EGDzK2Q=</DigestValue>
> >             </Hash>
> >             <CEK>1BF2BEB249EE8EF2CB373E9800AC6F01</CEK>
> >           </GetCMSToken>
> >         </AttributeValue>
> >       </Attribute>
> >     </Attributes>
> >
> > <!-- Ed's NEW STUFF BEGINS HERE! -->
> >
> >     <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-
> > category:access-subject">
> >       <Attribute
> AttributeId=""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > id"" IncludeInResult="false">
> >         <AttributeValue DataType="urn:oasis:names:tc:xacml:1.0:data-
> > type:rfc822Name">Alice@example.org</AttributeValue>
> >       </Attribute>
> >       <Attribute
> AttributeId=""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > id"" IncludeInResult="false">
> >         <AttributeValue DataType="urn:oasis:names:tc:xacml:1.0:data-
> > type:rfc822Name">Bob@example.org</AttributeValue>
> >       </Attribute>
> >       <Attribute
> AttributeId=""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > id"" IncludeInResult="false">
> >         <AttributeValue DataType="urn:oasis:names:tc:xacml:1.0:data-
> > type:rfc822Name">Carl@example.org</AttributeValue>
> >       </Attribute>
> >     </Attributes>
> >
> >     <Attributes
> > Category="urn:example:some-other-attributes-related-to-
> > processing-this-policy">
> >       <Attribute AttributeId="urn:example:something-1"
> > IncludeInResult="false">
> >         <AttributeValue DataType="urn:example:something-1-
> > format">SomethingSomethingSomethingSomething</AttributeValue>
> >       </Attribute>
> >       <Attribute AttributeId="urn:example:something-2"
> > IncludeInResult="false">
> >         <AttributeValue DataType="urn:example:something-2-
> >
>
format">asldkjfalskdjf32434534543dfjalkscxvkljzv2309080kjlkjlkj</AttributeV
> > alue>
> >       </Attribute>
> >     </Attributes>
> >
> >   </Request>
> >
> >
> > Ed
> > ________________________________________
> > From: Jim Schaad [ietf@augustcellars.com]
> > Sent: Wednesday, November 21, 2012 01:39
> > To: 'Trevor Freeman'; Ed Simon; plasma@ietf.org
> > Subject: RE: [plasma] Clarification of how client applications 
> > handle the LockBox in client in <plasma:GetCMSToken> elements
> >
> > What does it mean to have a recipient list if you are not looking at
> Email?
> >
> > If one has a recipient list, and that recipient list is updated 
> > during
> processing
> > (for example mail list expansion) does that change the original 
> > policy set
> by
> > the sender?
> >
> > I should have called the structure <LockBoxes> rather than 
> > <Recipients> to prevent the confusion.  However, I can see that this 
> > could be an input
> that is
> > of interest to the policy.  However doing so means that we have to 
> > figure
> out
> > what it means in a number of different cases that I am currently not 
> > ready
> to
> > think about
> >
> > Jim
> >
> >
> > > -----Original Message-----
> > > From: Trevor Freeman [mailto:trevorf@exchange.microsoft.com]
> > > Sent: Tuesday, November 20, 2012 2:46 PM
> > > To: Jim Schaad; 'Ed Simon'; plasma@ietf.org
> > > Subject: RE: [plasma] Clarification of how client applications 
> > > handle the LockBox in client in <plasma:GetCMSToken> elements
> > >
> > > Hi Jim,
> > >
> > > The list of recipients for a message is a single list per message.
> > > There
> > are no
> > > policy dependent recipient lists.  The need for the list is policy
> > dependent but
> > > One or more policies may want that data as input to the policy. It 
> > > seems pointless duplication to include the list of recipients as 
> > > part of the
> > policy as
> > > you have to repeat the same data to each policy.
> > >
> > > We have a per-message recipient list structure defined. If the 
> > > lock box element is optional, we can use the same structure for 
> > > both #1 and
> > > #2
> > below
> > > i.e. if I just want a recipient list with no lock boxes or if I 
> > > want a
> > recipient list
> > > with lock boxes.
> > >
> > > Trevor
> > >
> > >
> > > -----Original Message-----
> > > From: Jim Schaad [mailto:ietf@augustcellars.com]
> > > Sent: Monday, November 19, 2012 8:11 PM
> > > To: Trevor Freeman; 'Ed Simon'; plasma@ietf.org
> > > Subject: RE: [plasma] Clarification of how client applications 
> > > handle the LockBox in client in <plasma:GetCMSToken> elements
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Trevor Freeman [mailto:trevorf@exchange.microsoft.com]
> > > > Sent: Monday, November 19, 2012 2:18 PM
> > > > To: Jim Schaad; 'Ed Simon'; plasma@ietf.org
> > > > Subject: RE: [plasma] Clarification of how client applications 
> > > > handle the LockBox in client in <plasma:GetCMSToken> elements
> > > >
> > > > Hi Jim,
> > > >
> > > > Let me restate things to see if I understood you correctly.
> > > >
> > > > The list of recipient is one per message not one per policy. 
> > > > While one or
> > > more
> > > > policies may require the list be supplied; only one list would 
> > > > be included
> > > in
> > > > the GetCMSToken request via the recipient structure.
> > > >
> > > > < Recipient>
> > > > <Subject>lisa@simpsons.com</Subject>;
> > > > </Recipient>
> > > > < Recipient>
> > > > <Subject>bart@simpsons.com</Subject>;
> > > > </Recipient>
> > >
> > > No that is not correct.
> > >
> > > There are three distinct ways that a list of recipients may be 
> > > supplied to
> > the
> > > system.  These each have different outcomes.
> > >
> > > 1.  A recipient may be supplied with a lock box created by the sender.
> > This
> > > supports a mode where the Plasma server does not know the CEK.   This
> is
> > > done through the <Recipient/> element.  (As you did below here)
> > >
> > > 2.  A recipient list may be supplied as part of a policy.   This
allows
> > for
> > > a policy to have a set of names to evaluate as part of the policy.
> > > This
> > will
> > > (normally) be combined with giving a CEK to the server and 
> > > allowing it to determine who gets the CEK back.
> > >
> > > 3.  A recipient lists specific to email may be provided as part of 
> > > the
> > input data.
> > > This behavior (perhaps not currently in the document) is provided 
> > > for the purpose of doing pre-authorization of gateways and is 
> > > specific to
> email.
> > >
> > >
> > > Currently the above is better expressed as
> > >
> > > Policy=basic Policy
> > > BasicPolicy Recipient List is "lisa@simpsons.com bart@simpsons.com";
> > >
> > > Jim
> > >
> > > >
> > > > Policies may also require that lock boxes be generated for 
> > > > receipts rather than supply the CEK to the Plasma server. In 
> > > > that instance, the list of
> > > receipts
> > > > together with the associated lock box would be included in the 
> > > > GetCMSToken request.
> > > >
> > > > < Recipient>
> > > > <Subject>lisa@simpsons.com</Subject>;
> > > > <LockBox>123456789</LockBox>
> > > > </Recipient>
> > > > < Recipient>
> > > > <Subject>bart@simpsons.com</Subject>;
> > > > <LockBox>abcdef</LockBox>
> > > > </Recipient>
> > > >
> > > > Trevor
> > > >
> > > > -----Original Message-----
> > > > From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] 
> > > > On Behalf Of Jim Schaad
> > > > Sent: Monday, November 19, 2012 1:58 PM
> > > > To: 'Ed Simon'; plasma@ietf.org
> > > > Subject: Re: [plasma] Clarification of how client applications 
> > > > handle the LockBox in client in <plasma:GetCMSToken> elements
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] 
> > > > > On Behalf Of Ed Simon
> > > > > Sent: Saturday, November 17, 2012 1:07 PM
> > > > > To: plasma@ietf.org
> > > > > Subject: Re: [plasma] Clarification of how client applications 
> > > > > handle the LockBox in client in <plasma:GetCMSToken> elements
> > > > >
> > > > > Based on discussions with others on this mailing list, and
> > > > >
> > > > > http://www.ietf.org/mail-
> archive/web/plasma/current/msg00118.htm
> > > > > l
> > > > >
> > > > > ...I have drawn up the following three scenarios regarding the
> > > > construction of
> > > > > the <GetCMSToken> element sent to the PLASMA Server by the
> > Sending
> > > > > Agent, and the construction of the LockBox by the PLASMA Server.
> > > > >
> > > > > Does what I've described in these scenarios, particularly 
> > > > > Scenario B in
> > > > which
> > > > > the Sending Agent leaves it to the PLASMA Server to construct 
> > > > > a LockBox
> > > > for
> > > > > a named recipient, sound reasonable? Scenario B follows from 
> > > > > the
> text
> > > > >    "Additionally the Plasma server could return the standard
> > > > >    recipient info structures to be added to the message for
> recipients
> > > > >    if it can pre-authorize them to have access the message and 
> > > > > knows
> > the
> > > > >    appropriate keying material."
> > > > > in the PLASMA Service CMS Processing v2 document.
> > > >
> > > > This text is intended to deal with the case of creating 
> > > > lockboxes for
> > > entities
> > > > such as virus checking gateways in a mail system.  The lockboxes 
> > > > that are being returned with here are placed parallel to the 
> > > > Plasma Lockbox in the CMS Enveloped data object and are not 
> > > > embedded into the lockbox created by the Plasma server.
> > > >
> > > > >
> > > > > Here are the scenarios:
> > > > >
> > > > > Scenario A: The Sending Agent does NOT share the CEK with the 
> > > > > PLASMA server and specifies a limited set of recipients who 
> > > > > can decrypt the
> > > > message
> > > > > (for example, due to section 7.2.2 of PLASMA Service Trust 
> > > > > processing
> > > v3).
> > > > >
> > > > > Sending Agent: In the <GetCMSToken> element of the PLASMA
> > Request,
> > > > the
> > > > > sender will construct a <Recipient> list specifying, for each
> > > > recipient, both
> > > > > the <Subject> element (to identify the recipient), and the 
> > > > > <LockBox> element to contain the encrypted CEK for that 
> > > > > recipient (encrypted so only that recipient can decrypt it).
> > > > > There will be no <CEK>
> > element.
> > > > >
> > > > > PLASMA Server: Will construct an ASN.1 PLASMA LockBox (as 
> > > > > described in PLASMA Service CMS Processing v2). The LockBox 
> > > > > constructed by the PLASMA Server will comprise, in the 
> > > > > namedRecipients, the LockBox-es provided by the Sending Agent.
> > > > > There will be no defaultRecipients
> > > > structure.
> > > > > Note that in this scenario, the PLASMA Server will not be 
> > > > > able, barring
> > > > further
> > > > > communication with the Sending Agent, be able to supplement 
> > > > > the list of recipients.
> > > >
> > > > This looks correct
> > > >
> > > > >
> > > > > Scenario B: The sender shares the CEK with the PLASMA server 
> > > > > and specifies a limited set of recipients who can decrypt the 
> > > > > message (for example,
> > > > again,
> > > > > due to section 7.2.2 of PLASMA Trust processing). For each 
> > > > > recipient specified, there may or may not be a LockBox 
> > > > > specified by the Sending Agent.
> > > > >
> > > > > Sending Agent: In the <GetCMSToken> element of the PLASMA
> > Request,
> > > > the
> > > > > sender will construct a <Recipient> list specifying, for each
> > > > recipient, both
> > > > > the <Subject> element (to identify the recipient), and, 
> > > > > optionally, the <LockBox> element to contain the encrypted CEK 
> > > > > for that recipient (encrypted so only that recipient can 
> > > > > decrypt
it).
> > > > > The Sending Agent will
> > > > also
> > > > > construct a <CEK> element to contain the CEK.
> > > > >
> > > > > PLASMA Server: Where a LockBox for a recipient was specified 
> > > > > by the Sending Agent, it will be treated as in Scenario A; 
> > > > > otherwise, the PLASMA Server will create a LockBox for that 
> > > > > recipient to populate the namedRecipients structure. It will 
> > > > > also create a defaultRecipients
> > > > structure
> > > > > using the CEK provided by the Sending Agent. Note that in this 
> > > > > scenario,
> > > > the
> > > > > PLASMA Server will be able to, independently of the Sending 
> > > > > Agent, be able to supplement the list of recipients.
> > > > >
> > > > > Note that for Scenario B, the schema definition for the 
> > > > > <LockBox> element will need to have the attribute minOccurs=0.
> > > >
> > > > This is not currently an envisioned scenario in terms of the 
> > > > Plasma server creating the lock boxes at send time.  Currently 
> > > > if there is a list of
> > > recipients
> > > > that the sender does not create lockboxes for, it is envisioned 
> > > > that this
> > > would
> > > > be handled as part of the policy set on the message.  The Plasma 
> > > > server would then deal with potentially creating a lock box (as 
> > > > oppose to
> > > returning a
> > > > bare key) when the recipient tries to get the key from the server.
> > > >
> > > > >
> > > > > Scenario C: The Sending Agent shares the CEK with the PLASMA 
> > > > > server and does NOT specify any recipients.
> > > > >
> > > > > Sending Agent: The Sending Agent will also construct a <CEK> 
> > > > > element to contain the CEK; no <Recipient> element will be
created.
> > > > >
> > > > > PLASMA Server: The PLASMA Server will also create a 
> > > > > defaultRecipients structure using the CEK provided by the 
> > > > > Sending Agent; it may or may not create a namedRecipients 
> > > > > structure (populated independently of the Sending Agent). As 
> > > > > in Scenario B, the PLASMA Server will be able to, 
> > > > > independently of the Sending Agent, be able to supplement the list of recipients.
> > > >
> > > > This is what I would expect to see.
> > > >
> > > > Jim
> > > >
> > > > >
> > > > > _______________________________________________
> > > > > 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
> >
> >
> > _______________________________________________
> > plasma mailing list
> > plasma@ietf.org
> > https://www.ietf.org/mailman/listinfo/plasma