Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD741294AB for ; Mon, 21 Nov 2016 15:36:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6wOdU1Ph0m7 for ; Mon, 21 Nov 2016 15:36:55 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12C0B127078 for ; Mon, 21 Nov 2016 15:36:55 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id j65so54129170iof.0 for ; Mon, 21 Nov 2016 15:36:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Jc6Sdg/uJ1Jvh96ojTzuKewbWIMPF0pcFDnCx1sqJZE=; b=cLi3e0E3pwHyN0p0Hi0++NM3lY9MJm8Y9yAacs+OZpRcF0F0vR+sCeGDkw7pywOnAv 5ZkJ6SSFmICPtIbDdziZljLIGjZe0lKzctiMNcLf1z1th7pe3kUpulsik0suTNSc/ieq ARUKVfALHmCEBi4qefx5nSVnCtAjUoxWn9zOW2oPoLx/Cp60Q5/uLHqMUpK47gdRDnmd 0o+r6PUI4S81fxeaPYEty5zWJitFODIyVm6Ef0Gu3fYWvuAd8J6oOcrjVaWjwu9j5n02 IeezD8Py8ut9w6PJJaBbZiQtHA8P4ak8WL4CDRW/uLLWfQUEaDsgAbMPIcS+bFancsvY +3kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Jc6Sdg/uJ1Jvh96ojTzuKewbWIMPF0pcFDnCx1sqJZE=; b=b+1kdHIS8VE0+8BAZ43aDlqpBl+1jaDdPbe46XVswbgEEe/syQL1zZrv5M/1r9Bnvz 4N0Vpq5SrTuSe56TpQjrkN0wvXbvW0AKApUypMRNEitCLODN+VVKE1bQnoAHNDaaTIUE z9wK05w5N7E0lrndXHboCKOjp/Vky4cMuLvDdnN4LMc1cNrH/JaxriucywdfgXdu2o2n qdfA/amE2Ia9P1MW4Q2sJyFWAHsKQQknNqKF+Lzkb1wLDjB6WoxUfQPm+HoldZn/5w5H r09Mc4mAXRDTD0Z0spw7ZjU2ucTW6+6xqhs+Rzoudv9g4kbmfXgwnk2l71atPdMu4fZS mzjA== X-Gm-Message-State: AKaTC01EPXqF3OU/mBHZm3wqP1ib4RESGS6R6LT203McRo6gy4x1lfOTcggmGcriesYeu37BWNSO3NTtuGegPQ== X-Received: by 10.107.2.8 with SMTP id 8mr12834952ioc.83.1479771414141; Mon, 21 Nov 2016 15:36:54 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Costin Manolache Date: Mon, 21 Nov 2016 23:36:43 +0000 Message-ID: To: jr conlin , Martin Thomson Content-Type: multipart/alternative; boundary=001a113978767d215e0541d821aa Archived-At: Cc: "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Vapid public key X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Nov 2016 23:36:58 -0000 --001a113978767d215e0541d821aa Content-Type: text/plain; charset=UTF-8 On Mon, Nov 21, 2016 at 9:51 AM jr conlin wrote: > FWIW, I'm really not a fan of having an extra data path for things like > this. More paths mean more things that folks can screw up or not be able to > implement for various reasons. > > I think it's HIGHLY reasonable to ask that for a given restricted update, > the Application that is making the request include a public key for the > VAPID spec. The application could pull it from where ever, hard code it, or > whatever makes most sense to the Application developer team (and the > corresponding Subscription Update service provider). > > Things aren't exactly easy now, making them harder just means that less > folks will be able to do it. > My goal was to make it easier - in particular in cases where it's easy to screw up. If a developer has a test key and a production key ( which is a good idea - you want the prod private key well protected, and dev/testing be done with a different key ), it would be easier to have a different pub key file rather than different .js file or extra complexity/if It is a bit more work for the UA - but not much more. > > > On 11/20/2016 8:01 PM, Costin Manolache wrote: > > On Sun, Nov 20, 2016 at 5:32 PM Martin Thomson > wrote: > > On 20 November 2016 at 02:53, Costin Manolache wrote: > > One more small suggestion: one of the pain points ( for me ) is the W3C > > subscribe taking the > > vapid pubkey as bytes instead of a string, and having to include the key > in > > .js files as a constant. > > Your suggestion being that we define a base64url parser. You can > include the key in the form Uint8Array.from([4, 5, 6, 6, ...]); It's > > bigger and you have to work itI"m a out once, but it saves shipping a > converter. > > > Not really - the UA will need to take the uint8[] and convert it to b64 - > since that's what > the push service expects. AFAIK the UA has no use with the vapid public > key in current > protocol (except pass it along in subscribe) - we do not pass the > Authorization header > from push service to UA > > > I'm a bit confused here. If you use most key generation tools like > $ openssl ecparam -name prime256v1 -genkey -noout -out vapid_private.pem > $ openssl ec -in vapid_private.pem -pubout -out vapid_public.pem > $ grep -v "^-" vapid_public.pe > that dumps a b64 string the user can easily work with. Is the suggestion > that we ask users to convert to binary themselves? That may reduce the need > for base64 in the UA, but means that developers will need to add one. > Considering the fun that happened with "lpad" not too long ago, I'm a bit > concerned about the frustration that may come with that. > My suggestion is to _not_ ask the users to convert to binary ( or array of decimals ) themselves - that's what the current W3C API requires. I'll file the bug when I return (if Peter or someone else doesn't beat me to it :-). And as currently defined, the browser will need to take the Uint8array and b64 encode it before calling the webpush /subscribe. I think it would be better if W3C subscribe would take a string, and just pass it to the push service with no conversions - and let the pushservice deal with it. It would also be more future proof. > > > > > Either way, this is probably something to take here: > https://github.com/w3c/push-api/issues > > > Would it be possible to define a .well-known/vapid/... file where the > public > > key can be saved ? > > This may simplify tools, testing ( test env may use test sender keys), > etc. > > One problem is that > > .well-known is at root - so either have > > /.well-known/vapid/ENCODED_SW_URL.pub or > > have a less standard .well-known/ in the same directory with the SW. > > Now that we are considering removal of Crypto-Key (I'm about to send > out drafts with that change), I need to work out how to push the keys > along with the registration. I don't think that using .well-known > will give us the right binding to the subscription request though. > > Maybe I don't understand the proposal, though. Can you walk through > how a client would use this? > > > If client calls subscribe() - the UA will look for .well-known/vapid.pub > and pass it > in the /subscribe request to the push service. > > ... So the subscription provider will have to be able to create and > maintain a discrete path, the UA will need to make an extra successful data > call, just to provide a string that is for public consumption? > subscribe is not a very frequent event - and a page requires plenty of fetches. The convenience to just copy a file - instead of editing a JS file - may or may not be worth it, I'm not feeling very strongly about it. > > > If client calls subscribe( Uint8Array ) - UA will use the explicit key. > > Again, bit confused here. Granted, the UA's subscribe() function can do > whatever it wants once it has the public key. How the server actually > enacts the subscription restriction is irrelevant to both the UA and the > Subscription provider. > > The UA can also accept a key in several different formats by doing simple > tests. Likewise, how the Application acquires the key is really up to the > Application. > Agreed. UA can also just pass it to push service, and let the push service decide how to interpret it. > I'm seeing this more as "suggested practices" and "platform features" > rather than part of the specification. > > It is a bit simpler to just copy the key in a defined location - in > particular if you have > multiple environments. It is possible to do it in code too ( using the URL > to decide > which key to use ). Some people may also like the more declarative > approach. > > Huh, I'd argue that it may not always be possible. Some small vendor > platforms may not offer access to directories like "/.well-known" (e.g. if > you're working with classical Apache, you may be forced to root under > "/username/...", or some platforms may prohibit the use of leading "." > because of poor path management. I've had to deal with both in the past. > > Hopefully, I'm must misunderstanding the proposal again. > My concern was to make it easier for developers to specify the public key. The '.well-known' was just one idea, keeping the manifest or using a relative path to SW, or anything else is fine too. Costin > > > > Not a big deal - but I think it would be nice. > > Re. Crypto-Key: my understanding was that there are use cases for it, as a > way to > distribute keys, as discussed in the other thread. Subscribe needs some > header > ( or query param ?) to pass the authorized entity to the push service. We > just > don't need it for authorization or encrypted body. > > Costin > > > --001a113978767d215e0541d821aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 21= , 2016 at 9:51 AM jr conlin <jcon= lin@mozilla.com> wrote:
=20 =20 =20
FWIW, I&= #39;m really not a fan of having an extra data path for things like this. More paths mean more things that folks can screw up or not be able to implement for various reasons.


