From nobody Thu Feb 13 13:16:28 2014 Return-Path: X-Original-To: plasma@ietfa.amsl.com Delivered-To: plasma@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB641A04E6 for ; Thu, 13 Feb 2014 13:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k_4TU5aLiPbp for ; Thu, 13 Feb 2014 13:16:23 -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 873701A04AD for ; Thu, 13 Feb 2014 13:16:23 -0800 (PST) Received: from BL2SR01CA102.namsdf01.sdf.exchangelabs.com (10.255.109.147) by BL2SR01MB594.namsdf01.sdf.exchangelabs.com (10.255.109.165) with Microsoft SMTP Server (TLS) id 15.0.888.2; Thu, 13 Feb 2014 21:16:20 +0000 Received: from BY1FFOFD001.ffo.gbl (2a01:111:f400:7c00::88) by BL2SR01CA102.outlook.office365.com (2a01:111:e400:c01::19) with Microsoft SMTP Server (TLS) id 15.0.888.2 via Frontend Transport; Thu, 13 Feb 2014 21:16:20 +0000 Received: from hybrid.exchange.microsoft.com (131.107.147.100) by BY1FFOFD001.mail.o365filtering.com (10.1.16.83) with Microsoft SMTP Server (TLS) id 15.0.878.11 via Frontend Transport; Thu, 13 Feb 2014 21:16:20 +0000 Received: from DFM-TK5MBX15-08.exchange.corp.microsoft.com (157.54.109.47) by DFM-TK5EDG15-02.exchange.corp.microsoft.com (157.54.27.97) with Microsoft SMTP Server (TLS) id 15.0.847.29; Thu, 13 Feb 2014 13:16:14 -0800 Received: from DFM-TK5MBX15-05.exchange.corp.microsoft.com (157.54.109.44) by DFM-TK5MBX15-08.exchange.corp.microsoft.com (157.54.109.47) with Microsoft SMTP Server (TLS) id 15.0.847.29; Thu, 13 Feb 2014 13:16:14 -0800 Received: from DFM-TK5MBX15-05.exchange.corp.microsoft.com ([169.254.5.15]) by DFM-TK5MBX15-05.exchange.corp.microsoft.com ([169.254.5.15]) with mapi id 15.00.0847.027; Thu, 13 Feb 2014 13:16:01 -0800 From: Trevor Freeman To: "plasma@ietf.org" Thread-Topic: New Version Notification for draft-freeman-plasma-requirements-09.txt Thread-Index: AQHPKQCtJgF9VwkKhUy1I4LN7BZ1FJqzr2CA Date: Thu, 13 Feb 2014 21:16:00 +0000 Message-ID: References: <20140213211420.7757.87291.idtracker@ietfa.amsl.com> In-Reply-To: <20140213211420.7757.87291.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.13] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.147.100; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(377454003)(13464003)(377424004)(199002)(69234005)(189002)(51856001)(80022001)(76482001)(74706001)(65816001)(95416001)(76786001)(76796001)(77096001)(19580395003)(83322001)(19580405001)(50466002)(92566001)(94946001)(95666001)(94316002)(90146001)(56816005)(93516002)(59766001)(93136001)(54316002)(56776001)(77982001)(85306002)(74366001)(87266001)(4396001)(63696002)(6806004)(20776003)(33646001)(47776003)(69226001)(81542001)(2656002)(83072002)(23676002)(54356001)(44976005)(53806001)(85852003)(31966008)(15975445006)(79102001)(46102001)(74662001)(74502001)(47446002)(81342001)(74876001)(50986001)(47736001)(47976001)(87936001)(81686001)(66066001)(15202345003)(80976001)(49866001)(81816001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2SR01MB594; H:hybrid.exchange.microsoft.com; CLIP:131.107.147.100; FPR:A468FDBE.AFF42740.B7E0104B.43E2D8E1.2040E; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Forefront-PRVS: 0121F24F22 X-OriginatorOrg: exchange.microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/plasma/Kwkcwra5WFpmXD9HZoFaO4W4ykw Subject: [plasma] FW: New Version Notification for draft-freeman-plasma-requirements-09.txt X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2014 21:16:26 -0000 RllJLCBuZXcgcmVxdWlyZW1lbnRzIGRyYWZ0IHB1Ymxpc2hlZA0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxMywgMjAxNCAx OjE0IFBNDQpUbzogUGF0cmljayBQYXR0ZXJzb247IFRyZXZvciBGcmVlbWFuOyBKaW0gU2NoYWFk OyBKaW0gU2NoYWFkOyBQYXRyaWNrIFBhdHRlcnNvbjsgVHJldm9yIEZyZWVtYW4NClN1YmplY3Q6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZnJlZW1hbi1wbGFzbWEtcmVxdWly ZW1lbnRzLTA5LnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1mcmVlbWFuLXBs YXNtYS1yZXF1aXJlbWVudHMtMDkudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IFRyZXZvciBGcmVlbWFuIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0K TmFtZToJCWRyYWZ0LWZyZWVtYW4tcGxhc21hLXJlcXVpcmVtZW50cw0KUmV2aXNpb246CTA5DQpU aXRsZToJCVJlcXVpcmVtZW50cyBmb3IgTWVzc2FnZSBBY2Nlc3MgQ29udHJvbA0KRG9jdW1lbnQg ZGF0ZToJMjAxNC0wMi0xMw0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJ NDcNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1mcmVlbWFuLXBsYXNtYS1yZXF1aXJlbWVudHMtMDkudHh0DQpTdGF0dXM6ICAgICAgICAg aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZnJlZW1hbi1wbGFzbWEtcmVx dWlyZW1lbnRzLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWZyZWVtYW4tcGxhc21hLXJlcXVpcmVtZW50cy0wOQ0KRGlmZjogICAgICAgICAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWZyZWVtYW4tcGxhc21hLXJlcXVpcmVt ZW50cy0wOQ0KDQpBYnN0cmFjdDoNCiAgUy9NSU1FIGhhcyBhIHByb3ZlbiB0cmFjayByZWNvcmQg aW4gZGVsdmluZyBjb25maWRlbnRpYWxpdHksIGludGVncml0eQ0KICBhbmQgZGF0YSBvcmlnaW5h dGlvbiBhdXRoZW50aWNhdGlvbiBmb3IgZW1haWwuIEhvd2V2ZXIsIHRoZXJlIGFyZSBtYW55DQog IHNpdHVhdGlvbnMgd2hlcmUgb3JnYW5pemF0aW9ucyB3YW50IHJvYnVzdCBhY2Nlc3MgY29udHJv bCBhcHBsaWVkIHRvDQogIGluZm9ybWF0aW9uIGluIG1lc3NhZ2VzLiBUaGUgRW5oYW5jZWQgU2Vj dXJpdHkgU2VydmljZXMgKEVTUykgUkZDNTAzNQ0KICBmb3IgUy9NSU1FIGRlZmluZXMgYW4gYWNj ZXNzIGNvbnRyb2wgbWVjaGFuaXNtIGZvciBlbWFpbCwgYnV0IHRoZQ0KICBhY2Nlc3MgY2hlY2sg aGFwcGVucyBhZnRlciB0aGUgZGF0YSBpcyBkZWNyeXB0ZWQgYnkgdGhlIHJlY2lwaWVudA0KICB3 aGljaCBkZXZhbHVlcyB0aGUgcHJvdGVjdGlvbiBhZmZvcmRlZCBieSB0aGUgY3J5cHRvZ3JhcGh5 IGFuZA0KICBwcm92aWRlcyB2ZXJ5IHdlZWsgZ3VhcmFudGVlcyBvZiBwb2xpY3kgY29tcGxpYW5j ZS4gQW5vdGhlciBtYWpvcg0KICBpc3N1ZXMgZm9yIFMvTUlNRSBpcyBpdHMgZGVwZW5kZW5jeSBv biBhIHNpbmdsZSB0eXBlIG9mIGlkZW50aXR5DQogIGNyZWRlbnRpYWwsIGFuIFguNTA5IGNlcnRp ZmljYXRlLiBNYW55IHVzZXJzIG9uIHRoZSBJbnRlcm5ldCB0b2RheSBkbw0KICBub3QgaGF2ZSBY LjUwOSBjZXJ0aWZpY2F0ZXMgYW5kIHRoZXJlZm9yZSBjYW5ub3QgdXNlIFMvTUlNRS4NCiAgRnVy dGhlcm1vcmUsIHRoZSByZXF1aXJlbWVudCB0byBkaXNjb3ZlciB0aGUgWC41MDkgY2VydGlmaWNh dGUgZm9yDQogIGV2ZXJ5IHJlY2lwaWVudCBvZiBhbiBlbmNyeXB0ZWQgbWVzc2FnZSBieSB0aGUg c2VuZGVyIGhhcyBwcm92ZW4gdG8gYmUNCiAgYW4gdW5yZWxpYWJsZSBwcm9jZXNzIGZvciBhIG51 bWJlciBvZiByZWFzb25zLg0KDQogIFRoaXMgZG9jdW1lbnQgcHJlc2VudHMgcmVxdWlyZW1lbnRz IGZvciBhbiBhbHRlcm5hdGl2ZSBtb2RlbCB0byBFU1MgdG8NCiAgYWRkcmVzcyB0aGUgaWRlbnRp ZmllZCBpc3N1ZXMgd2l0aCBhY2Nlc3MgY29udHJvbCB0byBkZWxpdmVyIG1vcmUNCiAgcm9idXN0 IGNvbXBsaWFuY2Ugd2l0aCBTL01JTUUgcHJvdGVjdGVkIG1lc3NhZ2VzLiBUaGlzIGRvY3VtZW50 DQogIGRlc2NyaWJlcyBhbiBhY2Nlc3MgY29udHJvbCBtb2RlbCB3aGljaCB1c2VzIGNyeXB0b2dy YXBoaWMga2V5cyB0bw0KICBlbmZvcmNlIGFjY2VzcyBjb250cm9sIHBvbGljeSBkZWNpc2lvbnMg d2hlcmUgdGhlIHBvbGljeSBjaGVjayBpcw0KICBwZXJmb3JtZWQgcHJpb3IgdG8gdGhlIGRlY3J5 cHRpb24gb2YgdGhlIG1lc3NhZ2UgY29udGVudHMuIFRoZSBtb2RlbA0KICBhbHNvIGFic3RyYWN0 cyB0aGUgc3BlY2lmaWNzIG9mIHRoZSBhdXRoZW50aWNhdGlvbiB0ZWNobm9sb2d5IHRoZXJlYnkN CiAgcmVtb3ZpbmcgdGhlIGRlcGVuZGVuY3kgb24gWC41MDkgY2VydGlmaWNhdGUgbWFraW5nIGl0 IHBvc3NpYmxlIGZvcg0KICBvdGhlciBmb3JtcyBvZiBjcmVkZW50aWFsIHRvIGJlIHVzZWQgZm9y IFMvTUlNRSBlbmFibGluZyBtdWNoIGJyb2FkZXINCiAgYWRvcHRpb24uIFRoaXMgbW9kZWwgY2Fu IGJlIGluc3RhbnRpYXRlZCBpbiBtYW55IGFyZWFzIHVzaW5nIGV4aXN0aW5nDQogIHN0YW5kYXJk cywgb3Igd2l0aCBvbmx5IG1pbm9yIHVwZGF0ZXMgdG8gZXhpc3Rpbmcgc3RhbmRhcmRzLiBUaGlz DQogIG1vZGVsIGluIG5vdCBpbnRlbmRlZCB0byBiZSBhIG9uZSBvZmYganVzdCBmb3IgZW1haWwg YW5kIGNhbiBhbHNvIGJlDQogIGFwcGxpZWQgdG8gb3RoZXIgZGF0YSB0eXBlcy4gVGhlIG1vZGVs IGFsc28gcmVtb3ZlcyB0aGUgZGVwZW5kZW5jeSBvbg0KICB0aGUgbmVlZCB0byBkaXNjb3ZlciBl bmNyeXB0aW9uIGNlcnRpZmljYXRlcyBhdCBzZW5kIHRpbWUuDQoNCiAgVGhlIG5hbWUgUGxhc21h IHdhcyBhc3NpZ25lZCB0byB0aGlzIGVmZm9ydCBhcyBwYXJ0IG9mIHRoZSBJRVRGDQogIHByb2Nl c3MuIEl0IGlzIGRlcml2ZWQgZnJvbSBQb0xpY3kgZW5oQW5jZWQgU2VjdXJlIGVNQWlsLg0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu b3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Fri Feb 14 13:35:39 2014 Return-Path: X-Original-To: plasma@ietfa.amsl.com Delivered-To: plasma@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8975B1A0369 for ; Fri, 14 Feb 2014 13:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2znU9B7-q97Q for ; Fri, 14 Feb 2014 13:35:26 -0800 (PST) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.94]) by ietfa.amsl.com (Postfix) with ESMTP id 833DE1A023F for ; Fri, 14 Feb 2014 13:35:26 -0800 (PST) Received: from BL2SR01CA104.namsdf01.sdf.exchangelabs.com (10.255.109.149) by BL2SR01MB593.namsdf01.sdf.exchangelabs.com (10.255.109.164) with Microsoft SMTP Server (TLS) id 15.0.888.2; Fri, 14 Feb 2014 21:35:22 +0000 Received: from SN2FFOFD002.ffo.gbl (2a01:111:f400:7c04::24) by BL2SR01CA104.outlook.office365.com (2a01:111:e400:c01::21) with Microsoft SMTP Server (TLS) id 15.0.888.2 via Frontend Transport; Fri, 14 Feb 2014 21:35:22 +0000 Received: from hybrid.exchange.microsoft.com (131.107.159.100) by SN2FFOFD002.mail.o365filtering.com (10.111.201.21) with Microsoft SMTP Server (TLS) id 15.0.888.4 via Frontend Transport; Fri, 14 Feb 2014 21:35:22 +0000 Received: from DFM-TK5MBX15-06.exchange.corp.microsoft.com (157.54.109.45) by DFM-TK5EDG15-02.exchange.corp.microsoft.com (157.54.27.97) with Microsoft SMTP Server (TLS) id 15.0.847.29; Fri, 14 Feb 2014 13:35:18 -0800 Received: from DFM-TK5MBX15-05.exchange.corp.microsoft.com (157.54.109.44) by DFM-TK5MBX15-06.exchange.corp.microsoft.com (157.54.109.45) with Microsoft SMTP Server (TLS) id 15.0.847.29; Fri, 14 Feb 2014 13:35:17 -0800 Received: from DFM-TK5MBX15-05.exchange.corp.microsoft.com ([169.254.5.15]) by DFM-TK5MBX15-05.exchange.corp.microsoft.com ([169.254.5.15]) with mapi id 15.00.0847.027; Fri, 14 Feb 2014 13:35:16 -0800 From: Trevor Freeman To: Carl Wallace Thread-Topic: draft-freeman-plasma-requirements-08 Thread-Index: AQHO5xuLOqYOH+vDREaHMpNE7K3BBpq0NP9g Date: Fri, 14 Feb 2014 21:35:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.59.235.233] Content-Type: multipart/alternative; boundary="_000_f36bc39d1220450583b5d64a4b4184a6DFMTK5MBX1505exchangeco_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.159.100; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(189002)(199002)(13464003)(377454003)(54356001)(90146001)(81542001)(51856001)(47736001)(74706001)(74662001)(71186001)(47446002)(74502001)(6806004)(85852003)(83072002)(46102001)(31966008)(81342001)(92566001)(44976005)(19580395003)(19580405001)(83322001)(512954002)(50986001)(19300405004)(551544002)(47976001)(4396001)(49866001)(56816005)(80976001)(53806001)(74366001)(69226001)(93516002)(56776001)(84326002)(80022001)(85306002)(95416001)(94946001)(87936001)(93136001)(2656002)(95666001)(63696002)(94316002)(20776003)(33646001)(77096001)(76796001)(76786001)(81816001)(15202345003)(81686001)(59766001)(15975445006)(66066001)(74876001)(54316002)(77982001)(65816001)(16236675003)(87266001)(551934002)(76482001)(79102001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2SR01MB593; H:hybrid.exchange.microsoft.com; CLIP:131.107.159.100; FPR:FC0DF1C5.AB229051.B6DF3183.4DE85A42.20912; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Forefront-PRVS: 01221E3973 X-OriginatorOrg: exchange.microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/plasma/_Roskn8mf8kHPbB1b3sF1aSv3bo Cc: "Peter Yee \(peter@akayla.com\)" , "plasma@ietf.org" Subject: Re: [plasma] draft-freeman-plasma-requirements-08 X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2014 21:35:37 -0000 --_000_f36bc39d1220450583b5d64a4b4184a6DFMTK5MBX1505exchangeco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Carl, General Sorry it took longer than I was hoping for but I finally got the 09 draft o= ut. I want to thank you and Peter for your feedback because it has help the doc= ument in my humble opinion.:) I have done a little more surgery in this version to try and put the focus = more on email with assess control rather than just access control as you su= ggested. I think it is now clear we are looking to deliver an alternative f= or ESS not an alternative for S/MIME as a whole. Jims document get more in= to the Recipient Info section so I did not want to steal his thunder on tha= t part. I have pruned out some of the non-essential content to get the size= down as you also suggested. I have added your suggested security and privacy concerns to the security = considerations. I hope I have accurately captured the concerns there. See inline below Trevor -----Original Message----- From: plasma [mailto:plasma-bounces@ietf.org] On Behalf Of Carl Wallace Sent: Thursday, November 21, 2013 2:21 PM To: plasma@ietf.org Subject: [plasma] draft-freeman-plasma-requirements-08 After IETF 88 I read this document for this first time. Below are some com= ments. General - The document is too long. The use cases seem unnecessary to support the = primary (?) motivation - i.e., ESS security labels don't work as desired. - Should state early in the document whether or not use of S/MIME (i.e., CMS) is a requirement or if the aim is to do something different (first bul= let in 5.2 asserts backwards compatibility but is pretty far into the docum= ent and section 5.2 is a bit fuzzy). - For a document that asserts an email focus up front, there is too much fo= cus on SAML/XACML concepts. An email focus for the document might be to re= ference a new recipient info type that points to a key server (and maybe a = signed attribute for instructions to key server too). While the document s= ets the table with ESS labels as the objection, it seems like the real obje= ction is premature release of CEKs relative to access control decisions (wh= ich doesn't necessarily have anything to do with labels). With a different orientation, most of the work would then be in the definit= ion of the key server interface (including formats, like a RecipientInfo lo= ckbox) and key server operations, where the SAML/XACML material would proba= bly fit more naturally. Comments - The vocabulary section seems misplaced on a first read through. It would= benefit from some text in the introductory section that alludes to the pro= posed architecture, or at least describes some of the SAML/XACML concepts t= hat appear in the vocabulary section. [tf] I have clarified this vocabulary list supplements rfc3198 which is a n= ormative reference and remove duplication with 3198 - In section 2.1, bullet 7 applies more to S/MIME than ESS security [tf] re= moved labels. - The last paragraph in section 2.2 would benefit from some connection to S= /MIME, i.e., describe how a S/MIME sender benefits from delegating authenti= cation of a recipient to a SAML attribute provider who uses username/passwo= rd for authentication. [tf] added some clarifying text on why use of other forms of credentials is= a benefit. - Why is section 2.3 necessary? [tf] removed - I would break section 2 into two parts: one part would provide background= on things like SAML. The other would catalog problems with current mechan= isms. Sections 2.1 and 2.5 would fall in the latter part. It's not altogether clear why the other sections are necessary in a documen= t generating requirements for improved email access control mechanisms. [tf] I have split out the access control model discussion to a separate sec= tion to the ESS discussion. - Requirements should be organized around functions, perhaps: sender genera= tion/release of email and keys, intermediary receipt/storage/release of ema= il and keys, recipient acquisition of email and key, attribute generation/a= ggregation/storage/release, access control policy definition/storage/evalua= tion/versioning/expiry. [tf] I want to discuss this more with Jim before I change the requirements = layout. - The last paragraph in section 3.2.1 is not clear. Why would Bob's use of= the same username/password attest to his identity in an email he sends in = response to a message from the bank? Is this suggesting he authenticates t= o some key server interface to obtain a new signature key and that attests = to his identity? [tf] Bob has a way to authenticate to his identity provider which is indepe= ndent of the use context. If he uses password, otp, rubber chicken etc., he= always uses the same mechanism regardless of if its email, web access etc= . - Section 3.3 seems like a bit of a stretch as a requirement given Dave cou= ld simply copy and paste mail into a new thread. [tf] The concern is to get the information from Charlie to Dave with some l= evel of assurance. Charlie has to trust Dave to treat the information appro= priately. This should be possible without the transaction needing to be p= re-ordained by some central admin in Charlie's organization. One common pro= blem with SAML implementations is the dependency establishing federation be= fore any interaction is possible between the identity provider and relying = party. - Section 3.4.1 refers to a curious concept: "finding all instances of the = data". How would any access control mechanism account apply policies to da= ta already released? This section notes that Frank labels an email with Pr= oject X and Company Foo's IP labels. How would a recipient know which labe= l applied to which portions of the email? This section concludes with the = idea that Grace can no longer access Program X mail. It should probably mo= re simply state that she can no longer retrieve CEKs for Program X mail fro= m the server. She may well have access to Program X mail through a local c= opy. Generally this section is confusing and seems likely to render email = threads very difficult to manage as multiple labels are applied that all pa= rties may not be able to access. How would labels be removed if one were t= o forward a message or reply to a message while including only the part ass= ociated with one of the labels? [tf] The mechanism in the plasma service document describes how to do that.= It allows for consistent policy enforcement regardless of how many times a= message is bifurcated and which domain it is delivered to. I have clarifie= d the text for Grace as you suggested. - In 3.4.2, where is Grace's signature generated, i.e., by Grace or by the = server? Item (f) is difficult to parse. Some explanation as to how one ca= n be required by policy to confirm compliance with policy without knowing t= he specifics of the policy would be helpful. This section asserts a requir= ement to support exchange of forms that does not seem to appear elsewhere i= n the document. These sections appear to address web-based access to a wor= kflow more than secure email. [tf] The policy compliance signature comes from the PDEP. Grace can sign as= well if the policy wants and she has a suitable credential, but it's the P= DEP who attests the policy compliance i.e. it's a e-notary in this case. - Section 3.5 describes (more or less) how anyone with same attributes as G= race can access email sent to Grace. Is there a requirement for Frank to b= e able to send email to Grace such that only Grace can access it? What pre= vents Brian from obtaining the key even if Grace is not away and did not fo= rward the message? [tf] its really setting the stage for whatever the policy requires. A polic= y can enforce named recipients only or anybody with the right attributes or= whatever it wants. It could change its mind depending on the domain of the= recipient. - Section 3.6 (like several other sections) asserts a requirement for recip= ient's to be able to confirm the email is from a specific sender. If serve= r-applied signatures are used, how does this work? If user-applied signatu= res are used doesn't this violate one of the primary aims of the work, i.e.= , to support users who do not possess an S/MIME credential? [tf] The PDEP signature would assert who it is singing on behalf of. - How do you permit the mail server from leaking attributes to a sender via= failure notices? For example, Alice sends various test messages to Bob un= der different policies to determine which attributes are associated with hi= m. [tf] The PIP manages that process in conjunction with the subject. It has = policy for what attributes it will release to which PDEPS where its B2B. Fo= r Consumers, it would likely need consent from the subject. - In section 3.8, should inbound inspection also search for leakage to unau= thorized parties? [tf] Isn't that more a function for outbound? Given the base model is attri= bute based there is also a challenge as often the full set of subject attri= butes are not know to the inspection service. It can typicaly do some high = level checks e.g. domain based rather than user based. - Is there a requirement to enable a sender to be able to express a specifi= c version of a policy be used at enforcement time (vs some later version)? [tf] this gets into the whole policy versioning discussion. I don't think i= t's a sender choice thing. I do think the PAP could make that choice but it= has latitude to do so via the URI. The URI binds to s asset of ruleks whic= h are managed over time. The PAP can choose to update the rules at the URL = location or start generating new URIs if it wants to distinguish a new set = of policies. - Is there a requirement for communications partners to be able to contribu= te attributes to others? For example, Alice may associate some attribute w= ith Frank to allow him to participate in some exchange. [tf] potentially yes but the issue is how to discover those attributes. The= PDEP may have a relationship with Alice's PIP so can discover attributes a= bout Frank that Alice want to publish. Certainly that may be cases where Fr= ank can go to multiple PIP to gather attributes. An example of this in acti= on I came across was in healthcare relating to control substance prescripti= ons. For a controlled substance prescription, the doctor needs an attribute= to say they are a licensed doctor in the state they are practicing in as w= ell as at attribute asserting they are authorized to issue controlled subst= ances. One attribute comes from an authority in the state, the other form t= he DEA. - Section 5.2 seems to reference the "basic policy" concept in conflicting = ways, i.e., as backwards compatible with current S/MIME practices and to ac= comodate users with no certificate. [tf] basic policies are simple, authentication only policies. Therefore if = the sender discovers an encryption certificate for a recipient, it can use = the existing S/MIME mechanism without conflict to the policy. If the sender= selects a basic policy, the client could do the normal S/MIME certificate = discovery process and only invoke the new mechanism if it fails to find a c= ertificate for some recipients therby eliminating the need to remove recipi= ents where no certificate can be found. The client cannot use the existing = S/MIME mechanism with an advanced policy. Maybe we should can them authenti= cation only polices and authorization polices? Some additional security considerations: - Use of an authentication mechanism that can be reset via control of an em= ail account is problematic in support of an email access control tool. - Granting access to different portions of an email message is similarly we= ak as ESS labels given there is no cryptographic separation between differe= nt groups of users accessing a single message. - Is there any need to provide an indication that a key has already been re= leased to Bob or someone purporting to be Bob in the past? For example, in= section 3.2.1. - Need to discuss migration from one algorithm to another in the event an a= lgorithm is deemed no longer suitable. What's the lifetime of documents/ke= ys held by a plasma server? Some additional privacy considerations - Moving the decryption capability to servers enables "pervasive monitoring= " in ways that end-to-end encryption does not. Some discussion of the trad= e off is warranted (including perhaps how it is not a significant change du= e to escrow of encryption keys in current practice). - Downloading keys allows for automated read receipt generation. Is this d= esirable? Miscellaneous - Given the references to SAML, XACML, etc., should KEYPROV be cited as a k= ey format spec to use? Nits - In section 2, change "without certificates" to "without valid certificate= s". - In section 2.1, bullet 6, s/enforce/enforced. - In section 2.2, s/replying party/relying party. (multiple occurrences) - In section 2.2, s/a mean/a means. - In section 2.2, s/by to a subjects/to a subject's. (the sentence containi= ng this change is pretty difficult to parse in general) - In section 2.2.1, s/subject's themselves/subjects themselves. - In section 3.1, should this reference Alice's ISP or her email service pr= ovider? - In section 3.2.1, s/recipients identity/recipient's identity - In section 3.4.1, s/confidentiality its own/confidentiality of its own - In section 3.4.2, s/Franks/Frank's - In section 3.6 bullet (4), delete " : , then encrypts the message." _______________________________________________ plasma mailing list plasma@ietf.org https://www.ietf.org/mailman/listinfo/plasma --_000_f36bc39d1220450583b5d64a4b4184a6DFMTK5MBX1505exchangeco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Carl,

 

