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

"Jim Schaad" <ietf@augustcellars.com> Thu, 03 January 2013 19:35 UTC

Return-Path: <ietf@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 D925921F8CFF for <plasma@ietfa.amsl.com>; Thu, 3 Jan 2013 11:35:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level:
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_65=0.6, 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 0tHi6Z0CmT0A for <plasma@ietfa.amsl.com>; Thu, 3 Jan 2013 11:35:54 -0800 (PST)
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCE821F8D02 for <plasma@ietf.org>; Thu, 3 Jan 2013 11:35:54 -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 6540C38F12; Thu, 3 Jan 2013 11:35:53 -0800 (PST)
From: "Jim Schaad" <ietf@augustcellars.com>
To: "'Trevor Freeman'" <trevorf@exchange.microsoft.com>, "'Ed Simon'" <Ed.Simon@titus.com>, <plasma@ietf.org>
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> <3020AC5E95452D43B5D8D0FB02F881D3162B90@DF-M14-10.exchange.corp.microsoft.com>
In-Reply-To: <3020AC5E95452D43B5D8D0FB02F881D3162B90@DF-M14-10.exchange.corp.microsoft.com>
Date: Thu, 3 Jan 2013 11:35:33 -0800
Message-ID: <009301cde9e9$80069820$8013c860$@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: AQHZToL2iFv9G069c1ZHgVd517VEZAK80yWoAZEmD6kCdhm+DgLAYmehASwA9VsCk/lBaAKuMoIyl6GgnWA=
Content-Language: en-us
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:35:57 -0000

> -----Original Message-----
> From: Trevor Freeman [mailto:trevorf@exchange.microsoft.com]
> Sent: Thursday, January 03, 2013 11:12 AM
> To: Ed Simon; Jim Schaad; plasma@ietf.org
> Subject: RE: [plasma] Clarification of how client applications handle the
> LockBox in client in <plasma:GetCMSToken> elements
> 
> 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 sender making the GetCMSKey call would never know if the set of
recipients is required.   Currently the set of policies on a message is not
exposed to the client and thus the client would have no way of determining
this.  Remember we are talking here about reading a message not sending a
message.

Jim

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