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:[email protected]] Sent: Friday, October 28, 2011 1:40 PM To: Fitch, Scott C; [email protected] 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: [email protected] [mailto:[email protected]] On Behalf Of Fitch, Scott C Sent: Tuesday, October 25, 2011 11:48 AM To: [email protected] 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 [email protected] https://www.ietf.org/mailman/listinfo/plasma _______________________________________________ plasma mailing list [email protected] https://www.ietf.org/mailman/listinfo/plasma
