From Ed.Simon@titus.com  Wed Jan  2 11:48:30 2013
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 11D3421F8870 for <plasma@ietfa.amsl.com>; Wed,  2 Jan 2013 11:48:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.998
X-Spam-Level: 
X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[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 V-7opYWMXQFx for <plasma@ietfa.amsl.com>; Wed,  2 Jan 2013 11:48:28 -0800 (PST)
Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.250.242]) by ietfa.amsl.com (Postfix) with ESMTP id 911CD21F85AC for <plasma@ietf.org>; Wed,  2 Jan 2013 11:48:25 -0800 (PST)
Received: from [216.82.250.179:23760] by server-13.bemta-12.messagelabs.com id 23/A1-13815-80F84E05; Wed, 02 Jan 2013 19:48:24 +0000
X-Env-Sender: Ed.Simon@titus.com
X-Msg-Ref: server-14.tower-210.messagelabs.com!1357156103!11088779!1
X-Originating-IP: [67.210.173.106]
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19891 invoked from network); 2 Jan 2013 19:48:24 -0000
Received: from 67-210-173.106.static.tel-ott.com (HELO snakeskin.titus.com) (67.210.173.106) by server-14.tower-210.messagelabs.com with SMTP; 2 Jan 2013 19:48:24 -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, 2 Jan 2013 14:48:23 -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: AQHNyFx6QAEfHVE3SUizATOKHQdq7Jf7HC6sgADLK4CAAnMyCYA4Vg5u
Date: Wed, 2 Jan 2013 19:48:23 +0000
Message-ID: <DCD8C7A5A8B3E844AA2E2CBE327CDC92013E5BD9@E10MB3.tituscorp.local>
References: <DCD8C7A5A8B3E844AA2E2CBE327CDC92013DA1E7@E10MB3.tituscorp.local> <DCD8C7A5A8B3E844AA2E2CBE327CDC92013DB34F@E10MB3.tituscorp.local>, <014401cdcb92$21497b60$63dc7220$@augustcellars.com>, <DCD8C7A5A8B3E844AA2E2CBE327CDC92013DBE78@E10MB3.tituscorp.local>
In-Reply-To: <DCD8C7A5A8B3E844AA2E2CBE327CDC92013DBE78@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: Wed, 02 Jan 2013 19:48:30 -0000

Following my prior email (see below), on the GetCMSKey side, any user-speci=
fied policy options (such as the list of recipients), which were captured i=
n the LockBox during the GetCMSToken call, would be evaluated against the X=
ACML attributes specified in the GetCMSKey request. For example, a specific=
 recipient would be specified through a XACML access subject (or perhaps XA=
CML recipient subject) attribute. (Note that I would disagree with assuming=
 the party named, if any, in the authentication token is necessarily an acc=
ess subject or recipient subject).

Thoughts?

Ed
________________________________________
From: Ed Simon
Sent: Tuesday, November 27, 2012 18:43
To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
Subject: RE: [plasma] Clarification of how client applications handle the L=
ockBox in client in <plasma:GetCMSToken> elements

Reworking the example, I've replaced <Leaf> with <Policy>/<PolicyOptions> (=
re-using the PolicyType structure defined for the GetRolesToken; but using =
the PolicyID attribute and replacing the PolicyType <Name> element with <Fr=
iendlyName> (as per SAML)). It seems to me we the specification's text may =
not be quite clear on the distinction between the use of Policy(s) and Labe=
l/Leaf; it seems to me that Label/Leaf in GetCMSToken could be logically re=
placed with the GetRolesToken PolicyType structure, though in a GetCMSToken=
 request, the policy options would be specified by the sender (whereas in G=
etRolesToken, the <PolicyOptions> specifies what the sender needs to specif=
y).

For composite policies, I would rename the GetCMSToken <Label> structure wi=
th <PolicyCombiner AlgorithmId=3D"...">, thus completing the policy-oriente=
d semantics and naming style.

The above paragraphs may answer Jim's first question.

The answer to the second question is that if the sender is specifying polic=
y options, which will later need to be used, on a GetCMSKey request from a =
recipient, then because the PLASMA server is stateless wrt specific message=
s, those options will need to be carried in the LockBox payload of the mess=
age. I suggest, and I think Jim was hinting he was considering this a few w=
eeks ago, that the content of the LockBox (labels/policies, namedRecipients=
, defaultRecipients, CEK, ...) be specified in terms of XML rather than ASN=
.1 and the ASN.1 LockBox be declared as UTF8String so it can hold the XML c=
ontents (ASN.1 structures such a ASN.1 RecipientInfo(s) could be stored as =
base64-encoded within the XML).

Here's the latest rework of the example...

>>>
  <Request xmlns=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" Combine=
dDecision=3D"false" ReturnPolicyIdList=3D"false">

    <Attributes Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-category=
:action">
      <Attribute AttributeId=3D"urn:plasma:action-id" IncludeInResult=3D"fa=
lse">
        <AttributeValue DataType=3D"http://www.w3.org/2001/XMLSchema#string=
">GetCMSToken</AttributeValue>
      </Attribute>
    </Attributes>
    <Attributes Category=3D"urn:ietf:plasma:data">
      <Attribute AttributeId=3D"urn:plasma:data-id" IncludeInResult=3D"fals=
e">
        <AttributeValue DataType=3D"http://www.w3.org/2001/XMLSchema#string=
">
          <GetCMSToken xmlns=3D"urn:ietf:schema:plasma:1.0">
            <Policy PolicyId=3D"urn:example:policies:only-allow-these-recip=
ients-to-decrypt-this-email">
              <FriendlyName>Only Allow These Recipients To Decrypt this Ema=
il</FriendlyName>
              <PolicyOptions>

              <!-- Specify parameters to the protection policy that the use=
r has specified here (note switch back to XACML namespace in this example, =
but contents of <PolicyParameters> could by in any namespace) -->

    <Attributes Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-category=
:access-subject" xmlns=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
      <Attribute AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subje=
ct-id"" IncludeInResult=3D"false">
        <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-type:=
rfc822Name">Alice@example.org</AttributeValue>
      </Attribute>
      <Attribute AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subje=
ct-id"" IncludeInResult=3D"false">
        <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-type:=
rfc822Name">Bob@example.org</AttributeValue>
      </Attribute>
      <Attribute AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subje=
ct-id"" IncludeInResult=3D"false">
        <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-type:=
rfc822Name">Carl@example.org</AttributeValue>
      </Attribute>
    </Attributes>

              </PolicyOptions>
            </Policy>
            <Hash>
              <DigestMethod xmlns=3D"http://www.w3.org/2000/09/xmldsig#" Al=
gorithm =3D"http://www.w3.org/2001/04/xmlenc#sha256"/>
              <DigestValue xmlns=3D"http://www.w3.org/2000/09/xmldsig#">hrQ=
kL07h1qZhPhgLXKlL0dVeFLAbUVy0no05EGDzK2Q=3D</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 (exam=
ple below) -->

    <Attributes Category=3D"urn:example:attributes-for-determining-whether-=
this-XACML-request-will-be-permitted">
      <Attribute AttributeId=3D"urn:example:something-1" IncludeInResult=3D=
"false">
        <AttributeValue DataType=3D"urn:example:something-1-format">Somethi=
ngSomethingSomethingSomething</AttributeValue>
      </Attribute>
      <Attribute AttributeId=3D"urn:example:something-2" IncludeInResult=3D=
"false">
        <AttributeValue DataType=3D"urn:example:something-2-format">asldkjf=
alskdjf32434534543dfjalkscxvkljzv2309080kjlkjlkj</AttributeValue>
      </Attribute>
    </Attributes>

  </Request>
<<<

Ed
________________________________________
From: Jim Schaad [ietf@augustcellars.com]
Sent: Sunday, November 25, 2012 23:54
To: Ed Simon; 'Trevor Freeman'; plasma@ietf.org
Subject: RE: [plasma] Clarification of how client applications handle the L=
ockBox in client in <plasma:GetCMSToken> elements

Ed,

I agree with most of this, however there are two things

1.  Currently one can place an arbitrary structure inside of the Leaf
element.  Do you believe that is insufficient or do we really need to have
the extra layer of the <PolicyParameters> element added?

2.  At the end you say that there is a needed change to the LockBox element=
.
I am not clear what this change would be.  Is it the <PolicyParameters>
element above or something else?

Jim


> -----Original Message-----
> From: Ed Simon [mailto:Ed.Simon@titus.com]
> Sent: Sunday, November 25, 2012 2:15 PM
> To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> Subject: RE: [plasma] Clarification of how client applications handle the
> LockBox in client in <plasma:GetCMSToken> elements
>
> Upon pondering this further, I think it is important to distinguish
between
> attributes that act as parameters to the policy the user wishes to enforc=
e
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=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
> CombinedDecision=3D"false" ReturnPolicyIdList=3D"false">
>
>     <Attributes Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-
> category:action">
>       <Attribute AttributeId=3D"urn:plasma:action-id"
IncludeInResult=3D"false">
>         <AttributeValue
> DataType=3D"http://www.w3.org/2001/XMLSchema#string">GetCMSToken</
> AttributeValue>
>       </Attribute>
>     </Attributes>
>     <Attributes Category=3D"urn:ietf:plasma:data">
>       <Attribute AttributeId=3D"urn:plasma:data-id" IncludeInResult=3D"fa=
lse">
>         <AttributeValue
> DataType=3D"http://www.w3.org/2001/XMLSchema#string">
>           <GetCMSToken xmlns=3D"urn:ietf:schema:plasma:1.0">
>             <Leaf
PolicyId=3D"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=3D"urn:oasis:names:tc:xacml:3.0:attribute-
> category:access-subject"
> xmlns=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
>       <Attribute
AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> id"" IncludeInResult=3D"false">
>         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> type:rfc822Name">Alice@example.org</AttributeValue>
>       </Attribute>
>       <Attribute
AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> id"" IncludeInResult=3D"false">
>         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> type:rfc822Name">Bob@example.org</AttributeValue>
>       </Attribute>
>       <Attribute
AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> id"" IncludeInResult=3D"false">
>         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> type:rfc822Name">Carl@example.org</AttributeValue>
>       </Attribute>
>     </Attributes>
>
>               </PolicyParameters>
>             </Leaf>
>             <Hash>
>               <DigestMethod xmlns=3D"http://www.w3.org/2000/09/xmldsig#"
> Algorithm =3D"http://www.w3.org/2001/04/xmlenc#sha256"/>
>               <DigestValue
> xmlns=3D"http://www.w3.org/2000/09/xmldsig#">hrQkL07h1qZhPhgLXKlL0dV
> eFLAbUVy0no05EGDzK2Q=3D</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=3D"urn:example:attributes-for-determining-whethe=
r-
> this-XACML-request-will-be-permitted">
>       <Attribute AttributeId=3D"urn:example:something-1"
> IncludeInResult=3D"false">
>         <AttributeValue DataType=3D"urn:example:something-1-
> format">SomethingSomethingSomethingSomething</AttributeValue>
>       </Attribute>
>       <Attribute AttributeId=3D"urn:example:something-2"
> IncludeInResult=3D"false">
>         <AttributeValue DataType=3D"urn:example:something-2-
>
format">asldkjfalskdjf32434534543dfjalkscxvkljzv2309080kjlkjlkj</AttributeV
> alue>
>       </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: plasma-bounces@ietf.org [plasma-bounces@ietf.org] on behalf of Ed
> Simon [Ed.Simon@titus.com]
> Sent: Wednesday, November 21, 2012 21:52
> To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> 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=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
> CombinedDecision=3D"false" ReturnPolicyIdList=3D"false">
>     <Attributes Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-
> category:action">
>       <Attribute AttributeId=3D"urn:plasma:action-id"
IncludeInResult=3D"false">
>         <AttributeValue
> DataType=3D"http://www.w3.org/2001/XMLSchema#string">GetCMSToken</
> AttributeValue>
>       </Attribute>
>     </Attributes>
>     <Attributes Category=3D"urn:ietf:plasma:data">
>       <Attribute AttributeId=3D"urn:plasma:data-id" IncludeInResult=3D"fa=
lse">
>         <AttributeValue
> DataType=3D"http://www.w3.org/2001/XMLSchema#string">
>           <GetCMSToken xmlns=3D"urn:ietf:schema:plasma:1.0">
>             <Leaf
PolicyId=3D"urn:example:policies:only-allow-recipients-to-decrypt-
> this-email"/>
>             <Hash>
>               <DigestMethod xmlns=3D"http://www.w3.org/2000/09/xmldsig#"
> Algorithm =3D"http://www.w3.org/2001/04/xmlenc#sha256"/>
>               <DigestValue
> xmlns=3D"http://www.w3.org/2000/09/xmldsig#">hrQkL07h1qZhPhgLXKlL0dV
> eFLAbUVy0no05EGDzK2Q=3D</DigestValue>
>             </Hash>
>             <CEK>1BF2BEB249EE8EF2CB373E9800AC6F01</CEK>
>           </GetCMSToken>
>         </AttributeValue>
>       </Attribute>
>     </Attributes>
>
> <!-- Ed's NEW STUFF BEGINS HERE! -->
>
>     <Attributes Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-
> category:access-subject">
>       <Attribute
AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> id"" IncludeInResult=3D"false">
>         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> type:rfc822Name">Alice@example.org</AttributeValue>
>       </Attribute>
>       <Attribute
AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> id"" IncludeInResult=3D"false">
>         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> type:rfc822Name">Bob@example.org</AttributeValue>
>       </Attribute>
>       <Attribute
AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> id"" IncludeInResult=3D"false">
>         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> type:rfc822Name">Carl@example.org</AttributeValue>
>       </Attribute>
>     </Attributes>
>
>     <Attributes Category=3D"urn:example:some-other-attributes-related-to-
> processing-this-policy">
>       <Attribute AttributeId=3D"urn:example:something-1"
> IncludeInResult=3D"false">
>         <AttributeValue DataType=3D"urn:example:something-1-
> format">SomethingSomethingSomethingSomething</AttributeValue>
>       </Attribute>
>       <Attribute AttributeId=3D"urn:example:something-2"
> IncludeInResult=3D"false">
>         <AttributeValue DataType=3D"urn:example:something-2-
>
format">asldkjfalskdjf32434534543dfjalkscxvkljzv2309080kjlkjlkj</AttributeV
> alue>
>       </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 se=
t
by
> the sender?
>
> I should have called the structure <LockBoxes> rather than <Recipients> t=
o
> 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 read=
y
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 i=
s
> > 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=3Dbasic 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=3D0.
> > >
> > > 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 mailing list
> plasma@ietf.org
> https://www.ietf.org/mailman/listinfo/plasma

From ietf@augustcellars.com  Wed Jan  2 14:15:56 2013
Return-Path: <ietf@augustcellars.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 5510A21F8481 for <plasma@ietfa.amsl.com>; Wed,  2 Jan 2013 14:15:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.763
X-Spam-Level: 
X-Spam-Status: No, score=-2.763 tagged_above=-999 required=5 tests=[AWL=0.236,  BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1]
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 7t7+LGrUdQCO for <plasma@ietfa.amsl.com>; Wed,  2 Jan 2013 14:15:54 -0800 (PST)
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5717721F86A9 for <plasma@ietf.org>; Wed,  2 Jan 2013 14:15:54 -0800 (PST)
Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id A43C62CA00; Wed,  2 Jan 2013 14:15:53 -0800 (PST)
From: "Jim Schaad" <ietf@augustcellars.com>
To: "'Ed Simon'" <Ed.Simon@titus.com>, "'Trevor Freeman'" <trevorf@exchange.microsoft.com>, <plasma@ietf.org>
References: <DCD8C7A5A8B3E844AA2E2CBE327CDC92013DA1E7@E10MB3.tituscorp.local> <DCD8C7A5A8B3E844AA2E2CBE327CDC92013DB34F@E10MB3.tituscorp.local>, <014401cdcb92$21497b60$63dc7220$@augustcellars.com>, <DCD8C7A5A8B3E844AA2E2CBE327CDC92013DBE78@E10MB3.tituscorp.local> <DCD8C7A5A8B3E844AA2E2CBE327CDC92013E5BD9@E10MB3.tituscorp.local>
In-Reply-To: <DCD8C7A5A8B3E844AA2E2CBE327CDC92013E5BD9@E10MB3.tituscorp.local>
Date: Wed, 2 Jan 2013 14:15:35 -0800
Message-ID: <004901cde936$b054ddb0$10fe9910$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHZToL2iFv9G069c1ZHgVd517VEZAK80yWoAZEmD6kCdhm+DgLAYmehl9OrmeA=
Content-Language: en-us
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: Wed, 02 Jan 2013 22:15:56 -0000

It would appear to me that not allowing for the identities asserted during
the process of doing the authentication not being a default set of access
subject attributes would be incorrect and would make life much harder.

For a simple policy one would still need to have a check that the access
subject attribute asserted by the client is allowed for the set of known
identities for the subject.  While this makes sense if the policy is going
to explicitly allow for impersonation, I think it is an unneeded burden on
policy writers for the simplest of policies.

Why would disagree with assuming that the party named is the same as the
access subject unless a different access subject is explicitly stated by the
client?

Jim


> -----Original Message-----
> From: Ed Simon [mailto:Ed.Simon@titus.com]
> Sent: Wednesday, January 02, 2013 11:48 AM
> To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> Subject: RE: [plasma] Clarification of how client applications handle the
> LockBox in client in <plasma:GetCMSToken> elements
> 
> Following my prior email (see below), on the GetCMSKey side, any user-
> specified policy options (such as the list of recipients), which were
captured
> in the LockBox during the GetCMSToken call, would be evaluated against the
> XACML attributes specified in the GetCMSKey request. For example, a
> specific recipient would be specified through a XACML access subject (or
> perhaps XACML recipient subject) attribute. (Note that I would disagree
with
> assuming the party named, if any, in the authentication token is
necessarily
> an access subject or recipient subject).
> 
> Thoughts?
> 
> Ed
> ________________________________________
> From: Ed Simon
> Sent: Tuesday, November 27, 2012 18:43
> To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> Subject: RE: [plasma] Clarification of how client applications handle the
> LockBox in client in <plasma:GetCMSToken> elements
> 
> Reworking the example, I've replaced <Leaf> with <Policy>/<PolicyOptions>
> (re-using the PolicyType structure defined for the GetRolesToken; but
using
> the PolicyID attribute and replacing the PolicyType <Name> element with
> <FriendlyName> (as per SAML)). It seems to me we the specification's text
> may not be quite clear on the distinction between the use of Policy(s) and
> Label/Leaf; it seems to me that Label/Leaf in GetCMSToken could be
logically
> replaced with the GetRolesToken PolicyType structure, though in a
> GetCMSToken request, the policy options would be specified by the sender
> (whereas in GetRolesToken, the <PolicyOptions> specifies what the sender
> needs to specify).
> 
> For composite policies, I would rename the GetCMSToken <Label> structure
> with <PolicyCombiner AlgorithmId="...">, thus completing the policy-
> oriented semantics and naming style.
> 
> The above paragraphs may answer Jim's first question.
> 
> The answer to the second question is that if the sender is specifying
policy
> options, which will later need to be used, on a GetCMSKey request from a
> recipient, then because the PLASMA server is stateless wrt specific
> messages, those options will need to be carried in the LockBox payload of
> the message. I suggest, and I think Jim was hinting he was considering
this a
> few weeks ago, that the content of the LockBox (labels/policies,
> namedRecipients, defaultRecipients, CEK, ...) be specified in terms of XML
> rather than ASN.1 and the ASN.1 LockBox be declared as UTF8String so it
can
> hold the XML contents (ASN.1 structures such a ASN.1 RecipientInfo(s)
could
> be stored as base64-encoded within the XML).
> 
> Here's the latest rework of the example...
> 
> >>>
>   <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">
>             <Policy
PolicyId="urn:example:policies:only-allow-these-recipients-to-
> decrypt-this-email">
>               <FriendlyName>Only Allow These Recipients To Decrypt this
> Email</FriendlyName>
>               <PolicyOptions>
> 
>               <!-- 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">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>
> 
>               </PolicyOptions>
>             </Policy>
>             <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#">hrQkL07h1qZhPhgLXKlL0dV
> eFLAbUVy0no05EGDzK2Q=</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</AttributeV
> alue>
>       </Attribute>
>     </Attributes>
> 
>   </Request>
> <<<
> 
> Ed
> ________________________________________
> From: Jim Schaad [ietf@augustcellars.com]
> Sent: Sunday, November 25, 2012 23:54
> To: Ed Simon; 'Trevor Freeman'; plasma@ietf.org
> Subject: RE: [plasma] Clarification of how client applications handle the
> LockBox in client in <plasma:GetCMSToken> elements
> 
> Ed,
> 
> I agree with most of this, however there are two things
> 
> 1.  Currently one can place an arbitrary structure inside of the Leaf
element.
> Do you believe that is insufficient or do we really need to have the extra
> layer of the <PolicyParameters> element added?
> 
> 2.  At the end you say that there is a needed change to the LockBox
element.
> I am not clear what this change would be.  Is it the <PolicyParameters>
> element above or something else?
> 
> Jim
> 
> 
> > -----Original Message-----
> > From: Ed Simon [mailto:Ed.Simon@titus.com]
> > Sent: Sunday, November 25, 2012 2:15 PM
> > To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> > Subject: RE: [plasma] Clarification of how client applications handle
> > the LockBox in client in <plasma:GetCMSToken> elements
> >
> > 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">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>
> >
> >               </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#">hrQkL07h1qZhPhgLXKlL0dV
> > eFLAbUVy0no05EGDzK2Q=</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</AttributeV
> > alue>
> >       </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: plasma-bounces@ietf.org [plasma-bounces@ietf.org] on behalf of
> > Ed Simon [Ed.Simon@titus.com]
> > Sent: Wednesday, November 21, 2012 21:52
> > To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> > 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#">hrQkL07h1qZhPhgLXKlL0dV
> > eFLAbUVy0no05EGDzK2Q=</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</AttributeV
> > alue>
> >       </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.htm
> > > > > l
> > > > >
> > > > > ...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 mailing list
> > plasma@ietf.org
> > https://www.ietf.org/mailman/listinfo/plasma


