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

From: Ed Simon <[email-masked]>
Date: Sat, 17 Nov 2012 21:07:03 +0000

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.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 19 Nov 2012 13:58:11 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ed Simon
> Sent: Saturday, November 17, 2012 1:07 PM
> To: [email-masked]
> Subject: Re: [plasma] Clarification of how client applications handle the
> LockBox in client in <plasma:GetCMSToken> elements
> 
> ...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
>    appropriate keying material."

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.

> 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-masked]
> https://www.ietf.org/mailman/listinfo/plasma

---

From: Trevor Freeman <[email-masked]>
Date: Mon, 19 Nov 2012 22:18:29 +0000

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-masked]</Subject>
</Recipient>
< Recipient>
<Subject>[email-masked]</Subject>
</Recipient>

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-masked]</Subject>
<LockBox>123456789</LockBox>
</Recipient>
< Recipient>
<Subject>[email-masked]</Subject>
<LockBox>abcdef</LockBox>
</Recipient>

Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Monday, November 19, 2012 1:58 PM
To: 'Ed Simon'; [email-masked]
Subject: Re: [plasma] Clarification of how client applications handle the LockBox in client in <plasma:GetCMSToken> elements

> Subject: Re: [plasma] Clarification of how client applications handle 
> the LockBox in client in <plasma:GetCMSToken> elements
> 
construction of
which
for
> 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.

message
> Sending Agent: In the <GetCMSToken> element of the PLASMA Request, the 
> sender will construct a <Recipient> list specifying, for each
recipient, both
> element to contain the encrypted CEK for that recipient (encrypted so 
> only that recipient can decrypt it). There will be no <CEK> element.
> 
structure.
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,
> 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 
also
> Sending Agent, it will be treated as in Scenario A; otherwise, the 
> PLASMA Server will create a LockBox for that recipient to populate the 
structure
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.

> Sending Agent: The Sending Agent will also construct a <CEK> element 
> to contain the CEK; no <Recipient> element will be created.
> 
> structure using the CEK provided by the Sending Agent; it may or may 
> not create a namedRecipients structure (populated independently of the 

Jim

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 19 Nov 2012 20:10:44 -0800

> From: Trevor Freeman [mailto:[email-masked]]
> Sent: Monday, November 19, 2012 2:18 PM
> To: Jim Schaad; 'Ed Simon'; [email-masked]
> Subject: RE: [plasma] Clarification of how client applications handle the
> 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>

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-masked] [email-masked]"

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>
> Behalf Of Jim Schaad
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:
> >
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.
> 
> >

---

From: Trevor Freeman <[email-masked]>
Date: Tue, 20 Nov 2012 22:46:29 +0000

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:[email-masked]] 
Sent: Monday, November 19, 2012 8:11 PM
To: Trevor Freeman; 'Ed Simon'; [email-masked]
Subject: RE: [plasma] Clarification of how client applications handle the LockBox in client in <plasma:GetCMSToken> elements

> Subject: RE: [plasma] Clarification of how client applications handle 
more
in

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.

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.

Policy=basic Policy

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
> > Subject: Re: [plasma] Clarification of how client applications 
> > handle the LockBox in client in <plasma:GetCMSToken> elements
> >
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 
> > (for example, due to section 7.2.2 of PLASMA Service Trust 
> > processing
v3).
> > 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 
> > specifies a limited set of recipients who can decrypt the message 
> > (for example,
> again,
> > specified, there may or may not be a LockBox specified by the 
> > Sending Agent.
> >
> > the <LockBox> element to contain the encrypted CEK for that 
> > recipient (encrypted so only that recipient can decrypt it). The 
> > Sending Agent will
> also
> > PLASMA Server will create a LockBox for that recipient to populate 
> > the namedRecipients structure. It will also create a 
> > defaultRecipients
> structure
> > PLASMA Server will be able to, independently of the Sending Agent, 
> > be able to supplement the list of recipients.
> >
> 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
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
> > 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.
>

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 20 Nov 2012 22:39:48 -0800

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

> Sent: Tuesday, November 20, 2012 2:46 PM
> 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.
the
> system.  These each have different outcomes.
> 
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.
> 
>