I think it's HIGHLY reasonable to ask that for a given restricted update, the Application that is making the request include a public key for the VAPID spec. The application could pull it from where ever, hard code it, or whatever makes most sense to the Application developer team (and the corresponding Subscription Update service provider).

Things aren't exactly easy now, making them harder just means tha= t less folks will be able to do it.

My goal was to make it easier - in particular in cases where it= 9;s easy to screw up. If a developer has a test key and=C2=A0
a p= roduction key ( which is a good idea - you want the prod private key well p= rotected, and dev/testing be done with
a different key ), it woul= d be easier to have a different pub key file rather than different .js file= or extra complexity/if

It is a bit more work for = the UA - but not much more.
=C2=A0


On 11/20/2016 8:01 PM, Costin Manolache wrote:
On Sun, Nov 20, 2016 at 5:32= PM Martin Thomson <martin.thomson@gmail.com> wrote:
<= div dir=3D"ltr" class=3D"gmail_msg">
On 20 November 2016 at 02:53, Costin Manolache <costin@gmail.com> wrote:
> One more small suggestion: one of the pain points ( for me ) is the W3C
> subscribe taking the
> vapid pubkey as bytes instead of a string, and having to include the key in
> .js files as a constant.

Your suggestion being that we define a base64url parser.=C2=A0 You can
include the key in the form Uint8Array.from([4, 5, 6, 6, ...]);=C2=A0 It's
bigger and you have to work itI"m a out once, but it saves shipping a
converter.