From Ed.Simon@titus.com  Wed Jan  2 15:04:47 2013
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 2BCF221F8836 for <plasma@ietfa.amsl.com>; Wed,  2 Jan 2013 15:04:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.998
X-Spam-Level: 
X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[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 uIJVqeAg9SO6 for <plasma@ietfa.amsl.com>; Wed,  2 Jan 2013 15:04:45 -0800 (PST)
Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.255.50]) by ietfa.amsl.com (Postfix) with ESMTP id CD49121F8831 for <plasma@ietf.org>; Wed,  2 Jan 2013 15:04:31 -0800 (PST)
Received: from [216.82.254.3:38906] by server-8.bemta-7.messagelabs.com id 4A/1B-18754-EFCB4E05; Wed, 02 Jan 2013 23:04:30 +0000
X-Env-Sender: Ed.Simon@titus.com
X-Msg-Ref: server-6.tower-172.messagelabs.com!1357167869!8197206!1
X-Originating-IP: [67.210.173.106]
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10475 invoked from network); 2 Jan 2013 23:04:29 -0000
Received: from 67-210-173.106.static.tel-ott.com (HELO snakeskin.titus.com) (67.210.173.106) by server-6.tower-172.messagelabs.com with SMTP; 2 Jan 2013 23:04:29 -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, 2 Jan 2013 18:04:27 -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: AQHNyFx6QAEfHVE3SUizATOKHQdq7Jf7HC6sgADLK4CAAnMyCYA4Vg5ugAB/34D//7Pyug==
Date: Wed, 2 Jan 2013 23:04:27 +0000
Message-ID: <DCD8C7A5A8B3E844AA2E2CBE327CDC92013E5C75@E10MB3.tituscorp.local>
References: <DCD8C7A5A8B3E844AA2E2CBE327CDC92013DA1E7@E10MB3.tituscorp.local> <DCD8C7A5A8B3E844AA2E2CBE327CDC92013DB34F@E10MB3.tituscorp.local>, <014401cdcb92$21497b60$63dc7220$@augustcellars.com>, <DCD8C7A5A8B3E844AA2E2CBE327CDC92013DBE78@E10MB3.tituscorp.local> <DCD8C7A5A8B3E844AA2E2CBE327CDC92013E5BD9@E10MB3.tituscorp.local>, <004901cde936$b054ddb0$10fe9910$@augustcellars.com>
In-Reply-To: <004901cde936$b054ddb0$10fe9910$@augustcellars.com>
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: Wed, 02 Jan 2013 23:04:47 -0000

If a XACML policy includes, inter alia, a rule that requiring a that only r=
ecipients may read an email, then the XACML will require either that the ac=
cess subject be specified in the XACML request (as I have said below) or th=
at the identity of the access subject be accessible through a PIP; XACML, t=
o my recollection, makes no automatic assumption that the authenticating pa=
rty is the access subject party. If PLASMA is to require that the authentic=
ating party be implicitly considered also as a XACML access subject, then P=
LASMA needs to be explicit about that and perhaps describe the means throug=
h which that is to be accomplished wrt XACML -- would it not?

I do not see why it would be difficult for client apps to specify who the a=
ccess-requesting email recipient is through XACML attributes in the GetCMSK=
ey PLASMA request. That seems to me the easiest, most robust approach for b=
oth clients apps and policy servers.

My preference is for PLASMA to say that email recipients are to be specifie=
d as XACML access subjects in the XACML request part (as is the normal case=
 with XACML). If it is also deemed necessary to support the XACML PIP appro=
ach, we can do that too.=20

Ed

________________________________________
From: Jim Schaad [ietf@augustcellars.com]
Sent: Wednesday, January 02, 2013 17:15
To: Ed Simon; 'Trevor Freeman'; plasma@ietf.org
Subject: RE: [plasma] Clarification of how client applications handle the L=
ockBox in client in <plasma:GetCMSToken> elements

It would appear to me that not allowing for the identities asserted during
the process of doing the authentication not being a default set of access
subject attributes would be incorrect and would make life much harder.

For a simple policy one would still need to have a check that the access
subject attribute asserted by the client is allowed for the set of known
identities for the subject.  While this makes sense if the policy is going
to explicitly allow for impersonation, I think it is an unneeded burden on
policy writers for the simplest of policies.

Why would disagree with assuming that the party named is the same as the
access subject unless a different access subject is explicitly stated by th=
e
client?

Jim


> -----Original Message-----
> From: Ed Simon [mailto:Ed.Simon@titus.com]
> Sent: Wednesday, January 02, 2013 11:48 AM
> To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> Subject: RE: [plasma] Clarification of how client applications handle the
> LockBox in client in <plasma:GetCMSToken> elements
>
> Following my prior email (see below), on the GetCMSKey side, any user-
> specified policy options (such as the list of recipients), which were
captured
> in the LockBox during the GetCMSToken call, would be evaluated against th=
e
> XACML attributes specified in the GetCMSKey request. For example, a
> specific recipient would be specified through a XACML access subject (or
> perhaps XACML recipient subject) attribute. (Note that I would disagree
with
> assuming the party named, if any, in the authentication token is
necessarily
> an access subject or recipient subject).
>
> Thoughts?
>
> Ed
> ________________________________________
> From: Ed Simon
> Sent: Tuesday, November 27, 2012 18:43
> To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> Subject: RE: [plasma] Clarification of how client applications handle the
> LockBox in client in <plasma:GetCMSToken> elements
>
> Reworking the example, I've replaced <Leaf> with <Policy>/<PolicyOptions>
> (re-using the PolicyType structure defined for the GetRolesToken; but
using
> the PolicyID attribute and replacing the PolicyType <Name> element with
> <FriendlyName> (as per SAML)). It seems to me we the specification's text
> may not be quite clear on the distinction between the use of Policy(s) an=
d
> Label/Leaf; it seems to me that Label/Leaf in GetCMSToken could be
logically
> replaced with the GetRolesToken PolicyType structure, though in a
> GetCMSToken request, the policy options would be specified by the sender
> (whereas in GetRolesToken, the <PolicyOptions> specifies what the sender
> needs to specify).
>
> For composite policies, I would rename the GetCMSToken <Label> structure
> with <PolicyCombiner AlgorithmId=3D"...">, thus completing the policy-
> oriented semantics and naming style.
>
> The above paragraphs may answer Jim's first question.
>
> The answer to the second question is that if the sender is specifying
policy
> options, which will later need to be used, on a GetCMSKey request from a
> recipient, then because the PLASMA server is stateless wrt specific
> messages, those options will need to be carried in the LockBox payload of
> the message. I suggest, and I think Jim was hinting he was considering
this a
> few weeks ago, that the content of the LockBox (labels/policies,
> namedRecipients, defaultRecipients, CEK, ...) be specified in terms of XM=
L
> rather than ASN.1 and the ASN.1 LockBox be declared as UTF8String so it
can
> hold the XML contents (ASN.1 structures such a ASN.1 RecipientInfo(s)
could
> be stored as base64-encoded within the XML).
>
> Here's the latest rework of the example...
>
> >>>
>   <Request xmlns=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
> CombinedDecision=3D"false" ReturnPolicyIdList=3D"false">
>
>     <Attributes Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-
> category:action">
>       <Attribute AttributeId=3D"urn:plasma:action-id"
IncludeInResult=3D"false">
>         <AttributeValue
> DataType=3D"http://www.w3.org/2001/XMLSchema#string">GetCMSToken</
> AttributeValue>
>       </Attribute>
>     </Attributes>
>     <Attributes Category=3D"urn:ietf:plasma:data">
>       <Attribute AttributeId=3D"urn:plasma:data-id" IncludeInResult=3D"fa=
lse">
>         <AttributeValue
> DataType=3D"http://www.w3.org/2001/XMLSchema#string">
>           <GetCMSToken xmlns=3D"urn:ietf:schema:plasma:1.0">
>             <Policy
PolicyId=3D"urn:example:policies:only-allow-these-recipients-to-
> decrypt-this-email">
>               <FriendlyName>Only Allow These Recipients To Decrypt this
> Email</FriendlyName>
>               <PolicyOptions>
>
>               <!-- 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=3D"urn:oasis:names:tc:xacml:3.0:attribute-
> category:access-subject"
> xmlns=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
>       <Attribute
AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> id"" IncludeInResult=3D"false">
>         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> type:rfc822Name">Alice@example.org</AttributeValue>
>       </Attribute>
>       <Attribute
AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> id"" IncludeInResult=3D"false">
>         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> type:rfc822Name">Bob@example.org</AttributeValue>
>       </Attribute>
>       <Attribute
AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> id"" IncludeInResult=3D"false">
>         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> type:rfc822Name">Carl@example.org</AttributeValue>
>       </Attribute>
>     </Attributes>
>
>               </PolicyOptions>
>             </Policy>
>             <Hash>
>               <DigestMethod xmlns=3D"http://www.w3.org/2000/09/xmldsig#"
> Algorithm =3D"http://www.w3.org/2001/04/xmlenc#sha256"/>
>               <DigestValue
> xmlns=3D"http://www.w3.org/2000/09/xmldsig#">hrQkL07h1qZhPhgLXKlL0dV
> eFLAbUVy0no05EGDzK2Q=3D</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=3D"urn:example:attributes-for-determining-whethe=
r-
> this-XACML-request-will-be-permitted">
>       <Attribute AttributeId=3D"urn:example:something-1"
> IncludeInResult=3D"false">
>         <AttributeValue DataType=3D"urn:example:something-1-
> format">SomethingSomethingSomethingSomething</AttributeValue>
>       </Attribute>
>       <Attribute AttributeId=3D"urn:example:something-2"
> IncludeInResult=3D"false">
>         <AttributeValue DataType=3D"urn:example:something-2-
>
format">asldkjfalskdjf32434534543dfjalkscxvkljzv2309080kjlkjlkj</AttributeV
> alue>
>       </Attribute>
>     </Attributes>
>
>   </Request>
> <<<
>
> Ed
> ________________________________________
> From: Jim Schaad [ietf@augustcellars.com]
> Sent: Sunday, November 25, 2012 23:54
> To: Ed Simon; 'Trevor Freeman'; plasma@ietf.org
> Subject: RE: [plasma] Clarification of how client applications handle the
> LockBox in client in <plasma:GetCMSToken> elements
>
> Ed,
>
> I agree with most of this, however there are two things
>
> 1.  Currently one can place an arbitrary structure inside of the Leaf
element.
> Do you believe that is insufficient or do we really need to have the extr=
a
> layer of the <PolicyParameters> element added?
>
> 2.  At the end you say that there is a needed change to the LockBox
element.
> I am not clear what this change would be.  Is it the <PolicyParameters>
> element above or something else?
>
> Jim
>
>
> > -----Original Message-----
> > From: Ed Simon [mailto:Ed.Simon@titus.com]
> > Sent: Sunday, November 25, 2012 2:15 PM
> > To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> > Subject: RE: [plasma] Clarification of how client applications handle
> > the LockBox in client in <plasma:GetCMSToken> elements
> >
> > 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=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
> > CombinedDecision=3D"false" ReturnPolicyIdList=3D"false">
> >
> >     <Attributes Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-
> > category:action">
> >       <Attribute AttributeId=3D"urn:plasma:action-id"
> IncludeInResult=3D"false">
> >         <AttributeValue
> >
> DataType=3D"http://www.w3.org/2001/XMLSchema#string">GetCMSToken</
> > AttributeValue>
> >       </Attribute>
> >     </Attributes>
> >     <Attributes Category=3D"urn:ietf:plasma:data">
> >       <Attribute AttributeId=3D"urn:plasma:data-id"
IncludeInResult=3D"false">
> >         <AttributeValue
> > DataType=3D"http://www.w3.org/2001/XMLSchema#string">
> >           <GetCMSToken xmlns=3D"urn:ietf:schema:plasma:1.0">
> >             <Leaf
> PolicyId=3D"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=3D"urn:oasis:names:tc:xacml:3.0:attribute-
> > category:access-subject"
> > xmlns=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
> >       <Attribute
> AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > id"" IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> > type:rfc822Name">Alice@example.org</AttributeValue>
> >       </Attribute>
> >       <Attribute
> AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > id"" IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> > type:rfc822Name">Bob@example.org</AttributeValue>
> >       </Attribute>
> >       <Attribute
> AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > id"" IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> > type:rfc822Name">Carl@example.org</AttributeValue>
> >       </Attribute>
> >     </Attributes>
> >
> >               </PolicyParameters>
> >             </Leaf>
> >             <Hash>
> >               <DigestMethod xmlns=3D"http://www.w3.org/2000/09/xmldsig#=
"
> > Algorithm =3D"http://www.w3.org/2001/04/xmlenc#sha256"/>
> >               <DigestValue
> >
> xmlns=3D"http://www.w3.org/2000/09/xmldsig#">hrQkL07h1qZhPhgLXKlL0dV
> > eFLAbUVy0no05EGDzK2Q=3D</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=3D"urn:example:attributes-for-determining-whether-
> > this-XACML-request-will-be-permitted">
> >       <Attribute AttributeId=3D"urn:example:something-1"
> > IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:example:something-1-
> > format">SomethingSomethingSomethingSomething</AttributeValue>
> >       </Attribute>
> >       <Attribute AttributeId=3D"urn:example:something-2"
> > IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:example:something-2-
> >
>
format">asldkjfalskdjf32434534543dfjalkscxvkljzv2309080kjlkjlkj</AttributeV
> > alue>
> >       </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: plasma-bounces@ietf.org [plasma-bounces@ietf.org] on behalf of
> > Ed Simon [Ed.Simon@titus.com]
> > Sent: Wednesday, November 21, 2012 21:52
> > To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> > 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=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
> > CombinedDecision=3D"false" ReturnPolicyIdList=3D"false">
> >     <Attributes Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-
> > category:action">
> >       <Attribute AttributeId=3D"urn:plasma:action-id"
> IncludeInResult=3D"false">
> >         <AttributeValue
> >
> DataType=3D"http://www.w3.org/2001/XMLSchema#string">GetCMSToken</
> > AttributeValue>
> >       </Attribute>
> >     </Attributes>
> >     <Attributes Category=3D"urn:ietf:plasma:data">
> >       <Attribute AttributeId=3D"urn:plasma:data-id"
IncludeInResult=3D"false">
> >         <AttributeValue
> > DataType=3D"http://www.w3.org/2001/XMLSchema#string">
> >           <GetCMSToken xmlns=3D"urn:ietf:schema:plasma:1.0">
> >             <Leaf
> PolicyId=3D"urn:example:policies:only-allow-recipients-to-decrypt-
> > this-email"/>
> >             <Hash>
> >               <DigestMethod xmlns=3D"http://www.w3.org/2000/09/xmldsig#=
"
> > Algorithm =3D"http://www.w3.org/2001/04/xmlenc#sha256"/>
> >               <DigestValue
> >
> xmlns=3D"http://www.w3.org/2000/09/xmldsig#">hrQkL07h1qZhPhgLXKlL0dV
> > eFLAbUVy0no05EGDzK2Q=3D</DigestValue>
> >             </Hash>
> >             <CEK>1BF2BEB249EE8EF2CB373E9800AC6F01</CEK>
> >           </GetCMSToken>
> >         </AttributeValue>
> >       </Attribute>
> >     </Attributes>
> >
> > <!-- Ed's NEW STUFF BEGINS HERE! -->
> >
> >     <Attributes Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-
> > category:access-subject">
> >       <Attribute
> AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > id"" IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> > type:rfc822Name">Alice@example.org</AttributeValue>
> >       </Attribute>
> >       <Attribute
> AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > id"" IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> > type:rfc822Name">Bob@example.org</AttributeValue>
> >       </Attribute>
> >       <Attribute
> AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > id"" IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> > type:rfc822Name">Carl@example.org</AttributeValue>
> >       </Attribute>
> >     </Attributes>
> >
> >     <Attributes
> > Category=3D"urn:example:some-other-attributes-related-to-
> > processing-this-policy">
> >       <Attribute AttributeId=3D"urn:example:something-1"
> > IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:example:something-1-
> > format">SomethingSomethingSomethingSomething</AttributeValue>
> >       </Attribute>
> >       <Attribute AttributeId=3D"urn:example:something-2"
> > IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:example:something-2-
> >
>
format">asldkjfalskdjf32434534543dfjalkscxvkljzv2309080kjlkjlkj</AttributeV
> > alue>
> >       </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=3Dbasic 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.htm
> > > > > l
> > > > >
> > > > > ...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=3D0.
> > > >
> > > > 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 mailing list
> > plasma@ietf.org
> > https://www.ietf.org/mailman/listinfo/plasma


From trevorf@exchange.microsoft.com  Thu Jan  3 11:14:45 2013
Return-Path: <trevorf@exchange.microsoft.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 6751421F8CC8 for <plasma@ietfa.amsl.com>; Thu,  3 Jan 2013 11:14:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.51
X-Spam-Level: 
X-Spam-Status: No, score=-100.51 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_65=0.6, USER_IN_WHITELIST=-100]
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 kttqCnkcXthL for <plasma@ietfa.amsl.com>; Thu,  3 Jan 2013 11:14:25 -0800 (PST)
Received: from NA01-SN2-obe.outbound.o365filtering.com (na01-sn2-obe.ptr.o365filtering.com [157.55.158.27]) by ietfa.amsl.com (Postfix) with ESMTP id C8FE621F8A67 for <plasma@ietf.org>; Thu,  3 Jan 2013 11:14:05 -0800 (PST)
Received: from BY2SR01CA102.namsdf01.sdf.exchangelabs.com (10.255.93.147) by BY2SR01MB608.namsdf01.sdf.exchangelabs.com (10.255.93.167) with Microsoft SMTP Server (TLS) id 15.0.601.0; Thu, 3 Jan 2013 19:13:52 +0000
Received: from SN2FFOFD004.ffo.gbl (157.55.158.24) by BY2SR01CA102.outlook.office365.com (10.255.93.147) with Microsoft SMTP Server (TLS) id 15.0.601.3 via Frontend Transport; Thu, 3 Jan 2013 19:13:52 +0000
Received: from hybrid.exchange.microsoft.com (131.107.1.17) by SN2FFOFD004.mail.o365filtering.com (10.111.201.41) with Microsoft SMTP Server (TLS) id 15.0.596.1 via Frontend Transport; Thu, 3 Jan 2013 19:13:51 +0000
Received: from df-h14-02.exchange.corp.microsoft.com (157.54.78.140) by DF-G14-01.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 14.3.118.0; Thu, 3 Jan 2013 11:12:27 -0800
Received: from PIO-MLT-06.exchange.corp.microsoft.com (157.54.94.24) by DF-H14-02.exchange.corp.microsoft.com (157.54.78.140) with Microsoft SMTP Server (TLS) id 14.3.118.0; Thu, 3 Jan 2013 11:12:27 -0800
Received: from DF-M14-10.exchange.corp.microsoft.com ([fe80::b076:a99f:3049:4c76]) by PIO-MLT-06.exchange.corp.microsoft.com ([fe80::d57f:521a:3ae6:c130%10]) with mapi id 14.03.0118.000; Thu, 3 Jan 2013 11:12:27 -0800
From: Trevor Freeman <trevorf@exchange.microsoft.com>
To: Ed Simon <Ed.Simon@titus.com>, Jim Schaad <ietf@augustcellars.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: AQHNyFx6QAEfHVE3SUizATOKHQdq7Jf7HC6sgAD9dYCAAs3ZgIA4UiaAgAApIICAAA2ogIAAwKfw
Date: Thu, 3 Jan 2013 19:12:26 +0000
Message-ID: <3020AC5E95452D43B5D8D0FB02F881D3162B90@DF-M14-10.exchange.corp.microsoft.com>
References: <DCD8C7A5A8B3E844AA2E2CBE327CDC92013DA1E7@E10MB3.tituscorp.local> <DCD8C7A5A8B3E844AA2E2CBE327CDC92013DB34F@E10MB3.tituscorp.local>, <014401cdcb92$21497b60$63dc7220$@augustcellars.com>, <DCD8C7A5A8B3E844AA2E2CBE327CDC92013DBE78@E10MB3.tituscorp.local> <DCD8C7A5A8B3E844AA2E2CBE327CDC92013E5BD9@E10MB3.tituscorp.local>, <004901cde936$b054ddb0$10fe9910$@augustcellars.com> <DCD8C7A5A8B3E844AA2E2CBE327CDC92013E5C75@E10MB3.tituscorp.local>
In-Reply-To: <DCD8C7A5A8B3E844AA2E2CBE327CDC92013E5C75@E10MB3.tituscorp.local>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.94.18]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.1.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464002)(377454001)(51704002)(4396001)(876001)(46102001)(33656001)(74662001)(44976002)(47446002)(51856001)(23726001)(15202345002)(74502001)(59766001)(47736001)(49866001)(76482001)(47976001)(56816002)(54316002)(55846006)(56776001)(5343635001)(5343655001)(16406001)(77982001)(50986001)(50466001)(54356001)(47776002)(53806001)(46406002)(31966008)(44824002); DIR:OUT; SFP:; SCL:1; SRVR:BY2SR01MB608; H:hybrid.exchange.microsoft.com; LANG:en; 
X-Forefront-PRVS: 071518EF63
X-OriginatorOrg: DuplicateDomain-6c178e33-aecb-4786-8220-9afceeddbaf3.exchange.microsoft.com
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, 03 Jan 2013 19:14:45 -0000

Plasma is policy expression neutral. It is a mechanism to control access to=
 data.  The policy which controls the access which was defined by the sende=
r may require a list of recipients for the data in questions. I don't see h=
ow a PIP would know who the recipients are for a message.=20

The sender calling GetCMSKey would know if the set of recipients is require=
d from the role token and can specify the list of 822 recipients to the Pla=
sma server in the request. However a recipient calling GetMessageKey can on=
ly pass in attributes as SAML attributes. A Plasma server may use BAE to es=
tablish the email address of the requestor e.g. the request contains a DN a=
nd the plasma server used the DN to look up the email attribute from a PIP.=
 Alternatively the Plasma server can reply with an indeterminate response r=
equesting the email attribute in which case the client needs to get a SAML =
token with the requested attribute from its PIP.=20

The defining distinction is that the list of recipients by the sender is se=
lf-asserted whereas the email address of the recipient is not.=20

>From a server perspective it is simpler if all the attributes in a request =
is a single place. A server is going to search the supplied attributes for =
the data it needs. It will not care if there is more there than it needs. Y=
ou don't need to tie the attributes to a specific policy.=20

PLASMA does not, by design, require that the authenticating party be implic=
itly considered also as a recipient. The authenticating party may be an age=
nt acting on behalf of the recipient - in which case there is minimal value=
 in their authentication.=20

Trevor

-----Original Message-----
From: Ed Simon [mailto:Ed.Simon@titus.com]=20
Sent: Wednesday, January 2, 2013 3:04 PM
To: Jim Schaad; Trevor Freeman; plasma@ietf.org
Subject: RE: [plasma] Clarification of how client applications handle the L=
ockBox in client in <plasma:GetCMSToken> elements

If a XACML policy includes, inter alia, a rule that requiring a that only r=
ecipients may read an email, then the XACML will require either that the ac=
cess subject be specified in the XACML request (as I have said below) or th=
at the identity of the access subject be accessible through a PIP; XACML, t=
o my recollection, makes no automatic assumption that the authenticating pa=
rty is the access subject party. If PLASMA is to require that the authentic=
ating party be implicitly considered also as a XACML access subject, then P=
LASMA needs to be explicit about that and perhaps describe the means throug=
h which that is to be accomplished wrt XACML -- would it not?

I do not see why it would be difficult for client apps to specify who the a=
ccess-requesting email recipient is through XACML attributes in the GetCMSK=
ey PLASMA request. That seems to me the easiest, most robust approach for b=
oth clients apps and policy servers.

My preference is for PLASMA to say that email recipients are to be specifie=
d as XACML access subjects in the XACML request part (as is the normal case=
 with XACML). If it is also deemed necessary to support the XACML PIP appro=
ach, we can do that too.=20

Ed

________________________________________
From: Jim Schaad [ietf@augustcellars.com]
Sent: Wednesday, January 02, 2013 17:15
To: Ed Simon; 'Trevor Freeman'; plasma@ietf.org
Subject: RE: [plasma] Clarification of how client applications handle the L=
ockBox in client in <plasma:GetCMSToken> elements

It would appear to me that not allowing for the identities asserted during =
the process of doing the authentication not being a default set of access s=
ubject attributes would be incorrect and would make life much harder.

