[plasma] Use of the KEK Recipient Info field

"Jim Schaad" <ietf@augustcellars.com> Wed, 29 August 2012 03:40 UTC

Return-Path: <ietf@augustcellars.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 E70C111E8097 for <plasma@ietfa.amsl.com>; Tue, 28 Aug 2012 20:40:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.587
X-Spam-Level:
X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=-0.847, BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcUuavw5UkHW for <plasma@ietfa.amsl.com>; Tue, 28 Aug 2012 20:40:14 -0700 (PDT)
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 70E8821F841A for <plasma@ietf.org>; Tue, 28 Aug 2012 20:40:14 -0700 (PDT)
Received: from Tobias (50-39-234-129.bvtn.or.frontiernet.net [50.39.234.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id CDAC72CA17 for <plasma@ietf.org>; Tue, 28 Aug 2012 20:40:13 -0700 (PDT)
From: "Jim Schaad" <ietf@augustcellars.com>
To: <plasma@ietf.org>
Date: Tue, 28 Aug 2012 20:38:50 -0700
Message-ID: <05f601cd8597$d068afd0$713a0f70$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac2FLbUA1yGfuss0T4Ghfxr+B2Fy1Q==
Content-Language: en-us
Subject: [plasma] Use of the KEK Recipient Info field
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: Wed, 29 Aug 2012 03:40:15 -0000

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