Re: [Webpush] AD Review of draft-ietf-webpush-vapid

Martin Thomson <> Fri, 16 June 2017 02:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E507F129426; Thu, 15 Jun 2017 19:41:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b7iwCGL2nqo0; Thu, 15 Jun 2017 19:41:17 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5038312941D; Thu, 15 Jun 2017 19:41:17 -0700 (PDT)
Received: by with SMTP id p189so18372202lfe.2; Thu, 15 Jun 2017 19:41:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=C9Rst8SVCQHvvlfGHcaNAac415Fq8iRrQ2/uCMjC9lY=; b=iTPQkXUZ8K7070gc4xGLEGJvoW7UtcVylEVv4M9K48qpA4SL8r1bbmUEfzENYesxQO BIgD4FKnihmDqXe9ikJJLy5qvJqqIzrcSSBFlYX6N5jQefzdEEoaD/leDyXZX4uFCqNz 67hMEUg6OegrwOuFiyCG+k3uxcPk6qJ3oujFDrSCwtLcLWQSYNSkYUYmh4xC5Eg5u2Vj aJ058LqgHps+8paUn0JqmiQSFUMOqPAnDA3xjh0dc/KP3q51qj+wODeF6LCBYtQGtbIT smVHriF//Fk0ptpuIbXLSuQKKUHHa5sPurhfuPSaCf7EPqitZ+o040IP1T6B2YR71E4t +UTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=C9Rst8SVCQHvvlfGHcaNAac415Fq8iRrQ2/uCMjC9lY=; b=ZFpOQ2JwixHeC+MOixr4AWiaeR7nSa95JT8FztpRqKzOiKNvK0ErgTItJulDj0OuCw seXZ5kkEDKKkXwJkhR+DB4za/rEm1Dk0AgvEEOYAgihFqAFMFfhcq3aROyOnJCWurgH4 FCHbqgHIHelJPG9RtEqtKJpK2l7rEYTPaE4zt6GqDZU6NwifACjyhODuDxP5zSfc2ncr YGdX/WdhNb5lTb0lPDck2Yo4AyXTFVkhQLyTAITbUM+u6HcUGzYMdBRTZvOnUTY9ycPV NRnLyzY7SJJsQCSBwWEmp5dzN1gFVqG7P/pAEqGMxS5YtrZyT6vr1SoT3aRlRIseHOHB YC8w==
X-Gm-Message-State: AKS2vOwu0oSrxxrNfNAs5Ga2WnzreW26KqEql7KECme3OCP/pnHJr6HO NTqL+b4reGkshbSYTBZDz/VPTKJT6G91Ygo=
X-Received: by with SMTP id r21mr2339481ljd.22.1497580875457; Thu, 15 Jun 2017 19:41:15 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 15 Jun 2017 19:41:14 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Martin Thomson <>
Date: Fri, 16 Jun 2017 12:41:14 +1000
Message-ID: <>
To: Adam Roach <>
Cc:, "" <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Webpush] AD Review of draft-ietf-webpush-vapid
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of potential IETF work on a web push protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 16 Jun 2017 02:41:20 -0000

On 15 June 2017 at 10:09, Adam Roach <> wrote:
>> As you say, an application server doesn't really have any way of
>> determining that the push service supports a given algorithm.  That
>> means we need to be very careful about how we signal these things.
>> Using the authentication scheme (in this document, "vapid") as the
>> extension point means that we can use the existing mechanisms in HTTP
>> to signal which scheme is supported if it ever comes to the point
>> where we want to or are forced to deploy a new algorithm.
> Sure. Can the document say this?

>> We also have the option of replicating the supportedContentEncodings
>> parameter of PushManager in the API
>> ( so that
>> applications might avoid that round trip.
> ...and that's much better (presuming you intend to *add* something rather
> than shoehorning signature algorithms into a list intended for encryption
> algorithms). Is there anything we can do now to lay the groundwork for that?

That's not this document, but it closes the loop.

> Is the application server identification mechanism described in this
> document intended to *ever* be useful WITHOUT using the Subscription
> Restriction mechanism described in section 4?

The document addresses two use cases: subscription restriction and
self-identification.  The former most certainly relies on the
signature.  The latter is almost served by having the JWT payload in
the request, but we did agree that key continuity is an part of that
use case.  That means that the push service relies on the signature
for establishing continuity of identity.  It's hard to build up a
reputation as an upstanding application server when anyone can
trivially pretend that they are you.

Those two use cases are intended to be exhaustive.

For the reputation part, I believe that it is acceptable for key
rotation to result in loss of reputation, but it's probably worth
making an explicit note of the consequences:

> I don't care about the name, and what you propose is a fine shade for this
> shed. It would be worth noting that future documents may add more fields to
> the schema, and that they will do so by updating this document (along with
> the requisite "ignore fields you don't know" language).