For a simple policy one would still need to have a check that the access su=
bject attribute asserted by the client is allowed for the set of known iden=
tities for the subject.  While this makes sense if the policy is going to e=
xplicitly allow for impersonation, I think it is an unneeded burden on poli=
cy writers for the simplest of policies.

Why would disagree with assuming that the party named is the same as the ac=
cess subject unless a different access subject is explicitly stated by the =
client?

Jim


> -----Original Message-----
> From: Ed Simon [mailto:Ed.Simon@titus.com]
> Sent: Wednesday, January 02, 2013 11:48 AM
> To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> Subject: RE: [plasma] Clarification of how client applications handle=20
> the LockBox in client in <plasma:GetCMSToken> elements
>
> Following my prior email (see below), on the GetCMSKey side, any user-=20
> specified policy options (such as the list of recipients), which were
captured
> in the LockBox during the GetCMSToken call, would be evaluated against=20
> the XACML attributes specified in the GetCMSKey request. For example,=20
> a specific recipient would be specified through a XACML access subject=20
> (or perhaps XACML recipient subject) attribute. (Note that I would=20
> disagree
with
> assuming the party named, if any, in the authentication token is
necessarily
> an access subject or recipient subject).
>
> Thoughts?
>
> Ed
> ________________________________________
> From: Ed Simon
> Sent: Tuesday, November 27, 2012 18:43
> To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> Subject: RE: [plasma] Clarification of how client applications handle=20
> the LockBox in client in <plasma:GetCMSToken> elements
>
> Reworking the example, I've replaced <Leaf> with=20
> <Policy>/<PolicyOptions> (re-using the PolicyType structure defined=20
> for the GetRolesToken; but
using
> the PolicyID attribute and replacing the PolicyType <Name> element=20
> with <FriendlyName> (as per SAML)). It seems to me we the=20
> specification's text may not be quite clear on the distinction between=20
> the use of Policy(s) and Label/Leaf; it seems to me that Label/Leaf in=20
> GetCMSToken could be
logically
> replaced with the GetRolesToken PolicyType structure, though in a=20
> GetCMSToken request, the policy options would be specified by the=20
> sender (whereas in GetRolesToken, the <PolicyOptions> specifies what=20
> the sender needs to specify).
>
> For composite policies, I would rename the GetCMSToken <Label>=20
> structure with <PolicyCombiner AlgorithmId=3D"...">, thus completing the=
=20
> policy- oriented semantics and naming style.
>
> The above paragraphs may answer Jim's first question.
>
> The answer to the second question is that if the sender is specifying
policy
> options, which will later need to be used, on a GetCMSKey request from=20
> a recipient, then because the PLASMA server is stateless wrt specific=20
> messages, those options will need to be carried in the LockBox payload=20
> of the message. I suggest, and I think Jim was hinting he was=20
> considering
this a
> few weeks ago, that the content of the LockBox (labels/policies,=20
> namedRecipients, defaultRecipients, CEK, ...) be specified in terms of=20
> XML rather than ASN.1 and the ASN.1 LockBox be declared as UTF8String=20
> so it
can
> hold the XML contents (ASN.1 structures such a ASN.1 RecipientInfo(s)
could
> be stored as base64-encoded within the XML).
>
> Here's the latest rework of the example...
>
> >>>
>   <Request xmlns=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
> CombinedDecision=3D"false" ReturnPolicyIdList=3D"false">
>
>     <Attributes Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-
> category:action">
>       <Attribute AttributeId=3D"urn:plasma:action-id"
IncludeInResult=3D"false">
>         <AttributeValue
> DataType=3D"http://www.w3.org/2001/XMLSchema#string">GetCMSToken</
> AttributeValue>
>       </Attribute>
>     </Attributes>
>     <Attributes Category=3D"urn:ietf:plasma:data">
>       <Attribute AttributeId=3D"urn:plasma:data-id" IncludeInResult=3D"fa=
lse">
>         <AttributeValue
> DataType=3D"http://www.w3.org/2001/XMLSchema#string">
>           <GetCMSToken xmlns=3D"urn:ietf:schema:plasma:1.0">
>             <Policy
PolicyId=3D"urn:example:policies:only-allow-these-recipients-to-
> decrypt-this-email">
>               <FriendlyName>Only Allow These Recipients To Decrypt=20
> this Email</FriendlyName>
>               <PolicyOptions>
>
>               <!-- Specify parameters to the protection policy that=20
> the
user has
> specified here (note switch back to XACML namespace in this example,=20
> but contents of <PolicyParameters> could by in any namespace) -->
>
>     <Attributes Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-
> category:access-subject"
> xmlns=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
>       <Attribute
AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> id"" IncludeInResult=3D"false">
>         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> type:rfc822Name">Alice@example.org</AttributeValue>
>       </Attribute>
>       <Attribute
AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> id"" IncludeInResult=3D"false">
>         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> type:rfc822Name">Bob@example.org</AttributeValue>
>       </Attribute>
>       <Attribute
AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> id"" IncludeInResult=3D"false">
>         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> type:rfc822Name">Carl@example.org</AttributeValue>
>       </Attribute>
>     </Attributes>
>
>               </PolicyOptions>
>             </Policy>
>             <Hash>
>               <DigestMethod xmlns=3D"http://www.w3.org/2000/09/xmldsig#"
> Algorithm =3D"http://www.w3.org/2001/04/xmlenc#sha256"/>
>               <DigestValue
> xmlns=3D"http://www.w3.org/2000/09/xmldsig#">hrQkL07h1qZhPhgLXKlL0dV
> eFLAbUVy0no05EGDzK2Q=3D</DigestValue>
>             </Hash>
>             <CEK>1BF2BEB249EE8EF2CB373E9800AC6F01</CEK>
>           </GetCMSToken>
>         </AttributeValue>
>       </Attribute>
>     </Attributes>
>
>     <!-- Specify XACML attributes that may be used to determine=20
> whether
the
> user can execute the GetCMSToken request as regular XACML attributes=20
> (example below) -->
>
>     <Attributes=20
> Category=3D"urn:example:attributes-for-determining-whether-
> this-XACML-request-will-be-permitted">
>       <Attribute AttributeId=3D"urn:example:something-1"
> IncludeInResult=3D"false">
>         <AttributeValue DataType=3D"urn:example:something-1-
> format">SomethingSomethingSomethingSomething</AttributeValue>
>       </Attribute>
>       <Attribute AttributeId=3D"urn:example:something-2"
> IncludeInResult=3D"false">
>         <AttributeValue DataType=3D"urn:example:something-2-
>
format">asldkjfalskdjf32434534543dfjalkscxvkljzv2309080kjlkjlkj</AttributeV
> alue>
>       </Attribute>
>     </Attributes>
>
>   </Request>
> <<<
>
> Ed
> ________________________________________
> From: Jim Schaad [ietf@augustcellars.com]
> Sent: Sunday, November 25, 2012 23:54
> To: Ed Simon; 'Trevor Freeman'; plasma@ietf.org
> Subject: RE: [plasma] Clarification of how client applications handle=20
> the LockBox in client in <plasma:GetCMSToken> elements
>
> Ed,
>
> I agree with most of this, however there are two things
>
> 1.  Currently one can place an arbitrary structure inside of the Leaf
element.
> Do you believe that is insufficient or do we really need to have the=20
> extra layer of the <PolicyParameters> element added?
>
> 2.  At the end you say that there is a needed change to the LockBox
element.
> I am not clear what this change would be.  Is it the=20
> <PolicyParameters> element above or something else?
>
> Jim
>
>
> > -----Original Message-----
> > From: Ed Simon [mailto:Ed.Simon@titus.com]
> > Sent: Sunday, November 25, 2012 2:15 PM
> > To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> > Subject: RE: [plasma] Clarification of how client applications=20
> > handle the LockBox in client in <plasma:GetCMSToken> elements
> >
> > Upon pondering this further, I think it is important to distinguish
> between
> > attributes that act as parameters to the policy the user wishes to=20
> > 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=20
> > as
> part of
> > the PLASMA <GetCMSToken> element inside the <Leaf> child element=20
> > (which identifies the policy the user selects to govern the=20
> > message/document (should <Leaf> be renamed to <Policy> perhaps?)).
> >
> > For attributes that are used to determine whether the user can=20
> > perform a GetCMSToken request, these should be specified outside the=20
> > PLASMA <GetCMSToken> element.
> >
> > Reworking my prior example to reflect this design...
> >
> > >>>
> >   <Request xmlns=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
> > CombinedDecision=3D"false" ReturnPolicyIdList=3D"false">
> >
> >     <Attributes Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-
> > category:action">
> >       <Attribute AttributeId=3D"urn:plasma:action-id"
> IncludeInResult=3D"false">
> >         <AttributeValue
> >
> DataType=3D"http://www.w3.org/2001/XMLSchema#string">GetCMSToken</
> > AttributeValue>
> >       </Attribute>
> >     </Attributes>
> >     <Attributes Category=3D"urn:ietf:plasma:data">
> >       <Attribute AttributeId=3D"urn:plasma:data-id"
IncludeInResult=3D"false">
> >         <AttributeValue
> > DataType=3D"http://www.w3.org/2001/XMLSchema#string">
> >           <GetCMSToken xmlns=3D"urn:ietf:schema:plasma:1.0">
> >             <Leaf
> PolicyId=3D"urn:example:policies:only-allow-these-recipients-to-
> > decrypt-this-email">
> >               <PolicyParameters>
> >
> >               <!-- Specify parameters to the protection policy that=20
> > the
> user has
> > specified here (note switch back to XACML namespace in this example,=20
> > but contents of <PolicyParameters> could by in any namespace) -->
> >
> >     <Attributes Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-
> > category:access-subject"
> > xmlns=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
> >       <Attribute
> AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > id"" IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> > type:rfc822Name">Alice@example.org</AttributeValue>
> >       </Attribute>
> >       <Attribute
> AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > id"" IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> > type:rfc822Name">Bob@example.org</AttributeValue>
> >       </Attribute>
> >       <Attribute
> AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > id"" IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> > type:rfc822Name">Carl@example.org</AttributeValue>
> >       </Attribute>
> >     </Attributes>
> >
> >               </PolicyParameters>
> >             </Leaf>
> >             <Hash>
> >               <DigestMethod xmlns=3D"http://www.w3.org/2000/09/xmldsig#=
"
> > Algorithm =3D"http://www.w3.org/2001/04/xmlenc#sha256"/>
> >               <DigestValue
> >
> xmlns=3D"http://www.w3.org/2000/09/xmldsig#">hrQkL07h1qZhPhgLXKlL0dV
> > eFLAbUVy0no05EGDzK2Q=3D</DigestValue>
> >             </Hash>
> >             <CEK>1BF2BEB249EE8EF2CB373E9800AC6F01</CEK>
> >           </GetCMSToken>
> >         </AttributeValue>
> >       </Attribute>
> >     </Attributes>
> >
> >     <!-- Specify XACML attributes that may be used to determine=20
> > whether
> the
> > user can execute the GetCMSToken request as regular XACML attributes=20
> > (example below) -->
> >
> >     <Attributes
> > Category=3D"urn:example:attributes-for-determining-whether-
> > this-XACML-request-will-be-permitted">
> >       <Attribute AttributeId=3D"urn:example:something-1"
> > IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:example:something-1-
> > format">SomethingSomethingSomethingSomething</AttributeValue>
> >       </Attribute>
> >       <Attribute AttributeId=3D"urn:example:something-2"
> > IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:example:something-2-
> >
>
format">asldkjfalskdjf32434534543dfjalkscxvkljzv2309080kjlkjlkj</AttributeV
> > alue>
> >       </Attribute>
> >     </Attributes>
> >
> >   </Request>
> > <<<
> >
> > Because of the stateless nature of PLASMA, there would also need to=20
> > be a corresponding change to PLASMA-defined LockBox structure for=20
> > the label/policy in order to store the policy parameter information.
> >
> > Ed
> > ________________________________________
> > From: plasma-bounces@ietf.org [plasma-bounces@ietf.org] on behalf of=20
> > Ed Simon [Ed.Simon@titus.com]
> > Sent: Wednesday, November 21, 2012 21:52
> > To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> > Subject: Re: [plasma] Clarification of how client applications=20
> > handle the LockBox in client in <plasma:GetCMSToken> elements
> >
> > I propose, as a strawman proposal, that when policies require the=20
> > sender's recipient list, they should be specified through XACML=20
> > access-subject attributes, NOT PLASMA-specific attributes (e.g.=20
> > within <plasma:GetCMSToken>). My position would be that PLASMA=20
> > should only supplement XACML's pre-defined attributes where=20
> > necessary, not create PLASMA-specified attributes where existing=20
> > XACML-specified attributes are already defined and are sufficient.=20
> > Hence my position at the moment is I would NOT change the current=20
> > PLASMA semantics of <plasma:Recipient> which is specifically for=20
> > specifying a lockbox for a recipient (though I
> agree
> > with Jim that the name of the element should be changed to=20
> > <LockBoxes> to avoid confusion) and, instead indicate in the=20
> > 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=20
> > which specifies the recipients through XACML access-subject att  ribute=
s.
> >
> > 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,=20
> > 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=20
> > the list of recipients and other info could look like this...
> >
> >   <Request xmlns=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
> > CombinedDecision=3D"false" ReturnPolicyIdList=3D"false">
> >     <Attributes Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-
> > category:action">
> >       <Attribute AttributeId=3D"urn:plasma:action-id"
> IncludeInResult=3D"false">
> >         <AttributeValue
> >
> DataType=3D"http://www.w3.org/2001/XMLSchema#string">GetCMSToken</
> > AttributeValue>
> >       </Attribute>
> >     </Attributes>
> >     <Attributes Category=3D"urn:ietf:plasma:data">
> >       <Attribute AttributeId=3D"urn:plasma:data-id"
IncludeInResult=3D"false">
> >         <AttributeValue
> > DataType=3D"http://www.w3.org/2001/XMLSchema#string">
> >           <GetCMSToken xmlns=3D"urn:ietf:schema:plasma:1.0">
> >             <Leaf
> PolicyId=3D"urn:example:policies:only-allow-recipients-to-decrypt-
> > this-email"/>
> >             <Hash>
> >               <DigestMethod xmlns=3D"http://www.w3.org/2000/09/xmldsig#=
"
> > Algorithm =3D"http://www.w3.org/2001/04/xmlenc#sha256"/>
> >               <DigestValue
> >
> xmlns=3D"http://www.w3.org/2000/09/xmldsig#">hrQkL07h1qZhPhgLXKlL0dV
> > eFLAbUVy0no05EGDzK2Q=3D</DigestValue>
> >             </Hash>
> >             <CEK>1BF2BEB249EE8EF2CB373E9800AC6F01</CEK>
> >           </GetCMSToken>
> >         </AttributeValue>
> >       </Attribute>
> >     </Attributes>
> >
> > <!-- Ed's NEW STUFF BEGINS HERE! -->
> >
> >     <Attributes Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-
> > category:access-subject">
> >       <Attribute
> AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > id"" IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> > type:rfc822Name">Alice@example.org</AttributeValue>
> >       </Attribute>
> >       <Attribute
> AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > id"" IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> > type:rfc822Name">Bob@example.org</AttributeValue>
> >       </Attribute>
> >       <Attribute
> AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > id"" IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> > type:rfc822Name">Carl@example.org</AttributeValue>
> >       </Attribute>
> >     </Attributes>
> >
> >     <Attributes
> > Category=3D"urn:example:some-other-attributes-related-to-
> > processing-this-policy">
> >       <Attribute AttributeId=3D"urn:example:something-1"
> > IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:example:something-1-
> > format">SomethingSomethingSomethingSomething</AttributeValue>
> >       </Attribute>
> >       <Attribute AttributeId=3D"urn:example:something-2"
> > IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:example:something-2-
> >
>
format">asldkjfalskdjf32434534543dfjalkscxvkljzv2309080kjlkjlkj</AttributeV
> > alue>
> >       </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=20
> > 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=20
> > during
> processing
> > (for example mail list expansion) does that change the original=20
> > policy set
> by
> > the sender?
> >
> > I should have called the structure <LockBoxes> rather than=20
> > <Recipients> to prevent the confusion.  However, I can see that this=20
> > could be an input
> that is
> > of interest to the policy.  However doing so means that we have to=20
> > figure
> out
> > what it means in a number of different cases that I am currently not=20
> > 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=20
> > > 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=20
> > > seems pointless duplication to include the list of recipients as=20
> > > 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=20
> > > lock box element is optional, we can use the same structure for=20
> > > both #1 and
> > > #2
> > below
> > > i.e. if I just want a recipient list with no lock boxes or if I=20
> > > 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=20
> > > 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=20
> > > > 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.=20
> > > > While one or
> > > more
> > > > policies may require the list be supplied; only one list would=20
> > > > 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=20
> > > 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=20
> > > allowing it to determine who gets the CEK back.
> > >
> > > 3.  A recipient lists specific to email may be provided as part of=20
> > > the
> > input data.
> > > This behavior (perhaps not currently in the document) is provided=20
> > > for the purpose of doing pre-authorization of gateways and is=20
> > > specific to
> email.
> > >
> > >
> > > Currently the above is better expressed as
> > >
> > > Policy=3Dbasic Policy
> > > BasicPolicy Recipient List is "lisa@simpsons.com bart@simpsons.com"
> > >
> > > Jim
> > >
> > > >
> > > > Policies may also require that lock boxes be generated for=20
> > > > receipts rather than supply the CEK to the Plasma server. In=20
> > > > that instance, the list of
> > > receipts
> > > > together with the associated lock box would be included in the=20
> > > > 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]=20
> > > > 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=20
> > > > handle the LockBox in client in <plasma:GetCMSToken> elements
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org]=20
> > > > > 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=20
> > > > > 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.htm
> > > > > l
> > > > >
> > > > > ...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=20
> > > > > Scenario B in
> > > > which
> > > > > the Sending Agent leaves it to the PLASMA Server to construct=20
> > > > > a LockBox
> > > > for
> > > > > a named recipient, sound reasonable? Scenario B follows from=20
> > > > > 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=20
> > > > > knows
> > the
> > > > >    appropriate keying material."
> > > > > in the PLASMA Service CMS Processing v2 document.
> > > >
> > > > This text is intended to deal with the case of creating=20
> > > > lockboxes for
> > > entities
> > > > such as virus checking gateways in a mail system.  The lockboxes=20
> > > > that are being returned with here are placed parallel to the=20
> > > > Plasma Lockbox in the CMS Enveloped data object and are not=20
> > > > 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=20
> > > > > PLASMA server and specifies a limited set of recipients who=20
> > > > > can decrypt the
> > > > message
> > > > > (for example, due to section 7.2.2 of PLASMA Service Trust=20
> > > > > 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=20
> > > > > <LockBox> element to contain the encrypted CEK for that=20
> > > > > 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=20
> > > > > described in PLASMA Service CMS Processing v2). The LockBox=20
> > > > > constructed by the PLASMA Server will comprise, in the=20
> > > > > 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=20
> > > > > able, barring
> > > > further
> > > > > communication with the Sending Agent, be able to supplement=20
> > > > > the list of recipients.
> > > >
> > > > This looks correct
> > > >
> > > > >
> > > > > Scenario B: The sender shares the CEK with the PLASMA server=20
> > > > > and specifies a limited set of recipients who can decrypt the=20
> > > > > message (for example,
> > > > again,
> > > > > due to section 7.2.2 of PLASMA Trust processing). For each=20
> > > > > recipient specified, there may or may not be a LockBox=20
> > > > > 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,=20
> > > > > optionally, the <LockBox> element to contain the encrypted CEK=20
> > > > > for that recipient (encrypted so only that recipient can=20
> > > > > 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=20
> > > > > by the Sending Agent, it will be treated as in Scenario A;=20
> > > > > otherwise, the PLASMA Server will create a LockBox for that=20
> > > > > recipient to populate the namedRecipients structure. It will=20
> > > > > also create a defaultRecipients
> > > > structure
> > > > > using the CEK provided by the Sending Agent. Note that in this=20
> > > > > scenario,
> > > > the
> > > > > PLASMA Server will be able to, independently of the Sending=20
> > > > > Agent, be able to supplement the list of recipients.
> > > > >
> > > > > Note that for Scenario B, the schema definition for the=20
> > > > > <LockBox> element will need to have the attribute minOccurs=3D0.
> > > >
> > > > This is not currently an envisioned scenario in terms of the=20
> > > > Plasma server creating the lock boxes at send time.  Currently=20
> > > > if there is a list of
> > > recipients
> > > > that the sender does not create lockboxes for, it is envisioned=20
> > > > that this
> > > would
> > > > be handled as part of the policy set on the message.  The Plasma=20
> > > > server would then deal with potentially creating a lock box (as=20
> > > > 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=20
> > > > > server and does NOT specify any recipients.
> > > > >
> > > > > Sending Agent: The Sending Agent will also construct a <CEK>=20
> > > > > element to contain the CEK; no <Recipient> element will be
created.
> > > > >
> > > > > PLASMA Server: The PLASMA Server will also create a=20
> > > > > defaultRecipients structure using the CEK provided by the=20
> > > > > Sending Agent; it may or may not create a namedRecipients=20
> > > > > structure (populated independently of the Sending Agent). As=20
> > > > > in Scenario B, the PLASMA Server will be able to,=20
> > > > > independently of the Sending Agent, be able to supplement the lis=
t 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 mailing list
> > plasma@ietf.org
> > https://www.ietf.org/mailman/listinfo/plasma


From ietf@augustcellars.com  Thu Jan  3 11:34:51 2013
Return-Path: <ietf@augustcellars.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 9094121F8CFF for <plasma@ietfa.amsl.com>; Thu,  3 Jan 2013 11:34:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level: 
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1]
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 LbRhoBfDn1rF for <plasma@ietfa.amsl.com>; Thu,  3 Jan 2013 11:34:49 -0800 (PST)
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 36E0E21F8C6F for <plasma@ietf.org>; Thu,  3 Jan 2013 11:34:49 -0800 (PST)
Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 8B1E438F38; Thu,  3 Jan 2013 11:34:45 -0800 (PST)
From: "Jim Schaad" <ietf@augustcellars.com>
To: "'Ed Simon'" <Ed.Simon@titus.com>, "'Trevor Freeman'" <trevorf@exchange.microsoft.com>, <plasma@ietf.org>
References: <DCD8C7A5A8B3E844AA2E2CBE327CDC92013DA1E7@E10MB3.tituscorp.local> <DCD8C7A5A8B3E844AA2E2CBE327CDC92013DB34F@E10MB3.tituscorp.local>, <014401cdcb92$21497b60$63dc7220$@augustcellars.com>, <DCD8C7A5A8B3E844AA2E2CBE327CDC92013DBE78@E10MB3.tituscorp.local> <DCD8C7A5A8B3E844AA2E2CBE327CDC92013E5BD9@E10MB3.tituscorp.local>, <004901cde936$b054ddb0$10fe9910$@augustcellars.com> <DCD8C7A5A8B3E844AA2E2CBE327CDC92013E5C75@E10MB3.tituscorp.local>
In-Reply-To: <DCD8C7A5A8B3E844AA2E2CBE327CDC92013E5C75@E10MB3.tituscorp.local>
Date: Thu, 3 Jan 2013 11:34:26 -0800
Message-ID: <009201cde9e9$5791d800$06b58800$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHZToL2iFv9G069c1ZHgVd517VEZAK80yWoAZEmD6kCdhm+DgLAYmehASwA9VsCk/lBaJe3EZxQ
Content-Language: en-us
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, 03 Jan 2013 19:34:51 -0000

What is your feelings about the other attributes that are currently
transmitted in SAML statements that are going to be used as inputs to the
decision making process?

If the policy wants to check the company name, are you expecting the name to
be supplied by the client and then somehow checked by the server or does the
server extract it from the provided SAML statement that was used for
authentication and input it into the policy decision system?

I guess from my point of view, yes there will always be a PIP and the Plasma
server can be the PIP

Jim


> -----Original Message-----
> From: Ed Simon [mailto:Ed.Simon@titus.com]
> Sent: Wednesday, January 02, 2013 3:04 PM
> To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> Subject: RE: [plasma] Clarification of how client applications handle the
> LockBox in client in <plasma:GetCMSToken> elements
> 
> If a XACML policy includes, inter alia, a rule that requiring a that only
> recipients may read an email, then the XACML will require either that the
> access subject be specified in the XACML request (as I have said below) or
> that the identity of the access subject be accessible through a PIP;
XACML, to
> my recollection, makes no automatic assumption that the authenticating
> party is the access subject party. If PLASMA is to require that the
> authenticating party be implicitly considered also as a XACML access
subject,
> then PLASMA needs to be explicit about that and perhaps describe the
> means through which that is to be accomplished wrt XACML -- would it not?
> 
> I do not see why it would be difficult for client apps to specify who the
> access-requesting email recipient is through XACML attributes in the
> GetCMSKey PLASMA request. That seems to me the easiest, most robust
> approach for both clients apps and policy servers.
> 
> My preference is for PLASMA to say that email recipients are to be
specified
> as XACML access subjects in the XACML request part (as is the normal case
> with XACML). If it is also deemed necessary to support the XACML PIP
> approach, we can do that too.
> 
> Ed
> 
> ________________________________________
> From: Jim Schaad [ietf@augustcellars.com]
> Sent: Wednesday, January 02, 2013 17:15
> To: Ed Simon; 'Trevor Freeman'; plasma@ietf.org
> Subject: RE: [plasma] Clarification of how client applications handle the
> LockBox in client in <plasma:GetCMSToken> elements
> 
> It would appear to me that not allowing for the identities asserted during
the
> process of doing the authentication not being a default set of access
subject
> attributes would be incorrect and would make life much harder.
> 
> For a simple policy one would still need to have a check that the access
> subject attribute asserted by the client is allowed for the set of known
> identities for the subject.  While this makes sense if the policy is going
to
> explicitly allow for impersonation, I think it is an unneeded burden on
policy
> writers for the simplest of policies.
> 
> Why would disagree with assuming that the party named is the same as the
> access subject unless a different access subject is explicitly stated by
the
> client?
> 
> Jim
> 
> 
> > -----Original Message-----
> > From: Ed Simon [mailto:Ed.Simon@titus.com]
> > Sent: Wednesday, January 02, 2013 11:48 AM
> > To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> > Subject: RE: [plasma] Clarification of how client applications handle
> > the LockBox in client in <plasma:GetCMSToken> elements
> >
> > Following my prior email (see below), on the GetCMSKey side, any user-
> > specified policy options (such as the list of recipients), which were
> captured
> > in the LockBox during the GetCMSToken call, would be evaluated against
> > the XACML attributes specified in the GetCMSKey request. For example,
> > a specific recipient would be specified through a XACML access subject
> > (or perhaps XACML recipient subject) attribute. (Note that I would
> > disagree
> with
> > assuming the party named, if any, in the authentication token is
> necessarily
> > an access subject or recipient subject).
> >
> > Thoughts?
> >
> > Ed
> > ________________________________________
> > From: Ed Simon
> > Sent: Tuesday, November 27, 2012 18:43
> > To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> > Subject: RE: [plasma] Clarification of how client applications handle
> > the LockBox in client in <plasma:GetCMSToken> elements
> >
> > Reworking the example, I've replaced <Leaf> with
> > <Policy>/<PolicyOptions> (re-using the PolicyType structure defined
> > for the GetRolesToken; but
> using
> > the PolicyID attribute and replacing the PolicyType <Name> element
> > with <FriendlyName> (as per SAML)). It seems to me we the
> > specification's text may not be quite clear on the distinction between
> > the use of Policy(s) and Label/Leaf; it seems to me that Label/Leaf in
> > GetCMSToken could be
> logically
> > replaced with the GetRolesToken PolicyType structure, though in a
> > GetCMSToken request, the policy options would be specified by the
> > sender (whereas in GetRolesToken, the <PolicyOptions> specifies what
> > the sender needs to specify).
> >
> > For composite policies, I would rename the GetCMSToken <Label>
> > structure with <PolicyCombiner AlgorithmId="...">, thus completing the
> > policy- oriented semantics and naming style.
> >
> > The above paragraphs may answer Jim's first question.
> >
> > The answer to the second question is that if the sender is specifying
> policy
> > options, which will later need to be used, on a GetCMSKey request from
> > a recipient, then because the PLASMA server is stateless wrt specific
> > messages, those options will need to be carried in the LockBox payload
> > of the message. I suggest, and I think Jim was hinting he was
> > considering
> this a
> > few weeks ago, that the content of the LockBox (labels/policies,
> > namedRecipients, defaultRecipients, CEK, ...) be specified in terms of
> > XML rather than ASN.1 and the ASN.1 LockBox be declared as UTF8String
> > so it
> can
> > hold the XML contents (ASN.1 structures such a ASN.1 RecipientInfo(s)
> could
> > be stored as base64-encoded within the XML).
> >
> > Here's the latest rework of the example...
> >
> > >>>
> >   <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">
> >             <Policy
> PolicyId="urn:example:policies:only-allow-these-recipients-to-
> > decrypt-this-email">
> >               <FriendlyName>Only Allow These Recipients To Decrypt
> > this Email</FriendlyName>
> >               <PolicyOptions>
> >
> >               <!-- 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">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>
> >
> >               </PolicyOptions>
> >             </Policy>
> >             <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#">hrQkL07h1qZhPhgLXKlL0dV
> > eFLAbUVy0no05EGDzK2Q=</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</AttributeV
> > alue>
> >       </Attribute>
> >     </Attributes>
> >
> >   </Request>
> > <<<
> >
> > Ed
> > ________________________________________
> > From: Jim Schaad [ietf@augustcellars.com]
> > Sent: Sunday, November 25, 2012 23:54
> > To: Ed Simon; 'Trevor Freeman'; plasma@ietf.org
> > Subject: RE: [plasma] Clarification of how client applications handle
> > the LockBox in client in <plasma:GetCMSToken> elements
> >
> > Ed,
> >
> > I agree with most of this, however there are two things
> >
> > 1.  Currently one can place an arbitrary structure inside of the Leaf
> element.
> > Do you believe that is insufficient or do we really need to have the
> > extra layer of the <PolicyParameters> element added?
> >
> > 2.  At the end you say that there is a needed change to the LockBox
> element.
> > I am not clear what this change would be.  Is it the
> > <PolicyParameters> element above or something else?
> >
> > Jim
> >
> >
> > > -----Original Message-----
> > > From: Ed Simon [mailto:Ed.Simon@titus.com]
> > > Sent: Sunday, November 25, 2012 2:15 PM
> > > To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> > > Subject: RE: [plasma] Clarification of how client applications
> > > handle the LockBox in client in <plasma:GetCMSToken> elements
> > >
> > > 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">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>
> > >
> > >               </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#">hrQkL07h1qZhPhgLXKlL0dV
> > > eFLAbUVy0no05EGDzK2Q=</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</AttributeV
> > > alue>
> > >       </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: plasma-bounces@ietf.org [plasma-bounces@ietf.org] on behalf of
> > > Ed Simon [Ed.Simon@titus.com]
> > > Sent: Wednesday, November 21, 2012 21:52
> > > To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> > > 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#">hrQkL07h1qZhPhgLXKlL0dV
> > > eFLAbUVy0no05EGDzK2Q=</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</AttributeV
> > > alue>
> > >       </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.htm
> > > > > > l
> > > > > >
> > > > > > ...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 mailing list
> > > plasma@ietf.org
> > > https://www.ietf.org/mailman/listinfo/plasma


From ietf@augustcellars.com  Thu Jan  3 11:35:57 2013
Return-Path: <ietf@augustcellars.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 D925921F8CFF for <plasma@ietfa.amsl.com>; Thu,  3 Jan 2013 11:35:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level: 
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1]
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 0tHi6Z0CmT0A for <plasma@ietfa.amsl.com>; Thu,  3 Jan 2013 11:35:54 -0800 (PST)
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCE821F8D02 for <plasma@ietf.org>; Thu,  3 Jan 2013 11:35:54 -0800 (PST)
Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 6540C38F12; Thu,  3 Jan 2013 11:35:53 -0800 (PST)
From: "Jim Schaad" <ietf@augustcellars.com>
To: "'Trevor Freeman'" <trevorf@exchange.microsoft.com>, "'Ed Simon'" <Ed.Simon@titus.com>, <plasma@ietf.org>
References: <DCD8C7A5A8B3E844AA2E2CBE327CDC92013DA1E7@E10MB3.tituscorp.local> <DCD8C7A5A8B3E844AA2E2CBE327CDC92013DB34F@E10MB3.tituscorp.local>, <014401cdcb92$21497b60$63dc7220$@augustcellars.com>, <DCD8C7A5A8B3E844AA2E2CBE327CDC92013DBE78@E10MB3.tituscorp.local> <DCD8C7A5A8B3E844AA2E2CBE327CDC92013E5BD9@E10MB3.tituscorp.local>, <004901cde936$b054ddb0$10fe9910$@augustcellars.com> <DCD8C7A5A8B3E844AA2E2CBE327CDC92013E5C75@E10MB3.tituscorp.local> <3020AC5E95452D43B5D8D0FB02F881D3162B90@DF-M14-10.exchange.corp.microsoft.com>
In-Reply-To: <3020AC5E95452D43B5D8D0FB02F881D3162B90@DF-M14-10.exchange.corp.microsoft.com>
Date: Thu, 3 Jan 2013 11:35:33 -0800
Message-ID: <009301cde9e9$80069820$8013c860$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHZToL2iFv9G069c1ZHgVd517VEZAK80yWoAZEmD6kCdhm+DgLAYmehASwA9VsCk/lBaAKuMoIyl6GgnWA=
Content-Language: en-us
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, 03 Jan 2013 19:35:57 -0000

