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

Trevor Freeman <trevorf@exchange.microsoft.com> Mon, 19 November 2012 22:19 UTC

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 76C5921F8527 for <plasma@ietfa.amsl.com>; Mon, 19 Nov 2012 14:19:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 81XfyOLFcBDy for <plasma@ietfa.amsl.com>; Mon, 19 Nov 2012 14:19:55 -0800 (PST)
Received: from NA01-BY1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.89]) by ietfa.amsl.com (Postfix) with ESMTP id 792BF21F8523 for <plasma@ietf.org>; Mon, 19 Nov 2012 14:19:55 -0800 (PST)
Received: from BY2SR01CA101.namsdf01.sdf.exchangelabs.com (10.255.93.146) by BY2SR01MB608.namsdf01.sdf.exchangelabs.com (10.255.93.167) with Microsoft SMTP Server (TLS) id 15.0.568.2; Mon, 19 Nov 2012 22:19:50 +0000
Received: from SN2FFOFD001.ffo.gbl (157.55.158.23) by BY2SR01CA101.outlook.com (10.255.93.146) with Microsoft SMTP Server (TLS) id 15.0.568.11 via Frontend Transport; Mon, 19 Nov 2012 22:19:50 +0000
Received: from hybrid.exchange.microsoft.com (131.107.1.17) by SN2FFOFD001.mail.o365filtering.com (10.111.201.20) with Microsoft SMTP Server (TLS) id 15.0.568.0 via Frontend Transport; Mon, 19 Nov 2012 22:19:50 +0000
Received: from DFM-TK5MBX15-01.exchange.corp.microsoft.com (157.54.110.8) by DF-G14-01.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 14.3.111.0; Mon, 19 Nov 2012 14:18:30 -0800
Received: from PIO-MLT-06.exchange.corp.microsoft.com (157.54.94.24) by DFM-TK5MBX15-01.exchange.corp.microsoft.com (157.54.110.8) with Microsoft SMTP Server (TLS) id 15.0.516.32; Mon, 19 Nov 2012 14:18:30 -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.0111.000; Mon, 19 Nov 2012 14:18: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: AQHNxqESg1bk/4n40EGcCJKJSpfnw5fxtV0Q
Date: Mon, 19 Nov 2012 22:18:29 +0000
Message-ID: <3020AC5E95452D43B5D8D0FB02F881D30A6DA4@DF-M14-10.exchange.corp.microsoft.com>
References: <DCD8C7A5A8B3E844AA2E2CBE327CDC92013D21D4@E10MB3.tituscorp.local> <002601cdc6a0$fa38dcf0$eeaa96d0$@augustcellars.com>
In-Reply-To: <002601cdc6a0$fa38dcf0$eeaa96d0$@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.16]
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:(51704002)(377454001)(13464001)(47776002)(47736001)(33656001)(46406002)(31966008)(44976002)(56776001)(46102001)(47976001)(23726001)(56816002)(876001)(50986001)(51856001)(47446002)(76482001)(74502001)(53806001)(54316002)(74662001)(49866001)(5343655001)(50466001)(16406001)(4396001)(15202345002)(54356001)(55846005); DIR:OUT; SFP:; LANG:en;
X-Forefront-PRVS: 067071EFC8
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: Mon, 19 Nov 2012 22:19:56 -0000

Hi Jim,

Let me restate things to see if I understood you correctly.

The list of recipient is one per message not one per policy. While one or more policies may require the list be supplied; only one list would be included in the GetCMSToken request via the recipient structure. 

< Recipient>
<Subject>lisa@simpsons.com</Subject>;
</Recipient>
< Recipient>
<Subject>bart@simpsons.com</Subject>;
</Recipient>

Policies may also require that lock boxes be generated for receipts rather than supply the CEK to the Plasma server. In that instance, the list of receipts together with the associated lock box would be included in the GetCMSToken request. 

< Recipient>
<Subject>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