Not really - the UA will need to take th= e uint8[] and convert it to b64 - since that's what=C2=A0
the push service expects. AFAIK the UA h= as no use with the vapid public key in current
protocol (except pass it along in subscr= ibe) - we do not pass the Authorization header=C2=A0
from push service to UA

I'm a bit confused here. If you use most key generation tools like<= br class=3D"gmail_msg"> $ openssl ecparam -name prime256v1 -genkey -noout -out vapid_private.pem
$ openssl ec -in vapid_private.pem -pubout -out vapid_public.pem
$ grep -v "^-" vapid_public.pe
that dumps a b64 string the user can easily work with. Is the suggestion that we ask users to convert to binary themselves? That may reduce the need for base64 in the UA, but means that developers will need to add one. Considering the fun that happened with "lpad= " not too long ago, I'm a bit concerned about the frustration that ma= y come with that.

My suggestion is = to _not_ ask the users to convert to binary ( or array of decimals ) themse= lves - that's what the
current W3C API requires. I'll fil= e the bug when I return (if Peter or someone else doesn't beat me to it= :-).

And as currently defined, the browser will n= eed to take the Uint8array and b64 encode it before calling the=C2=A0
=
webpush /subscribe. I think it would be better if W3C subscribe would = take a string, and just pass it to the push=C2=A0
service with no= conversions - and let the pushservice deal with it.=C2=A0
It wou= ld also be more future proof.
=C2=A0



=C2=A0

Either way, this is probably something to take here:
https://github.com/w3c/push-ap= i/issues

> Would it be possible to define a .well-known/vapid/... file where the public
> key can be saved ?
> This may simplify tools, testing ( test env may use test sender keys), etc.
> One problem is that
> .well-known is at root - so either have
> /.well-known/vapid/ENCODED_SW_URL.pub or
> have a less standard .well-known/ in the same directory with the SW.

Now that we are considering removal of Crypto-Key (I'm abou= t to send
out drafts with that change), I need to work out how to push the keys
along with the registration.=C2=A0 I don't think that using .well-known
will give us the right binding to the subscription request though.

Maybe I don't understand the proposal, though.=C2=A0 Can yo= u walk through
how a client would use this?

If client calls subscribe() - the UA wil= l look for .well-known/vapid.pub and pass it=C2=A0
in the /subscribe request to the push se= rvice.
... So the subscription provider will have to be able to create and maintain a discrete path, the UA will need to make an extra successful data call, just to provide a string that is for public consumption?

subscribe is not a v= ery frequent event - and a page requires plenty of fetches.=C2=A0
The convenience to just copy a file - instead of editing a JS file - may o= r may not be worth it,=C2=A0
I'm not feeling very strongly ab= out it.

=C2=A0


If client calls subscribe( Uint8Array ) = - UA will use the explicit key.
Again, bit confused here. Granted, the UA's subscribe() function ca= n do whatever it wants once it has the public key. How the server actually enacts the subscription restriction is irrelevant to both the UA and the Subscription provider.

The UA can also accept a key in several different formats by doing simple tests. Likewise, how the Application acquires the key is really up to the Application.

Agreed. UA can also just pass it to push service, and= let the push service decide how to interpret it.=C2=A0

=C2=A0
I'm seeing this more as "suggested practices" and "p= latform features" rather than part of the specification.
=C2=A0
It is a bit simpler to just copy the key= in a defined location - in particular if you have=C2=A0
multiple environments. It is possible to= do it in code too ( using the URL to decide
which key to use ). Some people may also= like the more declarative approach.
Huh, I'd argue that it may not always be possible. Some small vendo= r platforms may not offer access to directories like "/.well-known&q= uot; (e.g. if you're working with classical Apache, you may be forced to root under "/username/...", or some platforms may prohibit th= e use of leading "." because of poor path management. I've had = to deal with both in the past.

Hopefully, I'm must misunderstanding the proposal again.

My concern was to make it easier for developers= to specify the public key.
The '.well-known' was just on= e idea, keeping the manifest or using a relative path to SW, or anything el= se
is fine too.

Costin
=C2=A0<= /div>


=C2=A0
Not a big deal - but I think it would be= nice.=C2=A0

Re. Crypto-Key: my understanding was tha= t there are use cases for it, as a way to=C2=A0
distribute keys, as discussed in the oth= er thread. Subscribe needs some header=C2=A0
( or query param ?) to pass the authoriz= ed entity to the push service. We just=C2=A0
don't need it for authorization or e= ncrypted body.

Costin


--001a113978767d215e0541d821aa--