From Ed.Simon@titus.com Wed Oct 3 19:03: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 E798E1F0C80 for ; Wed, 3 Oct 2012 19:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 KcSaIcAEPUht for ; Wed, 3 Oct 2012 19:03:05 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.255.50]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9231F0C84 for ; Wed, 3 Oct 2012 19:03:04 -0700 (PDT) Received: from [216.82.254.227:51389] by server-7.bemta-7.messagelabs.com id CC/CF-04534-85EEC605; Thu, 04 Oct 2012 02:03:04 +0000 X-Env-Sender: Ed.Simon@titus.com X-Msg-Ref: server-12.tower-202.messagelabs.com!1349316182!14743417!1 X-Originating-IP: [67.210.173.99] X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17996 invoked from network); 4 Oct 2012 02:03:03 -0000 Received: from 67-210-173.99.static.tel-ott.com (HELO snakeskin.titus.com) (67.210.173.99) by server-12.tower-202.messagelabs.com with AES128-SHA encrypted SMTP; 4 Oct 2012 02:03:03 -0000 Received: from E10MB3.tituscorp.local ([fe80::84f4:cfbe:f32f:9a5]) by E10CH1.tituscorp.local ([192.168.200.115]) with mapi id 14.03.0083.000; Wed, 3 Oct 2012 22:03:01 -0400 From: Ed Simon To: Jim Schaad , "plasma@ietf.org" Thread-Topic: [plasma] Clarification of how client applications handle the LockBox in client in elements Thread-Index: Ac2SFfmCa9Xxrf87RGaEESJmUK5LWwJaKH0AAZUhI/Y= Date: Thu, 4 Oct 2012 02:03:00 +0000 Message-ID: References: , <010b01cd9b5d$19d92f20$4d8b8d60$@nwlink.com> In-Reply-To: <010b01cd9b5d$19d92f20$4d8b8d60$@nwlink.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="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, 04 Oct 2012 02:03:06 -0000 Thanks Jim, That does help clarify the specifications. For additional clarity, I think = it might be helpful, for each of the scenarios you list, and the one where = the client agent specifies both recipientInfos and the content encryption k= ey (the spec indicates both may be specified in the same Send request, thou= gh in some ways they seem mutually exclusive), to have a specific list of s= teps with each step pointing to which sections of the two specifications ar= e applicable. Ed ________________________________________ From: Jim Schaad [jimsch@nwlink.com] Sent: Tuesday, September 25, 2012 16:33 To: Ed Simon; plasma@ietf.org Subject: RE: [plasma] Clarification of how client applications handle the L= ockBox in client in elements I apologize for the delay, I have been doing more traveling than I expected= . Would the following text make things clearer? \ Jim When sending a Plasma enabled message, there are three different classes of recipients that need to be considered. The information sent for these thre= e classes differs. The three classes are: 1. No Policy Protection - These recipients are those for which no Plasma policy protection is to be applied. Often times the sender of the message will fall into this class of recipient. For recipients in this class the Plasma server is not involved, the sender creates a lock box as if the Plasma server was not present and places the lock box in to the recipient info structure as normal. 2. Policy protected for a specific recipient - This case exists to allow a message to be policy protected, but also not allow the policy server to any access to the message. For recipients of this class access can be denied t= o existing recipients by the Plasma server, but new recipients cannot be adde= d to the list. For recipients in this class, the sender agent builds a norma= l recipient info structure for the recipient, but instead of placing it in th= e message direct, it is given to the Plasma server along with the policy to b= e satisfied before the lock box is released to the recipient. The Plasma server includes this recipient inside of the Plasma lock box which is returned to the sender for inclusion in the recipient info structure. 3. Policy Protected generic recipient - These recipients are those for which the inclusion in the group of individuals able to decrypt the message is based solely on the policy. For these recipients, the sender supplies the Plasma server with the policy to be applied for inclusion as a recipien= t and the content encryption key. The server then returns this information i= n it's Plasma encrypted lock box for inclusion in the recipient info structure. This recipient class must be used if a server is going to do pre-approval of recipients as described in section XXX of [Requirements]. > -----Original Message----- > From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On > Behalf Of Ed Simon > Sent: Thursday, September 13, 2012 6:12 PM > To: plasma@ietf.org > Subject: [plasma] Clarification of how client applications handle the LockBox > in client in elements > > I would like to see the clarification of how client applications handle the > LockBox. In section 8.1.1 of Plasma Service Trust Processing, which describes > the XML request created by the client which is sent to the server prior t= o > creating the email's CMS form, it states that the LockBox is a "base64 > encoded Recipient Info structure", but in section 3, Encoding Recipient Info, > of Plasma Service CMS Processing (the only place I see a sufficiently detailed > description of encoding PLASMA RecipientInfo structures), it says "A > recipient info structure as defined in this document MUST be created by a > Plasma server and MUST NOT be created by client software". I can see the > latter making sense in RecipientInfo structures returned by the server to the > client, but not in the client request for the CMS token. The question remains > then what is supposed to go into the LockBox in the sending client's CMS > token XML request. > > If it is the PLASMA-LockBox ASN.1 structure described in section 3.2 of > Plasma Service CMS Processing, then more clarity is needed as to exactly > what the client should send to the PLASMA server in a CMS token request > (e.g. is it everything but the RecipientInfo blob in the PLASMA-LockBox > structure?, if labels and recipient names are already specified in XML in the > CMS token request, does/should the client really need to create label and > NamedRecipient structures in the PLASMA-LockBox? (I suspect not)). > > Ed > _______________________________________________ > plasma mailing list > plasma@ietf.org > https://www.ietf.org/mailman/listinfo/plasma From Ed.Simon@titus.com Wed Oct 24 13:04: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 9A0DB21F86AD for ; Wed, 24 Oct 2012 13:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 RHCLFwLQtWPW for ; Wed, 24 Oct 2012 13:04:49 -0700 (PDT) Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by ietfa.amsl.com (Postfix) with ESMTP id 12B3121F8673 for ; Wed, 24 Oct 2012 13:04:48 -0700 (PDT) X-Env-Sender: Ed.Simon@titus.com X-Msg-Ref: server-9.tower-203.messagelabs.com!1351109087!15949650!1 X-Originating-IP: [67.210.173.99] X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27208 invoked from network); 24 Oct 2012 20:04:48 -0000 Received: from 67-210-173.99.static.tel-ott.com (HELO snakeskin.titus.com) (67.210.173.99) by server-9.tower-203.messagelabs.com with AES128-SHA encrypted SMTP; 24 Oct 2012 20:04:48 -0000 Received: from E10MB3.tituscorp.local ([fe80::84f4:cfbe:f32f:9a5]) by E10CH1.tituscorp.local ([192.168.200.115]) with mapi id 14.03.0083.000; Wed, 24 Oct 2012 16:04:47 -0400 From: Ed Simon To: "plasma@ietf.org" Thread-Topic: Clarification of specifying WS-Trust tokens in the PLASMA authentication element Thread-Index: Ac2yItByOS5dgk31QOCVMh2M3gsTfw== Date: Wed, 24 Oct 2012 20:04:46 +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] 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: Wed, 24 Oct 2012 20:04:49 -0000 The "Plasma Service Trust Processing" document includes a fragment of an XM= L Schema describing the element as such: ... ... I presume, based on the text of the "Plasma Service Trust Processing" docum= ent, that the "WS-Token" is actually supposed to be the /wst:RequestSecurityTokenResponse/wst:RequestedSecurityToken described in . Correct? If so, the XML Schema in the "Pla= sma Service Trust Processing" document needs to be adjusted to something li= ke . Also, with respect to t= he "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=