> -----Original Message-----
> From: Trevor Freeman [mailto:trevorf@exchange.microsoft.com]
> Sent: Thursday, January 03, 2013 11:12 AM
> To: Ed Simon; Jim Schaad; plasma@ietf.org
> Subject: RE: [plasma] Clarification of how client applications handle the
> LockBox in client in <plasma:GetCMSToken> elements
> 
> Plasma is policy expression neutral. It is a mechanism to control access
to
> data.  The policy which controls the access which was defined by the
sender
> may require a list of recipients for the data in questions. I don't see
how a PIP
> would know who the recipients are for a message.
> 
> The sender calling GetCMSKey would know if the set of recipients is
required
> from the role token and can specify the list of 822 recipients to the
Plasma
> server in the request. However a recipient calling GetMessageKey can only
> pass in attributes as SAML attributes. A Plasma server may use BAE to
> establish the email address of the requestor e.g. the request contains a
DN
> and the plasma server used the DN to look up the email attribute from a
PIP.
> Alternatively the Plasma server can reply with an indeterminate response
> requesting the email attribute in which case the client needs to get a
SAML
> token with the requested attribute from its PIP.

The sender making the GetCMSKey call would never know if the set of
recipients is required.   Currently the set of policies on a message is not
exposed to the client and thus the client would have no way of determining
this.  Remember we are talking here about reading a message not sending a
message.

Jim

> 
> The defining distinction is that the list of recipients by the sender is
self-
> asserted whereas the email address of the recipient is not.
> 
> From a server perspective it is simpler if all the attributes in a request
is a
> single place. A server is going to search the supplied attributes for the
data it
> needs. It will not care if there is more there than it needs. You don't
need to
> tie the attributes to a specific policy.
> 
> PLASMA does not, by design, require that the authenticating party be
> implicitly considered also as a recipient. The authenticating party may be
an
> agent acting on behalf of the recipient - in which case there is minimal
value
> in their authentication.
> 
> Trevor
> 
> -----Original Message-----
> From: Ed Simon [mailto:Ed.Simon@titus.com]
> Sent: Wednesday, January 2, 2013 3:04 PM
> To: Jim Schaad; Trevor Freeman; plasma@ietf.org
> Subject: RE: [plasma] Clarification of how client applications handle the
> LockBox in client in <plasma:GetCMSToken> elements
> 
> If a XACML policy includes, inter alia, a rule that requiring a that only
> recipients may read an email, then the XACML will require either that the
> access subject be specified in the XACML request (as I have said below) or
> that the identity of the access subject be accessible through a PIP;
XACML, to
> my recollection, makes no automatic assumption that the authenticating
> party is the access subject party. If PLASMA is to require that the
> authenticating party be implicitly considered also as a XACML access
subject,
> then PLASMA needs to be explicit about that and perhaps describe the
> means through which that is to be accomplished wrt XACML -- would it not?
> 
> I do not see why it would be difficult for client apps to specify who the
> access-requesting email recipient is through XACML attributes in the
> GetCMSKey PLASMA request. That seems to me the easiest, most robust
> approach for both clients apps and policy servers.
> 
> My preference is for PLASMA to say that email recipients are to be
specified
> as XACML access subjects in the XACML request part (as is the normal case
> with XACML). If it is also deemed necessary to support the XACML PIP
> approach, we can do that too.
> 
> Ed
> 
> ________________________________________
> From: Jim Schaad [ietf@augustcellars.com]
> Sent: Wednesday, January 02, 2013 17:15
> To: Ed Simon; 'Trevor Freeman'; plasma@ietf.org
> Subject: RE: [plasma] Clarification of how client applications handle the
> LockBox in client in <plasma:GetCMSToken> elements
> 
> It would appear to me that not allowing for the identities asserted during
the
> process of doing the authentication not being a default set of access
subject
> attributes would be incorrect and would make life much harder.
> 
> For a simple policy one would still need to have a check that the access
> subject attribute asserted by the client is allowed for the set of known
> identities for the subject.  While this makes sense if the policy is going
to
> explicitly allow for impersonation, I think it is an unneeded burden on
policy
> writers for the simplest of policies.
> 
> Why would disagree with assuming that the party named is the same as the
> access subject unless a different access subject is explicitly stated by
the
> client?
> 
> Jim
> 
> 
> > -----Original Message-----
> > From: Ed Simon [mailto:Ed.Simon@titus.com]
> > Sent: Wednesday, January 02, 2013 11:48 AM
> > To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> > Subject: RE: [plasma] Clarification of how client applications handle
> > the LockBox in client in <plasma:GetCMSToken> elements
> >
> > Following my prior email (see below), on the GetCMSKey side, any user-
> > specified policy options (such as the list of recipients), which were
> captured
> > in the LockBox during the GetCMSToken call, would be evaluated against
> > the XACML attributes specified in the GetCMSKey request. For example,
> > a specific recipient would be specified through a XACML access subject
> > (or perhaps XACML recipient subject) attribute. (Note that I would
> > disagree
> with
> > assuming the party named, if any, in the authentication token is
> necessarily
> > an access subject or recipient subject).
> >
> > Thoughts?
> >
> > Ed
> > ________________________________________
> > From: Ed Simon
> > Sent: Tuesday, November 27, 2012 18:43
> > To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> > Subject: RE: [plasma] Clarification of how client applications handle
> > the LockBox in client in <plasma:GetCMSToken> elements
> >
> > Reworking the example, I've replaced <Leaf> with
> > <Policy>/<PolicyOptions> (re-using the PolicyType structure defined
> > for the GetRolesToken; but
> using
> > the PolicyID attribute and replacing the PolicyType <Name> element
> > with <FriendlyName> (as per SAML)). It seems to me we the
> > specification's text may not be quite clear on the distinction between
> > the use of Policy(s) and Label/Leaf; it seems to me that Label/Leaf in
> > GetCMSToken could be
> logically
> > replaced with the GetRolesToken PolicyType structure, though in a
> > GetCMSToken request, the policy options would be specified by the
> > sender (whereas in GetRolesToken, the <PolicyOptions> specifies what
> > the sender needs to specify).
> >
> > For composite policies, I would rename the GetCMSToken <Label>
> > structure with <PolicyCombiner AlgorithmId="...">, thus completing the
> > policy- oriented semantics and naming style.
> >
> > The above paragraphs may answer Jim's first question.
> >
> > The answer to the second question is that if the sender is specifying
> policy
> > options, which will later need to be used, on a GetCMSKey request from
> > a recipient, then because the PLASMA server is stateless wrt specific
> > messages, those options will need to be carried in the LockBox payload
> > of the message. I suggest, and I think Jim was hinting he was
> > considering
> this a
> > few weeks ago, that the content of the LockBox (labels/policies,
> > namedRecipients, defaultRecipients, CEK, ...) be specified in terms of
> > XML rather than ASN.1 and the ASN.1 LockBox be declared as UTF8String
> > so it
> can
> > hold the XML contents (ASN.1 structures such a ASN.1 RecipientInfo(s)
> could
> > be stored as base64-encoded within the XML).
> >
> > Here's the latest rework of the example...
> >
> > >>>
> >   <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">
> >             <Policy
> PolicyId="urn:example:policies:only-allow-these-recipients-to-
> > decrypt-this-email">
> >               <FriendlyName>Only Allow These Recipients To Decrypt
> > this Email</FriendlyName>
> >               <PolicyOptions>
> >
> >               <!-- 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">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>
> >
> >               </PolicyOptions>
> >             </Policy>
> >             <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#">hrQkL07h1qZhPhgLXKlL0dV
> > eFLAbUVy0no05EGDzK2Q=</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</AttributeV
> > alue>
> >       </Attribute>
> >     </Attributes>
> >
> >   </Request>
> > <<<
> >
> > Ed
> > ________________________________________
> > From: Jim Schaad [ietf@augustcellars.com]
> > Sent: Sunday, November 25, 2012 23:54
> > To: Ed Simon; 'Trevor Freeman'; plasma@ietf.org
> > Subject: RE: [plasma] Clarification of how client applications handle
> > the LockBox in client in <plasma:GetCMSToken> elements
> >
> > Ed,
> >
> > I agree with most of this, however there are two things
> >
> > 1.  Currently one can place an arbitrary structure inside of the Leaf
> element.
> > Do you believe that is insufficient or do we really need to have the
> > extra layer of the <PolicyParameters> element added?
> >
> > 2.  At the end you say that there is a needed change to the LockBox
> element.
> > I am not clear what this change would be.  Is it the
> > <PolicyParameters> element above or something else?
> >
> > Jim
> >
> >
> > > -----Original Message-----
> > > From: Ed Simon [mailto:Ed.Simon@titus.com]
> > > Sent: Sunday, November 25, 2012 2:15 PM
> > > To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> > > Subject: RE: [plasma] Clarification of how client applications
> > > handle the LockBox in client in <plasma:GetCMSToken> elements
> > >
> > > 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">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>
> > >
> > >               </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#">hrQkL07h1qZhPhgLXKlL0dV
> > > eFLAbUVy0no05EGDzK2Q=</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</AttributeV
> > > alue>
> > >       </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: plasma-bounces@ietf.org [plasma-bounces@ietf.org] on behalf of
> > > Ed Simon [Ed.Simon@titus.com]
> > > Sent: Wednesday, November 21, 2012 21:52
> > > To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> > > 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#">hrQkL07h1qZhPhgLXKlL0dV
> > > eFLAbUVy0no05EGDzK2Q=</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</AttributeV
> > > alue>
> > >       </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.htm
> > > > > > l
> > > > > >
> > > > > > ...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 mailing list
> > > plasma@ietf.org
> > > https://www.ietf.org/mailman/listinfo/plasma


From trevorf@exchange.microsoft.com  Thu Jan  3 13:56:18 2013
Return-Path: <trevorf@exchange.microsoft.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 A0B0021F8D68 for <plasma@ietfa.amsl.com>; Thu,  3 Jan 2013 13:56:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.255
X-Spam-Level: 
X-Spam-Status: No, score=-101.255 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, USER_IN_WHITELIST=-100]
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 R9l-r1X2IWBp for <plasma@ietfa.amsl.com>; Thu,  3 Jan 2013 13:56:16 -0800 (PST)
Received: from NA01-BY1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.91]) by ietfa.amsl.com (Postfix) with ESMTP id 81C9121F8D44 for <plasma@ietf.org>; Thu,  3 Jan 2013 13:56:14 -0800 (PST)
Received: from BL2SR01CA102.namsdf01.sdf.exchangelabs.com (10.255.109.147) by BL2SR01MB604.namsdf01.sdf.exchangelabs.com (10.255.109.166) with Microsoft SMTP Server (TLS) id 15.0.601.3; Thu, 3 Jan 2013 21:56:10 +0000
Received: from SN2FFOFD004.ffo.gbl (157.55.158.24) by BL2SR01CA102.outlook.office365.com (10.255.109.147) with Microsoft SMTP Server (TLS) id 15.0.601.3 via Frontend Transport; Thu, 3 Jan 2013 21:56:10 +0000
Received: from hybrid.exchange.microsoft.com (131.107.1.27) by SN2FFOFD004.mail.o365filtering.com (10.111.201.41) with Microsoft SMTP Server (TLS) id 15.0.596.1 via Frontend Transport; Thu, 3 Jan 2013 21:56:10 +0000
Received: from DFM-TK5MBX15-06.exchange.corp.microsoft.com (157.54.109.45) by DF-G14-02.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 14.3.118.0; Thu, 3 Jan 2013 13:55:30 -0800
Received: from PIO-MLT-06.exchange.corp.microsoft.com (157.54.94.24) by DFM-TK5MBX15-06.exchange.corp.microsoft.com (157.54.109.45) with Microsoft SMTP Server (TLS) id 15.0.516.32; Thu, 3 Jan 2013 13:55:29 -0800
Received: from DF-M14-10.exchange.corp.microsoft.com ([fe80::b076:a99f:3049:4c76]) by PIO-MLT-06.exchange.corp.microsoft.com ([fe80::d57f:521a:3ae6:c130%10]) with mapi id 14.03.0118.000; Thu, 3 Jan 2013 13:55:29 -0800
From: Trevor Freeman <trevorf@exchange.microsoft.com>
To: Jim Schaad <ietf@augustcellars.com>, 'Ed Simon' <Ed.Simon@titus.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: AQHNyFx6QAEfHVE3SUizATOKHQdq7Jf7HC6sgAD9dYCAAs3ZgIA4UiaAgAApIICAAA2ogIAAwKfwgACXUID//52uYA==
Date: Thu, 3 Jan 2013 21:55:28 +0000
Message-ID: <3020AC5E95452D43B5D8D0FB02F881D3162C8A@DF-M14-10.exchange.corp.microsoft.com>
References: <DCD8C7A5A8B3E844AA2E2CBE327CDC92013DA1E7@E10MB3.tituscorp.local> <DCD8C7A5A8B3E844AA2E2CBE327CDC92013DB34F@E10MB3.tituscorp.local>, <014401cdcb92$21497b60$63dc7220$@augustcellars.com>, <DCD8C7A5A8B3E844AA2E2CBE327CDC92013DBE78@E10MB3.tituscorp.local> <DCD8C7A5A8B3E844AA2E2CBE327CDC92013E5BD9@E10MB3.tituscorp.local>, <004901cde936$b054ddb0$10fe9910$@augustcellars.com> <DCD8C7A5A8B3E844AA2E2CBE327CDC92013E5C75@E10MB3.tituscorp.local> <3020AC5E95452D43B5D8D0FB02F881D3162B90@DF-M14-10.exchange.corp.microsoft.com> <009301cde9e9$80069820$8013c860$@augustcellars.com>
In-Reply-To: <009301cde9e9$80069820$8013c860$@augustcellars.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.94.18]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.1.27; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464002)(377454001)(51704002)(47976001)(56776001)(54316002)(33656001)(49866001)(53806001)(74662001)(16406001)(50986001)(50466001)(54356001)(47736001)(59766001)(44976002)(77982001)(76482001)(47776002)(56816002)(31966008)(46102001)(46406002)(5343635001)(51856001)(47446002)(876001)(23726001)(4396001)(5343655001)(74502001)(15202345002)(55846006)(44824002); DIR:OUT; SFP:; SCL:1; SRVR:BL2SR01MB604; H:hybrid.exchange.microsoft.com; LANG:en; 
X-Forefront-PRVS: 071518EF63
X-OriginatorOrg: DuplicateDomain-6c178e33-aecb-4786-8220-9afceeddbaf3.exchange.microsoft.com
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, 03 Jan 2013 21:56:18 -0000