General

Sorry it took longer than I was hoping for but I = finally got the 09 draft out.

 

I want to thank you and Peter for your feedback b= ecause it has help the document in my humble opinion.J

 

I have done a little more surgery in this version= to try and put the focus more on email with assess control rather than jus= t access control as you suggested. I think it is now clear we are looking t= o deliver an alternative for ESS not an alternative for S/MIME as a whole.  Jims document get more into th= e Recipient Info section so I did not want to steal his thunder on that par= t. I have pruned out some of the non-essential content to get the size down= as you also suggested.

 

I have added your suggested security and privacy = concerns to the  security considerations. I hope I have accurately cap= tured the concerns there.

 

See inline below

 

Trevor

-----Original Message-----

From: plasma [mailto:plasma-bounces@ietf.org] On = Behalf Of Carl Wallace

Sent: Thursday, November 21, 2013 2:21 PM

To: plasma@ietf.org

Subject: [plasma] draft-freeman-plasma-requiremen= ts-08

 

After IETF 88 I read this document for this first= time.  Below are some comments.

 

General

 

- The document is too long.  The use cases s= eem unnecessary to support the primary (?) motivation - i.e., ESS security = labels don't work as desired.

 

- Should state early in the document whether or n= ot use of S/MIME (i.e.,

CMS) is a requirement or if the aim is to do some= thing different (first bullet in 5.2 asserts backwards compatibility but is= pretty far into the document and section 5.2 is a bit fuzzy).

 

