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 _______________________________________________ plasma mailing list [email protected] https://www.ietf.org/mailman/listinfo/plasma
