Re: [jose] SPI proposal

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

Return-Path: <rlb@ipv.sx>
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 25F2E21E8039 for <jose@ietfa.amsl.com>; Wed, 6 Feb 2013 14:31:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.063
X-Spam-Level:
X-Spam-Status: No, score=-1.063 tagged_above=-999 required=5 tests=[AWL=-0.638, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 QGLZhvHy5WHr for <jose@ietfa.amsl.com>; Wed, 6 Feb 2013 14:31:23 -0800 (PST)
Received: from mail-la0-x235.google.com (la-in-x0235.1e100.net [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id AC56D21F850C for <jose@ietf.org>; Wed, 6 Feb 2013 14:31:22 -0800 (PST)
Received: by mail-la0-f53.google.com with SMTP id fr10so1930592lab.40 for <jose@ietf.org>; Wed, 06 Feb 2013 14:31:21 -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:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=9hyAK941MokoXOMQ/F0u9fcUPx12x56DfT7uH9BW16A=; b=MXiUC9lA3wwm9PKQJYF5TsiWw0KXiSL0Oc9sQKLrD2oTZG3P/TcVnbF6eGoyh8Tibp KFvbDDncFknh8+gk0GzaSZO0dqr/kMkyN3e14SIgmm6UZsuU5USpo9dF2AprtwkSoDax Ky1vQmXypwfhp43HRIkoVoYv/TTx+LdWh4O9onn5Jj4WjfwAZUu5kQi9Vllx1x6Uz1cm 0YmfJ5ixom+vnBg3uoUjOqJIa/ZH5XpIqng2s42UVVnqPTpw1eF95cOjqTtzosEEB6vI YwQsUUxpaHrJ+Vh4XVEj4rtOGSweHAXS3IXyS4QOcrkdSythdKUooUtMyYnjDN18mSqC PGCQ==
MIME-Version: 1.0
X-Received: by 10.152.113.6 with SMTP id iu6mr28306774lab.43.1360189881232; Wed, 06 Feb 2013 14:31:21 -0800 (PST)
Received: by 10.112.147.164 with HTTP; Wed, 6 Feb 2013 14:31:21 -0800 (PST)
X-Originating-IP: [128.89.254.55]
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436741873C@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <CAL02cgSt7w5CrP+DXo7bz_+YsxKsVMoRbZLNWa6EHjnAyScWMg@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739436741873C@TK5EX14MBXC284.redmond.corp.microsoft.com>
Date: Wed, 6 Feb 2013 17:31:21 -0500
Message-ID: <CAL02cgQA6K_HBSeg9G5w_74C_sK85bH_o9xpqRuQcbii47H7fg@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary=f46d04089151b2ac1204d515e24a
X-Gm-Message-State: ALoCoQnnoUxza3M5ryKQEvK5e4a31tFYhZKA/KrjVRSB7bgtWXQHHlcQ3VqPxSuz5Kvf36odf0im
Cc: "jose@ietf.org" <jose@ietf.org>
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:31:24 -0000

I was thinking base64-encoded binary.
--Richard


On Wed, Feb 6, 2013 at 5:28 PM, Mike Jones <Michael.Jones@microsoft.com>wrote;wrote:

>  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<jose-bounces@ietf.org>]
> *On Behalf Of *Richard Barnes
> *Sent:* Wednesday, February 06, 2013 2:12 PM
> *To:* 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****
>