Re: [jose] #24: Move JWS headers into signature block

Richard Barnes <rlb@ipv.sx> Sun, 30 June 2013 22:19 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 ACCE721F9BF7 for <jose@ietfa.amsl.com>; Sun, 30 Jun 2013 15:19:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.476
X-Spam-Level:
X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Qd-nZEbvchu for <jose@ietfa.amsl.com>; Sun, 30 Jun 2013 15:19:11 -0700 (PDT)
Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id CFB3021F9BF6 for <jose@ietf.org>; Sun, 30 Jun 2013 15:19:10 -0700 (PDT)
Received: by mail-oa0-f41.google.com with SMTP id n10so4166036oag.0 for <jose@ietf.org>; Sun, 30 Jun 2013 15:19:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=nII0Kigyw5PEIjA8hyWyLIoPWxd110Req8N7RuZ+Tx0=; b=nUalZcrZlY5qmRuB8b8pexLrn9yl5L9zIZoGaww01DVPgWkieyLLxC2BpJR+SFZ84a ohKckMfvh7/Uu6itQrTkVvjNN7WLsiBoozeGW2UfMtwOM/ozJXiN8A6k+zC3PDHDwate YgRFV4uKP/SGZOcrfa3bDUw2iF0PdDuKWjSWRofAu5RaAyfVlVuHhb0/RItFcALUiiUs Z8jXRxoE7p9zSWsl3rn92TqzppQQhG0BHQJF1oOhsf8817k/p5f3wJHE+CcdyPdBwTjI v6aCgfzGCX0cs/wtuqsFm6mvWos/7wKOYw1QsSeF0NV9zQV+DDTOCQ4VcdzyV3K660Bk KEbw==
MIME-Version: 1.0
X-Received: by 10.60.97.74 with SMTP id dy10mr8538117oeb.27.1372630750242; Sun, 30 Jun 2013 15:19:10 -0700 (PDT)
Received: by 10.60.26.135 with HTTP; Sun, 30 Jun 2013 15:19:10 -0700 (PDT)
X-Originating-IP: [128.89.255.182]
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943678A937E@TK5EX14MBXC283.redmond.corp.microsoft.com>
References: <049.3a20609eab4b4c08a7e01f21f6d6565d@trac.tools.ietf.org> <064.9c6aec3e9813fc2933f6082d75e8e239@trac.tools.ietf.org> <4E1F6AAD24975D4BA5B1680429673943678A937E@TK5EX14MBXC283.redmond.corp.microsoft.com>
Date: Sun, 30 Jun 2013 18:19:10 -0400
Message-ID: <CAL02cgR0R2bc_d_mmXKovPe0Gzt=-GDiUU-A6cL8UShO=SJgmQ@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary="089e0115e9fa46b55204e0668002"
X-Gm-Message-State: ALoCoQlEK5ry5UJqdkxweNLIB/VUe8kGj6sUr8i0dh9YpvW/k1M6nPRPZurbMeyLNEiOAVnOe/0+
Cc: "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] #24: Move JWS headers into signature block
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: Sun, 30 Jun 2013 22:19:15 -0000

I was not on the call.  Sorry.

I also disagree with closing this issue.  This is not a crypto question,
it's just syntax cleanliness.  As Mike points out, the proposed syntax
allows the JSON serialization to have the same security properties as the
compact serialization.  The only cost is that protected items have to be
repeated for each signer.

I will definitely be on the call tomorrow.  Happy to discuss then.

--Richard


On Sat, Jun 29, 2013 at 6:42 AM, Mike Jones <Michael.Jones@microsoft.com>wrote:

> Perhaps I'm in an odd frame of mind tonight, because I wouldn't normally
> even consider re-raising a closed issue, but Ben Laurie's advice "why not
> just protect everything" kept running my mind and I realized that the
> current JWS JSON Serialization doesn't allow us to do that in the general
> case.  Specifically, we don't allow a per-signature "protected" headers
> field, which would be necessary to protect the cryptographic parameters if
> different signatures use different algorithms.
>
> So I'd at least like others' thoughts on whether we want to "fill in the
> matrix" for the JWS JSON Serialization and allow header parameters to be
> specified both in protected and unprotected forms, both on a shared and
> per-signature basis.  We currently support 3 of these 4 header parameter
> locations.
>
> Note that we would not do this for JWE, since (as extensively discussed)
> per-recipient protected content is problematic.
>
> For the signature input, if both shared and per-signature protected
> headers were present, we'd need to concatenate the two base64url encoded
> representations together with a separator character between (I'm thinking
> comma (',') because it is distinct from period ('.'), which is also used as
> a separator in the signature input).
>
> I'm fine with this issue remaining closed, but I wanted to at least run
> this possibility by the working group for their input, since it hadn't been
> discussed previously.
>
>                                 Cheers,
>                                 -- Mike
>
> -----Original Message-----
> From: jose issue tracker [mailto:trac+jose@trac.tools.ietf.org]
> Sent: Monday, June 24, 2013 10:57 PM
> To: draft-ietf-jose-json-web-signature@tools.ietf.org; Mike Jones;
> ietf@augustcellars.com
> Cc: jose@ietf.org
> Subject: Re: [jose] #24: Move JWS headers into signature block
>
> #24: Move JWS headers into signature block
>
> Changes (by ietf@augustcellars.com):
>
>  * status:  new => closed
>  * resolution:   => wontfix
>
>
> Comment:
>
>  Closing per the discussion on the teleconference.
>
>  We currently do not have a strong use case for per user items.   It will
>  be possible in future versions to add a protected field to the per signer
>  item and include both in the integrity protection in the event that a use
>  case appears.
>
>  There was no strong recommendation from the CFRG list if a hash
>  substitution attack is either probable or possible.
>
> --
> -------------------------+----------------------------------------------
> -------------------------+---
>  Reporter:  rlb@ipv.sx   |       Owner:  draft-ietf-jose-json-web-
>      Type:  defect       |  signature@tools.ietf.org
>  Priority:  major        |      Status:  closed
> Component:  json-web-    |   Milestone:
>   signature              |     Version:
>  Severity:  -            |  Resolution:  wontfix
>  Keywords:               |
> -------------------------+----------------------------------------------
> -------------------------+---
>
> Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/24#comment:2>
> jose <http://tools.ietf.org/jose/>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>