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

John Bradley <> Tue, 30 September 2014 20:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A97121A889A for <>; Tue, 30 Sep 2014 13:15:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6dcctZVWP-j1 for <>; Tue, 30 Sep 2014 13:15:06 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 05E4D1A88A1 for <>; Tue, 30 Sep 2014 13:15:01 -0700 (PDT)
Received: by with SMTP id m20so3809431qcx.17 for <>; Tue, 30 Sep 2014 13:15:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=/xR8PTR8c1PPD8WeRXaHNrU28QTowtQnkmIkiiDpB8U=; b=dyX0OaYDVwXBkAojsV4EJ2p9V84BMyFrPaDXGED9/qskI9KGS/GlDDWhB9sGyOLwfY z9zpYR4JYXTHozNsXzj2LxJ7MSL4obCNiDOT6wXL7AyQ7ktbJBGnkoezDFzD/39TbxFU bwCX2ognugqAN91mlFdUVbppCJapTgsDKAt8uR2s859oo5dYUUrfapGX3o/XPRV2Dfs8 HsuHAHuzVMvlHKJw6DEXoAGeSwQDqLaFlFDc9vCXUPIGcIa7A/wUxAlLrgizYuPtJdfp XixEM1N9llzHDpuKSxSAxRoROw6VgbQSqdkW5HpqL5Xj5cXx6CrfB/tGFixspiKBhcok J5iQ==
X-Gm-Message-State: ALoCoQlVxmX34hCVrDmds9q71xekSkI3ZCuNX2YjQWUWsiKBQ0l1EA5NCHjbyQUbUkQjuw3EWGaR
X-Received: by with SMTP id w9mr41222671qaj.32.1412108101003; Tue, 30 Sep 2014 13:15:01 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id w102sm14581999qgd.28.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Sep 2014 13:15:00 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_CBEA5CBE-7B76-4B9B-B829-A1E21D9C7EBA"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: John Bradley <>
In-Reply-To: <>
Date: Tue, 30 Sep 2014 17:15:04 -0300
Message-Id: <>
References: <> <> <> <> <>
To: Dave Cridland <>
X-Mailer: Apple Mail (2.1878.6)
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 20:15:07 -0000

The attack is not possible if the receiver validates the host from the x5u against the certificate CN and validates the path,  otherwise any valid certificate would work, as long as it chains to a valid root.

Yes we could explain that that the client could limit itself to a specific root or bridge and use the CN or DN for the identity of the signer.  

So yes it is possible to make an exception to the MUST but explaining how to do that safely is not trivial, and may cause more harm than good.

John B.
On Sep 30, 2014, at 4:53 PM, Dave Cridland <> wrote:

> 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.
> Dave.