Re: [Webpush] Voluntary Application Server Identification -02

On Wed, Feb 10, 2016 at 2:30 PM, JR Conlin <jconlin@mozilla.com> wrote:

> While talking with Kit, I'd like to present a set of rules (I was going to
> call them best practices, but really, that's like saying "Do not lick high
> voltage lines" is a best practice.)
>
> 1) If a site registers a public key as part of a subscription request,
> that key is used to validate the JWT. Invalid JWTs result in a 401.
>

Not sure I understand - the register() call takes a public key, and the
push service needs to verify that the send request
includes a JWT token with the same key - is that what you mean ?

>
> 2) If a site registers a public key, it should NOT include the public key
> as part of the Crypto-Key header in the Push request (since this increases
> the chance that the key is inadvertently disclosed.)
> I'm not sure how or if we should signal that back to the App Servers.
>

The key used in register() needs to be included in the push request -
technically we can work around this, by having the
push service store the key - but by having it in the push header it can
reduce the storage ( the push service can
only store a hash of the key, or can include a hash of the key in the
registration token, so no storage - assuming the registration is
encrypted/signed).

It's a public key - why would it be a problem in disclosing it ? Anyone who
cares can get it from the browser making
the subscribe request, it's more or less as secure as the public key in the
TLS cert.

Costin

>
> 3) If the Crypto-Key:p256ecdsa == Crypto-Key:p256dh, that will return a
> 401. (it's just math kids, you can pick different coordinate sets, for
> free.)
>
> Seem reasonable?
>

>
>
> On 2/1/2016 12:33 PM, Costin Manolache wrote:
>
> +1
>
> Costin
>
> On Mon, Feb 1, 2016 at 10:43 AM, Peter Beverloo <beverloo@google.com>
> wrote:
>
>> Thank you for publishing the draft, Martin!
>>
>> While I'm not sure how much significance it carries since I'm listed as
>> an editor, I do of course support the draft as the resolve to Issue 44.
>>
>> Server authentication and subscription association are important problems
>> to us, and, pending any further feedback from the working group, we plan to
>> adopt the proposed solution in our implementations.
>>
>> Thanks,
>> Peter
>>
>> On Mon, Feb 1, 2016 at 1:56 AM, Martin Thomson <
>> <martin.thomson@gmail.com>martin.thomson@gmail.com> wrote:
>>
>>> I have just posted a new version of the draft, taking the recent
>>> feedback from discussions into account.
>>>
>>> https://tools.ietf.org/html/draft-thomson-webpush-vapid-02
>>>
>>> This includes only the JWT option, with a lot more of the details
>>> fleshed out.  I've implemented it in order to create the example, and
>>> that is dead simple to do.
>>>
>>> I think that this is the answer we want for issue 44 [44].  Does the
>>> group agree? Is this worth adopting?
>>>
>>> [44] https://github.com/webpush-wg/webpush-protocol/issues/44
>>>
>>> _______________________________________________
>>> Webpush mailing list
>>> Webpush@ietf.org
>>> https://www.ietf.org/mailman/listinfo/webpush
>>>
>>
>>
>> _______________________________________________
>> Webpush mailing list
>> Webpush@ietf.org
>> https://www.ietf.org/mailman/listinfo/webpush
>>
>>
>
>
> _______________________________________________
> Webpush mailing listWebpush@ietf.orghttps://www.ietf.org/mailman/listinfo/webpush
>
>
>