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

[Costin Manolache <[e-mail]>]

On Thu, Jun 15, 2017 at 9:20 AM, Adam Roach <[e-mail]> wrote:

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


I don't think Martin's answer is very different, the draft reflects what we
all agree on - but there are different ways to
extend it. The perspective is a bit different - our system still support a
'legacy' sender authentication scheme, based
on project IDs, which works using the subscribe parameters.

We've also seen few application servers migrate the 'sender id' and auth
scheme, as well as cases where app servers
ran into problems authenticating.


Costin



>
>
> /a
>
>