From Ed.Simon@titus.com Wed Nov 7 18:38:31 2012 Return-Path: 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 130E221F88E9 for ; Wed, 7 Nov 2012 18:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 LkbKe6LSQ51J for ; Wed, 7 Nov 2012 18:38:30 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.250.242]) by ietfa.amsl.com (Postfix) with ESMTP id A5BA221F884B for ; Wed, 7 Nov 2012 18:38:30 -0800 (PST) Received: from [216.82.249.19:21691] by server-15.bemta-12.messagelabs.com id 67/EB-27665-62B1B905; Thu, 08 Nov 2012 02:38:30 +0000 X-Env-Sender: Ed.Simon@titus.com X-Msg-Ref: server-15.tower-137.messagelabs.com!1352342308!8417273!1 X-Originating-IP: [67.210.173.99] X-StarScan-Received: X-StarScan-Version: 6.6.1.8; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23183 invoked from network); 8 Nov 2012 02:38:29 -0000 Received: from 67-210-173.99.static.tel-ott.com (HELO snakeskin.titus.com) (67.210.173.99) by server-15.tower-137.messagelabs.com with AES128-SHA encrypted SMTP; 8 Nov 2012 02:38:29 -0000 Received: from E10MB3.tituscorp.local ([fe80::84f4:cfbe:f32f:9a5]) by E10CH2.tituscorp.local ([192.168.200.107]) with mapi id 14.03.0099.000; Wed, 7 Nov 2012 21:38:27 -0500 From: Ed Simon To: "plasma@ietf.org" Thread-Topic: Replacing occurences of GetSendCMSToken with GetCMSToken Thread-Index: Ac29WiHX0hxL3l35QSOXoIlYmRy/dw== Date: Thu, 8 Nov 2012 02:38:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [plasma] Replacing occurences of GetSendCMSToken with GetCMSToken X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 02:38:31 -0000 In the trust processing specification, GetSendCMSToken and GetCMSToken are = used interchangeably though it seems to me that only one form should be use= d (I suggest GetCMSToken). Ed= From alan.b.borland@googlemail.com Thu Nov 8 03:45:39 2012 Return-Path: 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 E775F21F8B06 for ; Thu, 8 Nov 2012 03:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 95XTvYIrGZUm for ; Thu, 8 Nov 2012 03:45:38 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 58F0121F8ACD for ; Thu, 8 Nov 2012 03:45:38 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so2061333pad.31 for ; Thu, 08 Nov 2012 03:45:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=0gmT8pIekqPb6U6zB7STsDvzajsmeSIl7CNoiVXyB/8=; b=rZVVwX/8xO+kdqPlgUCj6mSPdYBRFjwCvs7eePVf0AvnhXfw9lvwPQ7tAbKYKyCd6X iz7+JUBnSV3He+mO8sMS8VqX0luKynEr8e+g1gLbd+55VAA3LZ6TGAA4zQU329suC6hl +jDBlIT7mFOgjHJUaEQHsJ2XPWr2fIDFH/WUA2k+m88bHD0HwFQveqWK2Lsxftcu4MHY 1vvI2Xr27uddOVgLoLgABXoYS+mUmu6lscJdYwgue0GAtyu+3HWy3eCvcv3gjzJ7PHrM lZt6xsHWmB/g99iG4cKGKR/Mo/+EyA/NKjLx6/qC2xd4DIw9bidut9dJyh57sipVCCqf k1wQ== MIME-Version: 1.0 Received: by 10.68.223.37 with SMTP id qr5mr23167590pbc.101.1352375138174; Thu, 08 Nov 2012 03:45:38 -0800 (PST) Received: by 10.66.230.232 with HTTP; Thu, 8 Nov 2012 03:45:38 -0800 (PST) Date: Thu, 8 Nov 2012 11:45:38 +0000 Message-ID: From: Alan Borland To: plasma@ietf.org Content-Type: multipart/alternative; boundary=047d7b1601f1b6c52704cdfa5f31 Subject: [plasma] GetRoleToken or GetRoleTokens? X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 11:45:39 -0000 --047d7b1601f1b6c52704cdfa5f31 Content-Type: text/plain; charset=ISO-8859-1 In draft-schaad-plasma-service-03: - Section 7.1 uses 'GetRoleToken' - Appendix B uses 'GetRoleTokens' For our prototyping exercise we have been using 'GetRoleToken' Alan. --047d7b1601f1b6c52704cdfa5f31 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In draft-schaad-plasma-service-03:
=A0
- Section 7= .1 uses 'GetRoleToken'
=A0
- Appendix B uses &#= 39;GetRoleTokens'
=A0
For our prototyping exercise = we have=A0been using 'GetRoleToken'
=A0
Alan.
--047d7b1601f1b6c52704cdfa5f31-- From Ed.Simon@titus.com Thu Nov 8 05:46:44 2012 Return-Path: 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 B1BDA21F8B6A for ; Thu, 8 Nov 2012 05:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.669 X-Spam-Level: X-Spam-Status: No, score=-5.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, 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 jUKqdha5eoy9 for ; Thu, 8 Nov 2012 05:46:44 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.250.242]) by ietfa.amsl.com (Postfix) with ESMTP id 1F85821F8B0C for ; Thu, 8 Nov 2012 05:46:44 -0800 (PST) Received: from [216.82.249.51:49306] by server-7.bemta-12.messagelabs.com id 57/29-32705-3C7BB905; Thu, 08 Nov 2012 13:46:43 +0000 X-Env-Sender: Ed.Simon@titus.com X-Msg-Ref: server-9.tower-190.messagelabs.com!1352382402!9841842!1 X-Originating-IP: [67.210.173.99] X-StarScan-Received: X-StarScan-Version: 6.6.1.8; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14828 invoked from network); 8 Nov 2012 13:46:43 -0000 Received: from 67-210-173.99.static.tel-ott.com (HELO snakeskin.titus.com) (67.210.173.99) by server-9.tower-190.messagelabs.com with AES128-SHA encrypted SMTP; 8 Nov 2012 13:46:43 -0000 Received: from E10MB3.tituscorp.local ([fe80::84f4:cfbe:f32f:9a5]) by E10CH2.tituscorp.local ([192.168.200.107]) with mapi id 14.03.0099.000; Thu, 8 Nov 2012 08:46:41 -0500 From: Ed Simon To: "plasma@ietf.org" Thread-Topic: Correct XACML attribute category for "data" Thread-Index: Ac29t3st9H7PAzlhQ5SjSRHmJKzwsQ== Date: Thu, 8 Nov 2012 13:46:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [plasma] Correct XACML attribute category for "data" X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 13:46:44 -0000 In the PLASMA Trust Processing specification, both the following "data" XAC= ML attribute categories are used (for the same purpose, I believe): In the latest XACML specification [1], there is no "urn:oasis:names:tc:xacm= l:3.0:attribute-category:data" category (and I do not recall there ever has= been), hence I believe it is necessary that PLASMA use "urn:ietf:plasma:at= tribute-category:data" where it is using the (non-existent) OASIS-namespace= d one. [1] http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-cos01-en.html#= _Toc325047260 Ed= From ietf@augustcellars.com Thu Nov 8 07:14:08 2012 Return-Path: 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 D3AE821F887F for ; Thu, 8 Nov 2012 07:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.349 X-Spam-Level: X-Spam-Status: No, score=-4.349 tagged_above=-999 required=5 tests=[AWL=-0.751, 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 t+HpvQyxL6uT for ; Thu, 8 Nov 2012 07:14:08 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id AACDA21F8460 for ; Thu, 8 Nov 2012 07:14:07 -0800 (PST) Received: from Philemon (dhcp-469b.meeting.ietf.org [130.129.70.155]) (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 11AA938F08; Thu, 8 Nov 2012 07:14:06 -0800 (PST) From: "Jim Schaad" To: "'Alan Borland'" , References: In-Reply-To: Date: Thu, 8 Nov 2012 10:13:58 -0500 Message-ID: <009b01cdbdc3$ae1ef830$0a5ce890$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009C_01CDBD99.C5498C70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFBXqUFK3gkS3ElMDVLmZ7FSnYSIJj4ycUg Content-Language: en-us Subject: Re: [plasma] GetRoleToken or GetRoleTokens? X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 15:14:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_009C_01CDBD99.C5498C70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit One should always use the schema as the authoritative space for names. I don't always manage to schema check the examples before publishing the document as I don't have a command line schema checker like I do for ASN.1 Let me know when text and schema disagree on the names Jim From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of Alan Borland Sent: Thursday, November 08, 2012 6:46 AM To: plasma@ietf.org Subject: [plasma] GetRoleToken or GetRoleTokens? In draft-schaad-plasma-service-03: - Section 7.1 uses 'GetRoleToken' - Appendix B uses 'GetRoleTokens' For our prototyping exercise we have been using 'GetRoleToken' Alan. ------=_NextPart_000_009C_01CDBD99.C5498C70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

