From ietf@augustcellars.com Tue Sep 4 22:25:20 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 DCA1321F8673 for ; Tue, 4 Sep 2012 22:25:20 -0700 (PDT) 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 XcdwytJB9Ib5 for ; Tue, 4 Sep 2012 22:25:20 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 5331621F8670 for ; Tue, 4 Sep 2012 22:25:19 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 3A8CE2CA17 for ; Tue, 4 Sep 2012 22:25:19 -0700 (PDT) From: "Jim Schaad" To: References: <20120905045813.21473.37392.idtracker@ietfa.amsl.com> In-Reply-To: <20120905045813.21473.37392.idtracker@ietfa.amsl.com> Date: Tue, 4 Sep 2012 22:23:57 -0700 Message-ID: <023f01cd8b26$a6951a60$f3bf4f20$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIQNa5paIdtELPJwB0r6MUHZaXK35b14c/A Content-Language: en-us Subject: [plasma] FW: New Version Notification for draft-schaad-plasma-cms-02.txt X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 05:25:21 -0000 Please note that a new draft has been issued dealing with the ASN.1 = sides of the protocol. Lots of comments are welcome. Jim > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, September 04, 2012 9:58 PM > To: ietf@augustcellars.com > Subject: New Version Notification for draft-schaad-plasma-cms-02.txt >=20 >=20 > A new version of I-D, draft-schaad-plasma-cms-02.txt has been = successfully > submitted by Jim Schaad and posted to the IETF repository. >=20 > Filename: draft-schaad-plasma-cms > Revision: 02 > Title: Plasma Service Cryptographic Message Syntax (CMS) > Processing > Creation date: 2012-09-04 > WG ID: Individual Submission > Number of pages: 33 > URL: = http://www.ietf.org/internet-drafts/draft-schaad-plasma-cms- > 02.txt > Status: = http://datatracker.ietf.org/doc/draft-schaad-plasma-cms > Htmlized: http://tools.ietf.org/html/draft-schaad-plasma-cms-02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-schaad-plasma-cms-02 >=20 > Abstract: > Secure MIME (S/MIME) defined a method of placing security labels on = a > Cryptographic Message Syntax (CMS) object. These labels are placed > as part of the data signed and validated by the parties. This = means > that the message content is visible to the recipient prior to the > label enforcement. A new model for enforcement of policy using a > third party is described in RFC TBD > [I.D-draft-freeman-plasma-requirements]. This is the Policy > Augmented S/MIME (PLASMA) system. This document provides the = details > needed to implement the new Plasma model in the CMS infrastructure. >=20 > An additional benefit of using the Plasma module is that the > server,based on policy, manages who has access to the message and = how > the keys are protected. >=20 > The document details how the client encryption and decryption > processes are performed, defines how to construct the CMS recipient > info structure, a new content to hold the data required for the > Plasma server to store the keys and policy information. The = document > does not cover the protocol between the client and the Plasma = policy > enforcement server. One example of the client/server protocol can = be > found in RFC TBD [plasma-token]. >=20 >=20 >=20 >=20 > The IETF Secretariat From Ed.Simon@titus.com Thu Sep 13 18:12: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 6135621F8608 for ; Thu, 13 Sep 2012 18:12:30 -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=[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 SYS7FrWrTmWw for ; Thu, 13 Sep 2012 18:12:29 -0700 (PDT) Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7CF21F8549 for ; Thu, 13 Sep 2012 18:12:29 -0700 (PDT) X-Env-Sender: Ed.Simon@titus.com X-Msg-Ref: server-8.tower-203.messagelabs.com!1347585139!10636340!1 X-Originating-IP: [67.210.173.99] X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11541 invoked from network); 14 Sep 2012 01:12:21 -0000 Received: from 67-210-173.99.static.tel-ott.com (HELO snakeskin.titus.com) (67.210.173.99) by server-8.tower-203.messagelabs.com with AES128-SHA encrypted SMTP; 14 Sep 2012 01:12:21 -0000 Received: from E10MB3.tituscorp.local ([fe80::84f4:cfbe:f32f:9a5]) by E10CH2.tituscorp.local ([192.168.200.107]) with mapi id 14.03.0071.000; Thu, 13 Sep 2012 21:12:14 -0400 From: Ed Simon To: "plasma@ietf.org" Thread-Topic: Clarification of how client applications handle the LockBox in client in elements Thread-Index: Ac2SFfmCa9Xxrf87RGaEESJmUK5LWw== Date: Fri, 14 Sep 2012 01:12:14 +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 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: Fri, 14 Sep 2012 01:12:30 -0000 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 descri= bes the XML request created by the client which is sent to the server prior= to creating the email's CMS form, it states that the LockBox is a "base64 = encoded Recipient Info structure", but in section 3, Encoding Recipient Inf= o, of Plasma Service CMS Processing (the only place I see a sufficiently de= tailed 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 la= tter making sense in RecipientInfo structures returned by the server to the= client, but not in the client request for the CMS token. The question rema= ins then what is supposed to go into the LockBox in the sending client's CM= S token XML request. If it is the PLASMA-LockBox ASN.1 structure described in section 3.2 of Pla= sma 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 toke= n request, does/should the client really need to create label and NamedReci= pient structures in the PLASMA-LockBox? (I suspect not)). Ed= From jimsch@nwlink.com Tue Sep 25 13:35:27 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 B6D1021F87CA for ; Tue, 25 Sep 2012 13:35:27 -0700 (PDT) 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 qYN63Ayh4rVG for ; Tue, 25 Sep 2012 13:35:27 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE8D21F86A0 for ; Tue, 25 Sep 2012 13:35:26 -0700 (PDT) Received: from Tobias (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (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 524B62CA25; Tue, 25 Sep 2012 13:35:26 -0700 (PDT) From: "Jim Schaad" To: "'Ed Simon'" , References: In-Reply-To: Date: Tue, 25 Sep 2012 13:33:54 -0700 Message-ID: <010b01cd9b5d$19d92f20$4d8b8d60$@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: AQHbD/DyIY7qmbcdstkCO3B4OhQ3jpeAmgKg 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, 25 Sep 2012 20:35:27 -0000 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 three 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 to existing recipients by the Plasma server, but new recipients cannot be added to the list. For recipients in this class, the sender agent builds a normal recipient info structure for the recipient, but instead of placing it in the message direct, it is given to the Plasma server along with the policy to be 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 recipient and the content encryption key. The server then returns this information in 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 to > 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