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

Adam Roach <> Thu, 15 June 2017 16:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E61C129524; Thu, 15 Jun 2017 09:21:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.881
X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aZibHEp9Oyg7; Thu, 15 Jun 2017 09:21:06 -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 62EB4129486; Thu, 15 Jun 2017 09:21:06 -0700 (PDT)
Received: from Orochi.local ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id v5FGL3YA022427 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 15 Jun 2017 11:21:03 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be Orochi.local
To: Costin Manolache <>
Cc:, "" <>
References: <> <>
From: Adam Roach <>
Message-ID: <>
Date: Thu, 15 Jun 2017 11:20:58 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
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: Thu, 15 Jun 2017 16:21:08 -0000

On 6/15/17 02:07, Costin Manolache wrote:
> I think the 'negotiation' must happen much earlier - at subscribe time 
> (and in general case - out of band). At the time of auth, when VAPID
> is used, the caller must have an endpoint that is bound to the server 
> public key.
> If a EC256 public key is used at the time of endpoint creation - it 
> determines the signing algorithm as well.
> So the 'challenge' happens long in advance.

This makes sense, but it is a substantially different answer than Martin 
gave. I'll note that the subscription request doesn't indicate the 
algorithm to which the key corresponds, so the push server doesn't seem 
to have any ability to detect an algorithm mismatch until it's way too 
late to do anything about it.

I'm not too caught up on what the details of the plan are, but I think 
that whatever is intended should be documented. I don't want to have 
this protocol painted into a corner when we decide to move on to other 
algorithms, and when I combine your and Martin's answers, it's not clear 
whether that's the case. I do get the impression, however, that this 
aspect of the system design hasn't yet been discussed by the working 
group. It should be.