Re: [plasma] KEK usage

"Fitch, Scott C" <> Fri, 28 October 2011 19:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1D8771F0C41 for <>; Fri, 28 Oct 2011 12:08:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.18
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7Jy023lBjFME for <>; Fri, 28 Oct 2011 12:08:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 109C11F0C40 for <>; Fri, 28 Oct 2011 12:08:23 -0700 (PDT)
Received: from ( []) by (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 ( [])by (LM-6) with ESMTP id p9SJ8KRg009994; Fri, 28 Oct 2011 15:08:20 -0400 (EDT)
Received: from by (PMDF V6.4 #31806) id <>; Fri, 28 Oct 2011 19:08:20 +0000 (GMT)
Received: from ([]) by (PMDF V6.4 #31806) with ESMTP id <>; Fri, 28 Oct 2011 19:08:15 +0000 (GMT)
Received: from ([fe80::c04a:c222:3486:3e3]) by ([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: []
To: Trevor Freeman <>, "" <>
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
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-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 [] 
Sent: Friday, October 28, 2011 1:40 PM
To: Fitch, Scott C;
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: [] On Behalf Of Fitch, Scott C
Sent: Tuesday, October 25, 2011 11:48 AM
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.

plasma mailing list