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

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E87941A1A69 for <>; Tue, 30 Sep 2014 12:08:52 -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 DQ9Hm_GlkIc2 for <>; Tue, 30 Sep 2014 12:08:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2E68A1A87D4 for <>; Tue, 30 Sep 2014 12:08:48 -0700 (PDT)
Received: by with SMTP id i17so4528604qcy.2 for <>; Tue, 30 Sep 2014 12:08:47 -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=mpQyZ9ubF7bQSPrYNkduiHqOO4iBK0B9LcecOt2t2P0=; b=DsA2EVN6KGaoEE+JNsDuwHLIhNn2qBUeA82d6mJf4r1vF7Qoz6HR4iIL0j5C/3oODN B/CqE2s2wG1iUdDoVGTJP+7iPNb6+Qx4swvGsrYm3o4ZWUCHT8tPatH9KGO2ShRT0rIu yEF6bQyaCy/zrgnS98IzCIpgPJdhxidmBat+k=
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=mpQyZ9ubF7bQSPrYNkduiHqOO4iBK0B9LcecOt2t2P0=; b=digIkiPtlgLYqV9SoQ1evokppAhipHPQj8Zj1kJ8oM3h2C/qKGgkDX9vFmYb94Ekkt E6AqmnJLBS1Et9teQzVijqlMBweINi4tbQHsqZpHsMtfZ6jGRz8u0C5/F1CBeSLWmI0p c2pOzKDbi/4B++o/Yk8B3AstdK7J/teKkhg2qArxT5tXGt9d8TJk0UAVBvNQRGw/PjA0 IJOnlgLnvMTyxcgfGAR6lI2Quo+b/jcTQfpuRUbINJ5xMWgTdR14LFBE0nnvPe3ZnBQU tHZ0i0jJy4YjBx8vwoz9hGXIq8hiddCS38Y+Yo8FLASHLqbp2qCHuWQRM/t+We70j/HX d6Mg==
X-Gm-Message-State: ALoCoQmEPFguRC57QvOUHm9jeqTqo46weWRl/VpaxI2m5Gc2urXPZGbm4p+Tjv+ej9P+gH4hbjfK
MIME-Version: 1.0
X-Received: by with SMTP id d93mr78362830qge.53.1412104127241; Tue, 30 Sep 2014 12:08:47 -0700 (PDT)
Received: by with HTTP; Tue, 30 Sep 2014 12:08:47 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Tue, 30 Sep 2014 20:08:47 +0100
Message-ID: <>
From: Dave Cridland <>
To: Mike Jones <>
Content-Type: multipart/alternative; boundary="001a11396236e404a805044d1c34"
X-Mailman-Approved-At: Tue, 30 Sep 2014 12:36:34 -0700
Cc: "" <>, IETF Gen-ART <>, Russ Housley <>, IETF <>, "" <>
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:08:53 -0000

On 30 September 2014 19:10, Mike Jones <> wrote:

>  - In Section 4.1.5, why is TLS required to fetch digitally signed
>    X.509 certificates?
> This question was explicitly discussed by the working group at IETF 87.
> The discussion is recorded in *the minutes
> <>* as follows:
> If there is an x5u pointing to a certification issued by a major CA, is
> TLS required for the HTTP query used to retrieve this certificate?  TLS
> shouldn't be needed since the certificate is a signed object.  Therefore,
> the "MUST" use TLS for cert retrieval should be changed to "SHOULD".  This
> is an application decision.  Mike Jones doesn't want removal of TLS in the
> case where there's no external means to verify the retrieved key.  Matt
> Miller: agrees with the jku case, but argues that for x5u, there is a class
> of applications where it isn't known if the retrieved object is
> self-protecting (like a certificate) until after it is retrieved.  Even if
> the object appears to be self-protecting, if the retriever doesn't have a
> trusted root for that object, it might not be able to verify the protection
> anyhow.  So it use of TLS might still be preferable instead of having to
> potentially retrieve an object twice, once over HTTP and then over HTTPS.
> Joe Hildebrand wanted to know what the upside of this proposal is.  Richard
> says it saves on TLS handshakes; Hildebrand envisions a world where TLS is
> ubiquitous.  Paul Hoffman said that a similar issue in DANE ended up being
> dropped after a couple of months of discussion.  Richard agreed to drop the
> TLS MUST to SHOULD proposal.
> Russ is certainly right that for certs that chain back to a known root of
> trust, integrity protection isn’t necessary.  It’s also the case that this
> is not true of all certificates that might be used – especially self-signed
> certificates intended only to carry a key value.  One possibility is to say
> that TLS MUST be used unless the certificate chains back to a known trust
> root accepted by the application.  Of course, just requiring TLS is
> simpler. Do people in the working group want to re-open this issue or are
> people content with the current requirements?
I thought the requirement was confusing as well, however I thought the
rationale might be entirely different:

JOSE exists, in no small part, because of the difficulty in handling X.509
within JavaScript. Therefore even where a certificate [chain] is entirely
valid and properly signed, a JOSE client dereferencing the URI almost
certainly cannot validate the certificate - yet can validate those used in
the TLS handshake because of the difference in the API calls possible.
Indeed, it also cannot validate that the certificate's public key matches
the private key in the JSON object; making use of a trusted source more
important still.

So I do support making the x5u require a dereference over TLS, however I
also think the rationale[s] should be carefully documented in the
specification otherwise the requirement is likely to be ignored.

(More concretely, I think the specification ought to make TLS a SHOULD
here, and explain the rationale, and in particular say that it might be
relaxed only if a consuming application can perform X.509/PKIX path