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

[Ed Simon <[e-mail]>]

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">[e-mail]</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">[e-mail]</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">[e-mail]</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#">hrQkL07h1qZhPhgLXKlL0dVeFLAbUVy0no05EGDzK2Q=</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</AttributeValue>
      </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: [e-mail] [[e-mail]] on behalf of Ed Simon [[e-mail]]
Sent: Wednesday, November 21, 2012 21:52
To: Jim Schaad; 'Trevor Freeman'; [e-mail]
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#">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">[e-mail]</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">[e-mail]</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">[e-mail]</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 [[e-mail]]
Sent: Wednesday, November 21, 2012 01:39
To: 'Trevor Freeman'; Ed Simon; [e-mail]
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:[e-mail]]
> Sent: Tuesday, November 20, 2012 2:46 PM
> To: Jim Schaad; 'Ed Simon'; [e-mail]
> 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:[e-mail]]
> Sent: Monday, November 19, 2012 8:11 PM
> To: Trevor Freeman; 'Ed Simon'; [e-mail]
> Subject: RE: [plasma] Clarification of how client applications handle the
> LockBox in client in <plasma:GetCMSToken> elements
>
>
>
> > -----Original Message-----
> > From: Trevor Freeman [mailto:[e-mail]]
> > Sent: Monday, November 19, 2012 2:18 PM
> > To: Jim Schaad; 'Ed Simon'; [e-mail]
> > 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>[e-mail]</Subject>
> > </Recipient>
> > < Recipient>
> > <Subject>[e-mail]</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 "[e-mail] [e-mail]"
>
> 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>[e-mail]</Subject>
> > <LockBox>123456789</LockBox>
> > </Recipient>
> > < Recipient>
> > <Subject>[e-mail]</Subject>
> > <LockBox>abcdef</LockBox>
> > </Recipient>
> >
> > Trevor
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Jim Schaad
> > Sent: Monday, November 19, 2012 1:58 PM
> > To: 'Ed Simon'; [e-mail]
> > Subject: Re: [plasma] Clarification of how client applications handle
> > the LockBox in client in <plasma:GetCMSToken> elements
> >
> >
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]] On
> > > Behalf Of Ed Simon
> > > Sent: Saturday, November 17, 2012 1:07 PM
> > > To: [e-mail]
> > > 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/plasma
> >
> > _______________________________________________
> > plasma mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/plasma


_______________________________________________
plasma mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/plasma