-----Original Message-----
From: Jim Schaad [mailto:ietf@augustcellars.com]=20
Sent: Thursday, January 3, 2013 11:36 AM
To: Trevor Freeman; 'Ed Simon'; plasma@ietf.org
Subject: RE: [plasma] Clarification of how client applications handle the L=
ockBox in client in <plasma:GetCMSToken> elements



> -----Original Message-----
> From: Trevor Freeman [mailto:trevorf@exchange.microsoft.com]
> Sent: Thursday, January 03, 2013 11:12 AM
> To: Ed Simon; Jim Schaad; plasma@ietf.org
> Subject: RE: [plasma] Clarification of how client applications handle=20
> the LockBox in client in <plasma:GetCMSToken> elements
>=20
> Plasma is policy expression neutral. It is a mechanism to control=20
> access
to
> data.  The policy which controls the access which was defined by the
sender
> may require a list of recipients for the data in questions. I don't=20
> see
how a PIP
> would know who the recipients are for a message.
>=20
> The sender calling GetCMSKey would know if the set of recipients is
required
> from the role token and can specify the list of 822 recipients to the
Plasma
> server in the request. However a recipient calling GetMessageKey can=20
> only pass in attributes as SAML attributes. A Plasma server may use=20
> BAE to establish the email address of the requestor e.g. the request=20
> contains a
DN
> and the plasma server used the DN to look up the email attribute from=20
> a
PIP.
> Alternatively the Plasma server can reply with an indeterminate=20
> response requesting the email attribute in which case the client needs=20
> to get a
SAML
> token with the requested attribute from its PIP.

The sender making the GetCMSKey call would never know if the set of
recipients is required.   Currently the set of policies on a message is not
exposed to the client and thus the client would have no way of determining =
this.  Remember we are talking here about reading a message not sending a m=
essage.
[TF] The sender knows to include the recipient list because the policy in t=
he role token has an option  with the email address option set (plasma serv=
ice section 7.2.2)=20
On first contact, the client making the get message key request does not kn=
ow if the email address attribute is required or not. It's a matter of loca=
l policy for the client to offer the email address up front or wait to be a=
sked. Offering the email address up front is a performance optimization whi=
ch you may choose. It's a tradeoff between performance and minimal disclosu=
re.=20

Jim

