[jose] SPI proposal

Richard Barnes <rlb@ipv.sx> Wed, 06 February 2013 22:11 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2A1B321F8539 for <jose@ietfa.amsl.com>; Wed, 6 Feb 2013 14:11:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.831
X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[AWL=1.145, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ERqQoVB91ITd for <jose@ietfa.amsl.com>; Wed, 6 Feb 2013 14:11:52 -0800 (PST)
Received: from mail-lb0-f195.google.com (mail-lb0-f195.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 08FB021F868D for <jose@ietf.org>; Wed, 6 Feb 2013 14:11:51 -0800 (PST)
Received: by mail-lb0-f195.google.com with SMTP id gf14so270703lbb.2 for <jose@ietf.org>; Wed, 06 Feb 2013 14:11:51 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type:x-gm-message-state; bh=D856pMUkUkE3CX/iz8aSC2yMmcg4egEbqLszCF8juww=; b=incEpOHahV9pmO6VazrnlSOSebpB3+8O4BDP8OwSaSYhjMGxrzM+Re5Mzdqlq9Vbnf yyX3a5hUcDqGnFhf8y0BRsL5/CszG5lh3AzdpapRRhCqdC9ekK2xFqJTImAZwRZuwcja GUghcLf7f/EtDnYRUhIvsoW+bSUTatKV4uCoYZkLjf4NHY+bhP5y8Pmjt7nT2RJBx+71 RAE8MAbORfos1b5xtmwnrpRew9YOOxX7oXq44BxQfOoz7AfhoDHoVUmDIUNzd5jkMpQy tigT3AQvuo6EiP3syN2aa8l+P7maDcbt5ZgHf+K7thNe25thWpWG6P9SZhAX6QIjAZaX 0sOg==
MIME-Version: 1.0
X-Received: by with SMTP id j5mr11693500lbl.37.1360188710878; Wed, 06 Feb 2013 14:11:50 -0800 (PST)
Received: by with HTTP; Wed, 6 Feb 2013 14:11:50 -0800 (PST)
X-Originating-IP: []
Date: Wed, 6 Feb 2013 17:11:50 -0500
Message-ID: <CAL02cgSt7w5CrP+DXo7bz_+YsxKsVMoRbZLNWa6EHjnAyScWMg@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: "jose@ietf.org" <jose@ietf.org>
Content-Type: multipart/alternative; boundary=e0cb4efe3572f07fb104d5159cee
X-Gm-Message-State: ALoCoQkWqBjz4WKwNy2CDePo5eSsjsVOsB0yFPIik1he6xxR3fxP2wcru7AIjilJEqdiqZPmzlbj
Subject: [jose] SPI proposal
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Feb 2013 22:11:53 -0000

To move us toward closing Issue #9 [9], here is some proposed text for an
SPI [1] field.  To recall, SPI stands for "security parameters index",
borrowing a term from IPsec.  The idea is that in cases where the same
crypto parameters are being used repeatedly, this would save the parties
from having to re-send the same parameters.

The below text is designed for the JWE spec, but could be adapted for JWS
(just keep header, ignore part about key/iv).  Similar text is probably
needed for the encryption/decryption/signing/verification sections.

Feedback welcome,

Section 4.1.X. "spi" Header Parameter

The "spi" (Security Parameters Index) header parameter contains an opaque
byte string that labels a set of security parameters.  This index is
designed to enable the use of smaller headers in cases where entities will
be re-using the same security parameters for several messages.

Entities supporting the use of the "spi" parameter MUST maintain a table of
cached security parameters.  When an entity receives an object whose header
contains both "spi" and "alg" values, then it MUST cache the following
values from the JWE, indexed by the "spi" value:
-- Contents of the JWE header
-- Encrypted Key
-- Initialization Vector

If an object containing an "spi" parameter but no "alg" parameter, then it
MUST NOT contain an Encrypted Key or Initialization Vector.  That is, it
will have the form "header.ciphertext.integrity_value".  When a recipient
receives such an object, it uses the "spi" value to retrieve cached header,
key, and initialization vector and reconstructs a full JWE.  This full JWE
can then be further processed according to the normal JWE processing rules.
 If the recipient has no cached parameters for the "spi" value, the process
MUST fail.

[9] http://tools.ietf.org/wg/jose/trac/ticket/9