Subject: [plasma] Use of the KEK Recipient Info field

From: "Jim Schaad" <[email-masked]>
Date: Tue, 28 Aug 2012 20:38:50 -0700

At the last IETF meeting Trevor and I decided that we really needed to send
the CEK rather than the KEK between the client and the server to support
pre-authorization cases.  This has one effect that I would like some input
on.

We currently use the KEK Recipient Info structure and define an Other
Attribute to hold the Plasma data.  We then have a KEK and a KEK Wrap
algorithm to protect the CEK.  Moving forward I see three ways of doing the
wrapping.

1.  Promote the current Other Attribute to a Key Wrap algorithm.  We no
longer have an Other Attribute but instead identify Plasma by the key wrap
algorithm OID and the wrapped key value is the Plasma lockbox data
structure.

2.  We define and use a dummy Key Wrap algorithm and empty key value field.
This keeps the current Other Attribute field, but since we don't' use the
key wrap algorithm and key value fields they become dummy values.

3.  The Plasma server will randomly generate a KEK value and wrap the CEK
with the KEK and provide the data in the KEK recipient Info structure.  The
server then receives the CEK and returns either the CEK or the KEK as we
decide is appropriate.

I don't have a strong feeling for any of the above solutions and therefore
request input and reasoning behind a selection process.

Jim