Re: [jose] Gen-ART review of draft-ietf-jose-json-web-signature-33

Dave Cridland <> Tue, 30 September 2014 19:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B2A681A8894 for <>; Tue, 30 Sep 2014 12:53:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CutQQ7cAh_jo for <>; Tue, 30 Sep 2014 12:53:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B7F221A8895 for <>; Tue, 30 Sep 2014 12:53:39 -0700 (PDT)
Received: by with SMTP id cm18so915321qab.30 for <>; Tue, 30 Sep 2014 12:53:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vkB7nZ2sHc22jzBa+h//sxURyy6R1jwpwqZQhH7xmmU=; b=gTvCcHMFgxh76YMSg3+PQ2Joj3wK2S3y4MQ8MvVA7oEGjmfABSShSHLkDZsu0tAy66 FTg/WsQZ4NL5clU2u4UHAyj7g2evnineWPVRmC/KkNarILHfGdXckQQlsUjIZRnJa4ZV D8iBYVGGWyfvC6D1cy+cKXa2p5VnMqXY24hD8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vkB7nZ2sHc22jzBa+h//sxURyy6R1jwpwqZQhH7xmmU=; b=bt0WPPx0HyNj9WP9pT45nRkUllMaLXS9CHS5BGkwoWOdq5NdICuQ1tPYb0+prVXB6e njmSvBRN4MZdIHQFixwnNX7B98sW5wL44RjBThvmdkwAAsDxX9wyGz7wgcPm8MeRsqf4 d8kcxMMrM4TrrdtKfHvj44LzdMtP9CcXSazYY5DXXsY7W51l5J1w/zMRqpU1tOjmecQa QILAs7/3JEp2EBuwqQW03gjJ8Rd2AeeCeupHItsI/t4TtSqDUUeJnKRkQ4pVIpwVU4Hz VvMiwyqLga8PNqCuXnSrmFkS/1bOVlOsZrcTvQFgxO9n2Hw8pTVQv7e/icj++Ao9cvqA X/xw==
X-Gm-Message-State: ALoCoQmXV7Cm0/Asuo6LxI9Aet6OzRpMkKcnl5P8AW0DPHEoXpdD8tufKJA1chyUd5FrI9K7QPom
MIME-Version: 1.0
X-Received: by with SMTP id o3mr15822194qak.103.1412106816975; Tue, 30 Sep 2014 12:53:36 -0700 (PDT)
Received: by with HTTP; Tue, 30 Sep 2014 12:53:36 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Tue, 30 Sep 2014 20:53:36 +0100
Message-ID: <>
From: Dave Cridland <>
To: John Bradley <>
Content-Type: multipart/alternative; boundary="047d7bdc9f78362e4605044dbdad"
X-Mailman-Approved-At: Tue, 30 Sep 2014 13:15:59 -0700
Cc: IETF <>, IETF Gen-ART <>, Russ Housley <>, Michael Jones <>, "" <>, "" <>
Subject: Re: [jose] Gen-ART review of draft-ietf-jose-json-web-signature-33
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Sep 2014 19:53:46 -0000

On 30 September 2014 20:37, John Bradley <> wrote:

> I agree, the likelihood of the application correctly walking the path and
> validating the chain is very small.
I think the likelihood of the application being *able* to is small given
the scope - however if it can, we should assume that it will.

> I strongly prefer leaving it a MUST use TLS and validate the server per
> RFC 6125.
> The other thing to note is that the CN of the cert is not in the header.
> If TLS is not used an attacker could simply modify the DNS to retrieve any
> valid certificate and use that to sign.
Whilst I agree there's a range of attacks possible against non-validating
clients - although "the CN of the cert" sets my teeth on edge - an attacker
cannot do these if the application performs path validation and checks the
key matches.

"SHOULD" and "MUST" are not a stick to beat the unthinking implementer, and
if there exist perfectly reasonable cases where this particular MUST can be
ignored, then by insisting on a MUST here we are simply weakening the
emphasis that all other RFC 2119 language has in this document.

"MUST unless you do X" is a compromise I'd be happy with, although that is
basically what "SHOULD" means.

Certainly this does require the rationale be documented in any case.