Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)

Richard Barnes <rlb@ipv.sx> Thu, 02 October 2014 18:38 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C9E1ACC86 for <jose@ietfa.amsl.com>; Thu, 2 Oct 2014 11:38:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlA0d6elcDgN for <jose@ietfa.amsl.com>; Thu, 2 Oct 2014 11:38:16 -0700 (PDT)
Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9787E1ABC0F for <jose@ietf.org>; Thu, 2 Oct 2014 11:38:15 -0700 (PDT)
Received: by mail-la0-f51.google.com with SMTP id ge10so2855233lab.24 for <jose@ietf.org>; Thu, 02 Oct 2014 11:38:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QXjRvAeksVbB8Y6djl9s65AI4tpQRS6UGSLcSzyJNZY=; b=Glh2OjVUsZOddBU7PPKe0rK/AcNf0XFqpVSvv/a5haWGUX+BgSDAETaFeGPxp4jmms L134PEgO+sFgAtxGpTqnKe5xBujwdPWedlGNtns0gRc7eRXwol+Oe3vQYyuN/s+uiXWL mwNr8aincrjWQQ7eV/sC3ROgugQeinAw1AFsoh/W5l7CinCGvuBZ+EKDwkJ+c4IuLA8x IZtjrQTmFJ3p8ooWbguTTwhqUDZyzhnKOS3e7cvCsQ/EpbIlosqAaTz0A97EF3c8gYze eT+5UayFRKPCAeuR/66E1r8xvht3Vl1Rw4VhlhWWKmNIemXJwGpxKdAZ6TsajF3nRQco ik9g==
X-Gm-Message-State: ALoCoQlqIGC6dzO9qBtifN4jxS9icI4ONWYoytEV+LgmAnWGgbfc1TPn2dz69Cq7KYJ/2peiaZxH
MIME-Version: 1.0
X-Received: by 10.112.167.137 with SMTP id zo9mr792137lbb.0.1412275093783; Thu, 02 Oct 2014 11:38:13 -0700 (PDT)
Received: by 10.25.142.3 with HTTP; Thu, 2 Oct 2014 11:38:13 -0700 (PDT)
In-Reply-To: <10d801cfde6e$4b109320$e131b960$@augustcellars.com>
References: <20141002042150.11117.29199.idtracker@ietfa.amsl.com> <10d801cfde6e$4b109320$e131b960$@augustcellars.com>
Date: Thu, 2 Oct 2014 14:38:13 -0400
Message-ID: <CAL02cgS+RSe8GgqzXr=VyzHuh0zouiNJWxqmUs9aitAHFVsk_g@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Jim Schaad <ietf@augustcellars.com>
Content-Type: multipart/alternative; boundary=001a11c2adde4a5a81050474eb17
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/kiKmIwW1NncbZCcH3frVAyuSYyY
Cc: "jose-chairs@tools.ietf.org" <jose-chairs@tools.ietf.org>, The IESG <iesg@ietf.org>, "jose@ietf.org" <jose@ietf.org>, "draft-ietf-jose-json-web-signature@tools.ietf.org" <draft-ietf-jose-json-web-signature@tools.ietf.org>
Subject: Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 02 Oct 2014 18:38:18 -0000

On Thu, Oct 2, 2014 at 2:25 PM, Jim Schaad <ietf@augustcellars.com> wrote:

>
>
> -----Original Message-----
> From: Richard Barnes [mailto:rlb@ipv.sx]
> Sent: Wednesday, October 01, 2014 9:22 PM
> To: The IESG
> Cc: jose@ietf.org; jose-chairs@tools.ietf.org;
> draft-ietf-jose-json-web-signature@tools.ietf.org
> Subject: Richard Barnes' Discuss on draft-ietf-jose-json-web-signature-33:
> (with DISCUSS and COMMENT)
>
> Richard Barnes has entered the following ballot position for
> draft-ietf-jose-json-web-signature-33: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-signature/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Overall, this document is in much more solid shape than when it began.
> Thanks to the WG for a lot of hard work.  I only have two remaining
> concerns, which should hopefully be easy to address.
>
> Section 7.2.
> I've had several implementors trying to use JWS in the JSON serialization
> ask why it was necessary to include a "signatures" array in cases where
> there's only one signer.  It seems like this is going to be a major barrier
> to deployment and re-use, so I would propose including the following text:
>
> """
> In cases where the JWS has been signed by only a single signer, the
> "signatures" array will contain a single object.  In such cases, the
> elements of the single "signatures" object MAY be included at the top level
> of the JWS object.  A JSON-formatted JWS that contains a "signatures" field
> MUST NOT contain a "protected", "header", or "signature" field, and vice
> versa.
> """
>
> This may also require some other changes where "signatures" is relied on,
> e.g., in Section 9 of the JWE spec.
>
>
> Section 6.
> """
> These Header Parameters MUST be integrity protected if the information
> that they convey is to be utilized in a trust decision.
> """
> This smells really fishy to me.  What's your attack scenario?  I'm pretty
> certain that there's no way any of these fields can be altered in such a
> way that (1) the signature will validate, and (2) the recipient will accept
> a key it shouldn't.  By way of contrast, CMS doesn't sign the certificate
> fields, and the Certificate payload in TLS is only signed as a side effect
> of the protocol's verification that the remote end has been the same
> through the whole handshake (which doesn't apply here).
>
> [JLS] There were a couple of attacks that were created for CMS based on
> using the SKI as the identifier in CMS.  There now exists a signed
> attribute for CMS to deal with this problem.   IMO the pointer the
> certificate probably should be a required signing field in CMS
>

Citation?



> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Section 2.
> In the definition of "Unsecured JWS", it would be good to note that this
> requires "alg" == "none".
>
> Section 3.3.
> Why doesn't this section have a JSON-encoded form as well?
>
> Appendix A.5.
> I would prefer if this example could be removed.  JWT is the only use case
> for Unsecured JWS right now, and there's already an example in that
> document.
>
> Thanks for Appendix C.  FWIW, it has been implemented:
>
> http://dxr.mozilla.org/mozilla-central/source/dom/crypto/CryptoBuffer.cpp#85
>
>
>