>=20
> The defining distinction is that the list of recipients by the sender=20
> is
self-
> asserted whereas the email address of the recipient is not.
>=20
> From a server perspective it is simpler if all the attributes in a=20
> request
is a
> single place. A server is going to search the supplied attributes for=20
> the
data it
> needs. It will not care if there is more there than it needs. You=20
> don't
need to
> tie the attributes to a specific policy.
>=20
> PLASMA does not, by design, require that the authenticating party be=20
> implicitly considered also as a recipient. The authenticating party=20
> may be
an
> agent acting on behalf of the recipient - in which case there is=20
> minimal
value
> in their authentication.
>=20
> Trevor
>=20
> -----Original Message-----
> From: Ed Simon [mailto:Ed.Simon@titus.com]
> Sent: Wednesday, January 2, 2013 3:04 PM
> To: Jim Schaad; Trevor Freeman; plasma@ietf.org
> Subject: RE: [plasma] Clarification of how client applications handle=20
> the LockBox in client in <plasma:GetCMSToken> elements
>=20
> If a XACML policy includes, inter alia, a rule that requiring a that=20
> only recipients may read an email, then the XACML will require either=20
> that the access subject be specified in the XACML request (as I have=20
> said below) or that the identity of the access subject be accessible=20
> through a PIP;
XACML, to
> my recollection, makes no automatic assumption that the authenticating=20
> party is the access subject party. If PLASMA is to require that the=20
> authenticating party be implicitly considered also as a XACML access
subject,
> then PLASMA needs to be explicit about that and perhaps describe the=20
> means through which that is to be accomplished wrt XACML -- would it not?
>=20
> I do not see why it would be difficult for client apps to specify who=20
> the access-requesting email recipient is through XACML attributes in=20
> the GetCMSKey PLASMA request. That seems to me the easiest, most=20
> robust approach for both clients apps and policy servers.
>=20
> My preference is for PLASMA to say that email recipients are to be
specified
> as XACML access subjects in the XACML request part (as is the normal=20
> case with XACML). If it is also deemed necessary to support the XACML=20
> PIP approach, we can do that too.
>=20
> Ed
>=20
> ________________________________________
> From: Jim Schaad [ietf@augustcellars.com]
> Sent: Wednesday, January 02, 2013 17:15
> To: Ed Simon; 'Trevor Freeman'; plasma@ietf.org
> Subject: RE: [plasma] Clarification of how client applications handle=20
> the LockBox in client in <plasma:GetCMSToken> elements
>=20
> It would appear to me that not allowing for the identities asserted=20
> during
the
> process of doing the authentication not being a default set of access
subject
> attributes would be incorrect and would make life much harder.
>=20
> For a simple policy one would still need to have a check that the=20
> access subject attribute asserted by the client is allowed for the set=20
> of known identities for the subject.  While this makes sense if the=20
> policy is going
to
> explicitly allow for impersonation, I think it is an unneeded burden=20
> on
policy
> writers for the simplest of policies.
>=20
> Why would disagree with assuming that the party named is the same as=20
> the access subject unless a different access subject is explicitly=20
> stated by
the
> client?
>=20
> Jim
>=20
>=20
> > -----Original Message-----
> > From: Ed Simon [mailto:Ed.Simon@titus.com]
> > Sent: Wednesday, January 02, 2013 11:48 AM
> > To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> > Subject: RE: [plasma] Clarification of how client applications=20
> > handle the LockBox in client in <plasma:GetCMSToken> elements
> >
> > Following my prior email (see below), on the GetCMSKey side, any=20
> > user- specified policy options (such as the list of recipients),=20
> > which were
> captured
> > in the LockBox during the GetCMSToken call, would be evaluated=20
> > against the XACML attributes specified in the GetCMSKey request. For=20
> > example, a specific recipient would be specified through a XACML=20
> > access subject (or perhaps XACML recipient subject) attribute. (Note=20
> > that I would disagree
> with
> > assuming the party named, if any, in the authentication token is
> necessarily
> > an access subject or recipient subject).
> >
> > Thoughts?
> >
> > Ed
> > ________________________________________
> > From: Ed Simon
> > Sent: Tuesday, November 27, 2012 18:43
> > To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> > Subject: RE: [plasma] Clarification of how client applications=20
> > handle the LockBox in client in <plasma:GetCMSToken> elements
> >
> > Reworking the example, I've replaced <Leaf> with=20
> > <Policy>/<PolicyOptions> (re-using the PolicyType structure defined=20
> > for the GetRolesToken; but
> using
> > the PolicyID attribute and replacing the PolicyType <Name> element=20
> > with <FriendlyName> (as per SAML)). It seems to me we the=20
> > specification's text may not be quite clear on the distinction=20
> > between the use of Policy(s) and Label/Leaf; it seems to me that=20
> > Label/Leaf in GetCMSToken could be
> logically
> > replaced with the GetRolesToken PolicyType structure, though in a=20
> > GetCMSToken request, the policy options would be specified by the=20
> > sender (whereas in GetRolesToken, the <PolicyOptions> specifies what=20
> > the sender needs to specify).
> >
> > For composite policies, I would rename the GetCMSToken <Label>=20
> > structure with <PolicyCombiner AlgorithmId=3D"...">, thus completing=20
> > the
> > policy- oriented semantics and naming style.
> >
> > The above paragraphs may answer Jim's first question.
> >
> > The answer to the second question is that if the sender is=20
> > specifying
> policy
> > options, which will later need to be used, on a GetCMSKey request=20
> > from a recipient, then because the PLASMA server is stateless wrt=20
> > specific messages, those options will need to be carried in the=20
> > LockBox payload of the message. I suggest, and I think Jim was=20
> > hinting he was considering
> this a
> > few weeks ago, that the content of the LockBox (labels/policies,=20
> > namedRecipients, defaultRecipients, CEK, ...) be specified in terms=20
> > of XML rather than ASN.1 and the ASN.1 LockBox be declared as=20
> > UTF8String so it
> can
> > hold the XML contents (ASN.1 structures such a ASN.1=20
> > RecipientInfo(s)
> could
> > be stored as base64-encoded within the XML).
> >
> > Here's the latest rework of the example...
> >
> > >>>
> >   <Request xmlns=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
> > CombinedDecision=3D"false" ReturnPolicyIdList=3D"false">
> >
> >     <Attributes Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-
> > category:action">
> >       <Attribute AttributeId=3D"urn:plasma:action-id"
> IncludeInResult=3D"false">
> >         <AttributeValue
> >
> DataType=3D"http://www.w3.org/2001/XMLSchema#string">GetCMSToken</
> > AttributeValue>
> >       </Attribute>
> >     </Attributes>
> >     <Attributes Category=3D"urn:ietf:plasma:data">
> >       <Attribute AttributeId=3D"urn:plasma:data-id"
IncludeInResult=3D"false">
> >         <AttributeValue
> > DataType=3D"http://www.w3.org/2001/XMLSchema#string">
> >           <GetCMSToken xmlns=3D"urn:ietf:schema:plasma:1.0">
> >             <Policy
> PolicyId=3D"urn:example:policies:only-allow-these-recipients-to-
> > decrypt-this-email">
> >               <FriendlyName>Only Allow These Recipients To Decrypt=20
> > this Email</FriendlyName>
> >               <PolicyOptions>
> >
> >               <!-- Specify parameters to the protection policy that=20
> > the
> user has
> > specified here (note switch back to XACML namespace in this example,=20
> > but contents of <PolicyParameters> could by in any namespace) -->
> >
> >     <Attributes Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-
> > category:access-subject"
> > xmlns=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
> >       <Attribute
> AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > id"" IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> > type:rfc822Name">Alice@example.org</AttributeValue>
> >       </Attribute>
> >       <Attribute
> AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > id"" IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> > type:rfc822Name">Bob@example.org</AttributeValue>
> >       </Attribute>
> >       <Attribute
> AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > id"" IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> > type:rfc822Name">Carl@example.org</AttributeValue>
> >       </Attribute>
> >     </Attributes>
> >
> >               </PolicyOptions>
> >             </Policy>
> >             <Hash>
> >               <DigestMethod xmlns=3D"http://www.w3.org/2000/09/xmldsig#=
"
> > Algorithm =3D"http://www.w3.org/2001/04/xmlenc#sha256"/>
> >               <DigestValue
> >
> xmlns=3D"http://www.w3.org/2000/09/xmldsig#">hrQkL07h1qZhPhgLXKlL0dV
> > eFLAbUVy0no05EGDzK2Q=3D</DigestValue>
> >             </Hash>
> >             <CEK>1BF2BEB249EE8EF2CB373E9800AC6F01</CEK>
> >           </GetCMSToken>
> >         </AttributeValue>
> >       </Attribute>
> >     </Attributes>
> >
> >     <!-- Specify XACML attributes that may be used to determine=20
> > whether
> the
> > user can execute the GetCMSToken request as regular XACML attributes=20
> > (example below) -->
> >
> >     <Attributes
> > Category=3D"urn:example:attributes-for-determining-whether-
> > this-XACML-request-will-be-permitted">
> >       <Attribute AttributeId=3D"urn:example:something-1"
> > IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:example:something-1-
> > format">SomethingSomethingSomethingSomething</AttributeValue>
> >       </Attribute>
> >       <Attribute AttributeId=3D"urn:example:something-2"
> > IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:example:something-2-
> >
>
format">asldkjfalskdjf32434534543dfjalkscxvkljzv2309080kjlkjlkj</AttributeV
> > alue>
> >       </Attribute>
> >     </Attributes>
> >
> >   </Request>
> > <<<
> >
> > Ed
> > ________________________________________
> > From: Jim Schaad [ietf@augustcellars.com]
> > Sent: Sunday, November 25, 2012 23:54
> > To: Ed Simon; 'Trevor Freeman'; plasma@ietf.org
> > Subject: RE: [plasma] Clarification of how client applications=20
> > handle the LockBox in client in <plasma:GetCMSToken> elements
> >
> > Ed,
> >
> > I agree with most of this, however there are two things
> >
> > 1.  Currently one can place an arbitrary structure inside of the=20
> > Leaf
> element.
> > Do you believe that is insufficient or do we really need to have the=20
> > extra layer of the <PolicyParameters> element added?
> >
> > 2.  At the end you say that there is a needed change to the LockBox
> element.
> > I am not clear what this change would be.  Is it the=20
> > <PolicyParameters> element above or something else?
> >
> > Jim
> >
> >
> > > -----Original Message-----
> > > From: Ed Simon [mailto:Ed.Simon@titus.com]
> > > Sent: Sunday, November 25, 2012 2:15 PM
> > > To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> > > Subject: RE: [plasma] Clarification of how client applications=20
> > > handle the LockBox in client in <plasma:GetCMSToken> elements
> > >
> > > Upon pondering this further, I think it is important to=20
> > > distinguish
> > between
> > > attributes that act as parameters to the policy the user wishes to=20
> > > enforce
> > for
> > > the message/document and those attributes used by the PLASMA=20
> > > server
> > to
> > > permit/deny the GetCMSToken request.
> > >
> > > For attributes that are policy parameters, these should be=20
> > > specified as
> > part of
> > > the PLASMA <GetCMSToken> element inside the <Leaf> child element=20
> > > (which identifies the policy the user selects to govern the=20
> > > message/document (should <Leaf> be renamed to <Policy> perhaps?)).
> > >
> > > For attributes that are used to determine whether the user can=20
> > > perform a GetCMSToken request, these should be specified outside=20
> > > the PLASMA <GetCMSToken> element.
> > >
> > > Reworking my prior example to reflect this design...
> > >
> > > >>>
> > >   <Request xmlns=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
> > > CombinedDecision=3D"false" ReturnPolicyIdList=3D"false">
> > >
> > >     <Attributes Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-
> > > category:action">
> > >       <Attribute AttributeId=3D"urn:plasma:action-id"
> > IncludeInResult=3D"false">
> > >         <AttributeValue
> > >
> >
> DataType=3D"http://www.w3.org/2001/XMLSchema#string">GetCMSToken</
> > > AttributeValue>
> > >       </Attribute>
> > >     </Attributes>
> > >     <Attributes Category=3D"urn:ietf:plasma:data">
> > >       <Attribute AttributeId=3D"urn:plasma:data-id"
> IncludeInResult=3D"false">
> > >         <AttributeValue
> > > DataType=3D"http://www.w3.org/2001/XMLSchema#string">
> > >           <GetCMSToken xmlns=3D"urn:ietf:schema:plasma:1.0">
> > >             <Leaf
> > PolicyId=3D"urn:example:policies:only-allow-these-recipients-to-
> > > decrypt-this-email">
> > >               <PolicyParameters>
> > >
> > >               <!-- Specify parameters to the protection policy=20
> > > that the
> > user has
> > > specified here (note switch back to XACML namespace in this=20
> > > example, but contents of <PolicyParameters> could by in any=20
> > > namespace) -->
> > >
> > >     <Attributes Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-
> > > category:access-subject"
> > > xmlns=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
> > >       <Attribute
> > AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > > id"" IncludeInResult=3D"false">
> > >         <AttributeValue=20
> > > DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> > > type:rfc822Name">Alice@example.org</AttributeValue>
> > >       </Attribute>
> > >       <Attribute
> > AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > > id"" IncludeInResult=3D"false">
> > >         <AttributeValue=20
> > > DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> > > type:rfc822Name">Bob@example.org</AttributeValue>
> > >       </Attribute>
> > >       <Attribute
> > AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > > id"" IncludeInResult=3D"false">
> > >         <AttributeValue=20
> > > DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> > > type:rfc822Name">Carl@example.org</AttributeValue>
> > >       </Attribute>
> > >     </Attributes>
> > >
> > >               </PolicyParameters>
> > >             </Leaf>
> > >             <Hash>
> > >               <DigestMethod xmlns=3D"http://www.w3.org/2000/09/xmldsi=
g#"
> > > Algorithm =3D"http://www.w3.org/2001/04/xmlenc#sha256"/>
> > >               <DigestValue
> > >
> >
> xmlns=3D"http://www.w3.org/2000/09/xmldsig#">hrQkL07h1qZhPhgLXKlL0dV
> > > eFLAbUVy0no05EGDzK2Q=3D</DigestValue>
> > >             </Hash>
> > >             <CEK>1BF2BEB249EE8EF2CB373E9800AC6F01</CEK>
> > >           </GetCMSToken>
> > >         </AttributeValue>
> > >       </Attribute>
> > >     </Attributes>
> > >
> > >     <!-- Specify XACML attributes that may be used to determine=20
> > > whether
> > the
> > > user can execute the GetCMSToken request as regular XACML=20
> > > attributes (example below) -->
> > >
> > >     <Attributes
> > > Category=3D"urn:example:attributes-for-determining-whether-
> > > this-XACML-request-will-be-permitted">
> > >       <Attribute AttributeId=3D"urn:example:something-1"
> > > IncludeInResult=3D"false">
> > >         <AttributeValue DataType=3D"urn:example:something-1-
> > > format">SomethingSomethingSomethingSomething</AttributeValue>
> > >       </Attribute>
> > >       <Attribute AttributeId=3D"urn:example:something-2"
> > > IncludeInResult=3D"false">
> > >         <AttributeValue DataType=3D"urn:example:something-2-
> > >
> >
>
format">asldkjfalskdjf32434534543dfjalkscxvkljzv2309080kjlkjlkj</AttributeV
> > > alue>
> > >       </Attribute>
> > >     </Attributes>
> > >
> > >   </Request>
> > > <<<
> > >
> > > Because of the stateless nature of PLASMA, there would also need=20
> > > to be a corresponding change to PLASMA-defined LockBox structure=20
> > > for the label/policy in order to store the policy parameter informati=
on.
> > >
> > > Ed
> > > ________________________________________
> > > From: plasma-bounces@ietf.org [plasma-bounces@ietf.org] on behalf=20
> > > of Ed Simon [Ed.Simon@titus.com]
> > > Sent: Wednesday, November 21, 2012 21:52
> > > To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> > > Subject: Re: [plasma] Clarification of how client applications=20
> > > handle the LockBox in client in <plasma:GetCMSToken> elements
> > >
> > > I propose, as a strawman proposal, that when policies require the=20
> > > sender's recipient list, they should be specified through XACML=20
> > > access-subject attributes, NOT PLASMA-specific attributes (e.g.
> > > within <plasma:GetCMSToken>). My position would be that PLASMA=20
> > > should only supplement XACML's pre-defined attributes where=20
> > > necessary, not create PLASMA-specified attributes where existing=20
> > > XACML-specified attributes are already defined and are sufficient.
> > > Hence my position at the moment is I would NOT change the current=20
> > > PLASMA semantics of <plasma:Recipient> which is specifically for=20
> > > specifying a lockbox for a recipient (though I
> > agree
> > > with Jim that the name of the element should be changed to=20
> > > <LockBoxes> to avoid confusion) and, instead indicate in the=20
> > > 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=20
> > > 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=20
> > > recipients, such policy-specific information would also be=20
> > > included through
> > > non-PLASMA- specific, XACML attributes.
> > >
> > > For example, a XACML request for GetCMSToken which needs to=20
> > > specify the list of recipients and other info could look like this...
> > >
> > >   <Request xmlns=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
> > > CombinedDecision=3D"false" ReturnPolicyIdList=3D"false">
> > >     <Attributes Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-
> > > category:action">
> > >       <Attribute AttributeId=3D"urn:plasma:action-id"
> > IncludeInResult=3D"false">
> > >         <AttributeValue
> > >
> >
> DataType=3D"http://www.w3.org/2001/XMLSchema#string">GetCMSToken</
> > > AttributeValue>
> > >       </Attribute>
> > >     </Attributes>
> > >     <Attributes Category=3D"urn:ietf:plasma:data">
> > >       <Attribute AttributeId=3D"urn:plasma:data-id"
> IncludeInResult=3D"false">
> > >         <AttributeValue
> > > DataType=3D"http://www.w3.org/2001/XMLSchema#string">
> > >           <GetCMSToken xmlns=3D"urn:ietf:schema:plasma:1.0">
> > >             <Leaf
> > PolicyId=3D"urn:example:policies:only-allow-recipients-to-decrypt-
> > > this-email"/>
> > >             <Hash>
> > >               <DigestMethod xmlns=3D"http://www.w3.org/2000/09/xmldsi=
g#"
> > > Algorithm =3D"http://www.w3.org/2001/04/xmlenc#sha256"/>
> > >               <DigestValue
> > >
> >
> xmlns=3D"http://www.w3.org/2000/09/xmldsig#">hrQkL07h1qZhPhgLXKlL0dV
> > > eFLAbUVy0no05EGDzK2Q=3D</DigestValue>
> > >             </Hash>
> > >             <CEK>1BF2BEB249EE8EF2CB373E9800AC6F01</CEK>
> > >           </GetCMSToken>
> > >         </AttributeValue>
> > >       </Attribute>
> > >     </Attributes>
> > >
> > > <!-- Ed's NEW STUFF BEGINS HERE! -->
> > >
> > >     <Attributes Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-
> > > category:access-subject">
> > >       <Attribute
> > AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > > id"" IncludeInResult=3D"false">
> > >         <AttributeValue=20
> > > DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> > > type:rfc822Name">Alice@example.org</AttributeValue>
> > >       </Attribute>
> > >       <Attribute
> > AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > > id"" IncludeInResult=3D"false">
> > >         <AttributeValue=20
> > > DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> > > type:rfc822Name">Bob@example.org</AttributeValue>
> > >       </Attribute>
> > >       <Attribute
> > AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > > id"" IncludeInResult=3D"false">
> > >         <AttributeValue=20
> > > DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> > > type:rfc822Name">Carl@example.org</AttributeValue>
> > >       </Attribute>
> > >     </Attributes>
> > >
> > >     <Attributes
> > > Category=3D"urn:example:some-other-attributes-related-to-
> > > processing-this-policy">
> > >       <Attribute AttributeId=3D"urn:example:something-1"
> > > IncludeInResult=3D"false">
> > >         <AttributeValue DataType=3D"urn:example:something-1-
> > > format">SomethingSomethingSomethingSomething</AttributeValue>
> > >       </Attribute>
> > >       <Attribute AttributeId=3D"urn:example:something-2"
> > > IncludeInResult=3D"false">
> > >         <AttributeValue DataType=3D"urn:example:something-2-
> > >
> >
>
format">asldkjfalskdjf32434534543dfjalkscxvkljzv2309080kjlkjlkj</AttributeV
> > > alue>
> > >       </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=20
> > > handle the LockBox in client in <plasma:GetCMSToken> elements
> > >
> > > What does it mean to have a recipient list if you are not looking=20
> > > at
> > Email?
> > >
> > > If one has a recipient list, and that recipient list is updated=20
> > > during
> > processing
> > > (for example mail list expansion) does that change the original=20
> > > policy set
> > by
> > > the sender?
> > >
> > > I should have called the structure <LockBoxes> rather than=20
> > > <Recipients> to prevent the confusion.  However, I can see that=20
> > > this could be an input
> > that is
> > > of interest to the policy.  However doing so means that we have to=20
> > > figure
> > out
> > > what it means in a number of different cases that I am currently=20
> > > 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=20
> > > > 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=20
> > > > policy
> > > dependent but
> > > > One or more policies may want that data as input to the policy.=20
> > > > It seems pointless duplication to include the list of recipients=20
> > > > 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=20
> > > > lock box element is optional, we can use the same structure for=20
> > > > both #1 and
> > > > #2
> > > below
> > > > i.e. if I just want a recipient list with no lock boxes or if I=20
> > > > 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=20
> > > > 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=20
> > > > > 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=20
> > > > > 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=20
> > > > 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=20
> > > > allowing it to determine who gets the CEK back.
> > > >
> > > > 3.  A recipient lists specific to email may be provided as part=20
> > > > of the
> > > input data.
> > > > This behavior (perhaps not currently in the document) is=20
> > > > provided for the purpose of doing pre-authorization of gateways=20
> > > > and is specific to
> > email.
> > > >
> > > >
> > > > Currently the above is better expressed as
> > > >
> > > > Policy=3Dbasic Policy
> > > > BasicPolicy Recipient List is "lisa@simpsons.com bart@simpsons.com"
> > > >
> > > > Jim
> > > >
> > > > >
> > > > > Policies may also require that lock boxes be generated for=20
> > > > > receipts rather than supply the CEK to the Plasma server. In=20
> > > > > that instance, the list of
> > > > receipts
> > > > > together with the associated lock box would be included in the=20
> > > > > 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]=20
> > > > > 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=20
> > > > > handle the LockBox in client in <plasma:GetCMSToken> elements
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: plasma-bounces@ietf.org=20
> > > > > > [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=20
> > > > > > applications handle the LockBox in client in=20
> > > > > > <plasma:GetCMSToken> elements
> > > > > >
> > > > > > Based on discussions with others on this mailing list, and
> > > > > >
> > > > > > http://www.ietf.org/mail-
> > archive/web/plasma/current/msg00118.htm
> > > > > > l
> > > > > >
> > > > > > ...I have drawn up the following three scenarios regarding=20
> > > > > > 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=20
> > > > > > Scenario B in
> > > > > which
> > > > > > the Sending Agent leaves it to the PLASMA Server to=20
> > > > > > construct a LockBox
> > > > > for
> > > > > > a named recipient, sound reasonable? Scenario B follows from=20
> > > > > > 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=20
> > > > > > 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=20
> > > > > lockboxes for
> > > > entities
> > > > > such as virus checking gateways in a mail system.  The=20
> > > > > lockboxes that are being returned with here are placed=20
> > > > > parallel to the Plasma Lockbox in the CMS Enveloped data=20
> > > > > object and are not embedded into the lockbox created by the Plasm=
a server.
> > > > >
> > > > > >
> > > > > > Here are the scenarios:
> > > > > >
> > > > > > Scenario A: The Sending Agent does NOT share the CEK with=20
> > > > > > the PLASMA server and specifies a limited set of recipients=20
> > > > > > who can decrypt the
> > > > > message
> > > > > > (for example, due to section 7.2.2 of PLASMA Service Trust=20
> > > > > > processing
> > > > v3).
> > > > > >
> > > > > > Sending Agent: In the <GetCMSToken> element of the PLASMA
> > > Request,
> > > > > the
> > > > > > sender will construct a <Recipient> list specifying, for=20
> > > > > > each
> > > > > recipient, both
> > > > > > the <Subject> element (to identify the recipient), and the=20
> > > > > > <LockBox> element to contain the encrypted CEK for that=20
> > > > > > 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=20
> > > > > > described in PLASMA Service CMS Processing v2). The LockBox=20
> > > > > > constructed by the PLASMA Server will comprise, in the=20
> > > > > > 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=20
> > > > > > able, barring
> > > > > further
> > > > > > communication with the Sending Agent, be able to supplement=20
> > > > > > the list of recipients.
> > > > >
> > > > > This looks correct
> > > > >
> > > > > >
> > > > > > Scenario B: The sender shares the CEK with the PLASMA server=20
> > > > > > and specifies a limited set of recipients who can decrypt=20
> > > > > > the message (for example,
> > > > > again,
> > > > > > due to section 7.2.2 of PLASMA Trust processing). For each=20
> > > > > > recipient specified, there may or may not be a LockBox=20
> > > > > > specified by the Sending Agent.
> > > > > >
> > > > > > Sending Agent: In the <GetCMSToken> element of the PLASMA
> > > Request,
> > > > > the
> > > > > > sender will construct a <Recipient> list specifying, for=20
> > > > > > each
> > > > > recipient, both
> > > > > > the <Subject> element (to identify the recipient), and,=20
> > > > > > optionally, the <LockBox> element to contain the encrypted=20
> > > > > > CEK for that recipient (encrypted so only that recipient can=20
> > > > > > 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=20
> > > > > > by the Sending Agent, it will be treated as in Scenario A;=20
> > > > > > otherwise, the PLASMA Server will create a LockBox for that=20
> > > > > > recipient to populate the namedRecipients structure. It will=20
> > > > > > also create a defaultRecipients
> > > > > structure
> > > > > > using the CEK provided by the Sending Agent. Note that in=20
> > > > > > this scenario,
> > > > > the
> > > > > > PLASMA Server will be able to, independently of the Sending=20
> > > > > > Agent, be able to supplement the list of recipients.
> > > > > >
> > > > > > Note that for Scenario B, the schema definition for the=20
> > > > > > <LockBox> element will need to have the attribute minOccurs=3D0=
.
> > > > >
> > > > > This is not currently an envisioned scenario in terms of the=20
> > > > > Plasma server creating the lock boxes at send time.  Currently=20
> > > > > if there is a list of
> > > > recipients
> > > > > that the sender does not create lockboxes for, it is=20
> > > > > envisioned that this
> > > > would
> > > > > be handled as part of the policy set on the message.  The=20
> > > > > Plasma server would then deal with potentially creating a lock=20
> > > > > 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=20
> > > > > > server and does NOT specify any recipients.
> > > > > >
> > > > > > Sending Agent: The Sending Agent will also construct a <CEK>=20
> > > > > > element to contain the CEK; no <Recipient> element will be
> created.
> > > > > >
> > > > > > PLASMA Server: The PLASMA Server will also create a=20
> > > > > > defaultRecipients structure using the CEK provided by the=20
> > > > > > Sending Agent; it may or may not create a namedRecipients=20
> > > > > > structure (populated independently of the Sending Agent). As=20
> > > > > > in Scenario B, the PLASMA Server will be able to,=20
> > > > > > independently of the Sending Agent, be able to supplement=20
> > > > > > 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 mailing list
> > > plasma@ietf.org
> > > https://www.ietf.org/mailman/listinfo/plasma


From Alan.Borland@BoldonJames.com  Fri Jan  4 01:55:05 2013
Return-Path: <Alan.Borland@BoldonJames.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 F016621F8EDE for <plasma@ietfa.amsl.com>; Fri,  4 Jan 2013 01:55:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.474
X-Spam-Level: 
X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_LOW_CONTRAST=0.124, HTML_MESSAGE=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 LkGciNUojk1v for <plasma@ietfa.amsl.com>; Fri,  4 Jan 2013 01:55:05 -0800 (PST)
Received: from outgoing.boldonjames.com (outgoing.boldonjames.com [195.217.233.97]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD3A21F8EDD for <plasma@ietf.org>; Fri,  4 Jan 2013 01:55:03 -0800 (PST)
Received: from BJEX3.corps.boldonjames.com ([fe80::b85c:343b:66b0:b132]) by bjex3.corps.boldonjames.com ([fe80::b85c:343b:66b0:b132%10]) with mapi id 14.02.0309.002; Fri, 4 Jan 2013 09:55:01 +0000
From: Alan Borland <Alan.Borland@BoldonJames.com>
To: "'plasma@ietf.org'" <plasma@ietf.org>
Thread-Topic: "Recipient List" thread and Distribution Lists
Thread-Index: Ac3qYPAE3drtyEDtTa+j5pBKKwy6zA==
Date: Fri, 4 Jan 2013 09:55:00 +0000
Message-ID: <0E5C08E16910F1409605822C0EC4DB5622037A47@bjex3.corps.boldonjames.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-protectivemarking: [BJ/UNMARKED/EXTERNAL]
x-bjprotectivemarking: <?xml version="1.0"?><sisl xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" sislVersion="0" policy="id_policy_bj" xmlns="http://www.boldonjames.com/2008/01/sie/internal/label"> <element uid="id_sensitivity_newvalue1" value="" />  <element uid="id_distribution_we" value="" /></sisl>
x-originating-ip: [10.20.0.31]
Content-Type: multipart/alternative; boundary="_000_0E5C08E16910F1409605822C0EC4DB5622037A47bjex3corpsboldo_"
MIME-Version: 1.0
Subject: [plasma] "Recipient List" thread and Distribution Lists
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: Fri, 04 Jan 2013 09:55:06 -0000

--_000_0E5C08E16910F1409605822C0EC4DB5622037A47bjex3corpsboldo_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Ignoring the syntax of the "Recipient List" for the moment, but how will th=
e recipient list mechanism work with distribution lists, especially those D=
Ls expanded by the mail server?  If on send I supply the plasma server "dl@=
xyz.com<mailto:dl@xyz.com>" as a <Recipient> and "fred@xyz.com" receives a =
copy of the message as a result of the DL expansion then will fred be able =
to read the message?



Alan.

Alan Borland

Boldon James Limited, a QinetiQ company
Mobile:        +44 (0)7810 556709
Direct:         +44 (0)1270 507841
Switch:        +44 (0)1270 507800
Email:          alan.borland@boldonjames.com<mailto:alan.borland@boldonjame=
s.com>
Email (R):    abborland@qinetiq.r.mil.uk<mailto:abborland@qinetiq.r.mil.uk>
Web:           www.boldonjames.com<x-excid://7DBF0000/pas:x-excid:/7DC00001=
/jmp:http:/www.boldonjames.com/>







Email classified by Boldon James Classifier - www.boldonjames.com<http://ww=
w.boldonjames.com>

--_000_0E5C08E16910F1409605822C0EC4DB5622037A47bjex3corpsboldo_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Calibri","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-GB" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoPlainText">Ignoring the syntax of the &quot;Recipient List&q=
uot; for the moment, but how will the recipient list mechanism work with di=
stribution lists, especially those DLs expanded by the mail server?&nbsp; I=
f on send I supply the plasma server &quot;<a href=3D"mailto:dl@xyz.com">dl=
@xyz.com</a>&quot;
 as a &lt;Recipient&gt; and &quot;fred@xyz.com&quot; receives a copy of the=
 message as a result of the DL expansion then will fred be able to read the=
 message?<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Alan.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;;color:navy;mso-fareast-language:EN-GB"=
>Alan Borland<o:p></o:p></span></b></p>
<p class=3D"MsoNormal"><span style=3D"font-size:7.5pt;font-family:&quot;Tah=
oma&quot;,&quot;sans-serif&quot;;color:#999999;mso-fareast-language:EN-GB">=
<br>
</span><b><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:&quot;=
Tahoma&quot;,&quot;sans-serif&quot;;color:#002B7F;mso-fareast-language:EN-G=
B">Boldon James Limited,
</span></b><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;;color:#002B7F;mso-fareast-language:EN-=
GB">a QinetiQ company</span><span lang=3D"EN-US" style=3D"font-size:10.0pt;=
font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black;mso-fareas=
t-language:EN-GB">
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ta=
homa&quot;,&quot;sans-serif&quot;;color:#999999;mso-fareast-language:EN-GB"=
>Mobile:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &#43;44 (0)7810 556709<b=
r>
Direct:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &#43;44 (0)1270 507=
841<br>
Switch: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &#43;44 (0)1270 507800<br>
Email:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href=3D"mai=
lto:alan.borland@boldonjames.com" target=3D"_blank"><span style=3D"color:bl=
ue">alan.borland@boldonjames.com</span></a><br>
Email (R):&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"mailto:abborland@qinetiq.r.mil=
.uk" target=3D"_blank"><span style=3D"color:blue">abborland@qinetiq.r.mil.u=
k</span></a><br>
Web:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href=3D=
"x-excid://7DBF0000/pas:x-excid:/7DC00001/jmp:http:/www.boldonjames.com/" t=
arget=3D"_blank" title=3D"http://www.boldonjames.com/">
<span style=3D"color:blue">www.boldonjames.com</span></a><o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ta=
homa&quot;,&quot;sans-serif&quot;;color:#999999;mso-fareast-language:EN-GB"=
><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:9.0pt;font-f=
amily:&quot;Tahoma&quot;,&quot;sans-serif&quot;;color:#999999;mso-fareast-l=
anguage:EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:&quot;Ti=
mes New Roman&quot;,&quot;serif&quot;;color:#1F497D;mso-fareast-language:EN=
-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;;color:black;mso-fareast-language:EN-GB"><o:p>&nbsp;</o:p></=
span></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<br>
<div id=3D"Classifier Footer">
<p style=3D"text-align:left;text-indent:0pt;margin:0pt 0pt 0pt 0pt;"><span =
style=3D"color:#0000C0;background-color:transparent;font-family:Arial;font-=
size:10pt;font-weight:normal;font-style:normal;">Email classified by
</span><span style=3D"color:#0000C0;background-color:transparent;font-famil=
y:Arial;font-size:10pt;font-weight:bold;font-style:normal;">Boldon James Cl=
assifier
</span><span style=3D"color:#0000C0;background-color:transparent;font-famil=
y:Arial;font-size:10pt;font-weight:normal;font-style:normal;">-</span><span=
 style=3D"color:#0000C0;background-color:transparent;font-family:Arial;font=
-size:10pt;font-weight:normal;font-style:italic;">
<a href=3D"http://www.boldonjames.com" target=3D"_blank" title=3D"http://ww=
w.boldonjames.com">
<span style=3D"color:#0000FF;background-color:transparent;font-family:Arial=
;font-size:10pt;font-weight:normal;font-style:italic;text-decoration: under=
line;">www.boldonjames.com</span></a></span></p>
</div>
</body>
</html>

--_000_0E5C08E16910F1409605822C0EC4DB5622037A47bjex3corpsboldo_--

From ietf@augustcellars.com  Fri Jan  4 11:09:47 2013
Return-Path: <ietf@augustcellars.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 49AD421F8716 for <plasma@ietfa.amsl.com>; Fri,  4 Jan 2013 11:09:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Level: 
X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.149,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 ftF9iXz31HTP for <plasma@ietfa.amsl.com>; Fri,  4 Jan 2013 11:09:46 -0800 (PST)
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 51D5921F870E for <plasma@ietf.org>; Fri,  4 Jan 2013 11:09:46 -0800 (PST)
Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 757FA38F1D; Fri,  4 Jan 2013 11:09:38 -0800 (PST)
From: "Jim Schaad" <ietf@augustcellars.com>
To: "'Alan Borland'" <Alan.Borland@BoldonJames.com>, <plasma@ietf.org>
References: <0E5C08E16910F1409605822C0EC4DB5622037A47@bjex3.corps.boldonjames.com>
In-Reply-To: <0E5C08E16910F1409605822C0EC4DB5622037A47@bjex3.corps.boldonjames.com>
Date: Fri, 4 Jan 2013 11:09:17 -0800
Message-ID: <00de01cdeaae$ff1be640$fd53b2c0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DF_01CDEA6B.F0FB3E50"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJ5rI3B+tobmEG9RDVCFDlVKhxk5ZbiAxTw
Content-Language: en-us
Subject: Re: [plasma] "Recipient List" thread and Distribution Lists
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: Fri, 04 Jan 2013 19:09:47 -0000

This is a multipart message in MIME format.

------=_NextPart_000_00DF_01CDEA6B.F0FB3E50
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

For a DL that is not Plasma enhanced, it will result in the final recipient
being unable to read the message as the Plasma server will refuse to grant
access to the message.  However this would assume that the DL is not
security aware and thus it is not expanding CMS lockboxes to begin with.
How the DL processes a message for which it cannot find a lockbox for itself
is going to be DL dependent.  It might just reject the message rather than
distributing it.  A Plasma server that knows a DL is not plasma enhanced
could create a lockbox for the DL which is not externally policy enforced,
thus the DL would process as today.

 

For a DL that is Plasma enhanced, the DL will create a new Plasma recipient
list and give it to the Plasma server.  The Plasma server will then return
either a new or an updated plasma CMS Recipient object to be placed in the
message. 

 

A DL that is partly Plasma enhanced would get the key from the Plasma
server, and then create new CMS lock boxes for all of the individuals on the
DL just as it does today.  This would lose the external policy enforcement
and might cause the originating plasma server to no longer grant access to
that DL.

 

Jim

 

 

From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of
Alan Borland
Sent: Friday, January 04, 2013 1:55 AM
To: 'plasma@ietf.org'
Subject: [plasma] "Recipient List" thread and Distribution Lists

 

Ignoring the syntax of the "Recipient List" for the moment, but how will the
recipient list mechanism work with distribution lists, especially those DLs
expanded by the mail server?  If on send I supply the plasma server
"dl@xyz.com" as a <Recipient> and "fred@xyz.com" receives a copy of the
message as a result of the DL expansion then will fred be able to read the
message?

 

Alan.

 

Alan Borland


Boldon James Limited, a QinetiQ company 

Mobile:        +44 (0)7810 556709
Direct:         +44 (0)1270 507841
Switch:        +44 (0)1270 507800
Email:           <mailto:alan.borland@boldonjames.com>
alan.borland@boldonjames.com
Email (R):     <mailto:abborland@qinetiq.r.mil.uk>
abborland@qinetiq.r.mil.uk
Web:
<x-excid://7DBF0000/pas:x-excid:/7DC00001/jmp:http:/www.boldonjames.com/>
www.boldonjames.com

 

 

 

 

 

 

Email classified by Boldon James Classifier -  <http://www.boldonjames.com>
www.boldonjames.com


------=_NextPart_000_00DF_01CDEA6B.F0FB3E50
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 14 =
(filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Calibri","sans-serif";}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle21
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US =
link=3D"#0563C1" vlink=3D"#954F72"><div class=3DWordSection1><p =
class=3DMsoNormal><span style=3D'color:#1F497D'>For a DL that is not =
Plasma enhanced, it will result in the final recipient being unable to =
read the message as the Plasma server will refuse to grant access to the =
message.&nbsp; However this would assume that the DL is not security =
aware and thus it is not expanding CMS lockboxes to begin with. =
&nbsp;How the DL processes a message for which it cannot find a lockbox =
for itself is going to be DL dependent.&nbsp; It might just reject the =
message rather than distributing it.&nbsp; A Plasma server that knows a =
DL is not plasma enhanced could create a lockbox for the DL which is not =
externally policy enforced, thus the DL would process as =
today.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span style=3D'color:#1F497D'>For a DL that is Plasma =
enhanced, the DL will create a new Plasma recipient list and give it to =
the Plasma server. &nbsp;The Plasma server will then return either a new =
or an updated plasma CMS Recipient object to be placed in the message. =
<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span style=3D'color:#1F497D'>A DL that is partly =
Plasma enhanced would get the key from the Plasma server, and then =
create new CMS lock boxes for all of the individuals on the DL just as =
it does today.&nbsp; This would lose the external policy enforcement and =
might cause the originating plasma server to no longer grant access to =
that DL.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'color:#1F497D'>Jim<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><div =
style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'><div><div style=3D'border:none;border-top:solid #B5C4DF =
1.0pt;padding:3.0pt 0in 0in 0in'><p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =
plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] <b>On Behalf Of =
</b>Alan Borland<br><b>Sent:</b> Friday, January 04, 2013 1:55 =
AM<br><b>To:</b> 'plasma@ietf.org'<br><b>Subject:</b> [plasma] =
&quot;Recipient List&quot; thread and Distribution =
Lists<o:p></o:p></span></p></div></div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoPlainText><span =
lang=3DEN-GB>Ignoring the syntax of the &quot;Recipient List&quot; for =
the moment, but how will the recipient list mechanism work with =
distribution lists, especially those DLs expanded by the mail =
server?&nbsp; If on send I supply the plasma server &quot;<a =
href=3D"mailto:dl@xyz.com">dl@xyz.com</a>&quot; as a &lt;Recipient&gt; =
and &quot;<a href=3D"mailto:fred@xyz.com">fred@xyz.com</a>&quot; =
receives a copy of the message as a result of the DL expansion then will =
fred be able to read the message?<o:p></o:p></span></p><p =
class=3DMsoPlainText><span lang=3DEN-GB><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoPlainText><span lang=3DEN-GB>Alan.<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-GB><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><b><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:navy;ms=
o-fareast-language:EN-GB'>Alan Borland<o:p></o:p></span></b></p><p =
class=3DMsoNormal><span lang=3DEN-GB =
style=3D'font-size:7.5pt;font-family:"Tahoma","sans-serif";color:#999999;=
mso-fareast-language:EN-GB'><br></span><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:#002B7F=
;mso-fareast-language:EN-GB'>Boldon James Limited, </span></b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:#002B7F=
;mso-fareast-language:EN-GB'>a QinetiQ company</span><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black;ms=
o-fareast-language:EN-GB'> <o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:#999999=
;mso-fareast-language:EN-GB'>Mobile:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; +44 (0)7810 =
556709<br>Direct:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +44 =
(0)1270 507841<br>Switch: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +44 =
(0)1270 =
507800<br>Email:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
<a href=3D"mailto:alan.borland@boldonjames.com" target=3D"_blank"><span =
style=3D'color:blue'>alan.borland@boldonjames.com</span></a><br>Email =
(R):&nbsp;&nbsp;&nbsp;&nbsp;<a =
href=3D"mailto:abborland@qinetiq.r.mil.uk" target=3D"_blank"><span =
style=3D'color:blue'>abborland@qinetiq.r.mil.uk</span></a><br>Web:&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a =
href=3D"x-excid://7DBF0000/pas:x-excid:/7DC00001/jmp:http:/www.boldonjame=
s.com/" target=3D"_blank" title=3D"http://www.boldonjames.com/"><span =
style=3D'color:blue'>www.boldonjames.com</span></a><o:p></o:p></span></p>=
<p class=3DMsoNormal><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:#999999=
;mso-fareast-language:EN-GB'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-size:9.0pt;font-family:"Tahoma","sans-serif";color:#999999;=
mso-fareast-language:EN-GB'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-GB =
style=3D'font-size:12.0pt;font-family:"Times New =
Roman","serif";color:#1F497D;mso-fareast-language:EN-GB'><o:p>&nbsp;</o:p=
></span></p><p class=3DMsoNormal><span lang=3DEN-GB =
style=3D'font-family:"Arial","sans-serif";color:black;mso-fareast-languag=
e:EN-GB'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-GB><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-GB style=3D'font-size:12.0pt;font-family:"Times New =
Roman","serif"'><o:p>&nbsp;</o:p></span></p><div id=3D"Classifier =
Footer"><p style=3D'margin:0in;margin-bottom:.0001pt'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#0000C0'=
>Email classified by <b>Boldon James Classifier </b>-<i> <a =
href=3D"http://www.boldonjames.com" target=3D"_blank" =
title=3D"http://www.boldonjames.com"><span =
style=3D'color:blue'>www.boldonjames.com</span></a></i></span><span =
lang=3DEN-GB><o:p></o:p></span></p></div></div></div></body></html>
------=_NextPart_000_00DF_01CDEA6B.F0FB3E50--


From trevorf@exchange.microsoft.com  Wed Jan  9 11:43:14 2013
Return-Path: <trevorf@exchange.microsoft.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 B49DE21F8833 for <plasma@ietfa.amsl.com>; Wed,  9 Jan 2013 11:43:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.851
X-Spam-Level: 
X-Spam-Status: No, score=-101.851 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, USER_IN_WHITELIST=-100]
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 t41LkLEqWsFQ for <plasma@ietfa.amsl.com>; Wed,  9 Jan 2013 11:43:12 -0800 (PST)
Received: from NA01-SN2-obe.outbound.o365filtering.com (na01-sn2-obe.ptr.o365filtering.com [157.55.158.27]) by ietfa.amsl.com (Postfix) with ESMTP id D172021F86F8 for <plasma@ietf.org>; Wed,  9 Jan 2013 11:43:11 -0800 (PST)
Received: from BL2SR01CA105.namsdf01.sdf.exchangelabs.com (10.255.109.150) by BL2SR01MB606.namsdf01.sdf.exchangelabs.com (10.255.109.168) with Microsoft SMTP Server (TLS) id 15.0.601.3; Wed, 9 Jan 2013 19:43:04 +0000
Received: from BY1FFOFD004.ffo.gbl (64.4.22.89) by BL2SR01CA105.outlook.office365.com (10.255.109.150) with Microsoft SMTP Server (TLS) id 15.0.601.3 via Frontend Transport; Wed, 9 Jan 2013 19:43:04 +0000
Received: from hybrid.exchange.microsoft.com (131.107.1.27) by BY1FFOFD004.mail.o365filtering.com (10.1.16.61) with Microsoft SMTP Server (TLS) id 15.0.596.1 via Frontend Transport; Wed, 9 Jan 2013 19:43:04 +0000
Received: from DFM-TK5MBX15-05.exchange.corp.microsoft.com (157.54.109.44) by DF-G14-02.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 14.3.118.0; Wed, 9 Jan 2013 11:40:37 -0800
Received: from PIO-MLT-05.exchange.corp.microsoft.com (157.54.94.22) by DFM-TK5MBX15-05.exchange.corp.microsoft.com (157.54.109.44) with Microsoft SMTP Server (TLS) id 15.0.516.32; Wed, 9 Jan 2013 11:40:36 -0800
Received: from DF-M14-10.exchange.corp.microsoft.com ([fe80::b076:a99f:3049:4c76]) by PIO-MLT-05.exchange.corp.microsoft.com ([fe80::d940:e316:1daa:5e6a%10]) with mapi id 14.03.0118.000; Wed, 9 Jan 2013 11:40:36 -0800
From: Trevor Freeman <trevorf@exchange.microsoft.com>
To: Ed Simon <Ed.Simon@titus.com>, Jim Schaad <ietf@augustcellars.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: AQHNyFx6QAEfHVE3SUizATOKHQdq7Jf7HC6sgAD9dYCAAs3ZgIA4UiaAgAApIICAAA2ogIAKPxaQ
Date: Wed, 9 Jan 2013 19:40:35 +0000
Message-ID: <3020AC5E95452D43B5D8D0FB02F881D316B4E9@DF-M14-10.exchange.corp.microsoft.com>
References: <DCD8C7A5A8B3E844AA2E2CBE327CDC92013DA1E7@E10MB3.tituscorp.local> <DCD8C7A5A8B3E844AA2E2CBE327CDC92013DB34F@E10MB3.tituscorp.local>, <014401cdcb92$21497b60$63dc7220$@augustcellars.com>, <DCD8C7A5A8B3E844AA2E2CBE327CDC92013DBE78@E10MB3.tituscorp.local> <DCD8C7A5A8B3E844AA2E2CBE327CDC92013E5BD9@E10MB3.tituscorp.local>, <004901cde936$b054ddb0$10fe9910$@augustcellars.com> <DCD8C7A5A8B3E844AA2E2CBE327CDC92013E5C75@E10MB3.tituscorp.local>
In-Reply-To: <DCD8C7A5A8B3E844AA2E2CBE327CDC92013E5C75@E10MB3.tituscorp.local>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.94.18]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.1.27; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(199002)(377454001)(13464002)(876001)(46102001)(16406001)(31966008)(77982001)(54316002)(79102001)(47776002)(47446002)(47736001)(15202345002)(53806001)(74502001)(33656001)(56816002)(47976001)(54356001)(74662001)(5343655001)(55846006)(51856001)(50986001)(56776001)(44976002)(46406002)(23726001)(59766001)(4396001)(76482001)(50466001)(5343635001)(49866001)(44824002); DIR:OUT; SFP:; SCL:1; SRVR:BL2SR01MB606; H:hybrid.exchange.microsoft.com; RD:mail7.exchange.microsoft.com; A:1; LANG:en; 
X-Forefront-PRVS: 07215D0470
Received-SPF: TempError (: error in processing during lookup of exchange.microsoft.com: DNS Timeout)
X-OriginatorOrg: DuplicateDomain-6c178e33-aecb-4786-8220-9afceeddbaf3.exchange.microsoft.com
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: Wed, 09 Jan 2013 19:43:14 -0000

