IETF Logo Mail Archive

Re: [plasma] KEK usage

"Fitch, Scott C" <scott.c.fitch@lmco.com> Fri, 28 October 2011 19:08 UTC

Return-Path: <scott.c.fitch@lmco.com>
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 <plasma@ietfa.amsl.com>; 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 <plasma@ietfa.amsl.com>; 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 <plasma@ietf.org>; 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" <scott.c.fitch@lmco.com>
In-reply-to: <E545B914D50B2A4B994F198378B1525D42750848@DF-M14-11.exchange.corp.microsoft.com>
X-Originating-IP: [158.188.95.7]
To: Trevor Freeman <trevorf@exchange.microsoft.com>, "plasma@ietf.org" <plasma@ietf.org>
Message-id: <DFE85D7EFA640D4886E9A9141AEBCD200A09C1F4@HDXDSP11.us.lmco.com>
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: <DFE85D7EFA640D4886E9A9141AEBCD200A097BD1@HDXDSP11.us.lmco.com> <E545B914D50B2A4B994F198378B1525D42750848@DF-M14-11.exchange.corp.microsoft.com>
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." <plasma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/plasma>, <mailto:plasma-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/plasma>
List-Post: <mailto:plasma@ietf.org>
List-Help: <mailto:plasma-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/plasma>, <mailto:plasma-request@ietf.org?subject=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

v2.23.0 | Report a Bug | By Email