Re: [plasma] Clarification of how client applications handle the LockBox in client in <plasma:GetCMSToken> elements
Ed Simon <Ed.Simon@titus.com> Thu, 22 November 2012 02:53 UTC
Return-Path: <Ed.Simon@titus.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 A41B421E8053 for <plasma@ietfa.amsl.com>; Wed, 21 Nov 2012 18:53:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.066
X-Spam-Level:
X-Spam-Status: No, score=-6.066 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
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 Ie4+2YsRqfFp for <plasma@ietfa.amsl.com>; Wed, 21 Nov 2012 18:53:03 -0800 (PST)
Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.255.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7F421E8048 for <plasma@ietf.org>; Wed, 21 Nov 2012 18:53:03 -0800 (PST)
Received: from [216.82.254.35:10221] by server-2.bemta-7.messagelabs.com id D4/15-29475-E839DA05; Thu, 22 Nov 2012 02:53:02 +0000
X-Env-Sender: Ed.Simon@titus.com
X-Msg-Ref: server-9.tower-143.messagelabs.com!1353552779!11814291!1
X-Originating-IP: [67.210.173.99]
X-StarScan-Received:
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21100 invoked from network); 22 Nov 2012 02:53:00 -0000
Received: from 67-210-173.99.static.tel-ott.com (HELO snakeskin.titus.com) (67.210.173.99) by server-9.tower-143.messagelabs.com with AES128-SHA encrypted SMTP; 22 Nov 2012 02:53:00 -0000
Received: from E10MB3.tituscorp.local ([fe80::84f4:cfbe:f32f:9a5]) by E10CH1.tituscorp.local ([192.168.200.115]) with mapi id 14.03.0099.000; Wed, 21 Nov 2012 21:52:59 -0500
From: Ed Simon <Ed.Simon@titus.com>
To: Jim Schaad <ietf@augustcellars.com>, 'Trevor Freeman' <trevorf@exchange.microsoft.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: AQHNyFx6QAEfHVE3SUizATOKHQdq7A==
Date: Thu, 22 Nov 2012 02:52:58 +0000
Message-ID: <DCD8C7A5A8B3E844AA2E2CBE327CDC92013DA1E7@E10MB3.tituscorp.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.200.2]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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, 22 Nov 2012 02:53:04 -0000
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 attributes. 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#">hrQkL07h1qZhPhgLXKlL0dVeFLAbUVy0no05EGDzK2Q=</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</AttributeValue> </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.html > > > > > > ...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] 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