To answer Ed point. For the read (GetCMSKey) case, the email should be prov=
ided as a signed claim in a SAML token or via BAE, not as a self-asserted X=
ACML attribute. This model holds where the requestor and the recipient are =
the same. This breaks down when they are different e.g. a server acting on =
behalf of a user. There we need some delegation claim coupled with the XACM=
L attribute e.g. a signed claim that I am a sever for *.foo.com and an XACM=
L attribute saying this instance of request id for alice@foo.com. This shou=
ld be covered in the Plasma for MTA draft.=20

-----Original Message-----
From: Ed Simon [mailto:Ed.Simon@titus.com]=20
Sent: Wednesday, January 2, 2013 3:04 PM
To: Jim Schaad; Trevor Freeman; plasma@ietf.org
Subject: RE: [plasma] Clarification of how client applications handle the L=
ockBox in client in <plasma:GetCMSToken> elements

If a XACML policy includes, inter alia, a rule that requiring a that only r=
ecipients may read an email, then the XACML will require either that the ac=
cess subject be specified in the XACML request (as I have said below) or th=
at the identity of the access subject be accessible through a PIP; XACML, t=
o my recollection, makes no automatic assumption that the authenticating pa=
rty is the access subject party. If PLASMA is to require that the authentic=
ating party be implicitly considered also as a XACML access subject, then P=
LASMA needs to be explicit about that and perhaps describe the means throug=
h which that is to be accomplished wrt XACML -- would it not?

I do not see why it would be difficult for client apps to specify who the a=
ccess-requesting email recipient is through XACML attributes in the GetCMSK=
ey PLASMA request. That seems to me the easiest, most robust approach for b=
oth clients apps and policy servers.

My preference is for PLASMA to say that email recipients are to be specifie=
d as XACML access subjects in the XACML request part (as is the normal case=
 with XACML). If it is also deemed necessary to support the XACML PIP appro=
ach, we can do that too.=20

Ed

________________________________________
From: Jim Schaad [ietf@augustcellars.com]
Sent: Wednesday, January 02, 2013 17:15
To: Ed Simon; 'Trevor Freeman'; plasma@ietf.org
Subject: RE: [plasma] Clarification of how client applications handle the L=
ockBox in client in <plasma:GetCMSToken> elements

It would appear to me that not allowing for the identities asserted during =
the process of doing the authentication not being a default set of access s=
ubject attributes would be incorrect and would make life much harder.

For a simple policy one would still need to have a check that the access su=
bject attribute asserted by the client is allowed for the set of known iden=
tities for the subject.  While this makes sense if the policy is going to e=
xplicitly allow for impersonation, I think it is an unneeded burden on poli=
cy writers for the simplest of policies.

Why would disagree with assuming that the party named is the same as the ac=
cess subject unless a different access subject is explicitly stated by the =
client?

Jim