One should always use the schema as the authoritative space for = names.  I don’t always manage to schema check the examples = before publishing the document as I don’t have a command line = schema checker like I do for ASN.1

 

Let me know when text and schema disagree on the = names

 

Jim

 

 

From:= = plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of = Alan Borland
Sent: Thursday, November 08, 2012 6:46 = AM
To: plasma@ietf.org
Subject: [plasma] = GetRoleToken or GetRoleTokens?

 

In = draft-schaad-plasma-service-03:

 

- = Section 7.1 uses 'GetRoleToken'

 

- = Appendix B uses 'GetRoleTokens'

 

For our prototyping exercise we have been using = 'GetRoleToken'

 

Alan.

------=_NextPart_000_009C_01CDBD99.C5498C70-- From jimsch@nwlink.com Mon Nov 5 07:17:09 2012 Return-Path: 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 6E32221F868E for ; Mon, 5 Nov 2012 07:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 8yDBQCtRZMuB for ; Mon, 5 Nov 2012 07:17:08 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 62F9321F867A for ; Mon, 5 Nov 2012 07:17:08 -0800 (PST) Received: from Philemon (dhcp-120b.meeting.ietf.org [130.129.18.11]) (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 A62A738F03; Mon, 5 Nov 2012 07:17:07 -0800 (PST) From: "Jim Schaad" To: "'Ed Simon'" , References: In-Reply-To: Date: Mon, 5 Nov 2012 10:17:00 -0500 Message-ID: <010501cdbb68$9b32c100$d1984300$@nwlink.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG3i8JPK9ICz89gW5HudViwMnrPf5gHtiXQ Content-Language: en-us X-Mailman-Approved-At: Thu, 08 Nov 2012 07:17:48 -0800 Subject: Re: [plasma] Clarification of specifying WS-Trust tokens in the PLASMA authentication element X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:17:09 -0000 Sorry for the delay on getting back, we have been really busy at the winery for the last couple of weeks. We have a choice between using our own name and referencing the type or reusing the same name and type from the WS Trust specification. Which is chosen is going to be just a question of style and a question of what that referenced specification looks as being a top level element. However in this case, there are differences between what is specified in this document and what is specified for wst:RequestedSecurityToken, specifically the addition of the tokenType parameter. We could alternatively defined this as I would not object to doing the change to the latter structure, but it is not a direct mapping currently. Jim > -----Original Message----- > From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On > Behalf Of Ed Simon > Sent: Wednesday, October 24, 2012 4:05 PM > To: plasma@ietf.org > Subject: [plasma] Clarification of specifying WS-Trust tokens in the PLASMA > authentication element > > The "Plasma Service Trust Processing" document includes a fragment of an > XML Schema describing the element as such: > > > > > .. > > > > > > > > > > .. > > I presume, based on the text of the "Plasma Service Trust Processing" > document, that the "WS-Token" is actually supposed to be the > > /wst:RequestSecurityTokenResponse/wst:RequestedSecurityToken > > described in trust-1.4-errata01-complete.html>. Correct? If so, the XML Schema in the > "Plasma Service Trust Processing" document needs to be adjusted to > something like . Also, with > respect to the "XML Nomenclature and Name Spaces" table, should we be > not be using this namespace > > http://docs.oasis-open.org/ws-sx/ws-trust/200802 > > for WS-Trust 1.4? > > Ed > _______________________________________________ > plasma mailing list > plasma@ietf.org > https://www.ietf.org/mailman/listinfo/plasma From Ed.Simon@titus.com Sat Nov 10 06:50:30 2012 Return-Path: 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 08ED521F846B for ; Sat, 10 Nov 2012 06:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.133 X-Spam-Level: X-Spam-Status: No, score=-6.133 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, 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 SzYm-bZk7OCn for ; Sat, 10 Nov 2012 06:50:29 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.255.50]) by ietfa.amsl.com (Postfix) with ESMTP id 4682F21F8462 for ; Sat, 10 Nov 2012 06:50:29 -0800 (PST) Received: from [216.82.254.227:34033] by server-1.bemta-7.messagelabs.com id E9/65-24120-4B96E905; Sat, 10 Nov 2012 14:50:28 +0000 X-Env-Sender: Ed.Simon@titus.com X-Msg-Ref: server-5.tower-202.messagelabs.com!1352559026!9956430!1 X-Originating-IP: [67.210.173.99] X-StarScan-Received: X-StarScan-Version: 6.6.1.8; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24290 invoked from network); 10 Nov 2012 14:50:27 -0000 Received: from 67-210-173.99.static.tel-ott.com (HELO snakeskin.titus.com) (67.210.173.99) by server-5.tower-202.messagelabs.com with AES128-SHA encrypted SMTP; 10 Nov 2012 14:50:27 -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; Sat, 10 Nov 2012 09:50:24 -0500 From: Ed Simon To: Jim Schaad , 'Alan Borland' , "plasma@ietf.org" Thread-Topic: [plasma] GetRoleToken or GetRoleTokens? Thread-Index: AQHNvaaoyazTj0FLX0mJ1gUDGl9Q/ZfgX94AgALHsns= Date: Sat, 10 Nov 2012 14:50:24 +0000 Message-ID: References: , <009b01cdbdc3$ae1ef830$0a5ce890$@augustcellars.com> In-Reply-To: <009b01cdbdc3$ae1ef830$0a5ce890$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.1] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [plasma] GetRoleToken or GetRoleTokens? X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 14:50:30 -0000 OK, but the schema does not cover many of the naming issues such as when th= e PLASMA schema references external schemas (such as SAML, XACML, etc.) and= the specification, but not the schema, requires certain values to be used = in those external structures. For Alan's question, the question is what should be the value of the XACML = action-id attribute; that is not specified in the schema (unless I missed i= t, though I agree the PLASMA-specific element is). For my question about the XACML category for PLASMA data, that= also is not defined in the PLASMA schema, correct? Ed ________________________________________ From: plasma-bounces@ietf.org [plasma-bounces@ietf.org] on behalf of Jim Sc= haad [ietf@augustcellars.com] Sent: Thursday, November 08, 2012 10:13 To: 'Alan Borland'; plasma@ietf.org Subject: Re: [plasma] GetRoleToken or GetRoleTokens? One should always use the schema as the authoritative space for names. I d= on=92t always manage to schema check the examples before publishing the doc= ument as I don=92t have a command line schema checker like I do for ASN.1 Let me know when text and schema disagree on the names Jim From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of= Alan Borland Sent: Thursday, November 08, 2012 6:46 AM To: plasma@ietf.org Subject: [plasma] GetRoleToken or GetRoleTokens? In draft-schaad-plasma-service-03: - Section 7.1 uses 'GetRoleToken' - Appendix B uses 'GetRoleTokens' For our prototyping exercise we have been using 'GetRoleToken' Alan. From Ed.Simon@titus.com Sat Nov 17 13:07:06 2012 Return-Path: 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 D13DA21F84D0 for ; Sat, 17 Nov 2012 13:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.288 X-Spam-Level: X-Spam-Status: No, score=-6.288 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, 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 G2SClhdYG61V for ; Sat, 17 Nov 2012 13:07:06 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.250.242]) by ietfa.amsl.com (Postfix) with ESMTP id 320EF21F84CA for ; Sat, 17 Nov 2012 13:07:06 -0800 (PST) Received: from [216.82.249.35:10485] by server-12.bemta-12.messagelabs.com id 8A/92-09292-97CF7A05; Sat, 17 Nov 2012 21:07:05 +0000 X-Env-Sender: Ed.Simon@titus.com X-Msg-Ref: server-11.tower-138.messagelabs.com!1353186424!10147714!1 X-Originating-IP: [67.210.173.99] X-StarScan-Received: X-StarScan-Version: 6.6.1.8; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9133 invoked from network); 17 Nov 2012 21:07:05 -0000 Received: from 67-210-173.99.static.tel-ott.com (HELO snakeskin.titus.com) (67.210.173.99) by server-11.tower-138.messagelabs.com with AES128-SHA encrypted SMTP; 17 Nov 2012 21:07:05 -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; Sat, 17 Nov 2012 16:07:04 -0500 From: Ed Simon To: "plasma@ietf.org" Thread-Topic: Clarification of how client applications handle the LockBox in client in elements Thread-Index: Ac3FB35SonDRZ33PRKGGX29wjdBweg== Date: Sat, 17 Nov 2012 21:07:03 +0000 Message-ID: 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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [plasma] Clarification of how client applications handle the LockBox in client in 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 21:07:06 -0000 Based on discussions with others on this mailing list, and http://www.ietf.org/mail-archive/web/plasma/current/msg00118.html ...I have drawn up the following three scenarios regarding the construction= of the element sent to the PLASMA Server by the Sending Agen= t, and the construction of the LockBox by the PLASMA Server. Does what I've described in these scenarios, particularly Scenario B in whi= ch 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=20 =93Additionally 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.=94=20 in the PLASMA Service CMS Processing v2 document. Here are the scenarios: Scenario A: The Sending Agent does NOT share the CEK with the PLASMA server= and specifies a limited set of recipients who can decrypt the message (for= example, due to section 7.2.2 of PLASMA Service Trust processing v3). Sending Agent: In the element of the PLASMA Request, the send= er will construct a list specifying, for each recipient, both t= he element (to identify the recipient), and the element= to contain the encrypted CEK for that recipient (encrypted so only that re= cipient can decrypt it). There will be no element. PLASMA Server: Will construct an ASN.1 PLASMA LockBox (as described in PLAS= MA Service CMS Processing v2). The LockBox constructed by the PLASMA Server= will comprise, in the namedRecipients, the LockBox-es provided by the Send= ing Agent. There will be no defaultRecipients structure. Note that in this = scenario, the PLASMA Server will not be able, barring further communication= with the Sending Agent, be able to supplement the list of recipients. Scenario B: The sender shares the CEK with the PLASMA server and specifies = a limited set of recipients who can decrypt the message (for example, again= , due to section 7.2.2 of PLASMA Trust processing). For each recipient spec= ified, there may or may not be a LockBox specified by the Sending Agent.=20 Sending Agent: In the element of the PLASMA Request, the send= er will construct a list specifying, for each recipient, both t= he element (to identify the recipient), and, optionally, the element to contain the encrypted CEK for that recipient (encrypted so= only that recipient can decrypt it). The Sending Agent will also construct= a 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 w= ill create a LockBox for that recipient to populate the namedRecipients str= ucture. It will also create a defaultRecipients structure using the CEK pro= vided by the Sending Agent. Note that in this scenario, the PLASMA Server w= ill be able to, independently of the Sending Agent, be able to supplement t= he list of recipients. Note that for Scenario B, the schema definition for the element w= ill need to have the attribute minOccurs=3D0. Scenario C: The Sending Agent shares the CEK with the PLASMA server and doe= s NOT specify any recipients.=20 Sending Agent: The Sending Agent will also construct a element to con= tain the CEK; no element will be created. PLASMA Server: The PLASMA Server will also create a defaultRecipients struc= ture using the CEK provided by the Sending Agent; it may or may not create = a namedRecipients structure (populated independently of the Sending Agent).= As in Scenario B, the PLASMA Server will be able to, independently of the = Sending Agent, be able to supplement the list of recipients. From ietf@augustcellars.com Mon Nov 19 13:58:25 2012 Return-Path: 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 548B521F863A for ; Mon, 19 Nov 2012 13:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 OjaADcMqUHxw for ; Mon, 19 Nov 2012 13:58:24 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id A389A21F85B0 for ; Mon, 19 Nov 2012 13:58:24 -0800 (PST) Received: from Philemon (70-89-128-250-totalnet-northwest-wa.hfc.comcastbusiness.net [70.89.128.250]) (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 3221A38F28; Mon, 19 Nov 2012 13:58:24 -0800 (PST) From: "Jim Schaad" To: "'Ed Simon'" , References: In-Reply-To: Date: Mon, 19 Nov 2012 13:58:11 -0800 Message-ID: <002601cdc6a0$fa38dcf0$eeaa96d0$@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+ivF6IKZlQatjg Content-Language: en-us Subject: Re: [plasma] Clarification of how client applications handle the LockBox in client in 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 21:58:25 -0000 > -----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 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 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 element of the PLASMA Request, > the sender will construct a list specifying, for each recipient, both > the element (to identify the recipient), and the > element to contain the encrypted CEK for that recipient (encrypted so only > that recipient can decrypt it). There will be no 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 element of the PLASMA Request, > the sender will construct a list specifying, for each recipient, both > the element (to identify the recipient), and, optionally, the > element to contain the encrypted CEK for that recipient > (encrypted so only that recipient can decrypt it). The Sending Agent will also > construct a 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 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 element to > contain the CEK; no 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 From trevorf@exchange.microsoft.com Mon Nov 19 14:19:56 2012 Return-Path: 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 ; 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 ; 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 ; 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 To: Jim Schaad , 'Ed Simon' , "plasma@ietf.org" Thread-Topic: [plasma] Clarification of how client applications handle the LockBox in client in 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: <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 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 m= ore policies may require the list be supplied; only one list would be inclu= ded in the GetCMSToken request via the recipient structure.=20 < Recipient> lisa@simpsons.com < Recipient> bart@simpsons.com 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 rec= eipts together with the associated lock box would be included in the GetCMS= Token request.=20 < Recipient> lisa@simpsons.com 123456789 < Recipient> bart@simpsons.com abcdef 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 L= ockBox in client in elements > -----Original Message----- > From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On=20 > 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=20 > the LockBox in client in elements >=20 > Based on discussions with others on this mailing list, and >=20 > http://www.ietf.org/mail-archive/web/plasma/current/msg00118.html >=20 > ...I have drawn up the following three scenarios regarding the construction of > the element sent to the PLASMA Server by the Sending=20 > Agent, and the construction of the LockBox by the PLASMA Server. >=20 > Does what I've described in these scenarios, particularly Scenario B=20 > in which > the Sending Agent leaves it to the PLASMA Server to construct a=20 > 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 entit= ies such as virus checking gateways in a mail system. The lockboxes that a= re being returned with here are placed parallel to the Plasma Lockbox in th= e CMS Enveloped data object and are not embedded into the lockbox created b= y the Plasma server. >=20 > Here are the scenarios: >=20 > Scenario A: The Sending Agent does NOT share the CEK with the PLASMA=20 > 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)= . >=20 > Sending Agent: In the element of the PLASMA Request, the=20 > sender will construct a list specifying, for each recipient, both > the element (to identify the recipient), and the =20 > element to contain the encrypted CEK for that recipient (encrypted so=20 > only that recipient can decrypt it). There will be no element. >=20 > PLASMA Server: Will construct an ASN.1 PLASMA LockBox (as described in=20 > PLASMA Service CMS Processing v2). The LockBox constructed by the=20 > PLASMA Server will comprise, in the namedRecipients, the LockBox-es=20 > provided by the Sending Agent. There will be no defaultRecipients structure. > Note that in this scenario, the PLASMA Server will not be able,=20 > barring further > communication with the Sending Agent, be able to supplement the list=20 > of recipients. This looks correct >=20 > Scenario B: The sender shares the CEK with the PLASMA server and=20 > specifies a limited set of recipients who can decrypt the message (for=20 > example, again, > due to section 7.2.2 of PLASMA Trust processing). For each recipient=20 > specified, there may or may not be a LockBox specified by the Sending=20 > Agent. >=20 > Sending Agent: In the element of the PLASMA Request, the=20 > sender will construct a list specifying, for each recipient, both > the element (to identify the recipient), and, optionally,=20 > the element to contain the encrypted CEK for that recipient=20 > (encrypted so only that recipient can decrypt it). The Sending Agent=20 > will also > construct a element to contain the CEK. >=20 > PLASMA Server: Where a LockBox for a recipient was specified by the=20 > Sending Agent, it will be treated as in Scenario A; otherwise, the=20 > PLASMA Server will create a LockBox for that recipient to populate the=20 > namedRecipients structure. It will 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 Agent, be=20 > able to supplement the list of recipients. >=20 > Note that for Scenario B, the schema definition for the =20 > 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 reci= pients 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 Plasm= a 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 ser= ver. >=20 > Scenario C: The Sending Agent shares the CEK with the PLASMA server=20 > and does NOT specify any recipients. >=20 > Sending Agent: The Sending Agent will also construct a element=20 > to contain the CEK; no element will be created. >=20 > PLASMA Server: The PLASMA Server will also create a defaultRecipients=20 > structure using the CEK provided by the Sending Agent; it may or may=20 > not create a namedRecipients structure (populated independently of the=20 > Sending Agent). As in Scenario B, the PLASMA Server will be able to,=20 > independently of the Sending Agent, be able to supplement the list of=20 > recipients. This is what I would expect to see. Jim >=20 > _______________________________________________ > 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 Mon Nov 19 20:10:57 2012 Return-Path: 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 ; 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 ; 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 ; 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" To: "'Trevor Freeman'" , "'Ed Simon'" , References: <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 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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> > lisa@simpsons.com > > < Recipient> > bart@simpsons.com > 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 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> > lisa@simpsons.com > 123456789 > > < Recipient> > bart@simpsons.com > abcdef > > > 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 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 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 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 element of the PLASMA Request, > the > > sender will construct a list specifying, for each > recipient, both > > the element (to identify the recipient), and the > > element to contain the encrypted CEK for that recipient (encrypted so > > only that recipient can decrypt it). There will be no 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 element of the PLASMA Request, > the > > sender will construct a list specifying, for each > recipient, both > > the element (to identify the recipient), and, optionally, > > the element to contain the encrypted CEK for that recipient > > (encrypted so only that recipient can decrypt it). The Sending Agent > > will > also > > construct a 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 > > 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 element > > to contain the CEK; no 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 From trevorf@exchange.microsoft.com Tue Nov 20 14:48:57 2012 Return-Path: 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 CDFC921F8808 for ; Tue, 20 Nov 2012 14:48:57 -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 hVMv9ykorNWQ for ; Tue, 20 Nov 2012 14:48:56 -0800 (PST) Received: from NA01-BY1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.92]) by ietfa.amsl.com (Postfix) with ESMTP id A725221F8691 for ; Tue, 20 Nov 2012 14:48:56 -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.568.2; Tue, 20 Nov 2012 22:48: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; Tue, 20 Nov 2012 22:48: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; Tue, 20 Nov 2012 22:48:50 +0000 Received: from DFM-TK5MBX15-02.exchange.corp.microsoft.com (157.54.110.9) by DF-G14-01.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 14.3.111.0; Tue, 20 Nov 2012 14:46:30 -0800 Received: from PIO-MLT-06.exchange.corp.microsoft.com (157.54.94.24) by DFM-TK5MBX15-02.exchange.corp.microsoft.com (157.54.110.9) with Microsoft SMTP Server (TLS) id 15.0.516.32; Tue, 20 Nov 2012 14:46: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; Tue, 20 Nov 2012 14:46:29 -0800 From: Trevor Freeman To: Jim Schaad , 'Ed Simon' , "plasma@ietf.org" Thread-Topic: [plasma] Clarification of how client applications handle the LockBox in client in elements Thread-Index: AQHNxqESg1bk/4n40EGcCJKJSpfnw5fxtV0QgADtggCAAK5toA== Date: Tue, 20 Nov 2012 22:46:29 +0000 Message-ID: <3020AC5E95452D43B5D8D0FB02F881D30A77B8@DF-M14-10.exchange.corp.microsoft.com> References: <002601cdc6a0$fa38dcf0$eeaa96d0$@augustcellars.com> <3020AC5E95452D43B5D8D0FB02F881D30A6DA4@DF-M14-10.exchange.corp.microsoft.com> <005d01cdc6d5$04f967c0$0eec3740$@augustcellars.com> In-Reply-To: <005d01cdc6d5$04f967c0$0eec3740$@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; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(13464001)(51704002)(74502001)(51856001)(15202345002)(47446002)(16406001)(33656001)(44976002)(23726001)(49866001)(47776002)(876001)(54356001)(74662001)(47976001)(4396001)(5343635001)(76482001)(50986001)(50466001)(53806001)(56776001)(46406002)(47736001)(46102001)(31966008)(5343655001)(54316002)(56816002)(55846005); DIR:OUT; SFP:; LANG:en; X-Forefront-PRVS: 0671F32598 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 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 22:48:57 -0000 Hi Jim, The list of recipients for a message is a single list per message. There ar= e no policy dependent recipient lists. The need for the list is policy dep= endent 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.=20 We have a per-message recipient list structure defined. If the lock box ele= ment 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 recipi= ent list with lock boxes.=20 Trevor -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com]=20 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 L= ockBox in client in 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=20 > the LockBox in client in elements >=20 > Hi Jim, >=20 > Let me restate things to see if I understood you correctly. >=20 > The list of recipient is one per message not one per policy. While one=20 > or more > policies may require the list be supplied; only one list would be=20 > included in > the GetCMSToken request via the recipient structure. >=20 > < Recipient> > lisa@simpsons.com > > < Recipient> > bart@simpsons.com > 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. Thi= s supports a mode where the Plasma server does not know the CEK. This is done through the 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 wi= ll (normally) be combined with giving a CEK to the server and allowing it t= o determine who gets the CEK back. 3. A recipient lists specific to email may be provided as part of the inpu= t data. This behavior (perhaps not currently in the document) is provided = for the purpose of doing pre-authorization of gateways and is specific to e= mail. Currently the above is better expressed as=20 Policy=3Dbasic Policy BasicPolicy Recipient List is "lisa@simpsons.com bart@simpsons.com" Jim >=20 > Policies may also require that lock boxes be generated for receipts=20 > rather than supply the CEK to the Plasma server. In that instance, the=20 > list of receipts > together with the associated lock box would be included in the=20 > GetCMSToken request. >=20 > < Recipient> > lisa@simpsons.com > 123456789 > > < Recipient> > bart@simpsons.com > abcdef > >=20 > Trevor >=20 > -----Original Message----- > From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On=20 > 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=20 > the LockBox in client in elements >=20 >=20 >=20 > > -----Original Message----- > > From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On=20 > > 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 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 element sent to the PLASMA Server by the Sending=20 > > Agent, and the construction of the LockBox by the PLASMA Server. > > > > Does what I've described in these scenarios, particularly Scenario B=20 > > in > which > > the Sending Agent leaves it to the PLASMA Server to construct a=20 > > 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 th= e > > appropriate keying material." > > in the PLASMA Service CMS Processing v2 document. >=20 > 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=20 > are being returned with here are placed parallel to the Plasma Lockbox=20 > in the CMS Enveloped data object and are not embedded into the lockbox=20 > created by the Plasma server. >=20 > > > > Here are the scenarios: > > > > Scenario A: The Sending Agent does NOT share the CEK with the PLASMA=20 > > 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=20 > > processing v3). > > > > Sending Agent: In the element of the PLASMA Request, > the > > sender will construct a list specifying, for each > recipient, both > > the element (to identify the recipient), and the =20 > > element to contain the encrypted CEK for that recipient (encrypted=20 > > so only that recipient can decrypt it). There will be no element. > > > > PLASMA Server: Will construct an ASN.1 PLASMA LockBox (as described=20 > > in PLASMA Service CMS Processing v2). The LockBox constructed by the=20 > > PLASMA Server will comprise, in the namedRecipients, the LockBox-es=20 > > provided by the Sending Agent. There will be no defaultRecipients > structure. > > Note that in this scenario, the PLASMA Server will not be able,=20 > > barring > further > > communication with the Sending Agent, be able to supplement the list=20 > > of recipients. >=20 > This looks correct >=20 > > > > Scenario B: The sender shares the CEK with the PLASMA server and=20 > > specifies a limited set of recipients who can decrypt the message=20 > > (for example, > again, > > due to section 7.2.2 of PLASMA Trust processing). For each recipient=20 > > specified, there may or may not be a LockBox specified by the=20 > > Sending Agent. > > > > Sending Agent: In the element of the PLASMA Request, > the > > sender will construct a list specifying, for each > recipient, both > > the element (to identify the recipient), and, optionally,=20 > > the element to contain the encrypted CEK for that=20 > > recipient (encrypted so only that recipient can decrypt it). The=20 > > Sending Agent will > also > > construct a element to contain the CEK. > > > > PLASMA Server: Where a LockBox for a recipient was specified by the=20 > > Sending Agent, it will be treated as in Scenario A; otherwise, the=20 > > PLASMA Server will create a LockBox for that recipient to populate=20 > > the namedRecipients structure. It will also create a=20 > > 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 Agent,=20 > > be able to supplement the list of recipients. > > > > Note that for Scenario B, the schema definition for the =20 > > element will need to have the attribute minOccurs=3D0. >=20 > This is not currently an envisioned scenario in terms of the Plasma=20 > server creating the lock boxes at send time. Currently if there is a=20 > list of recipients > that the sender does not create lockboxes for, it is envisioned that=20 > 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 oppose=20 > to returning a > bare key) when the recipient tries to get the key from the server. >=20 > > > > Scenario C: The Sending Agent shares the CEK with the PLASMA server=20 > > and does NOT specify any recipients. > > > > Sending Agent: The Sending Agent will also construct a element=20 > > to contain the CEK; no element will be created. > > > > PLASMA Server: The PLASMA Server will also create a=20 > > defaultRecipients structure using the CEK provided by the Sending=20 > > Agent; it may or may not create a namedRecipients structure=20 > > (populated independently of the Sending Agent). As in Scenario B,=20 > > the PLASMA Server will be able to, independently of the Sending=20 > > Agent, be able to supplement the list of recipients. >=20 > This is what I would expect to see. >=20 > Jim >=20 > > > > _______________________________________________ > > plasma mailing list > > plasma@ietf.org > > https://www.ietf.org/mailman/listinfo/plasma >=20 > _______________________________________________ > plasma mailing list > plasma@ietf.org > https://www.ietf.org/mailman/listinfo/plasma From ietf@augustcellars.com Tue Nov 20 22:40:03 2012 Return-Path: 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 E9AC721F884A for ; Tue, 20 Nov 2012 22:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 CVRY5MyUeuOQ for ; Tue, 20 Nov 2012 22:40:03 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id E112821F8849 for ; Tue, 20 Nov 2012 22:40:02 -0800 (PST) Received: from Philemon (50-39-217-203.bvtn.or.frontiernet.net [50.39.217.203]) (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 C28CF2CA1E; Tue, 20 Nov 2012 22:40:01 -0800 (PST) From: "Jim Schaad" To: "'Trevor Freeman'" , "'Ed Simon'" , References: <002601cdc6a0$fa38dcf0$eeaa96d0$@augustcellars.com> <3020AC5E95452D43B5D8D0FB02F881D30A6DA4@DF-M14-10.exchange.corp.microsoft.com> <005d01cdc6d5$04f967c0$0eec3740$@augustcellars.com> <3020AC5E95452D43B5D8D0FB02F881D30A77B8@DF-M14-10.exchange.corp.microsoft.com> In-Reply-To: <3020AC5E95452D43B5D8D0FB02F881D30A77B8@DF-M14-10.exchange.corp.microsoft.com> Date: Tue, 20 Nov 2012 22:39:48 -0800 Message-ID: <002d01cdc7b3$03c8b110$0b5a1330$@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+ivF6IKQHOr5HmAl5A6eMCpuxtugGlZd0MmQ7IWGA= Content-Language: en-us Subject: Re: [plasma] Clarification of how client applications handle the LockBox in client in 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 06:40:04 -0000 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 rather than 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 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 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 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> > > lisa@simpsons.com > > > > < Recipient> > > bart@simpsons.com > > > > 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 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> > > lisa@simpsons.com > > 123456789 > > > > < Recipient> > > bart@simpsons.com > > abcdef > > > > > > 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 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 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 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 element of the PLASMA Request, > > the > > > sender will construct a list specifying, for each > > recipient, both > > > the element (to identify the recipient), and the > > > element to contain the encrypted CEK for that recipient (encrypted > > > so only that recipient can decrypt it). There will be no 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 element of the PLASMA Request, > > the > > > sender will construct a list specifying, for each > > recipient, both > > > the element (to identify the recipient), and, optionally, > > > the element to contain the encrypted CEK for that > > > recipient (encrypted so only that recipient can decrypt it). The > > > Sending Agent will > > also > > > construct a 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 > > > 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 element > > > to contain the CEK; no 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 From Ed.Simon@titus.com Wed Nov 21 18:53:04 2012 Return-Path: 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 A41B421E8053 for ; Wed, 21 Nov 2012 18:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.066 X-Spam-Level: X-Spam-Status: No, score=-6.066 tagged_above=-999 required=5 tests=[AWL=-0.068, 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 Ie4+2YsRqfFp for ; Wed, 21 Nov 2012 18:53:03 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.255.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7F421E8048 for ; Wed, 21 Nov 2012 18:53:03 -0800 (PST) Received: from [216.82.254.35:10221] by server-2.bemta-7.messagelabs.com id D4/15-29475-E839DA05; Thu, 22 Nov 2012 02:53:02 +0000 X-Env-Sender: Ed.Simon@titus.com X-Msg-Ref: server-9.tower-143.messagelabs.com!1353552779!11814291!1 X-Originating-IP: [67.210.173.99] X-StarScan-Received: X-StarScan-Version: 6.6.1.8; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21100 invoked from network); 22 Nov 2012 02:53:00 -0000 Received: from 67-210-173.99.static.tel-ott.com (HELO snakeskin.titus.com) (67.210.173.99) by server-9.tower-143.messagelabs.com with AES128-SHA encrypted SMTP; 22 Nov 2012 02:53:00 -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, 21 Nov 2012 21:52:59 -0500 From: Ed Simon To: Jim Schaad , 'Trevor Freeman' , "plasma@ietf.org" Thread-Topic: [plasma] Clarification of how client applications handle the LockBox in client in elements Thread-Index: AQHNyFx6QAEfHVE3SUizATOKHQdq7A== Date: Thu, 22 Nov 2012 02:52:58 +0000 Message-ID: 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 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 02:53:04 -0000 I propose, as a strawman proposal, that when policies require the sender's = recipient list, they should be specified through XACML access-subject attri= butes, NOT PLASMA-specific attributes (e.g. within ). M= y position would be that PLASMA should only supplement XACML's pre-defined = attributes where necessary, not create PLASMA-specified attributes where ex= isting XACML-specified attributes are already defined and are sufficient. H= ence my position at the moment is I would NOT change the current PLASMA sem= antics of which is specifically for specifying a lockbox= for a recipient (though I agree with Jim that the name of the element shou= ld be changed to to avoid confusion) and, instead indicate in t= he specification, that when a policy processing depends on knowing the list= of recipients, that those recipients be specified through a XACML category for subjects which specifies the recipients through XACML acc= ess-subject attributes. Besides a list of recipients, I can imagine other policy-specific informati= on that could be used in a GetCMSToken request. Like the list of recipients= , such policy-specific information would also be included through non-PLASM= A-specific, XACML attributes. For example, a XACML request for GetCMSToken which needs to specify the lis= t of recipients and other info could look like this... GetCMSToken hrQ= kL07h1qZhPhgLXKlL0dVeFLAbUVy0no05EGDzK2Q=3D 1BF2BEB249EE8EF2CB373E9800AC6F01 Alice@example.org Bob@example.org Carl@example.org Somethi= ngSomethingSomethingSomething asldkjf= alskdjf32434534543dfjalkscxvkljzv2309080kjlkjlkj 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 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 rather than 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 figur= e 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 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 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 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> > > lisa@simpsons.com > > > > < Recipient> > > bart@simpsons.com > > > > No that is not correct. > > There are three distinct ways that a list of recipients may be supplied t= o 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 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> > > lisa@simpsons.com > > 123456789 > > > > < Recipient> > > bart@simpsons.com > > abcdef > > > > > > 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 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 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 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 recipient= s > > > 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 element of the PLASMA Request, > > the > > > sender will construct a list specifying, for each > > recipient, both > > > the element (to identify the recipient), and the > > > element to contain the encrypted CEK for that recipient (encrypted > > > so only that recipient can decrypt it). There will be no 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 element of the PLASMA Request, > > the > > > sender will construct a list specifying, for each > > recipient, both > > > the element (to identify the recipient), and, optionally, > > > the element to contain the encrypted CEK for that > > > recipient (encrypted so only that recipient can decrypt it). The > > > Sending Agent will > > also > > > construct a 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 > > > 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 element > > > to contain the CEK; no 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 From Ed.Simon@titus.com Sun Nov 25 14:15:05 2012 Return-Path: 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 79D4E21F8695 for ; Sun, 25 Nov 2012 14:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.123 X-Spam-Level: X-Spam-Status: No, score=-5.123 tagged_above=-999 required=5 tests=[AWL=-0.984, BAYES_20=-0.74, 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 3-6NMt2MKKWM for ; Sun, 25 Nov 2012 14:15:04 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.255.50]) by ietfa.amsl.com (Postfix) with ESMTP id D45AA21F8690 for ; Sun, 25 Nov 2012 14:15:03 -0800 (PST) Received: from [216.82.254.35:41090] by server-15.bemta-7.messagelabs.com id CD/4E-23705-66892B05; Sun, 25 Nov 2012 22:15:02 +0000 X-Env-Sender: Ed.Simon@titus.com X-Msg-Ref: server-10.tower-143.messagelabs.com!1353881701!12220184!1 X-Originating-IP: [67.210.173.99] X-StarScan-Received: X-StarScan-Version: 6.6.1.8; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9659 invoked from network); 25 Nov 2012 22:15:02 -0000 Received: from 67-210-173.99.static.tel-ott.com (HELO snakeskin.titus.com) (67.210.173.99) by server-10.tower-143.messagelabs.com with AES128-SHA encrypted SMTP; 25 Nov 2012 22:15:02 -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; Sun, 25 Nov 2012 17:15:01 -0500 From: Ed Simon To: Jim Schaad , 'Trevor Freeman' , "plasma@ietf.org" Thread-Topic: [plasma] Clarification of how client applications handle the LockBox in client in elements Thread-Index: AQHNyFx6QAEfHVE3SUizATOKHQdq7Jf7HC6s Date: Sun, 25 Nov 2012 22:14:59 +0000 Message-ID: References: In-Reply-To: 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 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 22:15:05 -0000 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 par= t of the PLASMA element inside the child element (whic= h identifies the policy the user selects to govern the message/document (sh= ould be renamed to perhaps?)). For attributes that are used to determine whether the user can perform a Ge= tCMSToken request, these should be specified outside the PLASMA element. Reworking my prior example to reflect this design... >>> GetCMSToken Alice@example.org Bob@example.org Carl@example.org hrQ= kL07h1qZhPhgLXKlL0dVeFLAbUVy0no05EGDzK2Q=3D 1BF2BEB249EE8EF2CB373E9800AC6F01 Somethi= ngSomethingSomethingSomething asldkjf= alskdjf32434534543dfjalkscxvkljzv2309080kjlkjlkj <<< Because of the stateless nature of PLASMA, there would also need to be a co= rresponding 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 Sim= on [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 L= ockBox in client in elements I propose, as a strawman proposal, that when policies require the sender's = recipient list, they should be specified through XACML access-subject attri= butes, NOT PLASMA-specific attributes (e.g. within ). M= y position would be that PLASMA should only supplement XACML's pre-defined = attributes where necessary, not create PLASMA-specified attributes where ex= isting XACML-specified attributes are already defined and are sufficient. H= ence my position at the moment is I would NOT change the current PLASMA sem= antics of which is specifically for specifying a lockbox= for a recipient (though I agree with Jim that the name of the element shou= ld be changed to to avoid confusion) and, instead indicate in t= he specification, that when a policy processing depends on knowing the list= of recipients, that those recipients be specified through a XACML category for subjects which specifies the recipients through XACML acc= ess-subject att ributes. Besides a list of recipients, I can imagine other policy-specific informati= on that could be used in a GetCMSToken request. Like the list of recipients= , such policy-specific information would also be included through non-PLASM= A-specific, XACML attributes. For example, a XACML request for GetCMSToken which needs to specify the lis= t of recipients and other info could look like this... GetCMSToken hrQ= kL07h1qZhPhgLXKlL0dVeFLAbUVy0no05EGDzK2Q=3D 1BF2BEB249EE8EF2CB373E9800AC6F01 Alice@example.org Bob@example.org Carl@example.org Somethi= ngSomethingSomethingSomething asldkjf= alskdjf32434534543dfjalkscxvkljzv2309080kjlkjlkj 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 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 rather than 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 figur= e 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 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 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 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> > > lisa@simpsons.com > > > > < Recipient> > > bart@simpsons.com > > > > No that is not correct. > > There are three distinct ways that a list of recipients may be supplied t= o 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 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> > > lisa@simpsons.com > > 123456789 > > > > < Recipient> > > bart@simpsons.com > > abcdef > > > > > > 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 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 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 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 recipient= s > > > 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 element of the PLASMA Request, > > the > > > sender will construct a list specifying, for each > > recipient, both > > > the element (to identify the recipient), and the > > > element to contain the encrypted CEK for that recipient (encrypted > > > so only that recipient can decrypt it). There will be no 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 element of the PLASMA Request, > > the > > > sender will construct a list specifying, for each > > recipient, both > > > the element (to identify the recipient), and, optionally, > > > the element to contain the encrypted CEK for that > > > recipient (encrypted so only that recipient can decrypt it). The > > > Sending Agent will > > also > > > construct a 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 > > > 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 element > > > to contain the CEK; no 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 Sun Nov 25 20:54:49 2012 Return-Path: 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 29B9921F8671 for ; Sun, 25 Nov 2012 20:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 heZ0349hABLk for ; Sun, 25 Nov 2012 20:54:47 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id A0CA621F8687 for ; Sun, 25 Nov 2012 20:54:43 -0800 (PST) Received: from Philemon (50-39-217-203.bvtn.or.frontiernet.net [50.39.217.203]) (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 9081D2CA1F; Sun, 25 Nov 2012 20:54:42 -0800 (PST) From: "Jim Schaad" To: "'Ed Simon'" , "'Trevor Freeman'" , References: In-Reply-To: Date: Sun, 25 Nov 2012 20:54:33 -0800 Message-ID: <014401cdcb92$21497b60$63dc7220$@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: AQHZToL2iFv9G069c1ZHgVd517VEZAK80yWol86f/wA= Content-Language: en-us Subject: Re: [plasma] Clarification of how client applications handle the LockBox in client in 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 04:54:49 -0000 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 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 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 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 element inside the child element > (which identifies the policy the user selects to govern the > message/document (should be renamed to perhaps?)). > > For attributes that are used to determine whether the user can perform a > GetCMSToken request, these should be specified outside the PLASMA > element. > > Reworking my prior example to reflect this design... > > >>> > CombinedDecision="false" ReturnPolicyIdList="false"> > > > > DataType="http://www.w3.org/2001/XMLSchema#string">GetCMSToken AttributeValue> > > > > > DataType="http://www.w3.org/2001/XMLSchema#string"> > > > > > > > xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"> > id"" IncludeInResult="false"> > Alice@example.org > > id"" IncludeInResult="false"> > Bob@example.org > > id"" IncludeInResult="false"> > Carl@example.org > > > > > > > Algorithm ="http://www.w3.org/2001/04/xmlenc#sha256"/> > xmlns="http://www.w3.org/2000/09/xmldsig#">hrQkL07h1qZhPhgLXKlL0dV > eFLAbUVy0no05EGDzK2Q= > > 1BF2BEB249EE8EF2CB373E9800AC6F01 > > > > > > > > > IncludeInResult="false"> > SomethingSomethingSomethingSomething > > IncludeInResult="false"> > asldkjfalskdjf32434534543dfjalkscxvkljzv2309080kjlkjlkj alue> > > > > > <<< > > 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 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 > ). 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 > 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 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 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... > > CombinedDecision="false" ReturnPolicyIdList="false"> > > > DataType="http://www.w3.org/2001/XMLSchema#string">GetCMSToken AttributeValue> > > > > > DataType="http://www.w3.org/2001/XMLSchema#string"> > > > > Algorithm ="http://www.w3.org/2001/04/xmlenc#sha256"/> > xmlns="http://www.w3.org/2000/09/xmldsig#">hrQkL07h1qZhPhgLXKlL0dV > eFLAbUVy0no05EGDzK2Q= > > 1BF2BEB249EE8EF2CB373E9800AC6F01 > > > > > > > > > id"" IncludeInResult="false"> > Alice@example.org > > id"" IncludeInResult="false"> > Bob@example.org > > id"" IncludeInResult="false"> > Carl@example.org > > > > > IncludeInResult="false"> > SomethingSomethingSomethingSomething > > IncludeInResult="false"> > asldkjfalskdjf32434534543dfjalkscxvkljzv2309080kjlkjlkj alue> > > > > > > > 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 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 rather than 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 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 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 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> > > > lisa@simpsons.com > > > > > > < Recipient> > > > bart@simpsons.com > > > > > > > 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 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> > > > lisa@simpsons.com > > > 123456789 > > > > > > < Recipient> > > > bart@simpsons.com > > > abcdef > > > > > > > > > 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 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 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 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 element of the PLASMA > Request, > > > the > > > > sender will construct a list specifying, for each > > > recipient, both > > > > the element (to identify the recipient), and the > > > > element to contain the encrypted CEK for that recipient > > > > (encrypted so only that recipient can decrypt it). There will be > > > > no > 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 element of the PLASMA > Request, > > > the > > > > sender will construct a list specifying, for each > > > recipient, both > > > > the element (to identify the recipient), and, > > > > optionally, the element to contain the encrypted CEK for > > > > that recipient (encrypted so only that recipient can decrypt it). > > > > The Sending Agent will > > > also > > > > construct a 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 > > > > 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 > > > > element to contain the CEK; no 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 Tue Nov 27 15:43:55 2012 Return-Path: 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 2464A21F856F for ; Tue, 27 Nov 2012 15:43:55 -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 nnnFnkyqDPqv for ; Tue, 27 Nov 2012 15:43:53 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.250.242]) by ietfa.amsl.com (Postfix) with ESMTP id E4D7521F8528 for ; Tue, 27 Nov 2012 15:43:52 -0800 (PST) Received: from [216.82.249.35:53232] by server-4.bemta-12.messagelabs.com id A4/42-06582-83055B05; Tue, 27 Nov 2012 23:43:52 +0000 X-Env-Sender: Ed.Simon@titus.com X-Msg-Ref: server-9.tower-138.messagelabs.com!1354059830!9605530!1 X-Originating-IP: [67.210.173.99] X-StarScan-Received: X-StarScan-Version: 6.6.1.8; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8266 invoked from network); 27 Nov 2012 23:43:51 -0000 Received: from 67-210-173.99.static.tel-ott.com (HELO snakeskin.titus.com) (67.210.173.99) by server-9.tower-138.messagelabs.com with AES128-SHA encrypted SMTP; 27 Nov 2012 23:43:51 -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; Tue, 27 Nov 2012 18:43:50 -0500 From: Ed Simon To: Jim Schaad , 'Trevor Freeman' , "plasma@ietf.org" Thread-Topic: [plasma] Clarification of how client applications handle the LockBox in client in elements Thread-Index: AQHNyFx6QAEfHVE3SUizATOKHQdq7Jf7HC6sgADLK4CAAnMyCQ== Date: Tue, 27 Nov 2012 23:43:49 +0000 Message-ID: References: , <014401cdcb92$21497b60$63dc7220$@augustcellars.com> In-Reply-To: <014401cdcb92$21497b60$63dc7220$@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 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 23:43:55 -0000 Reworking the example, I've replaced with / (= re-using the PolicyType structure defined for the GetRolesToken; but using = the PolicyID attribute and replacing the PolicyType element with (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 specifies what the sender needs to specif= y). For composite policies, I would rename the GetCMSToken > > > < Recipient> > > > bart@simpsons.com > > > > > > > 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 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> > > > lisa@simpsons.com > > > 123456789 > > > > > > < Recipient> > > > bart@simpsons.com > > > abcdef > > > > > > > > > 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 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 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 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 element of the PLASMA > Request, > > > the > > > > sender will construct a list specifying, for each > > > recipient, both > > > > the element (to identify the recipient), and the > > > > element to contain the encrypted CEK for that recipient > > > > (encrypted so only that recipient can decrypt it). There will be > > > > no > 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 element of the PLASMA > Request, > > > the > > > > sender will construct a list specifying, for each > > > recipient, both > > > > the element (to identify the recipient), and, > > > > optionally, the element to contain the encrypted CEK for > > > > that recipient (encrypted so only that recipient can decrypt it). > > > > The Sending Agent will > > > also > > > > construct a 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 > > > > 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 > > > > element to contain the CEK; no 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