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

"Jim Schaad" <ietf@augustcellars.com> Tue, 20 November 2012 04:10 UTC

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 4497321F87EF for <plasma@ietfa.amsl.com>; Mon, 19 Nov 2012 20:10:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.854
X-Spam-Level:
X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=0.745, 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 i8MvQZMRH2AW for <plasma@ietfa.amsl.com>; Mon, 19 Nov 2012 20:10:56 -0800 (PST)
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 621BC21F87F3 for <plasma@ietf.org>; Mon, 19 Nov 2012 20:10:56 -0800 (PST)
Received: from Philemon (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (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 1FA062CA18; Mon, 19 Nov 2012 20:10:56 -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: <DCD8C7A5A8B3E844AA2E2CBE327CDC92013D21D4@E10MB3.tituscorp.local> <002601cdc6a0$fa38dcf0$eeaa96d0$@augustcellars.com> <3020AC5E95452D43B5D8D0FB02F881D30A6DA4@DF-M14-10.exchange.corp.microsoft.com>
In-Reply-To: <3020AC5E95452D43B5D8D0FB02F881D30A6DA4@DF-M14-10.exchange.corp.microsoft.com>
Date: Mon, 19 Nov 2012 20:10:44 -0800
Message-ID: <005d01cdc6d5$04f967c0$0eec3740$@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: AQEeaXGaF3ugIn/POqXt8r+ivF6IKQHOr5HmAl5A6eOZL2vfIA==
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: Tue, 20 Nov 2012 04:10:57 -0000

> -----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.html
> >
> > ...I have drawn up the following three scenarios regarding the
> construction of
> > the <GetCMSToken> element sent to the PLASMA Server by the Sending
> > Agent, and the construction of the LockBox by the PLASMA Server.
> >
> > Does what I've described in these scenarios, particularly Scenario B
> > in
> which
> > the Sending Agent leaves it to the PLASMA Server to construct a
> > LockBox
> for
> > a named recipient, sound reasonable? Scenario B follows from the text
> >    "Additionally the Plasma server could return the standard
> >    recipient info structures to be added to the message for recipients
> >    if it can pre-authorize them to have access the message and knows the
> >    appropriate keying material."
> > in the PLASMA Service CMS Processing v2 document.
> 
> This text is intended to deal with the case of creating lockboxes for
entities
> such as virus checking gateways in a mail system.  The lockboxes that are
> being returned with here are placed parallel to the Plasma Lockbox in the
> CMS Enveloped data object and are not embedded into the lockbox created
> by the Plasma server.
> 
> >
> > Here are the scenarios:
> >
> > Scenario A: The Sending Agent does NOT share the CEK with the PLASMA
> > server and specifies a limited set of recipients who can decrypt the
> message
> > (for example, due to section 7.2.2 of PLASMA Service Trust processing
v3).
> >
> > Sending Agent: In the <GetCMSToken> element of the PLASMA Request,
> the
> > sender will construct a <Recipient> list specifying, for each
> recipient, both
> > the <Subject> element (to identify the recipient), and the <LockBox>
> > element to contain the encrypted CEK for that recipient (encrypted so
> > only that recipient can decrypt it). There will be no <CEK> element.
> >
> > PLASMA Server: Will construct an ASN.1 PLASMA LockBox (as described in
> > PLASMA Service CMS Processing v2). The LockBox constructed by the
> > PLASMA Server will comprise, in the namedRecipients, the LockBox-es
> > provided by the Sending Agent. There will be no defaultRecipients
> structure.
> > Note that in this scenario, the PLASMA Server will not be able,
> > barring
> further
> > communication with the Sending Agent, be able to supplement the list
> > of recipients.
> 
> This looks correct
> 
> >
> > Scenario B: The sender shares the CEK with the PLASMA server and
> > specifies a limited set of recipients who can decrypt the message (for
> > example,
> again,
> > due to section 7.2.2 of PLASMA Trust processing). For each recipient
> > specified, there may or may not be a LockBox specified by the Sending
> > Agent.
> >
> > Sending Agent: In the <GetCMSToken> element of the PLASMA Request,
> the
> > sender will construct a <Recipient> list specifying, for each
> recipient, both
> > the <Subject> element (to identify the recipient), and, optionally,
> > the <LockBox> element to contain the encrypted CEK for that recipient
> > (encrypted so only that recipient can decrypt it). The Sending Agent
> > will
> also
> > construct a <CEK> element to contain the CEK.
> >
> > PLASMA Server: Where a LockBox for a recipient was specified by the
> > Sending Agent, it will be treated as in Scenario A; otherwise, the
> > PLASMA Server will create a LockBox for that recipient to populate the
> > namedRecipients structure. It will also create a defaultRecipients
> structure
> > using the CEK provided by the Sending Agent. Note that in this
> > scenario,
> the
> > PLASMA Server will be able to, independently of the Sending Agent, be
> > able to supplement the list of recipients.
> >
> > Note that for Scenario B, the schema definition for the <LockBox>
> > element will need to have the attribute minOccurs=0.
> 
> This is not currently an envisioned scenario in terms of the Plasma server
> creating the lock boxes at send time.  Currently if there is a list of
recipients
> that the sender does not create lockboxes for, it is envisioned that this
would
> be handled as part of the policy set on the message.  The Plasma server
> would then deal with potentially creating a lock box (as oppose to
returning a
> bare key) when the recipient tries to get the key from the server.
> 
> >
> > Scenario C: The Sending Agent shares the CEK with the PLASMA server
> > and does NOT specify any recipients.
> >
> > Sending Agent: The Sending Agent will also construct a <CEK> element
> > to contain the CEK; no <Recipient> element will be created.
> >
> > PLASMA Server: The PLASMA Server will also create a defaultRecipients
> > structure using the CEK provided by the Sending Agent; it may or may
> > not create a namedRecipients structure (populated independently of the
> > Sending Agent). As in Scenario B, the PLASMA Server will be able to,
> > independently of the Sending Agent, be able to supplement the list of
> > recipients.
> 
> This is what I would expect to see.
> 
> Jim
> 
> >
> > _______________________________________________
> > plasma mailing list
> > plasma@ietf.org
> > https://www.ietf.org/mailman/listinfo/plasma
> 
> _______________________________________________
> plasma mailing list
> plasma@ietf.org
> https://www.ietf.org/mailman/listinfo/plasma