> -----Original Message-----
> From: Ed Simon [mailto:Ed.Simon@titus.com]
> Sent: Wednesday, January 02, 2013 11:48 AM
> To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> Subject: RE: [plasma] Clarification of how client applications handle=20
> the LockBox in client in <plasma:GetCMSToken> elements
>
> Following my prior email (see below), on the GetCMSKey side, any user-=20
> specified policy options (such as the list of recipients), which were
captured
> in the LockBox during the GetCMSToken call, would be evaluated against=20
> the XACML attributes specified in the GetCMSKey request. For example,=20
> a specific recipient would be specified through a XACML access subject=20
> (or perhaps XACML recipient subject) attribute. (Note that I would=20
> disagree
with
> assuming the party named, if any, in the authentication token is
necessarily
> an access subject or recipient subject).
>
> Thoughts?
>
> Ed
> ________________________________________
> From: Ed Simon
> Sent: Tuesday, November 27, 2012 18:43
> To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> Subject: RE: [plasma] Clarification of how client applications handle=20
> the LockBox in client in <plasma:GetCMSToken> elements
>
> Reworking the example, I've replaced <Leaf> with=20
> <Policy>/<PolicyOptions> (re-using the PolicyType structure defined=20
> for the GetRolesToken; but
using
> the PolicyID attribute and replacing the PolicyType <Name> element=20
> with <FriendlyName> (as per SAML)). It seems to me we the=20
> specification's text may not be quite clear on the distinction between=20
> the use of Policy(s) and Label/Leaf; it seems to me that Label/Leaf in=20
> GetCMSToken could be
logically
> replaced with the GetRolesToken PolicyType structure, though in a=20
> GetCMSToken request, the policy options would be specified by the=20
> sender (whereas in GetRolesToken, the <PolicyOptions> specifies what=20
> the sender needs to specify).
>
> For composite policies, I would rename the GetCMSToken <Label>=20
> structure with <PolicyCombiner AlgorithmId=3D"...">, thus completing the=
=20
> policy- oriented semantics and naming style.
>
> The above paragraphs may answer Jim's first question.
>
> The answer to the second question is that if the sender is specifying
policy
> options, which will later need to be used, on a GetCMSKey request from=20
> a recipient, then because the PLASMA server is stateless wrt specific=20
> messages, those options will need to be carried in the LockBox payload=20
> of the message. I suggest, and I think Jim was hinting he was=20
> considering
this a
> few weeks ago, that the content of the LockBox (labels/policies,=20
> namedRecipients, defaultRecipients, CEK, ...) be specified in terms of=20
> XML rather than ASN.1 and the ASN.1 LockBox be declared as UTF8String=20
> so it
can
> hold the XML contents (ASN.1 structures such a ASN.1 RecipientInfo(s)
could
> be stored as base64-encoded within the XML).
>
> Here's the latest rework of the example...
>
> >>>
>   <Request xmlns=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
> CombinedDecision=3D"false" ReturnPolicyIdList=3D"false">
>
>     <Attributes Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-
> category:action">
>       <Attribute AttributeId=3D"urn:plasma:action-id"
IncludeInResult=3D"false">
>         <AttributeValue
> DataType=3D"http://www.w3.org/2001/XMLSchema#string">GetCMSToken</
> AttributeValue>
>       </Attribute>
>     </Attributes>
>     <Attributes Category=3D"urn:ietf:plasma:data">
>       <Attribute AttributeId=3D"urn:plasma:data-id" IncludeInResult=3D"fa=
lse">
>         <AttributeValue
> DataType=3D"http://www.w3.org/2001/XMLSchema#string">
>           <GetCMSToken xmlns=3D"urn:ietf:schema:plasma:1.0">
>             <Policy
PolicyId=3D"urn:example:policies:only-allow-these-recipients-to-
> decrypt-this-email">
>               <FriendlyName>Only Allow These Recipients To Decrypt=20
> this Email</FriendlyName>
>               <PolicyOptions>
>
>               <!-- Specify parameters to the protection policy that=20
> the
user has
> specified here (note switch back to XACML namespace in this example,=20
> but contents of <PolicyParameters> could by in any namespace) -->
>
>     <Attributes Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-
> category:access-subject"
> xmlns=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
>       <Attribute
AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> id"" IncludeInResult=3D"false">
>         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> type:rfc822Name">Alice@example.org</AttributeValue>
>       </Attribute>
>       <Attribute
AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> id"" IncludeInResult=3D"false">
>         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> type:rfc822Name">Bob@example.org</AttributeValue>
>       </Attribute>
>       <Attribute
AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> id"" IncludeInResult=3D"false">
>         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> type:rfc822Name">Carl@example.org</AttributeValue>
>       </Attribute>
>     </Attributes>
>
>               </PolicyOptions>
>             </Policy>
>             <Hash>
>               <DigestMethod xmlns=3D"http://www.w3.org/2000/09/xmldsig#"
> Algorithm =3D"http://www.w3.org/2001/04/xmlenc#sha256"/>
>               <DigestValue
> xmlns=3D"http://www.w3.org/2000/09/xmldsig#">hrQkL07h1qZhPhgLXKlL0dV
> eFLAbUVy0no05EGDzK2Q=3D</DigestValue>
>             </Hash>
>             <CEK>1BF2BEB249EE8EF2CB373E9800AC6F01</CEK>
>           </GetCMSToken>
>         </AttributeValue>
>       </Attribute>
>     </Attributes>
>
>     <!-- Specify XACML attributes that may be used to determine=20
> whether
the
> user can execute the GetCMSToken request as regular XACML attributes=20
> (example below) -->
>
>     <Attributes=20
> Category=3D"urn:example:attributes-for-determining-whether-
> this-XACML-request-will-be-permitted">
>       <Attribute AttributeId=3D"urn:example:something-1"
> IncludeInResult=3D"false">
>         <AttributeValue DataType=3D"urn:example:something-1-
> format">SomethingSomethingSomethingSomething</AttributeValue>
>       </Attribute>
>       <Attribute AttributeId=3D"urn:example:something-2"
> IncludeInResult=3D"false">
>         <AttributeValue DataType=3D"urn:example:something-2-
>
format">asldkjfalskdjf32434534543dfjalkscxvkljzv2309080kjlkjlkj</AttributeV
> alue>
>       </Attribute>
>     </Attributes>
>
>   </Request>
> <<<
>
> Ed
> ________________________________________
> From: Jim Schaad [ietf@augustcellars.com]
> Sent: Sunday, November 25, 2012 23:54
> To: Ed Simon; 'Trevor Freeman'; plasma@ietf.org
> Subject: RE: [plasma] Clarification of how client applications handle=20
> the LockBox in client in <plasma:GetCMSToken> elements
>
> Ed,
>
> I agree with most of this, however there are two things
>
> 1.  Currently one can place an arbitrary structure inside of the Leaf
element.
> Do you believe that is insufficient or do we really need to have the=20
> extra layer of the <PolicyParameters> element added?
>
> 2.  At the end you say that there is a needed change to the LockBox
element.
> I am not clear what this change would be.  Is it the=20
> <PolicyParameters> element above or something else?
>
> Jim
>
>
> > -----Original Message-----
> > From: Ed Simon [mailto:Ed.Simon@titus.com]
> > Sent: Sunday, November 25, 2012 2:15 PM
> > To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> > Subject: RE: [plasma] Clarification of how client applications=20
> > handle the LockBox in client in <plasma:GetCMSToken> elements
> >
> > Upon pondering this further, I think it is important to distinguish
> between
> > attributes that act as parameters to the policy the user wishes to=20
> > 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=20
> > as
> part of
> > the PLASMA <GetCMSToken> element inside the <Leaf> child element=20
> > (which identifies the policy the user selects to govern the=20
> > message/document (should <Leaf> be renamed to <Policy> perhaps?)).
> >
> > For attributes that are used to determine whether the user can=20
> > perform a GetCMSToken request, these should be specified outside the=20
> > PLASMA <GetCMSToken> element.
> >
> > Reworking my prior example to reflect this design...
> >
> > >>>
> >   <Request xmlns=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
> > CombinedDecision=3D"false" ReturnPolicyIdList=3D"false">
> >
> >     <Attributes Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-
> > category:action">
> >       <Attribute AttributeId=3D"urn:plasma:action-id"
> IncludeInResult=3D"false">
> >         <AttributeValue
> >
> DataType=3D"http://www.w3.org/2001/XMLSchema#string">GetCMSToken</
> > AttributeValue>
> >       </Attribute>
> >     </Attributes>
> >     <Attributes Category=3D"urn:ietf:plasma:data">
> >       <Attribute AttributeId=3D"urn:plasma:data-id"
IncludeInResult=3D"false">
> >         <AttributeValue
> > DataType=3D"http://www.w3.org/2001/XMLSchema#string">
> >           <GetCMSToken xmlns=3D"urn:ietf:schema:plasma:1.0">
> >             <Leaf
> PolicyId=3D"urn:example:policies:only-allow-these-recipients-to-
> > decrypt-this-email">
> >               <PolicyParameters>
> >
> >               <!-- Specify parameters to the protection policy that=20
> > the
> user has
> > specified here (note switch back to XACML namespace in this example,=20
> > but contents of <PolicyParameters> could by in any namespace) -->
> >
> >     <Attributes Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-
> > category:access-subject"
> > xmlns=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
> >       <Attribute
> AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > id"" IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> > type:rfc822Name">Alice@example.org</AttributeValue>
> >       </Attribute>
> >       <Attribute
> AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > id"" IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> > type:rfc822Name">Bob@example.org</AttributeValue>
> >       </Attribute>
> >       <Attribute
> AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > id"" IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> > type:rfc822Name">Carl@example.org</AttributeValue>
> >       </Attribute>
> >     </Attributes>
> >
> >               </PolicyParameters>
> >             </Leaf>
> >             <Hash>
> >               <DigestMethod xmlns=3D"http://www.w3.org/2000/09/xmldsig#=
"
> > Algorithm =3D"http://www.w3.org/2001/04/xmlenc#sha256"/>
> >               <DigestValue
> >
> xmlns=3D"http://www.w3.org/2000/09/xmldsig#">hrQkL07h1qZhPhgLXKlL0dV
> > eFLAbUVy0no05EGDzK2Q=3D</DigestValue>
> >             </Hash>
> >             <CEK>1BF2BEB249EE8EF2CB373E9800AC6F01</CEK>
> >           </GetCMSToken>
> >         </AttributeValue>
> >       </Attribute>
> >     </Attributes>
> >
> >     <!-- Specify XACML attributes that may be used to determine=20
> > whether
> the
> > user can execute the GetCMSToken request as regular XACML attributes=20
> > (example below) -->
> >
> >     <Attributes
> > Category=3D"urn:example:attributes-for-determining-whether-
> > this-XACML-request-will-be-permitted">
> >       <Attribute AttributeId=3D"urn:example:something-1"
> > IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:example:something-1-
> > format">SomethingSomethingSomethingSomething</AttributeValue>
> >       </Attribute>
> >       <Attribute AttributeId=3D"urn:example:something-2"
> > IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:example:something-2-
> >
>
format">asldkjfalskdjf32434534543dfjalkscxvkljzv2309080kjlkjlkj</AttributeV
> > alue>
> >       </Attribute>
> >     </Attributes>
> >
> >   </Request>
> > <<<
> >
> > Because of the stateless nature of PLASMA, there would also need to=20
> > be a corresponding change to PLASMA-defined LockBox structure for=20
> > the label/policy in order to store the policy parameter information.
> >
> > Ed
> > ________________________________________
> > From: plasma-bounces@ietf.org [plasma-bounces@ietf.org] on behalf of=20
> > Ed Simon [Ed.Simon@titus.com]
> > Sent: Wednesday, November 21, 2012 21:52
> > To: Jim Schaad; 'Trevor Freeman'; plasma@ietf.org
> > Subject: Re: [plasma] Clarification of how client applications=20
> > handle the LockBox in client in <plasma:GetCMSToken> elements
> >
> > I propose, as a strawman proposal, that when policies require the=20
> > sender's recipient list, they should be specified through XACML=20
> > access-subject attributes, NOT PLASMA-specific attributes (e.g.=20
> > within <plasma:GetCMSToken>). My position would be that PLASMA=20
> > should only supplement XACML's pre-defined attributes where=20
> > necessary, not create PLASMA-specified attributes where existing=20
> > XACML-specified attributes are already defined and are sufficient.=20
> > Hence my position at the moment is I would NOT change the current=20
> > PLASMA semantics of <plasma:Recipient> which is specifically for=20
> > specifying a lockbox for a recipient (though I
> agree
> > with Jim that the name of the element should be changed to=20
> > <LockBoxes> to avoid confusion) and, instead indicate in the=20
> > 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=20
> > which specifies the recipients through XACML access-subject att  ribute=
s.
> >
> > 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,=20
> > 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=20
> > the list of recipients and other info could look like this...
> >
> >   <Request xmlns=3D"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
> > CombinedDecision=3D"false" ReturnPolicyIdList=3D"false">
> >     <Attributes Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-
> > category:action">
> >       <Attribute AttributeId=3D"urn:plasma:action-id"
> IncludeInResult=3D"false">
> >         <AttributeValue
> >
> DataType=3D"http://www.w3.org/2001/XMLSchema#string">GetCMSToken</
> > AttributeValue>
> >       </Attribute>
> >     </Attributes>
> >     <Attributes Category=3D"urn:ietf:plasma:data">
> >       <Attribute AttributeId=3D"urn:plasma:data-id"
IncludeInResult=3D"false">
> >         <AttributeValue
> > DataType=3D"http://www.w3.org/2001/XMLSchema#string">
> >           <GetCMSToken xmlns=3D"urn:ietf:schema:plasma:1.0">
> >             <Leaf
> PolicyId=3D"urn:example:policies:only-allow-recipients-to-decrypt-
> > this-email"/>
> >             <Hash>
> >               <DigestMethod xmlns=3D"http://www.w3.org/2000/09/xmldsig#=
"
> > Algorithm =3D"http://www.w3.org/2001/04/xmlenc#sha256"/>
> >               <DigestValue
> >
> xmlns=3D"http://www.w3.org/2000/09/xmldsig#">hrQkL07h1qZhPhgLXKlL0dV
> > eFLAbUVy0no05EGDzK2Q=3D</DigestValue>
> >             </Hash>
> >             <CEK>1BF2BEB249EE8EF2CB373E9800AC6F01</CEK>
> >           </GetCMSToken>
> >         </AttributeValue>
> >       </Attribute>
> >     </Attributes>
> >
> > <!-- Ed's NEW STUFF BEGINS HERE! -->
> >
> >     <Attributes Category=3D"urn:oasis:names:tc:xacml:3.0:attribute-
> > category:access-subject">
> >       <Attribute
> AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > id"" IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> > type:rfc822Name">Alice@example.org</AttributeValue>
> >       </Attribute>
> >       <Attribute
> AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > id"" IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> > type:rfc822Name">Bob@example.org</AttributeValue>
> >       </Attribute>
> >       <Attribute
> AttributeId=3D""urn:oasis:names:tc:xacml:1.0:subject:subject-
> > id"" IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:oasis:names:tc:xacml:1.0:data-
> > type:rfc822Name">Carl@example.org</AttributeValue>
> >       </Attribute>
> >     </Attributes>
> >
> >     <Attributes
> > Category=3D"urn:example:some-other-attributes-related-to-
> > processing-this-policy">
> >       <Attribute AttributeId=3D"urn:example:something-1"
> > IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:example:something-1-
> > format">SomethingSomethingSomethingSomething</AttributeValue>
> >       </Attribute>
> >       <Attribute AttributeId=3D"urn:example:something-2"
> > IncludeInResult=3D"false">
> >         <AttributeValue DataType=3D"urn:example:something-2-
> >
>
format">asldkjfalskdjf32434534543dfjalkscxvkljzv2309080kjlkjlkj</AttributeV
> > alue>
> >       </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=20
> > 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=20
> > during
> processing
> > (for example mail list expansion) does that change the original=20
> > policy set
> by
> > the sender?
> >
> > I should have called the structure <LockBoxes> rather than=20
> > <Recipients> to prevent the confusion.  However, I can see that this=20
> > could be an input
> that is
> > of interest to the policy.  However doing so means that we have to=20
> > figure
> out
> > what it means in a number of different cases that I am currently not=20
> > 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=20
> > > 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=20
> > > seems pointless duplication to include the list of recipients as=20
> > > 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=20
> > > lock box element is optional, we can use the same structure for=20
> > > both #1 and
> > > #2
> > below
> > > i.e. if I just want a recipient list with no lock boxes or if I=20
> > > 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=20
> > > 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=20
> > > > 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.=20
> > > > While one or
> > > more
> > > > policies may require the list be supplied; only one list would=20
> > > > 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=20
> > > 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=20
> > > allowing it to determine who gets the CEK back.
> > >
> > > 3.  A recipient lists specific to email may be provided as part of=20
> > > the
> > input data.
> > > This behavior (perhaps not currently in the document) is provided=20
> > > for the purpose of doing pre-authorization of gateways and is=20
> > > specific to
> email.
> > >
> > >
> > > Currently the above is better expressed as
> > >
> > > Policy=3Dbasic Policy
> > > BasicPolicy Recipient List is "lisa@simpsons.com bart@simpsons.com"
> > >
> > > Jim
> > >
> > > >
> > > > Policies may also require that lock boxes be generated for=20
> > > > receipts rather than supply the CEK to the Plasma server. In=20
> > > > that instance, the list of
> > > receipts
> > > > together with the associated lock box would be included in the=20
> > > > 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]=20
> > > > 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=20
> > > > handle the LockBox in client in <plasma:GetCMSToken> elements
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org]=20
> > > > > 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=20
> > > > > 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.htm
> > > > > l
> > > > >
> > > > > ...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=20
> > > > > Scenario B in
> > > > which
> > > > > the Sending Agent leaves it to the PLASMA Server to construct=20
> > > > > a LockBox
> > > > for
> > > > > a named recipient, sound reasonable? Scenario B follows from=20
> > > > > 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=20
> > > > > knows
> > the
> > > > >    appropriate keying material."
> > > > > in the PLASMA Service CMS Processing v2 document.
> > > >
> > > > This text is intended to deal with the case of creating=20
> > > > lockboxes for
> > > entities
> > > > such as virus checking gateways in a mail system.  The lockboxes=20
> > > > that are being returned with here are placed parallel to the=20
> > > > Plasma Lockbox in the CMS Enveloped data object and are not=20
> > > > 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=20
> > > > > PLASMA server and specifies a limited set of recipients who=20
> > > > > can decrypt the
> > > > message
> > > > > (for example, due to section 7.2.2 of PLASMA Service Trust=20
> > > > > 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=20
> > > > > <LockBox> element to contain the encrypted CEK for that=20
> > > > > 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=20
> > > > > described in PLASMA Service CMS Processing v2). The LockBox=20
> > > > > constructed by the PLASMA Server will comprise, in the=20
> > > > > 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=20
> > > > > able, barring
> > > > further
> > > > > communication with the Sending Agent, be able to supplement=20
> > > > > the list of recipients.
> > > >
> > > > This looks correct
> > > >
> > > > >
> > > > > Scenario B: The sender shares the CEK with the PLASMA server=20
> > > > > and specifies a limited set of recipients who can decrypt the=20
> > > > > message (for example,
> > > > again,
> > > > > due to section 7.2.2 of PLASMA Trust processing). For each=20
> > > > > recipient specified, there may or may not be a LockBox=20
> > > > > 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,=20
> > > > > optionally, the <LockBox> element to contain the encrypted CEK=20
> > > > > for that recipient (encrypted so only that recipient can=20
> > > > > 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=20
> > > > > by the Sending Agent, it will be treated as in Scenario A;=20
> > > > > otherwise, the PLASMA Server will create a LockBox for that=20
> > > > > recipient to populate the namedRecipients structure. It will=20
> > > > > also create a defaultRecipients
> > > > structure
> > > > > using the CEK provided by the Sending Agent. Note that in this=20
> > > > > scenario,
> > > > the
> > > > > PLASMA Server will be able to, independently of the Sending=20
> > > > > Agent, be able to supplement the list of recipients.
> > > > >
> > > > > Note that for Scenario B, the schema definition for the=20
> > > > > <LockBox> element will need to have the attribute minOccurs=3D0.
> > > >
> > > > This is not currently an envisioned scenario in terms of the=20
> > > > Plasma server creating the lock boxes at send time.  Currently=20
> > > > if there is a list of
> > > recipients
> > > > that the sender does not create lockboxes for, it is envisioned=20
> > > > that this
> > > would
> > > > be handled as part of the policy set on the message.  The Plasma=20
> > > > server would then deal with potentially creating a lock box (as=20
> > > > 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=20
> > > > > server and does NOT specify any recipients.
> > > > >
> > > > > Sending Agent: The Sending Agent will also construct a <CEK>=20
> > > > > element to contain the CEK; no <Recipient> element will be
created.
> > > > >
> > > > > PLASMA Server: The PLASMA Server will also create a=20
> > > > > defaultRecipients structure using the CEK provided by the=20
> > > > > Sending Agent; it may or may not create a namedRecipients=20
> > > > > structure (populated independently of the Sending Agent). As=20
> > > > > in Scenario B, the PLASMA Server will be able to,=20
> > > > > independently of the Sending Agent, be able to supplement the lis=
t 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 mailing list
> > plasma@ietf.org
> > https://www.ietf.org/mailman/listinfo/plasma


From ietf@augustcellars.com  Fri Jan 11 17:17:25 2013
Return-Path: <ietf@augustcellars.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 2291D21F868B for <plasma@ietfa.amsl.com>; Fri, 11 Jan 2013 17:17:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.179
X-Spam-Level: 
X-Spam-Status: No, score=-3.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1]
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 fMhgRzeea8nR for <plasma@ietfa.amsl.com>; Fri, 11 Jan 2013 17:17:19 -0800 (PST)
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id A43B221F8645 for <plasma@ietf.org>; Fri, 11 Jan 2013 17:17:19 -0800 (PST)
Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 12C9F2CA30 for <plasma@ietf.org>; Fri, 11 Jan 2013 17:17:18 -0800 (PST)
From: "Jim Schaad" <ietf@augustcellars.com>
To: <plasma@ietf.org>
References: <20130112011307.23936.47158.idtracker@ietfa.amsl.com>
In-Reply-To: <20130112011307.23936.47158.idtracker@ietfa.amsl.com>
Date: Fri, 11 Jan 2013 17:16:57 -0800
Message-ID: <016c01cdf062$85b3d970$911b8c50$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGrSbiPFKZaRWg88V5Ba4oezYq6hpiKML/g
Content-Language: en-us
Subject: [plasma] FW: New Version Notification for draft-schaad-plasma-service-04.txt
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: Sat, 12 Jan 2013 01:17:25 -0000

New draft has finally be posted.

Note - this draft has changed a great number of things, but has not yet =
addressed the options for policy questions..  I am still trying to get =
my mind around what needs to be done in all of the different locations =
and what it means for schema to try and get it all correct.  Sorry I =
haven't gotten that far.

I think that most of the issues people have raised other than that are =
included.  The examples at the end are generated from my current code =
base and I believe reflect both the schema and the text of the draft.  I =
have not however done a recent read through of all of the text to make =
sure that this is a correct statement.  The schema should be correct as =
I did use a schema verify tool and came up with only one schema =
violation in the examples.  That is the inclusion of an id attribute in =
the xacml:Request element.  This is not legal according to the xacml =
schema.

Jim


> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Friday, January 11, 2013 5:13 PM
> To: ietf@augustcellars.com
> Subject: New Version Notification for =
draft-schaad-plasma-service-04.txt
>=20
>=20
> A new version of I-D, draft-schaad-plasma-service-04.txt
> has been successfully submitted by Jim Schaad and posted to the IETF
> repository.
>=20
> Filename:	 draft-schaad-plasma-service
> Revision:	 04
> Title:		 Plasma Service Trust Processing
> Creation date:	 2013-01-11
> WG ID:		 Individual Submission
> Number of pages: 68
> URL:             =
http://www.ietf.org/internet-drafts/draft-schaad-plasma-
> service-04.txt
> Status:          =
http://datatracker.ietf.org/doc/draft-schaad-plasma-service
> Htmlized:        =
http://tools.ietf.org/html/draft-schaad-plasma-service-04
> Diff:            =
http://www.ietf.org/rfcdiff?url2=3Ddraft-schaad-plasma-service-04
>=20
> Abstract:
>    RFC TBD describes a new model and set of requirements to implement =
a
>    labeling system on Cryptographic Message Syntax (CMS) objects where
>    the entity in charge of doing the label enforcement is under the
>    control of a central authority rather than the recipient of the
>    object.
>=20
>    This document describes a protocol to be used by senders and
>    recipients of CMS objects to communicate with a centralized label
>    enforcement server.  The document outlines how a client will get =
the
>    set of labels or policies that it can use for sending messages,
>    composes a secure CMS object with a label on it and gets the
>    necessary keys to decrypt a CMS object from the server.  This
>    document is designed to be used with RFC TBD2 which describes the
>    extensions used in CMS objects to hold the label information.
>=20
>=20
>=20
>=20
> The IETF Secretariat


From ietf@augustcellars.com  Fri Jan 11 17:17:48 2013
Return-Path: <ietf@augustcellars.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 B8AFD21F8645 for <plasma@ietfa.amsl.com>; Fri, 11 Jan 2013 17:17:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Level: 
X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 oF2IEseJwUT1 for <plasma@ietfa.amsl.com>; Fri, 11 Jan 2013 17:17:48 -0800 (PST)
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 169C921F845A for <plasma@ietf.org>; Fri, 11 Jan 2013 17:17:48 -0800 (PST)
Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 01DFD38F29 for <plasma@ietf.org>; Fri, 11 Jan 2013 17:17:43 -0800 (PST)
From: "Jim Schaad" <ietf@augustcellars.com>
To: <plasma@ietf.org>
References: <20130112011253.9137.16504.idtracker@ietfa.amsl.com>
In-Reply-To: <20130112011253.9137.16504.idtracker@ietfa.amsl.com>
Date: Fri, 11 Jan 2013 17:17:24 -0800
Message-ID: <016d01cdf062$94732dd0$bd598970$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGbFlqKpDcUe6GtkZ29ORwEpWolYZiqmFgA
Content-Language: en-us
Subject: [plasma] FW: New Version Notification for draft-schaad-plasma-cms-03.txt
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: Sat, 12 Jan 2013 01:17:48 -0000

New document released.

Moderate amounts of changes I think.

Jim


> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Friday, January 11, 2013 5:13 PM
> To: ietf@augustcellars.com
> Subject: New Version Notification for draft-schaad-plasma-cms-03.txt
>=20
>=20
> A new version of I-D, draft-schaad-plasma-cms-03.txt has been =
successfully
> submitted by Jim Schaad and posted to the IETF repository.
>=20
> Filename:	 draft-schaad-plasma-cms
> Revision:	 03
> Title:		 Plasma Service Cryptographic Message Syntax (CMS)
> Processing
> Creation date:	 2013-01-11
> WG ID:		 Individual Submission
> Number of pages: 39
> URL:             =
http://www.ietf.org/internet-drafts/draft-schaad-plasma-cms-
> 03.txt
> Status:          =
http://datatracker.ietf.org/doc/draft-schaad-plasma-cms
> Htmlized:        http://tools.ietf.org/html/draft-schaad-plasma-cms-03
> Diff:            =
http://www.ietf.org/rfcdiff?url2=3Ddraft-schaad-plasma-cms-03
>=20
> Abstract:
>    Secure MIME (S/MIME) defined a method of placing security labels on =
a
>    Cryptographic Message Syntax (CMS) object.  These labels are placed
>    as part of the data signed and validated by the parties.  This =
means
>    that the message content is visible to the recipient prior to the
>    label enforcement.  A new model for enforcement of policy using a
>    third party is described in RFC TBD
>    [I.D-draft-freeman-plasma-requirements].  This is the Policy
>    Augmented S/MIME (PLASMA) system.  This document provides the =
details
>    needed to implement the new Plasma model in the CMS infrastructure.
>=20
>    An additional benefit of using the Plasma module is that the =
server,
>    based on policy, manages who has access to the message and how the
>    keys are protected.
>=20
>    The document details how the client encryption and decryption
>    processes are performed, defines how to construct the CMS recipient
>    info structure, a new content to hold the data required for the
>    Plasma server to store the keys and policy information.  The =
document
>    does not cover the protocol between the client and the Plasma =
policy
>    enforcement server.  One example of the client/server protocol can =
be
>    found in RFC TBD [plasma-token].
>=20
>=20
>=20
>=20
> The IETF Secretariat


From ietf@augustcellars.com  Thu Jan 17 00:04:30 2013
Return-Path: <ietf@augustcellars.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 93B1821F8B4C for <plasma@ietfa.amsl.com>; Thu, 17 Jan 2013 00:04:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.486
X-Spam-Level: 
X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=0.113,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 NLOKcW2m4fJs for <plasma@ietfa.amsl.com>; Thu, 17 Jan 2013 00:04:30 -0800 (PST)
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 1F18221F8AA6 for <plasma@ietf.org>; Thu, 17 Jan 2013 00:04:29 -0800 (PST)
Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 267FC2CA0B for <plasma@ietf.org>; Thu, 17 Jan 2013 00:04:29 -0800 (PST)
From: "Jim Schaad" <ietf@augustcellars.com>
To: <plasma@ietf.org>
References: <20130117073956.29281.7730.idtracker@ietfa.amsl.com>
In-Reply-To: <20130117073956.29281.7730.idtracker@ietfa.amsl.com>
Date: Thu, 17 Jan 2013 00:04:05 -0800
Message-ID: <011401cdf489$3a1f9e60$ae5edb20$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHi6e6qXSFB7rDQMvigkH6dTGtRtZgjPkEQ
Content-Language: en-us
Subject: [plasma] FW: New Version Notification for draft-schaad-plasma-redact-00.txt
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, 17 Jan 2013 08:04:30 -0000

I have just submitted this draft.=20

It has to do with how redacted documents would interact with Plasma =
servers.  This document is partially there and partially a place holder. =
 It does reflect my currently thinking, but that is subject to wild =
swings at the moment.

If you really want to go ahead and read and comment.

Jim


> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Wednesday, January 16, 2013 11:40 PM
> To: ietf@augustcellars.com
> Subject: New Version Notification for =
draft-schaad-plasma-redact-00.txt
>=20
>=20
> A new version of I-D, draft-schaad-plasma-redact-00.txt has been
> successfully submitted by Jim Schaad and posted to the IETF =
repository.
>=20
> Filename:	 draft-schaad-plasma-redact
> Revision:	 00
> Title:		 PLASMA and Redacted Documents
> Creation date:	 2013-01-16
> WG ID:		 Individual Submission
> Number of pages: 16
> URL:             =
http://www.ietf.org/internet-drafts/draft-schaad-plasma-redact-
> 00.txt
> Status:          =
http://datatracker.ietf.org/doc/draft-schaad-plasma-redact
> Htmlized:        =
http://tools.ietf.org/html/draft-schaad-plasma-redact-00
>=20
>=20
> Abstract:
>    Redacted documents are designed to have a single document which
>    allows different individuals to view different portions of the
>    document basd on the attributes of the individual.  In this =
document,
>    a protocol extension to the basic PLASMA protocol is described that
>    allows for multiple keys, each with a different policy, to be used =
in
>    a single electronic document for enforcement of redaction levels.
>    This document is agnostic relative to the actual format of the
>    redacted document, the only requirement being that the redacted
>    document be able to carry the PLASMA defined lock box.
>=20
>=20
>=20
>=20
> The IETF Secretariat


From trevorf@exchange.microsoft.com  Mon Jan 28 10:45:52 2013
Return-Path: <trevorf@exchange.microsoft.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 63D0821F86E8 for <plasma@ietfa.amsl.com>; Mon, 28 Jan 2013 10:45:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level: 
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 BtAlZaR-QC9A for <plasma@ietfa.amsl.com>; Mon, 28 Jan 2013 10:45:50 -0800 (PST)
Received: from na01-sn2-obe.outbound.o365filtering.com (na01-sn2-obe.ptr.o365filtering.com [157.55.158.24]) by ietfa.amsl.com (Postfix) with ESMTP id 57C1821F86E4 for <plasma@ietf.org>; Mon, 28 Jan 2013 10:45:49 -0800 (PST)
Received: from BY2SR01CA101.namsdf01.sdf.exchangelabs.com (10.255.93.146) by BY2SR01MB609.namsdf01.sdf.exchangelabs.com (10.255.93.168) with Microsoft SMTP Server (TLS) id 15.0.620.2; Mon, 28 Jan 2013 18:45:46 +0000
Received: from BY1FFOFD003.ffo.gbl (64.4.22.87) by BY2SR01CA101.outlook.office365.com (10.255.93.146) with Microsoft SMTP Server (TLS) id 15.0.620.2 via Frontend Transport; Mon, 28 Jan 2013 18:46:24 +0000
Received: from hybrid.exchange.microsoft.com (131.107.1.17) by BY1FFOFD003.mail.o365filtering.com (10.1.16.90) with Microsoft SMTP Server (TLS) id 15.0.609.1 via Frontend Transport; Mon, 28 Jan 2013 18:45:46 +0000
Received: from df-h14-02.exchange.corp.microsoft.com (157.54.78.140) by DF-G14-01.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 14.3.123.1; Mon, 28 Jan 2013 10:45:17 -0800
Received: from PIO-MLT-06.exchange.corp.microsoft.com (157.54.94.24) by DF-H14-02.exchange.corp.microsoft.com (157.54.78.140) with Microsoft SMTP Server (TLS) id 14.3.123.1; Mon, 28 Jan 2013 10:45:17 -0800
Received: from DF-M14-10.exchange.corp.microsoft.com ([fe80::b076:a99f:3049:4c76]) by PIO-MLT-06.exchange.corp.microsoft.com ([fe80::d57f:521a:3ae6:c130%10]) with mapi id 14.03.0123.001; Mon, 28 Jan 2013 10:45:17 -0800
From: Trevor Freeman <trevorf@exchange.microsoft.com>
To: "Jim Schaad (jimsch@augustcellars.com)" <jimsch@augustcellars.com>
Thread-Topic: SignedData vs. ContentInfo for keyatt-eps-kek 
Thread-Index: Ac39hm/mOk1DcgOkQXS7jcYq8bfI3g==
Date: Mon, 28 Jan 2013 18:45:16 +0000
Message-ID: <3020AC5E95452D43B5D8D0FB02F881D3BCDDDC@DF-M14-10.exchange.corp.microsoft.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.94.16]
Content-Type: multipart/alternative; boundary="_000_3020AC5E95452D43B5D8D0FB02F881D3BCDDDCDFM1410exchangeco_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.1.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(51856001)(5343655001)(16236675001)(876001)(54356001)(4396001)(56816002)(55846006)(53806001)(59766001)(77982001)(20776003)(74662001)(54316002)(47446002)(44976002)(74502001)(5343635001)(56776001)(512954001)(50986001)(47976001)(49866001)(79102001)(76482001)(47736001)(16406001)(33656001)(63696002)(31966008)(15202345002)(46102001); DIR:OUT; SFP:; SCL:1; SRVR:BY2SR01MB609; H:hybrid.exchange.microsoft.com; RD:mail1.exchange.microsoft.com; A:1; MX:1; LANG:en; 
X-Forefront-PRVS: 074040B844
X-OriginatorOrg: DuplicateDomain-6c178e33-aecb-4786-8220-9afceeddbaf3.exchange.microsoft.com
Cc: "plasma@ietf.org" <plasma@ietf.org>
Subject: [plasma] SignedData vs. ContentInfo for keyatt-eps-kek
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: Mon, 28 Jan 2013 18:45:52 -0000

--_000_3020AC5E95452D43B5D8D0FB02F881D3BCDDDCDFM1410exchangeco_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Jim

An observation on the CMS draft is that you currently have the keyatt-eps-k=
ek defined as a SignedData structure.

The standard CMS signature creation and verification APIs expect to have th=
e ContentInfo structure as the output\input data stream as defined by S/MIM=
E defines.

Net result when using these standard APIs is we end up manually removing th=
e ContentInfo structure on creation and adding it on verification when proc=
essing the keyatt-eps-kek attribute. While not strictly necessary, it would=
 streamline the code path if we were to use ContentInfo as we can skip the =
manual adding\removal of the ContentInfo structure.

Trevor

--_000_3020AC5E95452D43B5D8D0FB02F881D3BCDDDCDFM1410exchangeco_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Hi Jim<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">An observation on the CMS draft is that you currentl=
y have the keyatt-eps-kek defined as a SignedData structure.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">The standard CMS signature creation and verification=
 APIs expect to have the ContentInfo structure as the output\input data str=
eam as defined by S/MIME defines.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Net result when using these standard APIs is we end =
up manually removing the ContentInfo structure on creation and adding it on=
 verification when processing the keyatt-eps-kek attribute. While not stric=
tly necessary, it would streamline
 the code path if we were to use ContentInfo as we can skip the manual addi=
ng\removal of the ContentInfo structure.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Trevor <o:p></o:p></p>
</div>
</body>
</html>

--_000_3020AC5E95452D43B5D8D0FB02F881D3BCDDDCDFM1410exchangeco_--