- For a document that asserts an email focus up f= ront, there is too much focus on SAML/XACML concepts.  An email focus = for the document might be to reference a new recipient info type that point= s to a key server (and maybe a signed attribute for instructions to key server too).  While the document sets the tab= le with ESS labels as the objection, it seems like the real objection is pr= emature release of CEKs relative to access control decisions (which doesn't= necessarily have anything to do with labels).

With a different orientation, most of the work wo= uld then be in the definition of the key server interface (including format= s, like a RecipientInfo lockbox) and key server operations, where the SAML/= XACML material would probably fit more naturally.

 

Comments

- The vocabulary section seems misplaced on a fir= st read through.  It would benefit from some text in the introductory = section that alludes to the proposed architecture, or at least describes so= me of the SAML/XACML concepts that appear in the vocabulary section.

[tf] I have clar= ified this vocabulary list supplements rfc3198 which is a normative referen= ce and remove duplication with 3198

- In section 2.1, bullet 7 applies more to S/MIME= than ESS security [tf] removed

labels.  

- The last paragraph in section 2.2 would benefit= from some connection to S/MIME, i.e., describe how a S/MIME sender benefit= s from delegating authentication of a recipient to a SAML attribute provide= r who uses username/password for authentication.

[tf] added some = clarifying text on why use of other forms of credentials is a benefit.

- Why is section 2.3 necessary?

[tf] removed

- I would break section 2 into two parts: one par= t would provide background on things like SAML.  The other would catal= og problems with current mechanisms.  Sections 2.1 and 2.5 would fall = in the latter part.

It's not altogether clear why the other sections = are necessary in a document generating requirements for improved email acce= ss control mechanisms. 

[tf] I have spli= t out the access control model discussion to a separate section to the ESS = discussion.

- Requirements should be organized around functio= ns, perhaps: sender generation/release of email and keys, intermediary rece= ipt/storage/release of email and keys, recipient acquisition of email and k= ey, attribute generation/aggregation/storage/release, access control policy definition/storage/evaluation/versioning/expiry.

[tf] I want to d= iscuss this more with Jim before I change the requirements layout.

- The last paragraph in section 3.2.1 is not clea= r.  Why would Bob's use of the same username/password attest to his id= entity in an email he sends in response to a message from the bank?  I= s this suggesting he authenticates to some key server interface to obtain a new signature key and that attests to his ide= ntity?

[tf] Bob has a w= ay to authenticate to his identity provider which is independent of the use= context. If he uses password, otp, rubber chicken etc., he always uses the same mechanism regardless of if it= s email, web access  etc.

- Section 3.3 seems like a bit of a stretch as a = requirement given Dave could simply copy and paste mail into a new thread.<= o:p>

[tf] The concern= is to get the information from Charlie to Dave with some level of assuranc= e. Charlie has to trust Dave to treat the information appropriately.  This should be possible without the t= ransaction needing to be  pre-ordained by some central admin in Charli= e’s organization. One common problem with SAML implementations is the= dependency establishing federation before any interaction is possible between the identity provider and relyin= g party. 

- Section 3.4.1 refers to a curious concept: &quo= t;finding all instances of the data".  How would any access contr= ol mechanism account apply policies to data already released?  This se= ction notes that Frank labels an email with Project X and Company Foo's IP labels.  How would a recipient know which label = applied to which portions of the email?  This section concludes with t= he idea that Grace can no longer access Program X mail.  It should pro= bably more simply state that she can no longer retrieve CEKs for Program X mail from the server.  She may well have = access to Program X mail through a local copy.  Generally this section= is confusing and seems likely to render email threads very difficult to ma= nage as multiple labels are applied that all parties may not be able to access.  How would labels be removed if on= e were to forward a message or reply to a message while including only the = part associated with one of the labels?

[tf] The mechani= sm in the plasma service document describes how to do that. It allows for c= onsistent policy enforcement regardless of how many times a message is bifurcated and which domain it is delivered= to. I have clarified the text for Grace as you suggested.

- In 3.4.2, where is Grace's signature generated,= i.e., by Grace or by the server?  Item (f) is difficult to parse.&nbs= p; Some explanation as to how one can be required by policy to confirm comp= liance with policy without knowing the specifics of the policy would be helpful.  This section asserts a requirement t= o support exchange of forms that does not seem to appear elsewhere in the d= ocument.  These sections appear to address web-based access to a workf= low more than secure email.

[tf] The policy = compliance signature comes from the PDEP. Grace can sign as well if the pol= icy wants and she has a suitable credential, but it’s the PDEP who attests the policy compliance i.e. it’s = a e-notary in this case.

- Section 3.5 describes (more or less) how anyone= with same attributes as Grace can access email sent to Grace.  Is the= re a requirement for Frank to be able to send email to Grace such that only= Grace can access it?  What prevents Brian from obtaining the key even if Grace is not away and did not forward the m= essage?

[tf] its really = setting the stage for whatever the policy requires. A policy can enforce na= med recipients only or anybody with the right attributes or whatever it wants. It could change its mind depend= ing on the domain of the recipient.

- Section 3.6 (like several other sections) asser= ts a requirement for recipient's to be able to confirm the email is from a = specific sender.  If server-applied signatures are used, how does this= work?  If user-applied signatures are used doesn't this violate one of the primary aims of the work, i.e., to su= pport users who do not possess an S/MIME credential?

[tf] The PDEP si= gnature would assert who it is singing on behalf of.

- How do you permit the mail server from leaking = attributes to a sender via failure notices?  For example, Alice sends = various test messages to Bob under different policies to determine which at= tributes are associated with him.

[tf]  The PIP manages that proc= ess in conjunction with the subject. It has policy for what attributes it w= ill release to which PDEPS where its B2B. For Consumers, it would likely need consent from the subject.   =

- In section 3.8, should inbound inspection also = search for leakage to unauthorized parties?

[tf] Isn’t= that more a function for outbound? Given the base model is attribute based= there is also a challenge as often the full set of subject attributes are not know to the inspection service. It can t= ypicaly do some high level checks e.g. domain based rather than user based.=  

- Is there a requirement to enable a sender to be= able to express a specific version of a policy be used at enforcement time= (vs some later version)?

[tf] this gets i= nto the whole policy versioning discussion. I don’t think it’s = a sender choice thing. I do think the PAP could make that choice but it has latitude to do so via the URI. The URI binds t= o s asset of ruleks which are managed over time. The PAP can choose to upda= te the rules at the URL location or start generating new URIs if it wants t= o distinguish a new set of policies.

- Is there a requirement for communications partn= ers to be able to contribute attributes to others?  For example, Alice= may associate some attribute with Frank to allow him to participate in som= e exchange.

[tf] potentially= yes but the issue is how to discover those attributes. The PDEP may have a= relationship with Alice’s PIP so can discover attributes about Frank that Alice want to publish. Certainly that= may be cases where Frank can go to multiple PIP to gather attributes. An e= xample of this in action I came across was in healthcare relating to contro= l substance prescriptions. For a controlled substance prescription, the doctor needs an attribute to say th= ey are a licensed doctor in the state they are practicing in as well as at = attribute asserting they are authorized to issue controlled substances. One= attribute comes from an authority in the state, the other form the DEA.  

- Section 5.2 seems to reference the "basic = policy" concept in conflicting ways, i.e., as backwards compatible wit= h current S/MIME practices and to accomodate users with no certificate.

[tf] basic polic= ies are simple, authentication only policies. Therefore if the sender disco= vers an encryption certificate for a recipient, it can use the existing S/MIME mechanism without conflict to th= e policy. If the sender selects a basic policy, the client could do the nor= mal S/MIME certificate discovery process and only invoke the new mechanism = if it fails to find a certificate for some recipients therby eliminating the need to remove recipients where= no certificate can be found. The client cannot use the existing S/MIME mec= hanism with an advanced policy. Maybe we should can them authentication onl= y polices and authorization polices?

 

Some additional security considerations:

- Use of an authentication mechanism that can be = reset via control of an email account is problematic in support of an email= access control tool.

- Granting access to different portions of an ema= il message is similarly weak as ESS labels given there is no cryptographic = separation between different groups of users accessing a single message.

- Is there any need to provide an indication that= a key has already been released to Bob or someone purporting to be Bob in = the past?  For example, in section 3.2.1.

- Need to discuss migration from one algorithm to= another in the event an algorithm is deemed no longer suitable.  What= 's the lifetime of documents/keys held by a plasma server?

 

Some additional privacy considerations=

- Moving the decryption capability to servers ena= bles "pervasive monitoring" in ways that end-to-end encryption do= es not.  Some discussion of the trade off is warranted (including perh= aps how it is not a significant change due to escrow of encryption keys in current practice).

- Downloading keys allows for automated read rece= ipt generation.  Is this desirable?

 

Miscellaneous

- Given the references to SAML, XACML, etc., shou= ld KEYPROV be cited as a key format spec to use?

 

Nits

- In section 2, change "without certificates= " to "without valid certificates".

- In section 2.1, bullet 6, s/enforce/enforced.

- In section 2.2, s/replying party/relying party.= (multiple occurrences)

- In section 2.2, s/a mean/a means.

- In section 2.2, s/by to a subjects/to a subject= 's. (the sentence containing this change is pretty difficult to parse in ge= neral)

- In section 2.2.1, s/subject's themselves/subjec= ts themselves.

- In section 3.1, should this reference Alice's I= SP or her email service provider?

- In section 3.2.1, s/recipients identity/recipie= nt's identity

- In section 3.4.1, s/confidentiality  its o= wn/confidentiality of its own

- In section 3.4.2, s/Franks/Frank's

- In section 3.6 bullet (4), delete " : , th= en encrypts the message."

 

 

_______________________________________________

plasma mailing list

plasma@ietf.org

https://www.ietf.org/mailman/listinfo/plasma=

--_000_f36bc39d1220450583b5d64a4b4184a6DFMTK5MBX1505exchangeco_--