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, 03 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
- [plasma] Clarification of how client applications… Ed Simon
- Re: [plasma] Clarification of how client applicat… Jim Schaad
- Re: [plasma] Clarification of how client applicat… Ed Simon
- Re: [plasma] Clarification of how client applicat… Ed Simon
- Re: [plasma] Clarification of how client applicat… Jim Schaad
- Re: [plasma] Clarification of how client applicat… Trevor Freeman
- Re: [plasma] Clarification of how client applicat… Jim Schaad
- Re: [plasma] Clarification of how client applicat… Trevor Freeman
- Re: [plasma] Clarification of how client applicat… Jim Schaad
- Re: [plasma] Clarification of how client applicat… Ed Simon
- Re: [plasma] Clarification of how client applicat… Ed Simon
- Re: [plasma] Clarification of how client applicat… Jim Schaad
- Re: [plasma] Clarification of how client applicat… Ed Simon
- Re: [plasma] Clarification of how client applicat… Ed Simon
- Re: [plasma] Clarification of how client applicat… Jim Schaad
- Re: [plasma] Clarification of how client applicat… Ed Simon
- Re: [plasma] Clarification of how client applicat… Trevor Freeman
- Re: [plasma] Clarification of how client applicat… Jim Schaad
- Re: [plasma] Clarification of how client applicat… Jim Schaad
- Re: [plasma] Clarification of how client applicat… Trevor Freeman
- Re: [plasma] Clarification of how client applicat… Trevor Freeman