Re: [Webpush] Ben Campbell's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT)

Ben Campbell <> Thu, 17 August 2017 01:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB662126DD9; Wed, 16 Aug 2017 18:04:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DH6t8-hOoLX1; Wed, 16 Aug 2017 18:04:28 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B528A1323B6; Wed, 16 Aug 2017 18:04:27 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id v7H14MKB068807 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 16 Aug 2017 20:04:23 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ben Campbell <>
In-Reply-To: <>
Date: Wed, 16 Aug 2017 20:04:22 -0500
Cc: The IESG <>, draft-ietf-webpush-vapid <>, Phil Sorber <>,, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Martin Thomson <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [Webpush] Ben Campbell's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT)
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: Thu, 17 Aug 2017 01:04:30 -0000

> On Aug 16, 2017, at 8:01 PM, Martin Thomson <> wrote:
> On 17 August 2017 at 01:52, Ben Campbell <> wrote:
>>> I think that "MAY" is entirely appropriate given the non-blocking
>>> nature of the mechanism. A push service might look at the header
>>> field, but not require the token. Maybe they just wanted to attach an
>>> email address to a stream of messages (that's what we do).
>> I think there’s a fundamental difference between not validating in the first place, and ignoring a failed validation. My point is not to say that ignoring it is the wrong thing to do, just that I think some more elaboration here is needed. Would it make sense to say something of the effect of “SHOULD NOT use the information from a token that has failed validation”?
> That's easy.  MUST NOT even.  I added:  "A push service MUST NOT use
> information from an invalid token.”

WFM. I will clear.

>>> In NSS and many elliptic curve libraries, you can create an EC key for
>>> P-256.  You can then use that key for signing AND key exchange.  You
>>> shouldn't though.
>> Would it make sense to say “Some library implementations…”?
> The PR says "Some elliptic curve implementations ".  I think that's better.

Also WFM.

>> Oops, that was a cut and paste error. I meant to quote the following sentence:
>> " A push service MAY reject a
>>   message that includes invalid credentials with a 403 (Forbidden)
>>   status code. "
> I'll respond below.
>>> This section defines behaviour in the case that a
>>> subscription is limited to a particular application server key.  I
>>> realize now that this might have been unclear, so I have reworded to:
>>> "A push service MUST reject a message sent to a restricted push subscription if
>>> that message includes no "vapid" authentication or invalid "vapid"
>>> authentication.  A 401 (Unauthorized) status code might be used if the
>>> authentication is absent; a 403 (Forbidden) status code might be used if
>>> authentication is invalid."
>>> This also allows me to clear up a minor gripe about the prescriptive
>>> nature of the text regarding status codes.
>> I like that paragraph better, but does it conflict with the text in section 2, as discussed in my DISCUSS?
> The key point here is that the rejection mandated in Section 4.2 is
> specific to *restricted* subscriptions.  The text in Section 2 (above)
> is a more general statement.  I don't think that the two are in
> conflict.