> -----Original Message----- > From: Trevor Freeman [mailto:[email protected]] > Sent: Monday, November 19, 2012 2:18 PM > To: Jim Schaad; 'Ed Simon'; [email protected] > 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>[email protected]</Subject> > </Recipient> > < Recipient> > <Subject>[email protected]</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 "[email protected] [email protected]" 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>[email protected]</Subject> > <LockBox>123456789</LockBox> > </Recipient> > < Recipient> > <Subject>[email protected]</Subject> > <LockBox>abcdef</LockBox> > </Recipient> > > Trevor > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Jim Schaad > Sent: Monday, November 19, 2012 1:58 PM > To: 'Ed Simon'; [email protected] > Subject: Re: [plasma] Clarification of how client applications handle the > LockBox in client in <plasma:GetCMSToken> elements > > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On > > Behalf Of Ed Simon > > Sent: Saturday, November 17, 2012 1:07 PM > > To: [email protected] > > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/plasma > > _______________________________________________ > plasma mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/plasma _______________________________________________ plasma mailing list [email protected] https://www.ietf.org/mailman/listinfo/plasma
