Re: [jose] SPI proposal

Mike Jones <Michael.Jones@microsoft.com> Wed, 06 February 2013 22:29 UTC

Return-Path: <Michael.Jones@microsoft.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315D01F0CFF for <jose@ietfa.amsl.com>; Wed, 6 Feb 2013 14:29:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 dInLrkjnEAbV for <jose@ietfa.amsl.com>; Wed, 6 Feb 2013 14:29:03 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE8921F84FC for <jose@ietf.org>; Wed, 6 Feb 2013 14:29:03 -0800 (PST)
Received: from BL2FFO11FD013.protection.gbl (10.173.161.204) by BL2FFO11HUB018.protection.gbl (10.173.160.110) with Microsoft SMTP Server (TLS) id 15.0.609.9; Wed, 6 Feb 2013 22:28:55 +0000
Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD013.mail.protection.outlook.com (10.173.160.221) with Microsoft SMTP Server (TLS) id 15.0.609.9 via Frontend Transport; Wed, 6 Feb 2013 22:28:54 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.132]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Wed, 6 Feb 2013 22:28:19 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Richard Barnes <rlb@ipv.sx>, "jose@ietf.org" <jose@ietf.org>
Thread-Topic: [jose] SPI proposal
Thread-Index: AQHOBLcNADQWCZtyXUK8CEAiSWhmY5htZqNggAACHEA=
Date: Wed, 6 Feb 2013 22:28:19 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436741873C@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <CAL02cgSt7w5CrP+DXo7bz_+YsxKsVMoRbZLNWa6EHjnAyScWMg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.37]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436741873CTK5EX14MBXC284r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(377454001)(52604002)(51444002)(51914002)(31966008)(77982001)(76482001)(47446002)(51856001)(20776003)(4396001)(5343655001)(59766001)(55846006)(80022001)(74502001)(15202345001)(44976002)(54356001)(63696002)(5343635001)(512954001)(56816002)(54316002)(47736001)(79102001)(46102001)(53806001)(33656001)(16406001)(56776001)(49866001)(50986001)(65816001)(16236675001)(74662001)(47976001)(66066001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB018; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0749DC2CE6
Subject: Re: [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:29:06 -0000

BTW, what JSON data type did you intend to be used for the "spi" value?  A JSON string?  A string with any structure, or an unconstrained Unicode string?  A base64url-encoded byte sequence?

                                                            -- Mike

From: Mike Jones
Sent: Wednesday, February 06, 2013 2:27 PM
To: 'Richard Barnes'; jose@ietf.org
Subject: RE: [jose] SPI proposal

Thanks for writing this up, Richard.  I believe that captures the intent fairly well.

As we'd discussed off-list, I believe that it would be more consistent if, in the case were you are using a previously cached "spi" value, that the header contained "alg":"spi" and "spi":spi-value.  That would maintain the invariant that implementations always use the "alg" value to determine what the rest of the structure is - albeit in this case, via an indirection.

Also, then we'd register "spi" like any other "alg" value.  Other algorithms specify the use of particular header parameters.  This one would be no exception.  Registering it as an algorithm would also make it clear that it is up to implementations whether to support it or not.

I don't feel super-strongly about this, but I always try for consistency, where reasonable.  I think that this is such a case.

Again, thanks for the write-up to help move this forward.

                                                            Cheers,
                                                            -- Mike

From: jose-bounces@ietf.org<mailto:jose-bounces@ietf.org> [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Wednesday, February 06, 2013 2:12 PM
To: jose@ietf.org<mailto:jose@ietf.org>
Subject: [jose] SPI proposal

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,
--Richard

-----BEGIN-----
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.
-----END-----


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