From trevorf@exchange.microsoft.com Thu Oct 20 10:38:34 2011 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 57D7721F8BB6 for ; Thu, 20 Oct 2011 10:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNAuRFd1IsB9 for ; Thu, 20 Oct 2011 10:38:33 -0700 (PDT) Received: from mail.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9646521F8B03 for ; Thu, 20 Oct 2011 10:38:33 -0700 (PDT) Received: from df-h14-01.exchange.corp.microsoft.com (157.54.78.139) by DF-G14-02.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 14.2.247.0; Thu, 20 Oct 2011 10:38:33 -0700 Received: from PIO-MLT-06.exchange.corp.microsoft.com (157.54.94.24) by DF-H14-01.exchange.corp.microsoft.com (157.54.78.139) with Microsoft SMTP Server (TLS) id 14.2.202.4; Thu, 20 Oct 2011 10:38:33 -0700 Received: from DF-M14-11.exchange.corp.microsoft.com ([fe80::cc46:3da5:bed6:8dfc]) by PIO-MLT-06.exchange.corp.microsoft.com ([fe80::d57f:521a:3ae6:c130%10]) with mapi id 14.02.0247.000; Thu, 20 Oct 2011 10:38:32 -0700 From: Trevor Freeman To: "plasma@ietf.org" Thread-Topic: New Version Notification for draft-freeman-message-access-control-req-03.txt Thread-Index: AQHMj07OpyJecEtpekCkVeuw/+kCmJWFfw6A Date: Thu, 20 Oct 2011 17:38:32 +0000 Message-ID: References: <20111020173626.29893.46384.idtracker@ietfa.amsl.com> In-Reply-To: <20111020173626.29893.46384.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.101] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [plasma] FW: New Version Notification for draft-freeman-message-access-control-req-03.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: Thu, 20 Oct 2011 17:38:34 -0000 RllJLCBBIG5ldyByZXF1aXJlbWVudHMgZHJhZnQgaGFzIGJlZW4gcG9zdGVkLg0KDQpUaGVyZSBh cmUgYSBudW1iZXIgb2Ygc2lnbmlmaWNhbnQgY2hhbmdlcyBtb3N0IG5vdGFibHkgYSBkZXNjcmlw dGlvbiBvZiB0aGUgUGxhc21hIGRhdGEgbW9kZWwuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmddIA0KU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMjAsIDIwMTEgMTA6MzYgQU0N ClRvOiBUcmV2b3IgRnJlZW1hbg0KQ2M6IHBwYXR0ZXJzb25AY2FyaWxsb24uY2E7IFRyZXZvciBG cmVlbWFuOyBpZXRmQGF1Z3VzdGNlbGxhcnMuY29tDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LWZyZWVtYW4tbWVzc2FnZS1hY2Nlc3MtY29udHJvbC1yZXEtMDMu dHh0DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1mcmVlbWFuLW1lc3NhZ2UtYWNjZXNz LWNvbnRyb2wtcmVxLTAzLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFRy ZXZvciBGcmVlbWFuIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5h bWU6CSBkcmFmdC1mcmVlbWFuLW1lc3NhZ2UtYWNjZXNzLWNvbnRyb2wtcmVxDQpSZXZpc2lvbjoJ IDAzDQpUaXRsZToJCSBSZXF1aXJlbWVudHMgZm9yIE1lc3NhZ2UgQWNjZXNzIENvbnRyb2wNCkNy ZWF0aW9uIGRhdGU6CSAyMDExLTEwLTIwDQpXRyBJRDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24N Ck51bWJlciBvZiBwYWdlczogNDINCg0KQWJzdHJhY3Q6DQogICBUaGVyZSBhcmUgbWFueSBzaXR1 YXRpb25zIHdoZXJlIG9yZ2FuaXphdGlvbnMgd2FudCB0byBwcm90ZWN0DQogICBpbmZvcm1hdGlv biB3aXRoIHJvYnVzdCBhY2Nlc3MgY29udHJvbCwgZWl0aGVyIGZvciBpbXBsZW1lbnRhdGlvbiBv Zg0KICAgaW50ZWxsZWN0dWFsIHByb3BlcnR5IHJpZ2h0IHByb3RlY3Rpb25zLCBlbmZvcmNlbWVu dCBvZiBpbmZvcm1hdGlvbg0KICAgY29udHJhY3R1YWwgY29uZmlkZW50aWFsaXR5IGFncmVlbWVu dHMgb3IgYmVjYXVzZSBvZiBleHRlcm5hbGx5DQogICBpbXBvc2VkIGxlZ2FsIHJlZ3VsYXRpb25z LiAgVGhlIEVuaGFuY2VkIFNlY3VyaXR5IFNlcnZpY2VzIChFU1MpIGZvcg0KICAgUy9NSU1FIGRl ZmluZXMgYW4gYWNjZXNzIGNvbnRyb2wgbWVjaGFuaXNtIHdoaWNoIGlzIGVuZm9yY2VkIGJ5IHRo ZQ0KICAgcmVjaXBpZW50cyBjbGllbnQgYWZ0ZXIgZGVjcnlwdGlvbiBvZiB0aGUgbWVzc2FnZS4g VGhlIEVTUyBtZWNoYW5pc20NCiAgIHRoZXJlZm9yZSBpcyBkZXBlbmRlbnQgb24gdGhlIGNvcnJl Y3QgYWNjZXNzIHBvbGljeSBjb25maWd1cmF0aW9uIG9mDQogICBldmVyeSByZWNpcGllbnRzIGNs aWVudC4gVGhpcyBtZWNoYW5pc20gYWxzbyBwcm92aWRlcyBmdWxsIGFjY2VzcyB0bw0KICAgdGhl IGRhdGEgdG8gYWxsIHJlY2lwaWVudHMgcHJpb3IgdG8gdGhlIGFjY2VzcyBjb250cm9sIGNoZWNr IHdoaWNoIGlzDQogICBjb25zaWRlcmVkIHRvIGJlIGluYWRlcXVhdGUgZm9yIGR1ZSB0byB0aGUg ZGlmZmljdWx0eSBpbg0KICAgZGVtb25zdHJhdGluZyBwb2xpY3kgY29tcGxpYW5jZS4NCg0KICAg VGhpcyBkb2N1bWVudCBsYXlzIG91dCB0aGUgZGVmaWNpZW5jaWVzIG9mIHRoZSBjdXJyZW50IEVT UyBzZWN1cml0eQ0KICAgbGFiZWwsIGFuZCBwcmVzZW50cyByZXF1aXJlbWVudHMgZm9yIG5ldyBt b2RlbCBmb3IgZG9pbmcgYWNjZXNzDQogICBjb250cm9sIHRvIG1lc3NhZ2VzIHdoZXJlIHRoZSBh Y2Nlc3MgY2hlY2sgaXMgcGVyZm9ybWVkIHByaW9yIHRvDQogICBtZXNzYWdlIGNvbnRlbnQgZGVj cnlwdGlvbi4gVGhpcyBuZXcgbW9kZWwgYWxzbyBkb2VzIG5vdCByZXF1aXJlDQogICBwb2xpY3kg Y29uZmlndXJhdGlvbiBvbiB0aGUgY2xpZW50IHRvIHNpbXBsaWZ5IGRlcGxveW1lbnQgYW5kDQog ICBjb21wbGlhbmNlIHZlcmlmaWNhdGlvbi4NCg0KICAgVGhlIHByb3Bvc2VkIG1vZGVsIGFkZGl0 aW9uYWxseSBwcm92aWRlcyBhIG1ldGhvZCB3aGVyZSBub24tWC41MDkNCiAgIGNlcnRpZmljYXRl IGNyZWRlbnRpYWxzIGNhbiBiZSB1c2VkIGZvciBlbmNyeXB0aW9uL2RlY3J5cHRpb24gb2YNCiAg IFMvTUlNRSBtZXNzYWdlcy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJ RVRGIFNlY3JldGFyaWF0DQoNCg== From scott.c.fitch@lmco.com Tue Oct 25 10:16:00 2011 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 63A1621F84A7 for ; Tue, 25 Oct 2011 10:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tHEyyLaL+Oe for ; Tue, 25 Oct 2011 10:15:59 -0700 (PDT) Received: from mailfo01.lmco.com (mailfo01.lmco.com [192.31.106.12]) by ietfa.amsl.com (Postfix) with ESMTP id D07E221F85A8 for ; Tue, 25 Oct 2011 10:15:59 -0700 (PDT) Received: from mailgw1a.lmco.com (ppalertrelay.lmco.com [192.31.106.7]) by mailfo01.lmco.com (8.14.3/8.14.3) with ESMTP id p9PHFxI2020416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 25 Oct 2011 18:15:59 +0100 Received: from emss02g01.ems.lmco.com (relay2.ems.lmco.com [166.29.2.54])by mailgw1a.lmco.com (LM-6) with ESMTP id p9PHFwZg003129for ; Tue, 25 Oct 2011 11:15:59 -0600 (MDT) Received: from CONVERSION2-DAEMON.lmco.com by lmco.com (PMDF V6.4 #31805) id <0LTM00K01TAMG0@lmco.com> for plasma@ietf.org; Tue, 25 Oct 2011 17:15:58 +0000 (GMT) Received: from HDXHTPN7.us.lmco.com ([158.188.83.14]) by lmco.com (PMDF V6.4 #31805) with ESMTP id <0LTM009Y9TACNG@lmco.com> for plasma@ietf.org; Tue, 25 Oct 2011 17:15:48 +0000 (GMT) Received: from HDXDSP11.us.lmco.com ([fe80::c04a:c222:3486:3e3]) by HDXHTPN7.us.lmco.com ([fe80::f1:ff4b:90a4:695%14]) with mapi id 14.01.0289.001; Tue, 25 Oct 2011 11:15:48 -0600 Date: Tue, 25 Oct 2011 17:15:48 +0000 From: "Fitch, Scott C" X-Originating-IP: [158.188.95.7] To: "plasma@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Thread-Topic: PEPs, authentication, and attributes Thread-Index: AcyTMNeMJIyckKYkTc+x471Qa9C0Nw== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-10-25_05:2011-10-25, 2011-10-25, 1970-01-01 signatures=0 Subject: [plasma] PEPs, authentication, and attributes 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 Oct 2011 17:16:00 -0000 (The first of several threads on the v03 of the requirements document. Overall, I really like what I see.) Section 4.3 outlines the steps that the Content Consumption PEP and PDP following to read a plasma-protected email. The sequence doesn't specify an authentication step for the PEP to the PDP. It seems to me that the PDP will want not only attributes about the message recipient, but also evidence that the recipient is actually there at the other end of the wire. I see two possibilities here. First option is to have the PEP authenticate to the PDP at first concept in step (C). Or it can authenticate once the PDP asks for more attributes in step (E). I think I favor the first option, but am interested in others' view on this too. A few factors make me lean this direction: - This prevents the PDP from having to process any unauthenticated requests - If plasma implementations follow the federation model of SAML and WS-Fed, the recipient will have a trust relationship that defines a (baseline) set of attributes that can be sent to the PDP. This (hopefully) will reduce the instances that a PDP needs to ask the PEP to provide more attributes in step (E). - Where the PDP will be using a back-end attribute retrieval such as a SAML AttributeQuery, it will need to know something about the subject in order to be able to construct the query and possible to determine which PIP to query in the first place. Also related to attribute retrieval, I recommend tweaking the Back end Attribute Exchange definition to explain that this is a *query and retrieval* of attributes initiated by the PDP. The current definition implies that the information is sent from the PIP to the PDP, which from a data flow perspective is accurate, but from a security and implementation perspective doesn't accurately describe the communications. -Scott Scott Fitch Cyber Architect Lockheed Martin Corporate Information Security m: (860) 614-6013 w: (860) 868-9947 scott.c.fitch@lmco.com From scott.c.fitch@lmco.com Tue Oct 25 10:56:59 2011 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 C94B921F8BD5 for ; Tue, 25 Oct 2011 10:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTN6YS6ZhU8i for ; Tue, 25 Oct 2011 10:56:58 -0700 (PDT) Received: from mailfo01.lmco.com (mailfo01.lmco.com [192.31.106.12]) by ietfa.amsl.com (Postfix) with ESMTP id E0EA021F8BC5 for ; Tue, 25 Oct 2011 10:56:57 -0700 (PDT) Received: from mailgw1a.lmco.com (ppalertrelay.lmco.com [192.31.106.7]) by mailfo01.lmco.com (8.14.3/8.14.3) with ESMTP id p9PHuuO1007555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 25 Oct 2011 18:56:57 +0100 Received: from emss07g01.ems.lmco.com (relay5.ems.lmco.com [166.29.2.16])by mailgw1a.lmco.com (LM-6) with ESMTP id p9PHusFm023086for ; Tue, 25 Oct 2011 11:56:55 -0600 (MDT) Received: from CONVERSION2-DAEMON.lmco.com by lmco.com (PMDF V6.4 #31805) id <0LTM00201V6TC5@lmco.com> for plasma@ietf.org; Tue, 25 Oct 2011 17:56:53 +0000 (GMT) Received: from HDXHTPN7.us.lmco.com ([158.188.83.14]) by lmco.com (PMDF V6.4 #31805) with ESMTP id <0LTM00B5QV6OBX@lmco.com> for plasma@ietf.org; Tue, 25 Oct 2011 17:56:48 +0000 (GMT) Received: from HDXDSP11.us.lmco.com ([fe80::c04a:c222:3486:3e3]) by HDXHTPN7.us.lmco.com ([fe80::f1:ff4b:90a4:695%14]) with mapi id 14.01.0289.001; Tue, 25 Oct 2011 11:56:48 -0600 Date: Tue, 25 Oct 2011 17:56:47 +0000 From: "Fitch, Scott C" X-Originating-IP: [158.188.95.7] To: "plasma@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_mdMHyOeee6wR0nEm2nYnfw)" Content-language: en-US Thread-Topic: Delegation scenario Thread-Index: AcyTPvJuZ6lTqdglQi+54J/v8g5UNQ== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-10-25_06:2011-10-25, 2011-10-25, 1970-01-01 signatures=0 Subject: [plasma] Delegation scenario 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 Oct 2011 17:56:59 -0000 --Boundary_(ID_mdMHyOeee6wR0nEm2nYnfw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Plasma also opens up the opportunity to support delegation in a much more sustainable and elegant manner than current PKI-based S/MIME. I'd like to see that called out as a scenario in Section 3. Others have similar thoughts? -Scott --Boundary_(ID_mdMHyOeee6wR0nEm2nYnfw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Plasma also opens up the opportunity to support delegation in a much more sustainable and elegant manner than current PKI-based S/MIME. I’d like to see that called out as a scenario in Section 3. Others have similar thoughts?

 

                -Scott

--Boundary_(ID_mdMHyOeee6wR0nEm2nYnfw)-- From scott.c.fitch@lmco.com Tue Oct 25 11:55:44 2011 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 989D321F8AD1 for ; Tue, 25 Oct 2011 11:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4cKlyNWp+zU for ; Tue, 25 Oct 2011 11:55:44 -0700 (PDT) Received: from mailfo01.lmco.com (mailfo01.lmco.com [192.31.106.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0793021F8ABE for ; Tue, 25 Oct 2011 11:55:43 -0700 (PDT) Received: from mailgw3a.lmco.com (mailgw3a.lmco.com [192.35.35.7]) by mailfo01.lmco.com (8.14.3/8.14.3) with ESMTP id p9PItdtO019154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 25 Oct 2011 19:55:40 +0100 Received: from emss09g01.ems.lmco.com (relay6.ems.lmco.com [166.17.13.59])by mailgw3a.lmco.com (LM-6) with ESMTP id p9PItHLC028072for ; Tue, 25 Oct 2011 14:55:39 -0400 (EDT) Received: from CONVERSION2-DAEMON.lmco.com by lmco.com (PMDF V6.4 #31806) id <0LTM00D01XKGLZ@lmco.com> for plasma@ietf.org; Tue, 25 Oct 2011 18:48:16 +0000 (GMT) Received: from HDXHTPN7.us.lmco.com ([158.188.83.14]) by lmco.com (PMDF V6.4 #31806) with ESMTP id <0LTM0076SXKBJF@lmco.com> for plasma@ietf.org; Tue, 25 Oct 2011 18:48:11 +0000 (GMT) Received: from HDXDSP11.us.lmco.com ([fe80::c04a:c222:3486:3e3]) by HDXHTPN7.us.lmco.com ([fe80::f1:ff4b:90a4:695%14]) with mapi id 14.01.0289.001; Tue, 25 Oct 2011 12:48:11 -0600 Date: Tue, 25 Oct 2011 18:48:11 +0000 From: "Fitch, Scott C" X-Originating-IP: [158.188.95.7] To: "plasma@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Thread-Topic: KEK usage Thread-Index: AcyTRgPodLuEJ3NEQcqy3+T3/w0AYA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-10-25_06:2011-10-25, 2011-10-25, 1970-01-01 signatures=0 Subject: [plasma] KEK usage 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 Oct 2011 18:55:44 -0000 I have a question on using a KEK as described in Section 4.2. It states: The [Content Creation] PEP submits the CEK, the set of requires policies to be applied and the hash of the encrypted content to the PDP. The CEK can be a raw key or a CEK key encrypted by a KEK if the user does not want the PDP to have the ability to access the plain text data. In the case of encrypting the CEK with a KEK, whose key is used in that case? And how will the recipient decrypt it? I didn't see the corresponding steps listed in the Content Consuming sequence. -Scott From scott.c.fitch@lmco.com Tue Oct 25 11:57:31 2011 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 3D3DA1F0C3F for ; Tue, 25 Oct 2011 11:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPJ7OQVs4s8b for ; Tue, 25 Oct 2011 11:57:30 -0700 (PDT) Received: from mailfo02.lmco.com (mailfo02.lmco.com [192.35.35.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF781F0C3B for ; Tue, 25 Oct 2011 11:57:30 -0700 (PDT) Received: from mailgw3a.lmco.com (mailgw3a.lmco.com [192.35.35.7]) by mailfo02.lmco.com (8.14.3/8.14.3) with ESMTP id p9PIvTnZ018659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 25 Oct 2011 19:57:29 +0100 Received: from emss09g01.ems.lmco.com (relay6.ems.lmco.com [166.17.13.59])by mailgw3a.lmco.com (LM-6) with ESMTP id p9PItEd6028015for ; Tue, 25 Oct 2011 14:57:29 -0400 (EDT) Received: from CONVERSION2-DAEMON.lmco.com by lmco.com (PMDF V6.4 #31806) id <0LTM00E01XXIDX@lmco.com> for plasma@ietf.org; Tue, 25 Oct 2011 18:56:30 +0000 (GMT) Received: from HDXHTPN7.us.lmco.com ([158.188.83.14]) by lmco.com (PMDF V6.4 #31806) with ESMTP id <0LTM0078VXXLKF@lmco.com> for plasma@ietf.org; Tue, 25 Oct 2011 18:56:24 +0000 (GMT) Received: from HDXDSP11.us.lmco.com ([fe80::c04a:c222:3486:3e3]) by HDXHTPN7.us.lmco.com ([fe80::f1:ff4b:90a4:695%14]) with mapi id 14.01.0289.001; Tue, 25 Oct 2011 12:56:12 -0600 Date: Tue, 25 Oct 2011 18:56:11 +0000 From: "Fitch, Scott C" X-Originating-IP: [158.188.95.7] To: "plasma@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Thread-Topic: Levels of assurance Thread-Index: AcyTRx6pnTp5VUnTRUe7DOXMw+3LyQ== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-10-25_06:2011-10-25, 2011-10-25, 1970-01-01 signatures=0 Subject: [plasma] Levels of assurance 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 Oct 2011 18:57:31 -0000 Is it necessary to require levels of assurance in the Basic Policy requirements? I definitely think it's appropriate for Advanced Policies. But I wonder whether including levels of assurance in Basic Policies will impede adoption. Also, the fact that there are multiple LOA frameworks out there makes it difficult to meet the requirement to NOT require a priori bilateral agreements between the sender and recipient for Basic Policies. If the sender and recipient use different LOA scales, then some type of prior agreement must be in place to map the two scales. I don't think plasma wants to get into the business of creating a standard LOA mapping for interoperability. -Scott From scott.c.fitch@lmco.com Tue Oct 25 12:00:28 2011 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 07E0911E8128 for ; Tue, 25 Oct 2011 12:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QJ2-HbF1I3f for ; Tue, 25 Oct 2011 12:00:27 -0700 (PDT) Received: from mailgw1.lmco.com (mailgw1.lmco.com [192.31.106.3]) by ietfa.amsl.com (Postfix) with ESMTP id E6E4011E80B5 for ; Tue, 25 Oct 2011 12:00:22 -0700 (PDT) Received: from emss07g01.ems.lmco.com (relay5.ems.lmco.com [166.29.2.16])by mailgw1.lmco.com (LM-6) with ESMTP id p9PJ0LIn022755for ; Tue, 25 Oct 2011 13:00:22 -0600 (MDT) Received: from CONVERSION2-DAEMON.lmco.com by lmco.com (PMDF V6.4 #31805) id <0LTM00501Y4LMR@lmco.com> for plasma@ietf.org; Tue, 25 Oct 2011 19:00:21 +0000 (GMT) Received: from HDXHTPN7.us.lmco.com ([158.188.83.14]) by lmco.com (PMDF V6.4 #31805) with ESMTP id <0LTM005KXY4ESW@lmco.com> for plasma@ietf.org; Tue, 25 Oct 2011 19:00:16 +0000 (GMT) Received: from HDXDSP11.us.lmco.com ([fe80::c04a:c222:3486:3e3]) by HDXHTPN7.us.lmco.com ([fe80::f1:ff4b:90a4:695%14]) with mapi id 14.01.0289.001; Tue, 25 Oct 2011 13:00:15 -0600 Date: Tue, 25 Oct 2011 19:00:14 +0000 From: "Fitch, Scott C" X-Originating-IP: [158.188.95.7] To: "plasma@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Thread-Topic: S/MIME Capabilities Thread-Index: AcyTR93+zP+wCizmT46LHSpiVqxaJg== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [plasma] S/MIME Capabilities 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 Oct 2011 19:00:28 -0000 Section 5.2.1 notes the backwards compatibility requirement with existing S/MIME where a sender can create recipient info structures for recipients it can discover keys for. Should there be an equivalent mechanism to indicate a sender's support for plasma, similar to the way that S/MIME indicates current capabilities? This could be helpful, particularly when sending messages with Advanced Policies. -Scott From leifj@mnt.se Wed Oct 26 00:37:35 2011 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 8700F21F8AAF for ; Wed, 26 Oct 2011 00:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBzOnRVmgMSo for ; Wed, 26 Oct 2011 00:37:35 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id A968621F8AAA for ; Wed, 26 Oct 2011 00:37:31 -0700 (PDT) Received: from [212.25.132.67] ([212.25.132.67]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p9Q7bQYR004231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 26 Oct 2011 09:37:29 +0200 (CEST) Message-ID: <4EA7B8B6.2070608@mnt.se> Date: Wed, 26 Oct 2011 09:37:26 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: plasma@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [plasma] Levels of assurance 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, 26 Oct 2011 07:37:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/25/2011 08:56 PM, Fitch, Scott C wrote: > Is it necessary to require levels of assurance in the Basic Policy requirements? I definitely think it's appropriate for Advanced Policies. But I wonder whether including levels of assurance in Basic Policies will impede adoption. > > Also, the fact that there are multiple LOA frameworks out there makes it difficult to meet the requirement to NOT require a priori bilateral agreements between the sender and recipient for Basic Policies. If the sender and recipient use different LOA scales, then some type of prior agreement must be in place to map the two scales. I don't think plasma wants to get into the business of creating a standard LOA mapping for interoperability. > Supporting multiple LOA frameworks is partly a technical issue and partly a policy issue. The technical issue is that we need a way to communicate LOA per transaction. In SAML WebSSO there are technical controls (AuthenticationContext) for communicating LOA [1] [1] http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-assurance-profile.html Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6nuLYACgkQ8Jx8FtbMZnfPbQCeNkiKi0I/hoDUHz8d3ayq3ciy 7pkAnRtZwv6MNhBi19OnFwtNha4SjOmh =hkLH -----END PGP SIGNATURE----- From trevorf@exchange.microsoft.com Wed Oct 26 15:03:50 2011 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 906EE21F8B6D for ; Wed, 26 Oct 2011 15:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.099 X-Spam-Level: X-Spam-Status: No, score=-111.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHP1eEvVo8-P for ; Wed, 26 Oct 2011 15:03:49 -0700 (PDT) Received: from mail.exchange.microsoft.com (mail1.exchange.microsoft.com [131.107.1.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8568621F85F1 for ; Wed, 26 Oct 2011 15:03:49 -0700 (PDT) Received: from df-h14-01.exchange.corp.microsoft.com (157.54.78.139) by DF-G14-01.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 14.2.247.0; Wed, 26 Oct 2011 15:03:49 -0700 Received: from DF-M14-12.exchange.corp.microsoft.com ([fe80::7c94:4036:120:c95f]) by DF-H14-01.exchange.corp.microsoft.com ([157.54.78.139]) with mapi id 14.02.0202.004; Wed, 26 Oct 2011 15:03:49 -0700 From: Trevor Freeman To: Leif Johansson , "plasma@ietf.org" Thread-Topic: [plasma] Levels of assurance Thread-Index: AcyTRx6pnTp5VUnTRUe7DOXMw+3LyQApakYAAA76ewA= Date: Wed, 26 Oct 2011 22:03:47 +0000 Message-ID: References: <4EA7B8B6.2070608@mnt.se> In-Reply-To: <4EA7B8B6.2070608@mnt.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [plasma] Levels of assurance 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, 26 Oct 2011 22:03:50 -0000 I think it's a fair question as to why basic policy should have this one va= riable. Why not require any form of LoA to be an advanced policy. >From an implementation perspective it would be a huge tax on applications t= o require they support advanced polices. It would be reasonable to require = they support basic policy under this profile and to do that we need to make= it a lightweight as possible. However, a very frequent request is to requi= re something better than a simple password for authentication.=20 What I don't want is to see a lot of use cases broken because policy wants = something better than a password and the client only supports basic policy.= Having the LoA in basic policy was my attempt to make sure that gap did n= ot happen.=20 If there is some other way to ensure we can support things better than pass= words while not mandating LoA support in the policy I would welcome it as = I do want basic to be a simple as possible. Trevor -----Original Message----- From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of= Leif Johansson Sent: Wednesday, October 26, 2011 12:37 AM To: plasma@ietf.org Subject: Re: [plasma] Levels of assurance -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/25/2011 08:56 PM, Fitch, Scott C wrote: > Is it necessary to require levels of assurance in the Basic Policy requir= ements? I definitely think it's appropriate for Advanced Policies. But I wo= nder whether including levels of assurance in Basic Policies will impede ad= option. >=20 > Also, the fact that there are multiple LOA frameworks out there makes it = difficult to meet the requirement to NOT require a priori bilateral agreeme= nts between the sender and recipient for Basic Policies. If the sender and = recipient use different LOA scales, then some type of prior agreement must = be in place to map the two scales. I don't think plasma wants to get into t= he business of creating a standard LOA mapping for interoperability. >=20 Supporting multiple LOA frameworks is partly a technical issue and partly a= policy issue. The technical issue is that we need a way to communicate LOA= per transaction. In SAML WebSSO there are technical controls (AuthenticationContext) for com= municating LOA [1] [1] http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-assurance-profil= e.html Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6nuLYACgkQ8Jx8FtbMZnfPbQCeNkiKi0I/hoDUHz8d3ayq3ciy 7pkAnRtZwv6MNhBi19OnFwtNha4SjOmh =3DhkLH -----END PGP SIGNATURE----- _______________________________________________ plasma mailing list plasma@ietf.org https://www.ietf.org/mailman/listinfo/plasma From trevorf@exchange.microsoft.com Fri Oct 28 10:24:32 2011 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 3E49621F8514 for ; Fri, 28 Oct 2011 10:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.849 X-Spam-Level: X-Spam-Status: No, score=-110.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wS4DZmXHhp+f for ; Fri, 28 Oct 2011 10:24:31 -0700 (PDT) Received: from mail.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 898CD21F84B5 for ; Fri, 28 Oct 2011 10:24:31 -0700 (PDT) Received: from df-h14-02.exchange.corp.microsoft.com (157.54.78.140) by DF-G14-02.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 14.2.247.2; Fri, 28 Oct 2011 10:24:30 -0700 Received: from PIO-MLT-06.exchange.corp.microsoft.com (157.54.94.24) by DF-H14-02.exchange.corp.microsoft.com (157.54.78.140) with Microsoft SMTP Server (TLS) id 14.2.202.4; Fri, 28 Oct 2011 10:24:30 -0700 Received: from DF-M14-11.exchange.corp.microsoft.com ([fe80::cc46:3da5:bed6:8dfc]) by PIO-MLT-06.exchange.corp.microsoft.com ([fe80::d57f:521a:3ae6:c130%10]) with mapi id 14.02.0247.002; Fri, 28 Oct 2011 10:24:30 -0700 From: Trevor Freeman To: "Fitch, Scott C" , "plasma@ietf.org" Thread-Topic: Levels of assurance Thread-Index: AcyTRx6pnTp5VUnTRUe7DOXMw+3LyQCS+QNw Date: Fri, 28 Oct 2011 17:24:29 +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.54.51.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [plasma] Levels of assurance 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, 28 Oct 2011 17:24:32 -0000 I forgot to address the second part - general acceptability of LoA framewor= k. There are environments where they operate sometime by consensus rather than= bilateral agreements e.g. healthcare. While Healthcare does has some bilat= eral agreements, there are so many potential relationships it is impractica= l to set up all you may need. The last thing you would want is for access t= o an out of town ER patients record to be blocked because if the lack of a = bilateral agreement. =20 =20 Within any organization, there are ad-hoc communications which happen where= you have not yet established a relationship. If you don't accept some form= of LoA with basic policy, then those communications would be forced to be = implicitly level 1. Equally if you organization is to against accepting a L= oA, you could just use level 1 - which practically is the same thing. I was not thinking we would map LoA scales. The challenge for Plasma is get= consensus for a specific LoA scale that we could all adopt for basic polic= y. It will likely be like UN treaty negotiation where nobody is relay happ= y with the outcome but it's something that you can live with.=20 Trevor -----Original Message----- From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of= Fitch, Scott C Sent: Tuesday, October 25, 2011 11:56 AM To: plasma@ietf.org Subject: [plasma] Levels of assurance Is it necessary to require levels of assurance in the Basic Policy requirem= ents? I definitely think it's appropriate for Advanced Policies. But I wond= er whether including levels of assurance in Basic Policies will impede adop= tion. Also, the fact that there are multiple LOA frameworks out there makes it di= fficult to meet the requirement to NOT require a priori bilateral agreement= s between the sender and recipient for Basic Policies. If the sender and re= cipient use different LOA scales, then some type of prior agreement must be= in place to map the two scales. I don't think plasma wants to get into the= business of creating a standard LOA mapping for interoperability. -Scott _______________________________________________ plasma mailing list plasma@ietf.org https://www.ietf.org/mailman/listinfo/plasma From trevorf@exchange.microsoft.com Fri Oct 28 10:31:19 2011 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 475B821F8AD2 for ; Fri, 28 Oct 2011 10:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.799 X-Spam-Level: X-Spam-Status: No, score=-110.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1dwxsEmKn9q for ; Fri, 28 Oct 2011 10:31:18 -0700 (PDT) Received: from mail.exchange.microsoft.com (mail1.exchange.microsoft.com [131.107.1.17]) by ietfa.amsl.com (Postfix) with ESMTP id CCFD321F88B6 for ; Fri, 28 Oct 2011 10:31:18 -0700 (PDT) Received: from df-h14-01.exchange.corp.microsoft.com (157.54.78.139) by DF-G14-01.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 14.2.247.2; Fri, 28 Oct 2011 10:31:18 -0700 Received: from PIO-MLT-05.exchange.corp.microsoft.com (157.54.94.22) by DF-H14-01.exchange.corp.microsoft.com (157.54.78.139) with Microsoft SMTP Server (TLS) id 14.2.202.4; Fri, 28 Oct 2011 10:31:18 -0700 Received: from DF-M14-11.exchange.corp.microsoft.com ([fe80::cc46:3da5:bed6:8dfc]) by PIO-MLT-05.exchange.corp.microsoft.com ([fe80::d940:e316:1daa:5e6a%10]) with mapi id 14.02.0247.002; Fri, 28 Oct 2011 10:31:17 -0700 From: Trevor Freeman To: "Fitch, Scott C" , "plasma@ietf.org" Thread-Topic: S/MIME Capabilities Thread-Index: AcyTR93+zP+wCizmT46LHSpiVqxaJgCTqOGA Date: Fri, 28 Oct 2011 17:31:16 +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.54.51.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [plasma] S/MIME Capabilities 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, 28 Oct 2011 17:31:19 -0000 Creating an S/MIME capability for Plasma is a good idea. It provides some l= evel of heads up where users are not knowingly plasma enabled. Unlike S/MIM= E today, if a recipient upgrades to plasma they will be able to read previo= usly received plasma email just as they would be able to read plasma email = if the were given new encryption keys where the organization does not maint= ain an encryption key history. -----Original Message----- From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of= Fitch, Scott C Sent: Tuesday, October 25, 2011 12:00 PM To: plasma@ietf.org Subject: [plasma] S/MIME Capabilities Section 5.2.1 notes the backwards compatibility requirement with existing S= /MIME where a sender can create recipient info structures for recipients it= can discover keys for. Should there be an equivalent mechanism to indicate a sender's support for = plasma, similar to the way that S/MIME indicates current capabilities? This= could be helpful, particularly when sending messages with Advanced Policie= s. -Scott _______________________________________________ plasma mailing list plasma@ietf.org https://www.ietf.org/mailman/listinfo/plasma From trevorf@exchange.microsoft.com Fri Oct 28 10:39:44 2011 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 4877121F8514 for ; Fri, 28 Oct 2011 10:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.766 X-Spam-Level: X-Spam-Status: No, score=-110.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdSFyryN1yA6 for ; Fri, 28 Oct 2011 10:39:42 -0700 (PDT) Received: from mail.exchange.microsoft.com (mail1.exchange.microsoft.com [131.107.1.17]) by ietfa.amsl.com (Postfix) with ESMTP id 96B1021F84FA for ; Fri, 28 Oct 2011 10:39:42 -0700 (PDT) Received: from df-h14-02.exchange.corp.microsoft.com (157.54.78.140) by DF-G14-01.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 14.2.247.2; Fri, 28 Oct 2011 10:39:42 -0700 Received: from PIO-MLT-05.exchange.corp.microsoft.com (157.54.94.22) by DF-H14-02.exchange.corp.microsoft.com (157.54.78.140) with Microsoft SMTP Server (TLS) id 14.2.202.4; Fri, 28 Oct 2011 10:39:42 -0700 Received: from DF-M14-11.exchange.corp.microsoft.com ([fe80::cc46:3da5:bed6:8dfc]) by PIO-MLT-05.exchange.corp.microsoft.com ([fe80::d940:e316:1daa:5e6a%10]) with mapi id 14.02.0247.002; Fri, 28 Oct 2011 10:39:41 -0700 From: Trevor Freeman To: "Fitch, Scott C" , "plasma@ietf.org" Thread-Topic: KEK usage Thread-Index: AcyTRgPodLuEJ3NEQcqy3+T3/w0AYACUW+7A Date: Fri, 28 Oct 2011 17:39:41 +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.54.51.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [plasma] KEK usage 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, 28 Oct 2011 17:39:44 -0000 If the policy does not want to disclose the KEK to the PDP in the clear, th= en they have to do early key binding like S/MIME does today. You discover t= he user's encryption key and encrypt the KEK using their public key to crea= te a recipient info structure which you include for the PDP. The PDP would = need to request a claim about the identity of the recipient's public key an= d then it can release the appropriate recipient info structure.=20 -----Original Message----- From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of= Fitch, Scott C Sent: Tuesday, October 25, 2011 11:48 AM To: plasma@ietf.org Subject: [plasma] KEK usage I have a question on using a KEK as described in Section 4.2. It states: The [Content Creation] PEP submits the CEK, the set of requires policies to= be applied and the hash of the encrypted content to the PDP. The CEK can b= e a raw key or a CEK key encrypted by a KEK if the user does not want the P= DP to have the ability to access the plain text data. In the case of encrypting the CEK with a KEK, whose key is used in that cas= e? And how will the recipient decrypt it? I didn't see the corresponding st= eps listed in the Content Consuming sequence. -Scott _______________________________________________ plasma mailing list plasma@ietf.org https://www.ietf.org/mailman/listinfo/plasma From trevorf@exchange.microsoft.com Fri Oct 28 10:48:27 2011 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 6B39B11E8089 for ; Fri, 28 Oct 2011 10:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.741 X-Spam-Level: X-Spam-Status: No, score=-110.741 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5K0yJegTMW9p for ; Fri, 28 Oct 2011 10:48:15 -0700 (PDT) Received: from mail.exchange.microsoft.com (mail1.exchange.microsoft.com [131.107.1.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8B821F8A4E for ; Fri, 28 Oct 2011 10:48:15 -0700 (PDT) Received: from df-h14-01.exchange.corp.microsoft.com (157.54.78.139) by DF-G14-01.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 14.2.247.2; Fri, 28 Oct 2011 10:48:14 -0700 Received: from PIO-MLT-06.exchange.corp.microsoft.com (157.54.94.24) by DF-H14-01.exchange.corp.microsoft.com (157.54.78.139) with Microsoft SMTP Server (TLS) id 14.2.202.4; Fri, 28 Oct 2011 10:48:14 -0700 Received: from DF-M14-11.exchange.corp.microsoft.com ([fe80::cc46:3da5:bed6:8dfc]) by PIO-MLT-06.exchange.corp.microsoft.com ([fe80::d57f:521a:3ae6:c130%10]) with mapi id 14.02.0247.002; Fri, 28 Oct 2011 10:48:14 -0700 From: Trevor Freeman To: "Fitch, Scott C" , "plasma@ietf.org" Thread-Topic: Delegation scenario Thread-Index: AcyTPvJuZ6lTqdglQi+54J/v8g5UNQCWpMtQ Date: Fri, 28 Oct 2011 17:48:13 +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.54.51.100] Content-Type: multipart/alternative; boundary="_000_E545B914D50B2A4B994F198378B1525D42750872DFM1411exchange_" MIME-Version: 1.0 Subject: Re: [plasma] Delegation scenario 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, 28 Oct 2011 17:48:27 -0000 --_000_E545B914D50B2A4B994F198378B1525D42750872DFM1411exchange_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That is a good observation. If you give a brief outline on how you see a sc= enario changing for delegation and I will incorporate that into the next ve= rsion. From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of= Fitch, Scott C Sent: Tuesday, October 25, 2011 10:57 AM To: plasma@ietf.org Subject: [plasma] Delegation scenario Plasma also opens up the opportunity to support delegation in a much more s= ustainable and elegant manner than current PKI-based S/MIME. I'd like to se= e that called out as a scenario in Section 3. Others have similar thoughts? -Scott --_000_E545B914D50B2A4B994F198378B1525D42750872DFM1411exchange_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That is a good observa= tion. If you give a brief outline on how you see a scenario changing for delegation and I will incorporate that into the ne= xt version.

 

From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of Fitch, Scott C
Sent: Tuesday, October 25, 2011 10:57 AM
To: plasma@ietf.org
Subject: [plasma] Delegation scenario

 

Plasma also opens up the opportunity to support delegation in= a much more sustainable and elegant manner than current PKI-based S/MIME. = I’d like to see that called out as a scenario in Section 3. Others have similar thoughts?

 

          &= nbsp;     -Scott

--_000_E545B914D50B2A4B994F198378B1525D42750872DFM1411exchange_-- From scott.c.fitch@lmco.com Fri Oct 28 12:08:25 2011 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 1D8771F0C41 for ; Fri, 28 Oct 2011 12:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.18 X-Spam-Level: X-Spam-Status: No, score=-9.18 tagged_above=-999 required=5 tests=[AWL=-1.418, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Jy023lBjFME for ; Fri, 28 Oct 2011 12:08:24 -0700 (PDT) Received: from mailfo02.lmco.com (mailfo02.lmco.com [192.35.35.12]) by ietfa.amsl.com (Postfix) with ESMTP id 109C11F0C40 for ; Fri, 28 Oct 2011 12:08:23 -0700 (PDT) Received: from mailgw3a.lmco.com (mailgw3a.lmco.com [192.35.35.7]) by mailfo02.lmco.com (8.14.3/8.14.3) with ESMTP id p9SJ8LhP006256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Oct 2011 20:08:21 +0100 Received: from emss04g01.ems.lmco.com (relay4.ems.lmco.com [166.17.13.122])by mailgw3a.lmco.com (LM-6) with ESMTP id p9SJ8KRg009994; Fri, 28 Oct 2011 15:08:20 -0400 (EDT) Received: from CONVERSION2-DAEMON.lmco.com by lmco.com (PMDF V6.4 #31806) id <0LTS00801IHW5E@lmco.com>; Fri, 28 Oct 2011 19:08:20 +0000 (GMT) Received: from HDXHTPN6.us.lmco.com ([158.188.83.13]) by lmco.com (PMDF V6.4 #31806) with ESMTP id <0LTS00M73IG60E@lmco.com>; Fri, 28 Oct 2011 19:08:15 +0000 (GMT) Received: from HDXDSP11.us.lmco.com ([fe80::c04a:c222:3486:3e3]) by HDXHTPN6.us.lmco.com ([fe80::1db3:a00c:a3c9:9df6%14]) with mapi id 14.01.0289.001; Fri, 28 Oct 2011 13:08:07 -0600 Date: Fri, 28 Oct 2011 19:08:07 +0000 From: "Fitch, Scott C" In-reply-to: X-Originating-IP: [158.188.95.7] To: Trevor Freeman , "plasma@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Thread-Topic: KEK usage Thread-Index: AcyTRgPodLuEJ3NEQcqy3+T3/w0AYACUW+7AAAM+6SA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: References: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-10-28_05:2011-10-28, 2011-10-28, 1970-01-01 signatures=0 Subject: Re: [plasma] KEK usage 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, 28 Oct 2011 19:08:25 -0000 Thanks for clarifying, Trevor. I almost hesitate to say it, but it sounds a bit like a "holder of key" variant for plasma. This is probably worth exploring a bit more to see if it can meet the NIST Level 4 authentication requirements. That would help encourage adoption in the high security use cases. Either way, the process you outlined below should be more clearly described in the requirements document. -----Original Message----- From: Trevor Freeman [mailto:trevorf@exchange.microsoft.com] Sent: Friday, October 28, 2011 1:40 PM To: Fitch, Scott C; plasma@ietf.org Subject: EXTERNAL: RE: KEK usage If the policy does not want to disclose the KEK to the PDP in the clear, then they have to do early key binding like S/MIME does today. You discover the user's encryption key and encrypt the KEK using their public key to create a recipient info structure which you include for the PDP. The PDP would need to request a claim about the identity of the recipient's public key and then it can release the appropriate recipient info structure. -----Original Message----- From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of Fitch, Scott C Sent: Tuesday, October 25, 2011 11:48 AM To: plasma@ietf.org Subject: [plasma] KEK usage I have a question on using a KEK as described in Section 4.2. It states: The [Content Creation] PEP submits the CEK, the set of requires policies to be applied and the hash of the encrypted content to the PDP. The CEK can be a raw key or a CEK key encrypted by a KEK if the user does not want the PDP to have the ability to access the plain text data. In the case of encrypting the CEK with a KEK, whose key is used in that case? And how will the recipient decrypt it? I didn't see the corresponding steps listed in the Content Consuming sequence. -Scott _______________________________________________ plasma mailing list plasma@ietf.org https://www.ietf.org/mailman/listinfo/plasma