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

[Ed Simon <[e-mail]>]

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.

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.

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.

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.