From nobody Tue Jun 13 17:21:10 2017 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 C43CF127058; Tue, 13 Jun 2017 17:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cL9UvyCUZ6B2; Tue, 13 Jun 2017 17:21:06 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 2BD6C126DEE; Tue, 13 Jun 2017 17:21:03 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v5E0L1lI027441 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 13 Jun 2017 19:21:02 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: draft-ietf-webpush-vapid.all@ietf.org Cc: webpush@ietf.org From: Adam Roach Message-ID: <47693535-bfde-d2b3-4db5-98ffa05da2ad@nostrum.com> Date: Tue, 13 Jun 2017 19:21:00 -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 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Webpush] AD Review of draft-ietf-webpush-vapid X-BeenThere: webpush@ietf.org 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: Wed, 14 Jun 2017 00:21:09 -0000 VAPID authors -- This is my AD review for draft-ietf-webpush-vapid-02. I think the document may be ready for IETF last call, but I'd like some clarifications before sending it out. The first issue I'd like to have clarified regards agility of the crypto suite. This document hard-codes the signing algorithm as ES256. I'm familiar with the fact that documents will frequently do this kind of hardcoding, and then normatively update allowed algorithms in future documents; however, for all such cases I'm familiar with, there is a negotiation involved that allows for bilateral transition from one algorithm to another. For example, RFC7616 was able to include new algorithms because of the challenge/response nature of its authentication scheme. Since VAPID specifically does not include a challenge, application servers have no way of reasonably knowing what the push server might be capable of handling. I think the security section really needs a treatment of how this can be handled, since the obvious solutions with the current design are less than elegant. The second issue entails application server key rotation, especially when used without the Subscription Restriction mechanism described in section 4. My reading of the document (and I'll note, as a nit, that this is implied but not particularly explicit) is that the public key used to identify a server is a TOFU token; and that the only means a server has to detect impersonation is verifying that the public key is identical to previous uses. What is the system behavior intended to be when an application server needs to change its VAPID key gracefully; and what is the behavior intended to be when an application server loses its key unexpectedly? For subscription restriction purposes, I can see how servers could just change the key used for the subscription request; but when this mechanism is being used solely for the purposes of continuity of an application server's identity, it seems problematic. Finally, I'm curious about whether there was any discussion regarding the use of "application/json" rather than using the syntax defined by RFC6839 (e.g., "application/vapid+json"). My concern is that the use of a semantic-free syntactic designation here makes it more complicated to use push subscription requests for anything *other* than conveying a VAPID key in the future. If the intention is that push subscription bodies generically contain a JSON object with potentially myriad keys for a variety of unrelated purposes, please spell that out clearly (and I would still encourage the use of something less generic than "application/json" even in such a case). Nits: Although "vapid" appears in the protocol elements and section headers, it is never put next to its expansion in the document. Please consider changing the title to "Voluntary Application Server Identification (VAPID) for Web Push". The abstract's phrasing of "This can used to reduce the secrecy for push subscription URLs..." seems quite awkward. While this is necessarily one result of employing the described technique, it could hardly be construed as a goal. I suggest rephrasing. The JWT shown in the Authorization header field has an expiration date of 1453523768, while the JSON that claims to be its expansion shows an expiration date of 1453341205. Please make these match: implementors are likely to use the examples as part of testing their implementations, and this may cause unnecessary confusion. Please also double-check that the signature in the example is valid after performing this adjustment. Thanks! /a From nobody Wed Jun 14 00:34:50 2017 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 74C7B1270B4; Wed, 14 Jun 2017 00:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 lKyzUlxGO6ta; Wed, 14 Jun 2017 00:34:46 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 D8BEF129B45; Wed, 14 Jun 2017 00:34:44 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id v20so85614597lfa.1; Wed, 14 Jun 2017 00:34:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mdp7oqwKCvH4NdQks34qvAWYZMr0m949nRFVOZxZGLI=; b=jHy2AyXa74mpS0mzsOx8OemUWesvGwid9SEC7IMi7mn48H75G5N8od8L5zyB9AC3nF SWKK2rVU2JX3KPiZDSlN5IrjUl6T/J2MxODGzYJ2g/Indw61Fyfm6bZX+G8ZUr7OxP4O PFU4omk7C97JWwXV6gBhMA6yqTaYf0dqYygliwg6b2uKeRJjtTMQNxEAGQoANITRAKF2 r/LPDlERLw/c2IIBBUxbSmnmtb7fBm1BvWDpC8iVmFyAS0HDzdi+6lnRmWXNiWy83QEH tI8bwfwrbyCx3JmC1c5dJ2YgcO9BVmzETnL6y+/UFny4y3tRedIptpV01qAQ3KG6zAAb J9JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mdp7oqwKCvH4NdQks34qvAWYZMr0m949nRFVOZxZGLI=; b=rA9IezwbMGvcA2v9e1MxoFO/p8EWh3QXUibl1fPLGcaZ11bRHuBXpntrKMG5VweErW VsbCuUJo8N3IuJtJCXdOgexOtvK/8T1oPYr6btY107Q0bQ+goG61Hs8PEKlE570+YOy3 PiHbFFlA1B4u4SFE+uHDIVMfAMQtKSgIkScyCaK/Nij4vOwWsYfcZ8P7Oyn3c+4Z1HMz aTkYgQEE2FG3CSuuUK31SzpNfaN8Dpaa1VMACtV2yahR/5J5zGB0qxm5VWZkAD2wz+gm rFFEVaDzTK5VhZQzNosYE+lRFjLI9zbVxtdoYLsoeD7z21SUYzas3VbpexsGi94jzxsn LBQQ== X-Gm-Message-State: AKS2vOy88iJPsmQNDX2KI+ChvF5OdgxVjEkecvjHfmJdUPIMWzMrmr95 VT/YM4rX5Ra8tz1uWbicDFXb3Hrjn2LZ X-Received: by 10.25.217.77 with SMTP id q74mr1236155lfg.50.1497425683009; Wed, 14 Jun 2017 00:34:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.78.17 with HTTP; Wed, 14 Jun 2017 00:34:42 -0700 (PDT) In-Reply-To: <47693535-bfde-d2b3-4db5-98ffa05da2ad@nostrum.com> References: <47693535-bfde-d2b3-4db5-98ffa05da2ad@nostrum.com> From: Martin Thomson Date: Wed, 14 Jun 2017 08:34:42 +0100 Message-ID: To: Adam Roach Cc: draft-ietf-webpush-vapid.all@ietf.org, "webpush@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Webpush] AD Review of draft-ietf-webpush-vapid X-BeenThere: webpush@ietf.org 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: Wed, 14 Jun 2017 07:34:48 -0000 Hi Adam, Thanks for looking at this. On 14 June 2017 at 01:21, Adam Roach wrote: > The first issue I'd like to have clarified regards agility of the crypto > suite. This document hard-codes the signing algorithm as ES256. I'm familiar > with the fact that documents will frequently do this kind of hardcoding, and > then normatively update allowed algorithms in future documents; however, for > all such cases I'm familiar with, there is a negotiation involved that > allows for bilateral transition from one algorithm to another. For example, > RFC7616 was able to include new algorithms because of the challenge/response > nature of its authentication scheme. Since VAPID specifically does not > include a challenge, application servers have no way of reasonably knowing > what the push server might be capable of handling. I think the security > section really needs a treatment of how this can be handled, since the > obvious solutions with the current design are less than elegant. The decision we made here, as with other documents in this series, is to define a single profile rather than allow flexibility in the scheme. The rationale for this being that it is better to have fewer points of articulation in a protocol and where we already rely on one, which is the authentication scheme. We do have the option to change to (for example) Ed25519 by changing the JWT header and tweaking the definition of the k= parameter, but I think that the general idea is that we would define a new authentication scheme in preference to doing that. As you say, an application server doesn't really have any way of determining that the push service supports a given algorithm. That means we need to be very careful about how we signal these things. Using the authentication scheme (in this document, "vapid") as the extension point means that we can use the existing mechanisms in HTTP to signal which scheme is supported if it ever comes to the point where we want to or are forced to deploy a new algorithm. In this case, that's probably going to depend on the rather ugly 401 (Unauthorized) status code and a WWW-Authenticate header field. We also have the option of replicating the supportedContentEncodings parameter of PushManager in the API (https://w3c.github.io/push-api/#pushmanager-interface) so that applications might avoid that round trip. > The second issue entails application server key rotation, especially when > used without the Subscription Restriction mechanism described in section 4. > My reading of the document (and I'll note, as a nit, that this is implied > but not particularly explicit) is that the public key used to identify a > server is a TOFU token; and that the only means a server has to detect > impersonation is verifying that the public key is identical to previous > uses. What is the system behavior intended to be when an application server > needs to change its VAPID key gracefully; and what is the behavior intended > to be when an application server loses its key unexpectedly? For > subscription restriction purposes, I can see how servers could just change > the key used for the subscription request; but when this mechanism is being > used solely for the purposes of continuity of an application server's > identity, it seems problematic. This isn't TOFU as much as it is a delegated credential. The server designates a sender that can speak for it. The API ultimately relies on server authentication. The model that the current draft assumes is that an application server that wants to roll keys would need to create new subscriptions. This is always possible, though it requires contacting every user agent to do so. See https://github.com/webpush-wg/webpush-vapid/pull/33 We could change the single key to a list of keys, but it would require making similar changes to the API. That would potentially allow application servers the option of using updated keys more quickly without creating new subscriptions provided that they do sufficient preparation (which I suspect is unlikely). It does change the storage models on push services, and I'd be a little cautious about doing so given how widely deployed this is already. > Finally, I'm curious about whether there was any discussion regarding the > use of "application/json" rather than using the syntax defined by RFC6839 > (e.g., "application/vapid+json"). My concern is that the use of a > semantic-free syntactic designation here makes it more complicated to use > push subscription requests for anything *other* than conveying a VAPID key > in the future. If the intention is that push subscription bodies generically > contain a JSON object with potentially myriad keys for a variety of > unrelated purposes, please spell that out clearly (and I would still > encourage the use of something less generic than "application/json" even in > such a case). There was no discussion on this point. I'm happy to add a new media type registration, but I would probably make it a generic push subscription options type than restrict it to this narrow use. My initial thought is "application/webpush-options+json", but there's a bike shed hidden in there. I need to catch a plane right now. I'll write up a proposal for this (and the nits) as soon as I am able. > Nits: > > Although "vapid" appears in the protocol elements and section headers, it is > never put next to its expansion in the document. Please consider changing > the title to "Voluntary Application Server Identification (VAPID) for Web > Push". > > The abstract's phrasing of "This can used to reduce the secrecy for push > subscription URLs..." seems quite awkward. While this is necessarily one > result of employing the described technique, it could hardly be construed as > a goal. I suggest rephrasing. > > The JWT shown in the Authorization header field has an expiration date of > 1453523768, while the JSON that claims to be its expansion shows an > expiration date of 1453341205. Please make these match: implementors are > likely to use the examples as part of testing their implementations, and > this may cause unnecessary confusion. Please also double-check that the > signature in the example is valid after performing this adjustment. From nobody Wed Jun 14 17:10:04 2017 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 AEC8D128616; Wed, 14 Jun 2017 17:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfBYlcfVp9tT; Wed, 14 Jun 2017 17:10:00 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 3F19E12941D; Wed, 14 Jun 2017 17:09:59 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v5F09tfh061664 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 14 Jun 2017 19:09:56 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Martin Thomson Cc: draft-ietf-webpush-vapid.all@ietf.org, "webpush@ietf.org" References: <47693535-bfde-d2b3-4db5-98ffa05da2ad@nostrum.com> From: Adam Roach Message-ID: Date: Wed, 14 Jun 2017 19:09:50 -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-BeenThere: webpush@ietf.org 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 00:10:03 -0000 On 6/14/17 02:34, Martin Thomson wrote: > On 14 June 2017 at 01:21, Adam Roach wrote: >> The first issue I'd like to have clarified regards agility of the crypto >> suite. This document hard-codes the signing algorithm as ES256. I'm familiar >> with the fact that documents will frequently do this kind of hardcoding, and >> then normatively update allowed algorithms in future documents; however, for >> all such cases I'm familiar with, there is a negotiation involved that >> allows for bilateral transition from one algorithm to another. For example, >> RFC7616 was able to include new algorithms because of the challenge/response >> nature of its authentication scheme. Since VAPID specifically does not >> include a challenge, application servers have no way of reasonably knowing >> what the push server might be capable of handling. I think the security >> section really needs a treatment of how this can be handled, since the >> obvious solutions with the current design are less than elegant. > The decision we made here, as with other documents in this series, is > to define a single profile rather than allow flexibility in the > scheme. The rationale for this being that it is better to have fewer > points of articulation in a protocol and where we already rely on one, > which is the authentication scheme. We do have the option to change > to (for example) Ed25519 by changing the JWT header and tweaking the > definition of the k= parameter, but I think that the general idea is > that we would define a new authentication scheme in preference to > doing that. > > As you say, an application server doesn't really have any way of > determining that the push service supports a given algorithm. That > means we need to be very careful about how we signal these things. > Using the authentication scheme (in this document, "vapid") as the > extension point means that we can use the existing mechanisms in HTTP > to signal which scheme is supported if it ever comes to the point > where we want to or are forced to deploy a new algorithm. Sure. Can the document say this? > In this case, that's probably going to depend on the rather ugly 401 > (Unauthorized) status code and a WWW-Authenticate header field. Yes, that's the "less than elegant" solution I mention above... > We also have the option of replicating the supportedContentEncodings > parameter of PushManager in the API > (https://w3c.github.io/push-api/#pushmanager-interface) so that > applications might avoid that round trip. ...and that's much better (presuming you intend to *add* something rather than shoehorning signature algorithms into a list intended for encryption algorithms). Is there anything we can do now to lay the groundwork for that? Basically, what I'm looking to see here is breadcrumbs for whomever picks this work up in the future to extend it when ES256 reaches the end of its useful life. It sounds like the authors and WG have given some thought to the topic, and we can either capture those thoughts or lose them. > >> The second issue entails application server key rotation, especially when >> used without the Subscription Restriction mechanism described in section 4. >> My reading of the document (and I'll note, as a nit, that this is implied >> but not particularly explicit) is that the public key used to identify a >> server is a TOFU token; and that the only means a server has to detect >> impersonation is verifying that the public key is identical to previous >> uses. What is the system behavior intended to be when an application server >> needs to change its VAPID key gracefully; and what is the behavior intended >> to be when an application server loses its key unexpectedly? For >> subscription restriction purposes, I can see how servers could just change >> the key used for the subscription request; but when this mechanism is being >> used solely for the purposes of continuity of an application server's >> identity, it seems problematic. > This isn't TOFU as much as it is a delegated credential. The server > designates a sender that can speak for it. The API ultimately relies > on server authentication. > > The model that the current draft assumes is that an application server > that wants to roll keys would need to create new subscriptions. This > is always possible, though it requires contacting every user agent to > do so. See https://github.com/webpush-wg/webpush-vapid/pull/33 > > We could change the single key to a list of keys, but it would require > making similar changes to the API. That would potentially allow > application servers the option of using updated keys more quickly > without creating new subscriptions provided that they do sufficient > preparation (which I suspect is unlikely). It does change the storage > models on push services, and I'd be a little cautious about doing so > given how widely deployed this is already. For use with Subscription Restrictions, I think it's even easier than you propose: if all you're trying to do is ensure that the server is authorized to trigger a push, and the way you're doing that is by matching the public key from the subscription with the public key in the push, then all the application server needs to do is keep track of which key is associated with each subscription, and start using a new key for new subscriptions. I mean, technically, it could use a different key for each subscription and everything would work fine (although the system would clearly not scale as well) -- right?. This doesn't bear on the protocol, but I agree that it should be described in the security section to ensure that both implementors and operators understand what's supposed to happen here. But that's the case I wasn't asking about. Before I repeat the question, I realize now that perhaps the problem is that I'm reading something into the document that wasn't intended. I might be able to clear this up with a single yes-or-no question: Is the application server identification mechanism described in this document intended to *ever* be useful WITHOUT using the Subscription Restriction mechanism described in section 4? > >> Finally, I'm curious about whether there was any discussion regarding the >> use of "application/json" rather than using the syntax defined by RFC6839 >> (e.g., "application/vapid+json"). My concern is that the use of a >> semantic-free syntactic designation here makes it more complicated to use >> push subscription requests for anything *other* than conveying a VAPID key >> in the future. If the intention is that push subscription bodies generically >> contain a JSON object with potentially myriad keys for a variety of >> unrelated purposes, please spell that out clearly (and I would still >> encourage the use of something less generic than "application/json" even in >> such a case). > There was no discussion on this point. I'm happy to add a new media > type registration, but I would probably make it a generic push > subscription options type than restrict it to this narrow use. My > initial thought is "application/webpush-options+json", but there's a > bike shed hidden in there. > I don't care about the name, and what you propose is a fine shade for this shed. It would be worth noting that future documents may add more fields to the schema, and that they will do so by updating this document (along with the requisite "ignore fields you don't know" language). /a From nobody Thu Jun 15 00:07:07 2017 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 A7C541294EE; Thu, 15 Jun 2017 00:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 csLWMJOmLA_U; Thu, 15 Jun 2017 00:07:03 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 252FC126CF6; Thu, 15 Jun 2017 00:07:03 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id c10so8402760qtd.1; Thu, 15 Jun 2017 00:07:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rmjqgj9D6voWYcMsmaL4VhkicMvDlsRMiofl0RUd70U=; b=XeLJhx+lsUnowrgZ9dQGTCvQXfsh8GV7DzWCcIHn7lckW8LwLUpoqOiIk8n7VtY68C ECtA9cpfGSN/bmC7el0ghgqDMATRpjIUQTpG4mugahTxyiq341kL7Zto7Xf4dA4yojsz SnThbnX0gzZVKnm0rI8KzA08RPuYSkQl7fhhn0RtwqGjV0GoWzx4oB4AZaQGF6deqJBO LdoZ9U7imZKzyjCvLjNuspNZ23xE2pkBhzxjNHmM3ZMaEf46+0/+FGw6intttsxUYfsV jxWgGgqno8S80opyEhMu3CXACW8X2dw1DrPx+eCo7RMIQpaxc9qdg7eZZfx5cR7w37+5 HHXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rmjqgj9D6voWYcMsmaL4VhkicMvDlsRMiofl0RUd70U=; b=cf+RZZsEc7QxzGBkH+J7SEHjcYBGUWSlZ86LHvmXh7U8gE8XLXx1scROiHRJKNTEvC BZn0BgNXsPQ+nR0slkcgOEfQhhyqJ0UZCzCE/ojZIbmcxvIkBrE2ybSWUi8PtL+BiIGr uSPFaoAR0QEUuXph2tMT4H4+zXyBWV6Lzvs4/wab6R7+1b+FJD93ndXKHJ891bB3tuc3 wC0ODyoeW+d//2LgRryB2tbfW+YCBp2JusLyPk0blusu+DtAu/KnHdj7i9EN0dcxAeb8 iWOOcIIvylroFTg4zW61z518qowiUDgQTiTfi0Oj1rdy6uy68LDh5Xcd0cYg05wtDNys hoXg== X-Gm-Message-State: AKS2vOwQLXC4V55qKZLebmuloobZBa1d/sSiksqHxiKol2TY0qAbeGoI 42Y9hM+z+or4/Q8cqJ5RhhFklyKWRQBK X-Received: by 10.200.55.98 with SMTP id p31mr4546732qtb.64.1497510422242; Thu, 15 Jun 2017 00:07:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.35.109 with HTTP; Thu, 15 Jun 2017 00:07:01 -0700 (PDT) In-Reply-To: <47693535-bfde-d2b3-4db5-98ffa05da2ad@nostrum.com> References: <47693535-bfde-d2b3-4db5-98ffa05da2ad@nostrum.com> From: Costin Manolache Date: Thu, 15 Jun 2017 00:07:01 -0700 Message-ID: To: Adam Roach Cc: draft-ietf-webpush-vapid.all@ietf.org, "webpush@ietf.org" Content-Type: multipart/alternative; boundary="001a11434010c3e97f0551fa5049" Archived-At: Subject: Re: [Webpush] AD Review of draft-ietf-webpush-vapid X-BeenThere: webpush@ietf.org 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 07:07:06 -0000 --001a11434010c3e97f0551fa5049 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 13, 2017 at 5:21 PM, Adam Roach wrote: > VAPID authors -- > > This is my AD review for draft-ietf-webpush-vapid-02. > > I think the document may be ready for IETF last call, but I'd like some > clarifications before sending it out. > > The first issue I'd like to have clarified regards agility of the crypto > suite. This document hard-codes the signing algorithm as ES256. I'm > familiar with the fact that documents will frequently do this kind of > hardcoding, and then normatively update allowed algorithms in future > documents; however, for all such cases I'm familiar with, there is a > negotiation involved that allows for bilateral transition from one > algorithm to another. For example, RFC7616 was able to include new > algorithms because of the challenge/response nature of its authentication > scheme. Since VAPID specifically does not include a challenge, application > servers have no way of reasonably knowing what the push server might be > capable of handling. I think the security section really needs a treatment > of how this can be handled, since the obvious solutions with the current > design are less than elegant. > 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. > > The second issue entails application server key rotation, especially when > used without the Subscription Restriction mechanism described in section 4. > My reading of the document (and I'll note, as a nit, that this is implied > but not particularly explicit) is that the public key used to identify a > server is a TOFU token; and that the only means a server has to detect > impersonation is verifying that the public key is identical to previous > uses. What is the system behavior intended to be when an application server > needs to change its VAPID key gracefully; and what is the behavior intended > to be when an application server loses its key unexpectedly? For > subscription restriction purposes, I can see how servers could just change > the key used for the subscription request; but when this mechanism is being > used solely for the purposes of continuity of an application server's > identity, it seems problematic. > The endpoints are supposed to expire after some time, and need to be periodically rotated. That would be the best point to do graceful rotation, as the endpoints are refreshed. If a server loses the key - at least in the case of webpush it is possible to update the web application with the new key and recover. If the key is stolen: the endpoint secrecy may provide some protection while the web app is updated. If both private key and endpoint database are stolen - I think right now the only option is to contact the provider and have it blacklisted, or to update the application to stop accepting messages from that key. It may be good to add more mechanisms to simplify this - but probably better in separate documents. > > Finally, I'm curious about whether there was any discussion regarding the > use of "application/json" rather than using the syntax defined by RFC6839 > (e.g., "application/vapid+json"). My concern is that the use of a > semantic-free syntactic designation here makes it more complicated to use > push subscription requests for anything *other* than conveying a VAPID key > in the future. If the intention is that push subscription bodies > generically contain a JSON object with potentially myriad keys for a > variety of unrelated purposes, please spell that out clearly (and I would > still encourage the use of something less generic than "application/json" > even in such a case). > I think the intent was to allow other attributes in the json, besides the vapid key, including vendor-specific attributes. The vapid just defines the 'vapid' key in the subscription json. Costin > > Nits: > > Although "vapid" appears in the protocol elements and section headers, it > is never put next to its expansion in the document. Please consider > changing the title to "Voluntary Application Server Identification (VAPID) > for Web Push". > > The abstract's phrasing of "This can used to reduce the secrecy for push > subscription URLs..." seems quite awkward. While this is necessarily one > result of employing the described technique, it could hardly be construed > as a goal. I suggest rephrasing. > > The JWT shown in the Authorization header field has an expiration date of > 1453523768, while the JSON that claims to be its expansion shows an > expiration date of 1453341205. Please make these match: implementors are > likely to use the examples as part of testing their implementations, and > this may cause unnecessary confusion. Please also double-check that the > signature in the example is valid after performing this adjustment. > > Thanks! > > /a > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --001a11434010c3e97f0551fa5049 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 13, 2017 at 5:21 PM, Adam Roach <adam@nostrum.com> wrote:
VAPID authors --

This is my AD review for draft-ietf-webpush-vapid-02.

I think the document may be ready for IETF last call, but I'd like some= clarifications before sending it out.

The first issue I'd like to have clarified regards agility of the crypt= o suite. This document hard-codes the signing algorithm as ES256. I'm f= amiliar with the fact that documents will frequently do this kind of hardco= ding, and then normatively update allowed algorithms in future documents; h= owever, for all such cases I'm familiar with, there is a negotiation in= volved that allows for bilateral transition from one algorithm to another. = For example, RFC7616 was able to include new algorithms because of the chal= lenge/response nature of its authentication scheme. Since VAPID specificall= y does not include a challenge, application servers have no way of reasonab= ly knowing what the push server might be capable of handling. I think the s= ecurity section really needs a treatment of how this can be handled, since = the obvious solutions with the current design are less than elegant.

I think the 'negotiation' must happen= much earlier - at subscribe time (and in general case - out of band). At t= he time of auth, when VAPID
is used, the caller must have an endp= oint that is bound to the server public key.=C2=A0

If a EC256 public key is used at the time of endpoint creation - it determ= ines the signing algorithm as well.=C2=A0

So the &= #39;challenge' happens long in advance.=C2=A0

= =C2=A0

The second issue entails application server key rotation, especially when u= sed without the Subscription Restriction mechanism described in section 4. = My reading of the document (and I'll note, as a nit, that this is impli= ed but not particularly explicit) is that the public key used to identify a= server is a TOFU token; and that the only means a server has to detect imp= ersonation is verifying that the public key is identical to previous uses. = What is the system behavior intended to be when an application server needs= to change its VAPID key gracefully; and what is the behavior intended to b= e when an application server loses its key unexpectedly? For subscription r= estriction purposes, I can see how servers could just change the key used f= or the subscription request; but when this mechanism is being used solely f= or the purposes of continuity of an application server's identity, it s= eems problematic.

The endpoints are sup= posed to expire after some time, and need to be periodically rotated. That = would be the best point to do graceful rotation, as
the endpoints= are refreshed.=C2=A0

If a server loses the key - = at least in the case of webpush it is possible to update the web applicatio= n with the new key and recover.=C2=A0
If the key is stolen: the e= ndpoint secrecy may provide some protection while the web app is updated. I= f both private key and
endpoint database are stolen - I think rig= ht now the only option is to contact the provider and have it blacklisted, = or to=C2=A0
update the application to stop accepting messages fro= m that key.

It may be good to add more mechanisms = to simplify this - but probably better in separate documents.
=C2= =A0

Finally, I'm curious about whether there was any discussion regarding t= he use of "application/json" rather than using the syntax defined= by RFC6839 (e.g., "application/vapid+json"). My concern is that = the use of a semantic-free syntactic designation here makes it more complic= ated to use push subscription requests for anything *other* than conveying = a VAPID key in the future. If the intention is that push subscription bodie= s generically contain a JSON object with potentially myriad keys for a vari= ety of unrelated purposes, please spell that out clearly (and I would still= encourage the use of something less generic than "application/json&qu= ot; even in such a case).

I think the i= ntent was to allow other attributes in the json, besides the vapid key, inc= luding vendor-specific attributes. The vapid just=C2=A0
defines t= he 'vapid' key in the subscription json.

<= br>
Costin
=C2=A0

Nits:

Although "vapid" appears in the protocol elements and section hea= ders, it is never put next to its expansion in the document. Please conside= r changing the title to "Voluntary Application Server Identification (= VAPID) for Web Push".

The abstract's phrasing of "This can used to reduce the secrecy fo= r push subscription URLs..." seems quite awkward. While this is necess= arily one result of employing the described technique, it could hardly be c= onstrued as a goal. I suggest rephrasing.

The JWT shown in the Authorization header field has an expiration date of 1= 453523768, while the JSON that claims to be its expansion shows an expirati= on date of 1453341205. Please make these match: implementors are likely to = use the examples as part of testing their implementations, and this may cau= se unnecessary confusion. Please also double-check that the signature in th= e example is valid after performing this adjustment.

Thanks!

/a

_______________________________________________
Webpush mailing list
Webpush@ietf.org<= br> https://www.ietf.org/mailman/listinfo/webpush<= br>

--001a11434010c3e97f0551fa5049-- From nobody Thu Jun 15 09:21:09 2017 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 0E61C129524; Thu, 15 Jun 2017 09:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZibHEp9Oyg7; Thu, 15 Jun 2017 09:21:06 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 62EB4129486; Thu, 15 Jun 2017 09:21:06 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (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 adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Costin Manolache Cc: draft-ietf-webpush-vapid.all@ietf.org, "webpush@ietf.org" References: <47693535-bfde-d2b3-4db5-98ffa05da2ad@nostrum.com> 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-BeenThere: webpush@ietf.org 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. /a From nobody Thu Jun 15 12:54:54 2017 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 1C985124BE8; Thu, 15 Jun 2017 12:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 ViEBo_rGRhVN; Thu, 15 Jun 2017 12:54:51 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 657C61201F2; Thu, 15 Jun 2017 12:54:51 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id u12so34970974qth.0; Thu, 15 Jun 2017 12:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LzbZBlberQMk9x4ldTIi94nI9Iof6uT5izQPiWeGa9w=; b=vef/5/nFj5J7vtqq9VS0iyjOnfbACwrbWS4r6b95q71IKaTHXEBEdShWrF4xexNyAp PengVIEVz+RXpWopD9qXsAADE+JSpFmUX7BCm0g3gd9X/8iGrJsTXjAQWMvDfDiZ28ys X6QrgbeGqhkqgukcVyVEXnv1DNISlh6hXI96Plte4AeQ86jyZWS1AFjSBU8r8ubTnQ+O jklV+8RQzhZbBVv9WBRkVz/nmt6KPsAK4feTEo9VJfLcF8l8iMNLHZOy/5f8c9BQg32l Buy8P6CiOlAtp0TAW81ZLeugI6rYL6EMP5F3a0V5bgQH1pf9gxmPf/xNDyJVCVrEbE8O Uw2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LzbZBlberQMk9x4ldTIi94nI9Iof6uT5izQPiWeGa9w=; b=eq8eo3Y4OmsEoxibkoie8mh1O6fwFPrXEeAjsOp8oJbJVAU19yQTF4BZpUWAW9gLec f4IiQUBLNDFQCilP5SvZb/hmso0vbzyS03EOKGewG+/j8HNj6dqXsy6vVn1nCAeVUPAF V54CS7tmjivN1gJQ3jgwJKCjJSW/hHr70pPiAJ0RZ+TSfePaJHG//j3F9B8ZUBXaZ4kf DwfDtShFow+FvksITWwyeNB6taEpxhAZn7JqFR0ZlWC1KCGcMiMgVj2ouNjgKk5V2QXp 9T6hrqB7C3Ch7mmjRpX2qm+i/AkUj4jB2Dt1KfnDdNjON1n3JJ7wtacBraOhFVNuIH+s QB3Q== X-Gm-Message-State: AKS2vOywTkNZdILfgY9PN83tZI1MWdYwNYsKF4JQlAfzUBdmGN4TglwY zV5kF3Nrpkxi6O//T6+0cD3tDuGvZw== X-Received: by 10.200.8.169 with SMTP id v38mr8913349qth.213.1497556490511; Thu, 15 Jun 2017 12:54:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.35.109 with HTTP; Thu, 15 Jun 2017 12:54:50 -0700 (PDT) In-Reply-To: References: <47693535-bfde-d2b3-4db5-98ffa05da2ad@nostrum.com> From: Costin Manolache Date: Thu, 15 Jun 2017 12:54:50 -0700 Message-ID: To: Adam Roach Cc: draft-ietf-webpush-vapid.all@ietf.org, "webpush@ietf.org" Content-Type: multipart/alternative; boundary="001a1145c4f2a5f22a0552050a7c" Archived-At: Subject: Re: [Webpush] AD Review of draft-ietf-webpush-vapid X-BeenThere: webpush@ietf.org 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 19:54:53 -0000 --001a1145c4f2a5f22a0552050a7c Content-Type: text/plain; charset="UTF-8" On Thu, Jun 15, 2017 at 9:20 AM, Adam Roach 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 > > --001a1145c4f2a5f22a0552050a7c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jun 15, 2017 at 9:20 AM, Adam Roach <adam@nostrum.com> wrote:
On 6/15/17 = 02:07, Costin Manolache wrote:
I think the 'negotiation' must happen much earlier - at subscribe t= ime (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 publi= c key.

If a EC256 public key is used at the time of endpoint creation - it determi= nes the signing algorithm as well.

So the 'challenge' happens long in advance.


 This makes sense, but it is a substantially different answer than Martin ga= ve. I'll note that the subscription request doesn't indicate the al= gorithm to which the key corresponds, so the push server doesn't seem t= o have any ability to detect an algorithm mismatch until it's way too l= ate 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 th= is protocol painted into a corner when we decide to move on to other algori= thms, 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 as= pect of the system design hasn't yet been discussed by the working grou= p. It should be.

I don't think Martin&#= 39;s answer is very different, the draft reflects what we all agree on - bu= t there are different ways to=C2=A0
extend it. The perspective is= a bit different - our system still support a 'legacy' sender authe= ntication scheme, based
on project IDs, which works using the sub= scribe parameters.=C2=A0

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


Costin

<= div>=C2=A0
<= font color=3D"#888888">

/a


--001a1145c4f2a5f22a0552050a7c-- From nobody Thu Jun 15 19:41:21 2017 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 E507F129426; Thu, 15 Jun 2017 19:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 b7iwCGL2nqo0; Thu, 15 Jun 2017 19:41:17 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (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 5038312941D; Thu, 15 Jun 2017 19:41:17 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id p189so18372202lfe.2; Thu, 15 Jun 2017 19:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=C9Rst8SVCQHvvlfGHcaNAac415Fq8iRrQ2/uCMjC9lY=; b=iTPQkXUZ8K7070gc4xGLEGJvoW7UtcVylEVv4M9K48qpA4SL8r1bbmUEfzENYesxQO BIgD4FKnihmDqXe9ikJJLy5qvJqqIzrcSSBFlYX6N5jQefzdEEoaD/leDyXZX4uFCqNz 67hMEUg6OegrwOuFiyCG+k3uxcPk6qJ3oujFDrSCwtLcLWQSYNSkYUYmh4xC5Eg5u2Vj aJ058LqgHps+8paUn0JqmiQSFUMOqPAnDA3xjh0dc/KP3q51qj+wODeF6LCBYtQGtbIT smVHriF//Fk0ptpuIbXLSuQKKUHHa5sPurhfuPSaCf7EPqitZ+o040IP1T6B2YR71E4t +UTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=C9Rst8SVCQHvvlfGHcaNAac415Fq8iRrQ2/uCMjC9lY=; b=ZFpOQ2JwixHeC+MOixr4AWiaeR7nSa95JT8FztpRqKzOiKNvK0ErgTItJulDj0OuCw seXZ5kkEDKKkXwJkhR+DB4za/rEm1Dk0AgvEEOYAgihFqAFMFfhcq3aROyOnJCWurgH4 FCHbqgHIHelJPG9RtEqtKJpK2l7rEYTPaE4zt6GqDZU6NwifACjyhODuDxP5zSfc2ncr YGdX/WdhNb5lTb0lPDck2Yo4AyXTFVkhQLyTAITbUM+u6HcUGzYMdBRTZvOnUTY9ycPV NRnLyzY7SJJsQCSBwWEmp5dzN1gFVqG7P/pAEqGMxS5YtrZyT6vr1SoT3aRlRIseHOHB YC8w== X-Gm-Message-State: AKS2vOwu0oSrxxrNfNAs5Ga2WnzreW26KqEql7KECme3OCP/pnHJr6HO NTqL+b4reGkshbSYTBZDz/VPTKJT6G91Ygo= X-Received: by 10.46.87.85 with SMTP id r21mr2339481ljd.22.1497580875457; Thu, 15 Jun 2017 19:41:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.78.17 with HTTP; Thu, 15 Jun 2017 19:41:14 -0700 (PDT) In-Reply-To: References: <47693535-bfde-d2b3-4db5-98ffa05da2ad@nostrum.com> From: Martin Thomson Date: Fri, 16 Jun 2017 12:41:14 +1000 Message-ID: To: Adam Roach Cc: draft-ietf-webpush-vapid.all@ietf.org, "webpush@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Webpush] AD Review of draft-ietf-webpush-vapid X-BeenThere: webpush@ietf.org 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: Fri, 16 Jun 2017 02:41:20 -0000 On 15 June 2017 at 10:09, Adam Roach wrote: >> As you say, an application server doesn't really have any way of >> determining that the push service supports a given algorithm. That >> means we need to be very careful about how we signal these things. >> Using the authentication scheme (in this document, "vapid") as the >> extension point means that we can use the existing mechanisms in HTTP >> to signal which scheme is supported if it ever comes to the point >> where we want to or are forced to deploy a new algorithm. > > Sure. Can the document say this? https://github.com/webpush-wg/webpush-vapid/pull/35 >> We also have the option of replicating the supportedContentEncodings >> parameter of PushManager in the API >> (https://w3c.github.io/push-api/#pushmanager-interface) so that >> applications might avoid that round trip. > > > ...and that's much better (presuming you intend to *add* something rather > than shoehorning signature algorithms into a list intended for encryption > algorithms). Is there anything we can do now to lay the groundwork for that? https://github.com/w3c/push-api/pull/262 That's not this document, but it closes the loop. > Is the application server identification mechanism described in this > document intended to *ever* be useful WITHOUT using the Subscription > Restriction mechanism described in section 4? The document addresses two use cases: subscription restriction and self-identification. The former most certainly relies on the signature. The latter is almost served by having the JWT payload in the request, but we did agree that key continuity is an part of that use case. That means that the push service relies on the signature for establishing continuity of identity. It's hard to build up a reputation as an upstanding application server when anyone can trivially pretend that they are you. Those two use cases are intended to be exhaustive. For the reputation part, I believe that it is acceptable for key rotation to result in loss of reputation, but it's probably worth making an explicit note of the consequences: https://github.com/webpush-wg/webpush-vapid/pull/36 > I don't care about the name, and what you propose is a fine shade for this > shed. It would be worth noting that future documents may add more fields to > the schema, and that they will do so by updating this document (along with > the requisite "ignore fields you don't know" language). https://github.com/webpush-wg/webpush-vapid/pull/34 From nobody Fri Jun 16 07:36:24 2017 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 87ECA13182D; Fri, 16 Jun 2017 07:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYreXBxdP0Tt; Fri, 16 Jun 2017 07:36:21 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 33B5A124D85; Fri, 16 Jun 2017 07:35:28 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v5GEZO28041445 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 16 Jun 2017 09:35:25 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Martin Thomson Cc: draft-ietf-webpush-vapid.all@ietf.org, "webpush@ietf.org" References: <47693535-bfde-d2b3-4db5-98ffa05da2ad@nostrum.com> From: Adam Roach Message-ID: <939cd910-e106-30c9-8504-ed95fcee6ba1@nostrum.com> Date: Fri, 16 Jun 2017 09:35:19 -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-BeenThere: webpush@ietf.org 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: Fri, 16 Jun 2017 14:36:23 -0000 These all look like good changes. Drop a new version of the document, and I'll push it forward. Thanks! /a On 6/15/17 21:41, Martin Thomson wrote: > On 15 June 2017 at 10:09, Adam Roach wrote: >>> As you say, an application server doesn't really have any way of >>> determining that the push service supports a given algorithm. That >>> means we need to be very careful about how we signal these things. >>> Using the authentication scheme (in this document, "vapid") as the >>> extension point means that we can use the existing mechanisms in HTTP >>> to signal which scheme is supported if it ever comes to the point >>> where we want to or are forced to deploy a new algorithm. >> Sure. Can the document say this? > https://github.com/webpush-wg/webpush-vapid/pull/35 > > >>> We also have the option of replicating the supportedContentEncodings >>> parameter of PushManager in the API >>> (https://w3c.github.io/push-api/#pushmanager-interface) so that >>> applications might avoid that round trip. >> >> ...and that's much better (presuming you intend to *add* something rather >> than shoehorning signature algorithms into a list intended for encryption >> algorithms). Is there anything we can do now to lay the groundwork for that? > https://github.com/w3c/push-api/pull/262 > > That's not this document, but it closes the loop. > >> Is the application server identification mechanism described in this >> document intended to *ever* be useful WITHOUT using the Subscription >> Restriction mechanism described in section 4? > The document addresses two use cases: subscription restriction and > self-identification. The former most certainly relies on the > signature. The latter is almost served by having the JWT payload in > the request, but we did agree that key continuity is an part of that > use case. That means that the push service relies on the signature > for establishing continuity of identity. It's hard to build up a > reputation as an upstanding application server when anyone can > trivially pretend that they are you. > > Those two use cases are intended to be exhaustive. > > For the reputation part, I believe that it is acceptable for key > rotation to result in loss of reputation, but it's probably worth > making an explicit note of the consequences: > > https://github.com/webpush-wg/webpush-vapid/pull/36 > >> I don't care about the name, and what you propose is a fine shade for this >> shed. It would be worth noting that future documents may add more fields to >> the schema, and that they will do so by updating this document (along with >> the requisite "ignore fields you don't know" language). > https://github.com/webpush-wg/webpush-vapid/pull/34 From nobody Sat Jun 17 23:08:37 2017 Return-Path: X-Original-To: webpush@ietf.org Delivered-To: webpush@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E31C4126DCA; Sat, 17 Jun 2017 23:08:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: webpush@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149776610888.14337.4771132068877022522@ietfa.amsl.com> Date: Sat, 17 Jun 2017 23:08:28 -0700 Archived-At: Subject: [Webpush] I-D Action: draft-ietf-webpush-vapid-03.txt X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 18 Jun 2017 06:08:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web-Based Push Notifications of the IETF. Title : Voluntary Application Server Identification (VAPID) for Web Push Authors : Martin Thomson Peter Beverloo Filename : draft-ietf-webpush-vapid-03.txt Pages : 14 Date : 2017-06-17 Abstract: An application server can use the method described to voluntarily identify itself to a push service. This identification information can be used by the push service to attribute requests that are made by the same application server to a single entity. An application server can include additional information that the operator of a push service can use to contact the operator of the application server. This identification information can be used to restrict the use of a push subscription a single application server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-webpush-vapid/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-webpush-vapid-03 https://datatracker.ietf.org/doc/html/draft-ietf-webpush-vapid-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-webpush-vapid-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jun 17 23:31:39 2017 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 B1AEF12944A; Sat, 17 Jun 2017 23:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 DWV4Rkr89dYv; Sat, 17 Jun 2017 23:31:36 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 E4336126DCA; Sat, 17 Jun 2017 23:31:35 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id o83so41170100lff.3; Sat, 17 Jun 2017 23:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LQte3l0DFip0I8dK+S/V6fepB8sPjbve9QDgCWXslZo=; b=cqNy4zxsbsYCCsFpqgVC9ZSVgtHbQFylSI400cTtNjvldSDhyWQ8dBzI/47MkDUzrq wQ/nZgJWYQ6xzTpkty+Pj+06oTosi2qeIGTA5bNCTpTI4sHYMTinElYUoVj1K4J0Zk+E pD40CO2P2YIEkGhuId4Phz4ZQssWH5gng9Cv3KXE+VteiQuI93PR1vg+yesJdSAQiTaF lmlFRJrJv5nFXSl95mm6xT4Zvmr5d19pe0Dq/2j2v5PNhnH7/YFeguGqpfH1uzEl+kMY 1BIZw6OfRXqJixBMBaOkHqz1NIy1SBDiYsty7i2SEJQIA1XMuSEfPojzTrF2XDGJ9+h1 qUIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LQte3l0DFip0I8dK+S/V6fepB8sPjbve9QDgCWXslZo=; b=LXre65jheMbFZ2zeT6yfpB/jg4tPU/VQTYytssIDWtvO2dH2YQ9dUmTehEVBKYoNXd wDr+PH62XQM4m3u+ZktkaFOjckY1BrFU8NT9mB0ZOsmux+50YMtZbDvw2XgkRHthP30I nrnA9MK3WYoqQTgm/64NEmxwm+QWwK4pZZIIZoEeZIapuZExcMIcJ4kh4CmFyG2vFH8h O7PaUQQIANQGZn2iWge1aeylF+i7R5uEP2KBrm0Gji7tk5x9eKcTGnPBsjPSIkjqExSm tcu/ZOFbmNhJc2mQCzbm1ge7kbVB82AgVeuz0LRLdIoF7f3fRE/Ik6O05awR/xyoJBFt zQXw== X-Gm-Message-State: AKS2vOyNSsJfUCLgSqoSzbjI/jzsBN6c5X4YTV9TKdfg6QYTFNxLpjeB tOBjLPGAHhfVHqTEFEuxf0D007Lk+t7L X-Received: by 10.25.217.77 with SMTP id q74mr5806501lfg.50.1497767494214; Sat, 17 Jun 2017 23:31:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.78.17 with HTTP; Sat, 17 Jun 2017 23:31:33 -0700 (PDT) In-Reply-To: <939cd910-e106-30c9-8504-ed95fcee6ba1@nostrum.com> References: <47693535-bfde-d2b3-4db5-98ffa05da2ad@nostrum.com> <939cd910-e106-30c9-8504-ed95fcee6ba1@nostrum.com> From: Martin Thomson Date: Sun, 18 Jun 2017 16:31:33 +1000 Message-ID: To: Adam Roach Cc: draft-ietf-webpush-vapid.all@ietf.org, "webpush@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Webpush] AD Review of draft-ietf-webpush-vapid X-BeenThere: webpush@ietf.org 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: Sun, 18 Jun 2017 06:31:38 -0000 On 17 June 2017 at 00:35, Adam Roach wrote: > These all look like good changes. Drop a new version of the document, and > I'll push it forward. Posted -03. From nobody Sun Jun 18 20:41:55 2017 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 187DF126E3A for ; Sun, 18 Jun 2017 20:41:48 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 qlx_uSAbxl-S for ; Sun, 18 Jun 2017 20:41:46 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 C754D126557 for ; Sun, 18 Jun 2017 20:41:45 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id p189so47959891lfe.2 for ; Sun, 18 Jun 2017 20:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=aoDP0laVxFLS8Zy1UpEv7HLwGbcDCiLa/RJjjFPgFuw=; b=C5tBztS+qkxTBNEKkVDTwqDgOKeTQXDvFdHlJU2YvDp7nhbEePHYvFXCJSZmP8QBQT 4WOJLVnJQzNeW7MxImUE9o7ojbdftrkKAVZgII8yG562IaGZ6KMmuNfL1duo3dWZvhjx 4h5aX3RG9PCLC+9OgShONJEHA9IoUqJzBFTfGHAjaH2PW6ZmxeAYM86yKFNgL/cmaeC4 A1pOYDOroZTDDyLa6IneeK6Eizaqgkw+OlkEGdVbXrduRR6upUeHgv2/NtiXhsXOu+mD oOtHohBknCJpEdnCoVJeII7yzgkL7Qv8AyESzkFt5PmbMyLTFpK6ZAO9AC+UVQs8SOzh wobw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=aoDP0laVxFLS8Zy1UpEv7HLwGbcDCiLa/RJjjFPgFuw=; b=UBJswIneQnBlvC2IfgppqZYuCBgkoX9PGjPlFgD+0aJtkt5n68kxD8UXXgP+7+7cp/ GiVh6K0vmdh9CjBJu6y4Mz1CQo+jVuLsLp2M26bmswtJpW1Cf01MeGC2KcBx6wkfrJND O0/yOJCZ0CV0LfJHDbyNHk0d+XefFg9KfBa9wggGpAaHf6ZiNccR27Cp0jTxwCMAhX8B bn6FK8Mz5hm0Qj2TlbQwklfzW400mOzQUqm0u3DDXMbtVmrzkKYNg3eM8DvS9iHcSLtv 5uV+85Q5cLW230v7cAJ2eHh9FCl2eWi7LDEEa5/F0JFu+uwAukabqprWnzyRz1oynfVQ pFfQ== X-Gm-Message-State: AKS2vOzxsjwzF1o/HgltTFvij/U4/HKS4G9e89CtJeIuIqf64vnrEcji ygY2c4MwIByOE9HO1Rky8COnAzZgHg== X-Received: by 10.25.145.19 with SMTP id t19mr7474060lfd.130.1497843704070; Sun, 18 Jun 2017 20:41:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.78.17 with HTTP; Sun, 18 Jun 2017 20:41:43 -0700 (PDT) From: Martin Thomson Date: Mon, 19 Jun 2017 13:41:43 +1000 Message-ID: To: media-types@iana.org Cc: "webpush@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Webpush] Media type review for application/webpush-options+json X-BeenThere: webpush@ietf.org 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: Mon, 19 Jun 2017 03:41:48 -0000 Copying the template from https://datatracker.ietf.org/doc/html/draft-ietf-webpush-vapid#section-6.3 Type name: application Subtype name: webpush-options+json Required parameters: n/a Optional parameters: n/a Encoding considerations: binary Security considerations: See [RFC7159] for security considerations specific to JSON. Interoperability considerations: See [RFC7159] for interoperability considerations specific to JSON. Published specification: This document. Applications that use this media type: Web browsers, via the Web Push Protocol [RFC8030]. Fragment identifier considerations: None, see [RFC7159]. Additional information: Deprecated alias names for this type: n/a Magic number(s): n/a File extension(s): .json Macintosh file type code(s): TEXT Person & email address to contact for further information: Martin Thomson (martin.thomson@gmail.com) Intended usage: LIMITED USE Restrictions on usage: For use with the Web Push Protocol [RFC8030]. Author: See "Authors' Addresses" section of this document. Change controller: Internet Engineering Task Force From nobody Sun Jun 18 21:01:16 2017 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 098DE124C27 for ; Sun, 18 Jun 2017 21:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.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 wWy3QjTO1kkI for ; Sun, 18 Jun 2017 21:01:12 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0138.outbound.protection.outlook.com [104.47.92.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAA46126CC7 for ; Sun, 18 Jun 2017 21:01:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wm4JdQROcoh8AmYmn1n024MAJkQnMyhqI4EoeVQbfXM=; b=cIkpqfreTVcAd5L8EaqmwycLJ4FS+d6kBKoRqqDth1g5tuxkHL74PKVmK9kYPdRuWkupjW/63SBm+ZiP7M+XE4+C4w9vFqOvimLAbOC8fWpC8QYK1aiSOBpleLwYFtAqgWd5068bWcv5fRVMMdyTFgbZlXlwrkCP/GM9SDAQHyE= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by TY1PR01MB0650.jpnprd01.prod.outlook.com (10.167.158.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.14; Mon, 19 Jun 2017 04:01:09 +0000 To: Martin Thomson , CC: "webpush@ietf.org" References: From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Mon, 19 Jun 2017 13:01:06 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: OS2PR01CA0089.jpnprd01.prod.outlook.com (10.165.51.177) To TY1PR01MB0650.jpnprd01.prod.outlook.com (10.167.158.13) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8c2233f2-b163-481f-e7d2-08d4b6c7d18a X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:TY1PR01MB0650; X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0650; 3:MMQcJ89l7GudDPwQVr7p51bKNVLXVcbxIT1kqnD+MSyRFpKUzG+5vTcKPKG3iaAp5WidIPfdxKHiep62ra/Pf+a7+WtGqs1o0uG4VL1ZxUiAC/60F+6foM6xZ+pgHSkLm7jpU8T48GjHgbraHGGUpJ1wIKX18TLSoHF0yGrJdnh7L//ZkMVOF2yhlXBrqJLT3PvzXBl2eHSo8OLFyWJ54uaXfY3agZofjudfghIsHgSZVMNYivHRIgr2B2e5a/thW3Phn+bc5RkAaFfoCQOjNZkWCJk/pDDMWdVc+eNdI4Ms93CPRmiM/k0MCSsXUDFkcIxE9NmGZ0pLV1b1mvaPdA==; 25:y3Q0mIvNcWf8hpwj/Ut9Ds+Y6ZbUMCsexRsDU4UmTI0PNek7NKubDJlkOm4luftXYmICup6K3zsf4z7J0VoAAX7j/F43HE7Xqw9qU+hiknELjytkaGkOydKXWbdmeYGAmYUJkTcaWwtbB/x1uSQ7b6mDMNoA3wUYYYLTkdhv3avE7B8CadrsKAUWYvxKCYo1y1JDIeVoTFRmRIMZwwiXjvVAejPDhAa5u+/qDNd37hEj5Agmim4aAgpk2YhAk0Qo4Y9DGGd1cf+9W3ebd1oM57vRldy0OZokGcGb+7pNRjdeotQkH8YauaPF92qfYkq9A+y7rwRkE/APG7PB8pQIGou7KIVoTupyON9do14TVubOtzsm6I0/lGm2w0AJZDnex+M5Lk5BWVKUyRSSzXPFOtqaMKoEXlnEhTpgeMZggxX8jecxAv9YSIhEovFJuLMuuJDxRqxUvn1VGZyrBwtL3aWjiWK2KU5zG6tZhJADbuU= X-MS-TrafficTypeDiagnostic: TY1PR01MB0650: X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0650; 31:OFibJ0U2sQIdMq/DHgLbQwAMbEsXvTDwHLGww0gVsejQ4nD7eGhsDG8Nyu5UtyuV5AOQyiGGcHvNn74GCnGt5icAg4ScQ4MMCQGg5MOp0fJq42A2OGRpqjnel6vc/S3LhI5l3VYlnfk2T6fDJh+Ug0jkwivbKoVGv4TrTQg2cS9hDLun6iFkKj/uYxxzmzi+amwRel89RHKjyoJKfZ7f7gsVUdoSJQQzAn+uEb3Yh5Bq6CX5gLn2A9OSZKUrL6i1gP09MRkW2UbS7QGHYIH9wQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(120809045254105)(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6041248)(20161123558100)(20161123560025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:TY1PR01MB0650; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:TY1PR01MB0650; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWTFQUjAxTUIwNjUwOzQ6UUc3NnpHT0xyVXJvRkFOREhtV2xUWHZPcFIw?= =?utf-8?B?OXk3eW96aHBCWlpLODE4OEgreFhaZXZLZ2RCN1VaWjhyZTJWYnBXcnU0czZq?= =?utf-8?B?T1d1R1dWamVteFpxOWE3VWgvbTdYZkpjdDZMblFnSDM5M2l2WkJ0MzlZVTNF?= =?utf-8?B?OEgzTFgwaW96RWk2NEhhbjBKdXlBRGdSSGpITjRFemNxSlJPeDlhL1I5WnI3?= =?utf-8?B?OGpuNjZGYjYwTE1jVHdDMG1CUS94bktyek5YdkZmcGx1blBScWM1TTlWZjhm?= =?utf-8?B?V1AxT25vbjBQR2luY0NMTXBDTG1HYk9IbUZCSlBsNDhieFJDMkRsUDkwcC9J?= =?utf-8?B?aUhaTkIxU1kxbXBGdm9pOUw1NnIyalBEL2hLbklKcmhTRUpjb2M2S0J6Tkor?= =?utf-8?B?TFV0ZWQ2ZEIzRFJLYlRIeDIyeU9xSDVZNTlIcXZwUEsyY1FHNWdGWkVBQ2ps?= =?utf-8?B?WGJBL3NPMHZHZytYNTgxaDNOTkcwamFURDBxSWpsdDdNMGJ0TjZrLzFCOFZD?= =?utf-8?B?SG1vZnlRY2pvb2hlYy9IM0t5NWg5UnVCRSs1WnQ2YjJqS3FwSVJVTitOMmVS?= =?utf-8?B?cG5sMTBsTmRkbzBIUmxqd3czQmxCV0gwQWYvNHZTMm5LajVMR2VIcDBJQTZ1?= =?utf-8?B?V1hISWVyUzBScWtEYWlndTk1YmR5QmRSSlNSWGlGNXlubURkVG0ySzNPeFVQ?= =?utf-8?B?K25DeXVBTml1MlVyWHNRNWZGMENSK0ZOb2hEcFJFeHNrOUJrMFFwL3U5akVy?= =?utf-8?B?S0ppQlhBaWtORG9pS3dlVmFYdXVrV3NTZFJ1UWRiOWFtbWhOclY1anc1NlFK?= =?utf-8?B?L0toWWF6cFc1UFJ4UjQweUR6ckIzYlFwUUVTZmZER2FXQ05aSUQ5bnZwSEZz?= =?utf-8?B?Y0Q2RWhlWXljQlhXcUYra2h5eFd3Z0h0Qld5UVNtTlhBZTVTTC9PVmdIMS9K?= =?utf-8?B?TWtZSVdSeGNZeFJSWkVPWTB2dmcwb0hsZThoRWd6d3Rhd0pieXZYTVMzSHQ5?= =?utf-8?B?c29LeTB0MzdwT1AwbUlJcSs0TlZkQzV1VFpXUVlSaWt5bU5IcXVjbm1vMlNG?= =?utf-8?B?ZzJlVlNSWXBiaDgyRGNaOWlJSDYzUEthcjVQRjY2bHNoRnlpNWU4ZmFib0Nn?= =?utf-8?B?a255cXU1dG5BOERWUWNnN2pTTnpTSDhxTHFIeHBOdFAzZmNqSmpGQUw0Zzli?= =?utf-8?B?YnZKZTlTTUZVaG9CZkxpYldud1RGdFF6Q21ZNkt4NFdpeTN5blJXbkc0RlRV?= =?utf-8?B?VUdNMDNUYWJMTHdWWk1PQ2VVckRxWkRhaHVoaXFSMjdCeUlSS2dIdURKVVgz?= =?utf-8?B?UktCSTZEbFltUEhMOFpjWFdrR1JtVTFFRFg0K0dSdXpXWm56Z255bGRvSlk0?= =?utf-8?B?L09xUUtqblRQM0VtTUFmQW5aTnVjSkRyQk9pR1FsUVFKdlQ0bk5LME9PQi9a?= =?utf-8?B?SGp5akgwV0tuK1VmZWpUK1Bwa3NZWmNrNWdScmFLdnRZRkM4MmNReEg1WnI1?= =?utf-8?B?MlQzQTdxd3N0MjBxdUptRkVMYlp2Uk1UeUJ0dSsvYVVjcDBkd1RMaFhLamow?= =?utf-8?B?aFBRWElyZytjVXl2aTlCaGtUbFFhTXcrZi9Wc1gramxpVXJVY2hDenIwL04x?= =?utf-8?B?TzlFWGticlZFMEI4M3JOMXlueWZRSVNycnpiWmRzcW9ZVjN5M0JOeDhrUVZC?= =?utf-8?Q?8+dRHUbmDYEJKfsWcsBPFEKFC0FLI6g26yLTmz?= X-Forefront-PRVS: 0343AC1D30 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(39830400002)(39450400003)(39410400002)(39400400002)(24454002)(50986999)(6486002)(230700001)(4001350100001)(54356999)(229853002)(76176999)(6666003)(74482002)(31696002)(86362001)(5660300001)(189998001)(65826007)(305945005)(42882006)(2950100002)(7736002)(2906002)(8676002)(23676002)(25786009)(33646002)(50466002)(42186005)(966005)(31686004)(6306002)(53936002)(3846002)(478600001)(6116002)(90366009)(4326008)(64126003)(47776003)(83506001)(81166006)(53546009)(38730400002)(66066001)(65806001)(3940600001)(2101003); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB0650; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWTFQUjAxTUIwNjUwOzIzOlZONFFNRXE2RVU5d0hKMmp1RGp6dXRJMDVU?= =?utf-8?B?amRHRmpwbG1CMjBTTlQ0NTQ2dHArQS9lRThsdDRTbUIrNW1RM3kyRTdNTURZ?= =?utf-8?B?djRCaWgrU0NwZ1RZdHBJY0JrVWswL2pLV3NGZysvV3VZd0dWQ21QcVhMVmVK?= =?utf-8?B?VVRzK0FVcG9jY3ZUNkVDcVdVRmtnWDBqUk1MWEdEVWljWEFGWlRiY0pJelU3?= =?utf-8?B?WExxcXI0ZHlOVGFDbi8zNnk1dHRXaWtWcVNqMU50cWx5UUxRc2VEVUtmYkZR?= =?utf-8?B?OStUWVVsdWZwYnJvL3VqNFJqZ3NMMlpMb2phY0VqTkg1aTBRMzlJc3VnWEkx?= =?utf-8?B?dHFnZmdEa0x5V3ROQnJ5dGY2Znlkby9kMk5GVHU5eWJXdWtGbktCdlUybmlB?= =?utf-8?B?NWFaOXVESXp4elJ6VVk4L2JNd2lVSEtTTFhHWWVLZXM1bE1wd2orclZFNzR6?= =?utf-8?B?dXhPQllGWEN5bDdXWFNNQ0h2OVRFaVZIdkxVSXRJRFJNS1BuSUptRnpBY2N5?= =?utf-8?B?MjNyKzE5VDZObG8rb3FtQzJzcG9pZFRLemdZZEtpL1NLOU5xOGdmKzlramtC?= =?utf-8?B?cnFSckVxa3E0NWhJMzBWcGc2Ukt4SEtrbkRmYW1jc1p1RVJmZnNKZDRPTkpD?= =?utf-8?B?bVJ1UHFzUTBUUlNzbzJ6WW00V052TUJTbjJGd3dsWEgxcFJOZENwZ1Q1Q1Ri?= =?utf-8?B?L09vNTFLcUpqamdWUC85WmpmWHk5MERPM3AyQ0VjOTNvN2RGNnhCNWxHS2Iz?= =?utf-8?B?TC9rWmRLYkZmOS9LcFp3eENJRlNMeFBxRGl4SGlJMmg0STZBbUtYR3R2UVJY?= =?utf-8?B?NVpUQ0hUUk90b1laZHAvaHVweGtlbmQ0U0tPc0xnZmZ4cXlHWFMvTHRiWDRN?= =?utf-8?B?NkltU3psMldMNWxyTGVtWVhOdFNzRWl6eGEwZm1vM0VDZXBGK0s2aXpEdzll?= =?utf-8?B?UE5hWFFRUGRRaW1GY3hjUVUxNERiUTh3b1ZUNTNnbG9uR3ErTGVEQzljRlJK?= =?utf-8?B?My9qWkZ3R2pjLzlXbUpuZzh3NHFGNS9xL0xiYnViOVV0dzlCUUppNVloY3kx?= =?utf-8?B?S2RrdzgvRGg4QVI5Y1lRYVZOWTZPM28vOXRHYzhFcVpFNHNjZWlBMUZ5YVFZ?= =?utf-8?B?aEhFdjY1ZlUzOGI5QUxSMlNKMGgyTGkrK0VraXJ1SWU0SXRMbkJpLzkrcDNm?= =?utf-8?B?c3V4N2hnVHJ3VGE3c1hTUHFybWY2RjR1dklFaW5uQmdsZHZxL0JvWHRXbG1T?= =?utf-8?B?aVJOeitKSTJCbVljZUlvMUd6Syt5V1VCbkxjUnhFMlZmakt3L3hwZEpzUFBR?= =?utf-8?B?U2t0a244dHh2bWtGdW8wY3lUdzJadkpmQW9HVEJTQlg0eFVIOGlHd0dYZU12?= =?utf-8?B?a3cyUEFzbVBjdm56NVB5aUF6dG13bmFGaVlTa3NQSDRqQXRxVGdsalVXQmZY?= =?utf-8?B?cEN6VktWRzRnWGs2ZDgzKzRtUnVod01FMUdaQkpMZEx6QytWNXZDeTNxUjZW?= =?utf-8?B?TVcvRWM2OEY4T21ocG94VVNHYjFMYnUxRXBJcnl6NnQ3dWhZOGUwbmlTdTI3?= =?utf-8?B?VXFXallmNVdodFl6Vkw3ODJLVUdaMmwvL0djdXZ3Zyt5a3FydnlTdldMOEhm?= =?utf-8?B?ZXJHQ3FSYjlwVmxEWndha3VFYnE4L3Y2RnBzc0tURERpRWxWQkErVng3V0Vt?= =?utf-8?Q?chqPZaV//c2t7HMzEwN6bvx7jG35p2Bb29u/IEX?= X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWTFQUjAxTUIwNjUwOzY6VGx0UGFmVGZhYmFyUDlkekwySzhvYXhwa3pK?= =?utf-8?B?L3dxWG5tUC9jM0l0bHUzM1VPMEUyMzlIS1VtTG4xbEFyWEx2WmVob2R1SWgr?= =?utf-8?B?V1U0N2VpbmpKNEtSUmhUNGdhK0VRSHQ4YWVuSEtNUDJTM2EyVHIzRjF0K0dr?= =?utf-8?B?bndkKzhrSGVhU0EzU0dBYzYrUjd1VG9CL3RqVElzL1FHejJUaUdGek9PMmlv?= =?utf-8?B?dFovSDllMjM0cnBkV0JXTW9lZmFaWFlnRHh6V3QyS0hFTTd3ZTFGOTEwL1FV?= =?utf-8?B?bmVHMVVhdnplZWo3ZkFVZGc3N241WElqeC9uRHdqd29xMHRsZnl5cHBSNUl4?= =?utf-8?B?d3F2c001VEMyZmdWS3g0YVNic0ZIaS9CNGxZRXdZSm52Um16Y2cwSVo0MEVt?= =?utf-8?B?dEREWWVZQ09nRlFWN2daSTNXUWJ6eTdtZTZIU1ZQaUY1SlBOY2RLczhZMytQ?= =?utf-8?B?NFhYNHo2NDFGbTE0V051MURvMGZ0b0NDcEpBbHVTNHc5cldNS1BFVURyTW5y?= =?utf-8?B?VW5PWlJUR0tsU3ozYXRWUUxCQWpMblNaUURvVWd0cVpoY0xwSUpudFFhQWJR?= =?utf-8?B?YmwyUzFjdDcvNnRlWTlJSkRiWHhRK2dOdEV0MHpSUCtoQVFqbnF3N0Vjby9r?= =?utf-8?B?T0oxSHhPbWhxWUxuaWlpVUZHRm5weHlBaUhObXBmVEU4OEo5RlF6WEllMFlQ?= =?utf-8?B?ZE5CQ1hQOEJHTEtXTVNHVm5UNkxCQjBoTk1rcGQwSmdvU2JacS9jS0dOMTI5?= =?utf-8?B?YkRydzFhNUlDUXlFbzJZcXVWeHIrOTZkZSsyK1MybGo2dERtY0F3bmxSWDBs?= =?utf-8?B?Qisrczg4WFdZNk5qTnd3eEgyOFgycGlWUnNLUG00MTV3L2dEVExaemc0SEFs?= =?utf-8?B?WHJiZU0xd0hqOGlkekNra01FbUMrblh0b2ViL3ZFcVhRMks3RlZCQUJyWStt?= =?utf-8?B?NUJPUXFGcjlaUHQwcldycmN1Z2V5dlV1UUhsZFpwTEJFcms1dTVocWpaUWhl?= =?utf-8?B?cTFGcDQ0MGl0ZmFVWHVQZW5kbmRDYmpTalUxOWExTm9FYzVSb0tzR1JzcXJE?= =?utf-8?B?MjVCMVFNY29VZHVaejJ4RU8zR0VnaWJvaDdYSVJxWEhFdWxSV0VVV2pDZEs4?= =?utf-8?B?SHM1d090WUtDYVdZTVNUcWtUUkVvMUZUMWZoaEtLd3RwK1FPeTd0c1VqMWdV?= =?utf-8?B?WXpIVGN6Z2hmV3E0UGJieDhnaHpCWHd1NDFRSnhSUU41LzhKNStVcFZBZmZ2?= =?utf-8?B?N1UrdUhkZkxweWFScHhhOFBsSXFVa1FFVEFuT2Jlb29jeEcxdm1xNTdwY0Vz?= =?utf-8?Q?cL9UVGjEcJdjbaHvf5ZHfVqtc2LI/g0=3D?= X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0650; 5:6rXYRgcBnL8hRPO7gS9A6al19/qjv+A1L0r2/hdFm1neZ12PN7+2Ns/3ZOKCq6J8V9KSwXL3wDIeMBpBO3Bd4wsBDIejW6TFYQp7IK2G4BtFvRtg3b8ClqtM6x3NrCmwuoNn8bjHFFd1wDtGviQh4wXdHCqGva/Mw12N/P0WnZUvK6pRA7xwp/lWzfQTlJtDnOljoEHpgPmYu6w1QTJlwa2Qxri2PiDk9fsQEOmUwzrRj0ddlmaVbge0dLpgZAGC16I3dVtpksrWGt7pE7uDtO1OtrytRaIzYO0D0HR0AKtOkA2OAYhwgwC8VcMskbuwaBBCBIqR634hoq4uev58n9kGsU/X43jpGAuP84MuV/uQ3k2HOpRBgSs7f9YyZ6uRuikG4WduxXEUoSAzDmaxqXqj6SnQsLEhl976Smk+1hQmV+YwXYe7enjKuZ2MPLyh8MBxE/dkgId0VvtfEOL9388TCqXHdnToF6ZNnlSre+KQbwO3AfDb/nXS/cr769+x; 24:pPpsEb6zYzJQjd15PIplklvsqE6nElWt0tRzqslvzuv6z4WEUTFgkuaduBiQftNG9Y9njFvA4VkPnjVmlh0/xa8Zz3AyTtUixw3psk3o3gE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0650; 7:KWNFz8s9w+sjBDi/YysCflOc6LhoVyVAARocUdiB+Ilw1CWvKb+DUrNtnkXhuvnGOS3P7ibghyc/PuChGa/mEWP23rdh72+ZVJjsRjVxY4zJsQZ4XE8iNAE5Et1aEySVBB6tOT/CL5M+Me73uRpjRff2sfHeHa0s/4xCr/Zv8Ixbxejhjlwcrim4AXHw0d/EvpVVxyPZ4zxJ7AKzA0lmEZPDT8y9cN0hopUZ1h7+yKn21T+2ZoCX5jwQZzSRXGqa4hmDZjgFpKVxmh9g3BOO9Lg3JjKF/HV10S9ZsKLFWh274iMYgi3eHIG2tEx6V7eCL+rHDDubxliQiUr6QFtLzHlrMb0+OiPwcADz1e0uh6R/HlfJGm6ULmrQexQBVA1XH4S/gmlnoSLvbvIto7Kc2DuaDSkfVeJWSotHMLjgLXscLKAoODvhzaynxckOLzbSGbT2D8ZzOo0nQUeCvHpwETi5TNtaMLTzppnmS16fRhHzBcQ4HDuU7zMg8P2nHq4SIJdIo8vMyZwnZl7ib0b0Ac0ftvVW5AFGrfzkX9OgOp77Htv7DgXGJi4FiZBmosvfepEm1PplAYa/qAJ2Bllmhy4ymKTqzaety98kSrWtVPDfuGKa7gWC7FYJpVln8xYlZK5Oq1EiWbPXfm3TOCOLLwjBS6usNzyNTtbkWWgx9EB9gfxB2SQw0EQ0IYGGk7OrUbV9sdf5FXgIULIayl1jtYhWt7v++eklmvYNVTFmTkc978GlP9oMp7lbvCkTRIttz1hkK0izvMsNUDK/ESzl0qg73EPksE6/3rZOfRLCyZw= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jun 2017 04:01:09.1106 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0650 Archived-At: Subject: Re: [Webpush] [media-types] Media type review for application/webpush-options+json X-BeenThere: webpush@ietf.org 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: Mon, 19 Jun 2017 04:01:15 -0000 Hello Martin, For those fields where you have "n/a", I think in most cases, "none" would be more precise. Also, "Published specification: This document." doesn't work when the template is extracted. Also, "Encoding considerations: binary" looks wrong (but maybe it was choosen because 8bit has a line length limitation?). Anyway, it would be good to add a comment there that the format is essentially text-based, and the character encoding is UTF-8. Regards, Martin. On 2017/06/19 12:41, Martin Thomson wrote: > Copying the template from > https://datatracker.ietf.org/doc/html/draft-ietf-webpush-vapid#section-6.3 > > Type name: application > > Subtype name: webpush-options+json > > Required parameters: n/a > > Optional parameters: n/a > > Encoding considerations: binary > > Security considerations: See [RFC7159] for security considerations > specific to JSON. > > Interoperability considerations: See [RFC7159] for interoperability > considerations specific to JSON. > > Published specification: This document. > > Applications that use this media type: Web browsers, via the Web > Push Protocol [RFC8030]. > > Fragment identifier considerations: None, see [RFC7159]. > > Additional information: > > Deprecated alias names for this type: n/a > > Magic number(s): n/a > > File extension(s): .json > > Macintosh file type code(s): TEXT > > Person & email address to contact for further information: Martin > Thomson (martin.thomson@gmail.com) > > Intended usage: LIMITED USE > > Restrictions on usage: For use with the Web Push Protocol [RFC8030]. > > Author: See "Authors' Addresses" section of this document. > > Change controller: Internet Engineering Task Force From nobody Sun Jun 18 21:17:13 2017 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 5925E126DC2 for ; Sun, 18 Jun 2017 21:17:06 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 qGgbeW6ASFZE for ; Sun, 18 Jun 2017 21:17:04 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 D986E124C27 for ; Sun, 18 Jun 2017 21:17:03 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id v20so48341832lfa.1 for ; Sun, 18 Jun 2017 21:17:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7+j3N788rw2UYE4gCF8AXhFbMsHcnmzjegngI41VYlo=; b=AKPfjoTQSa6YI9xatMbeNlw8Qg0qs8aZOj7tGBB4gKg3+8fbIbDffOQIAJzKTo4tPv Zq0AMiqSU8kFX/qutA24ZMJSPv6XPHhQrJcUBFBhL1mtp+c81CLYo3T1AIHljTf78rB6 4n7+lHrIa0DZmVe0g35LvUZQdotzRkc0jqAyNnMLo1EKbGRrALslwLuIttzA9866Bm4p wCmyRC9dE3emDq0dsanKRvCwG8Ana1qwdKnxC3Irb65nan4fY8NbISGDwbRb39fdxCu6 kejXIHBpIsI1aoAt7xbGs3Zkrl8JzsuEx2v7fzLjDitjmbg25qkAZGORPP3ZKPT6V6Z4 9yLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7+j3N788rw2UYE4gCF8AXhFbMsHcnmzjegngI41VYlo=; b=F6dQNbcHSDzS43gg5aE2ookyw6XIDQWKNAjx4cnYzABSsIwhEI81VuyMB69w2Ms16L OBGmwt1dj+HoJEUo1+W8AK7i4T5gtN2q4BAZbBagTN60/JBwkpVFbGid5t1Nj/tgyN2g sTs6O7TsP27FtTXumvngQ9QBDIDUHAjytO4oVdtXW3MCadPqgh4i6dmGfBWDny7T4Byu r33JfghRup+9pMtwKunv1TeMDHYulZZz1K0m6Ugr1GdCkNNrdbH4O04oGCUIy9C9JW+A LrM+rxdWinXo/fbeoah3uS9HsrqUNkWW7ZN48gXFDzrKDWxZy293ZSR9jPu31FA53iUp nMKA== X-Gm-Message-State: AKS2vOy9VaOgqM1y+SOxLZKH7Lsux1mz30ONgPa/ARo232hi9l88ghf6 LbFrKqqXmcN7lpyCBJM06GcMKB2P/w== X-Received: by 10.46.21.92 with SMTP id 28mr5781086ljv.50.1497845822105; Sun, 18 Jun 2017 21:17:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.78.17 with HTTP; Sun, 18 Jun 2017 21:17:01 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Mon, 19 Jun 2017 14:17:01 +1000 Message-ID: To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Cc: media-types@iana.org, "webpush@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Webpush] [media-types] Media type review for application/webpush-options+json X-BeenThere: webpush@ietf.org 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: Mon, 19 Jun 2017 04:17:06 -0000 Thanks Martin, Corrected in https://github.com/webpush-wg/webpush-vapid/commit/c9e2d0259d2= bc6fd3b6 On 19 June 2017 at 14:01, Martin J. D=C3=BCrst wro= te: > Hello Martin, > > For those fields where you have "n/a", I think in most cases, "none" woul= d > be more precise. Also, "Published specification: This document." doesn't > work when the template is extracted. Also, "Encoding considerations: > binary" looks wrong (but maybe it was choosen because 8bit has a line len= gth > limitation?). Anyway, it would be good to add a comment there that the > format is essentially text-based, and the character encoding is UTF-8. > > Regards, Martin. > > > On 2017/06/19 12:41, Martin Thomson wrote: >> >> Copying the template from >> https://datatracker.ietf.org/doc/html/draft-ietf-webpush-vapid#section-6= .3 >> >> Type name: application >> >> Subtype name: webpush-options+json >> >> Required parameters: n/a >> >> Optional parameters: n/a >> >> Encoding considerations: binary >> >> Security considerations: See [RFC7159] for security considerations >> specific to JSON. >> >> Interoperability considerations: See [RFC7159] for interoperability >> considerations specific to JSON. >> >> Published specification: This document. >> >> Applications that use this media type: Web browsers, via the Web >> Push Protocol [RFC8030]. >> >> Fragment identifier considerations: None, see [RFC7159]. >> >> Additional information: >> >> Deprecated alias names for this type: n/a >> >> Magic number(s): n/a >> >> File extension(s): .json >> >> Macintosh file type code(s): TEXT >> >> Person & email address to contact for further information: Martin >> Thomson (martin.thomson@gmail.com) >> >> Intended usage: LIMITED USE >> >> Restrictions on usage: For use with the Web Push Protocol [RFC8030]= . >> >> Author: See "Authors' Addresses" section of this document. >> >> Change controller: Internet Engineering Task Force From nobody Mon Jun 19 15:17:38 2017 Return-Path: X-Original-To: webpush@ietf.org Delivered-To: webpush@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E4501129329; Mon, 19 Jun 2017 15:17:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.55.0 Auto-Submitted: auto-generated Precedence: bulk CC: adam@nostrum.com, draft-ietf-webpush-vapid@ietf.org, Phil Sorber , sorber@apache.org, webpush-chairs@ietf.org, webpush@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149791064984.23654.7582568658130984876.idtracker@ietfa.amsl.com> Date: Mon, 19 Jun 2017 15:17:29 -0700 Archived-At: Subject: [Webpush] Last Call: (Voluntary Application Server Identification (VAPID) for Web Push) to Proposed Standard X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 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, 19 Jun 2017 22:17:30 -0000 The IESG has received a request from the Web-Based Push Notifications WG (webpush) to consider the following document: - 'Voluntary Application Server Identification (VAPID) for Web Push' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-07-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract An application server can use the method described to voluntarily identify itself to a push service. This identification information can be used by the push service to attribute requests that are made by the same application server to a single entity. An application server can include additional information that the operator of a push service can use to contact the operator of the application server. This identification information can be used to restrict the use of a push subscription a single application server. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-webpush-vapid/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-webpush-vapid/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Jun 22 14:14:55 2017 Return-Path: X-Original-To: webpush@ietf.org Delivered-To: webpush@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F4312945E; Thu, 22 Jun 2017 14:14:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: Cc: webpush@ietf.org, ietf@ietf.org, draft-ietf-webpush-vapid.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149816608028.23068.7975099108704386725@ietfa.amsl.com> Date: Thu, 22 Jun 2017 14:14:40 -0700 Archived-At: Subject: [Webpush] Genart last call review of draft-ietf-webpush-vapid-03 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 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, 22 Jun 2017 21:14:40 -0000 Reviewer: Joel Halpern Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-webpush-vapid-?? Reviewer: Joel Halpern Review Date: 2017-06-22 IETF LC End Date: 2017-07-03 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standard Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A From nobody Wed Jun 28 14:38:53 2017 Return-Path: X-Original-To: webpush@ietf.org Delivered-To: webpush@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F2DDC12EC71; Wed, 28 Jun 2017 14:38:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks To: Cc: webpush@ietf.org, ietf@ietf.org, draft-ietf-webpush-vapid.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149868592596.7659.3988919152591675113@ietfa.amsl.com> Date: Wed, 28 Jun 2017 14:38:45 -0700 Archived-At: Subject: [Webpush] Secdir last call review of draft-ietf-webpush-vapid-03 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 28 Jun 2017 21:38:46 -0000 Reviewer: Robert Sparks Review result: Has Nits Summary: Ready (with nits) This document provides a mechanism for an application server to voluntarily identify itself to a push server using JWT. The draft is easy to follow. The security properties of this mechanism are clearly and thoroughly discussed. There are some minor nits: 1) The draft says that expiry claims MUST NOT be more than 24 hours from the time of the request. Consider adding some discussion of why 24 hours was chosen (vs some other arbitrary value), especially given the MUST NOT strength of the requirement. 2) The last paragraph of 4.2 says application servers create subscriptions, but it means to say that user agents do. Martin already addressed when I brought it up out-of-band with . 3) The last sentence of the abstract is missing a word. Perhaps s/subscription a/subscription to a/ ? 4) Consider using the RFC8174 update to RFC2119. From nobody Wed Jun 28 16:30:59 2017 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 DCA1512EB0B; Wed, 28 Jun 2017 16:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 0lhYZe-n-4Ws; Wed, 28 Jun 2017 16:30:56 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (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 ABB8212EC2A; Wed, 28 Jun 2017 16:30:55 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id h22so43452089lfk.3; Wed, 28 Jun 2017 16:30:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u/HhFhLLRZcU5z43GA4cKl/VbYnkux0RTu+AneGlxIY=; b=L5GtFivmyDiLgvG3xB31/bFgJIQQPJnlOYm3i5wZtNr+Rw3qajc5+0vOwW6CkS+g30 SLt9TGHJThbXI4BbN1Y7bIdzW52qqg+FmDNqwpyV92obYdgL7CWSj5K16RarI1Lqnust D1/B57aDa/I9y8cCFSv/TtF8VkViVl7hQXT/JLBmjXJSw9ydDa4nzxehvrPS4Ctk5IWU 12GlPMG0wK4TUSSw2yj1rN+8mJCc09v8xaot8dlTaL98azpqum4SWJyHmbXweYfpehDb Bqou8GyGUoAqJh5ZkCZ4ImcdrbTVvOfvT1ueP7aeggFFnckqunfkztvs+mH1TijPLV7n QDhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=u/HhFhLLRZcU5z43GA4cKl/VbYnkux0RTu+AneGlxIY=; b=rmHBKxcHigmDMesgBehDXiGBMU88F0NHRo3KSEBKOrzdv5yZxJVopLg2AjLigcsJNZ m5ljWbdzM+YWWNoTQOhb0qsdHiuSVTGbVzJT7IP6uCR2YUg9xSq53r74d7lZ16HwV25b Zuo4v5WAzDkcWc+QuVTOpZVLDsombM44ud1J6/lF6nNmFuRKWdbrXNbKtHXLWEFrTuoT ItUHac3ZtrGSMGfss3kCN+3Fky9qSjR657GgXCq7SCjtheEF912szSEb3DEnLddJO+Ak a3QGC4pEUycoiM2w5OGx5w+yw9EE+F/k/KOPZP99xtKuIlOUOXhZQtOm+OVI/1ilRi8k B24Q== X-Gm-Message-State: AKS2vOyV5urLhAr5YTD0EUiIWN1YSnM7ToxVoceEPnRLMqkzJ6L7Ny+t so9ZZ9S1L339f720DZf9M6xS6wIxrK79KzA= X-Received: by 10.25.196.205 with SMTP id u196mr3774462lff.19.1498692654005; Wed, 28 Jun 2017 16:30:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.78.17 with HTTP; Wed, 28 Jun 2017 16:30:53 -0700 (PDT) In-Reply-To: <149868592596.7659.3988919152591675113@ietfa.amsl.com> References: <149868592596.7659.3988919152591675113@ietfa.amsl.com> From: Martin Thomson Date: Wed, 28 Jun 2017 16:30:53 -0700 Message-ID: To: Robert Sparks Cc: "secdir@ietf.org" , "webpush@ietf.org" , "ietf@ietf.org" , draft-ietf-webpush-vapid.all@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Webpush] Secdir last call review of draft-ietf-webpush-vapid-03 X-BeenThere: webpush@ietf.org 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: Wed, 28 Jun 2017 23:30:58 -0000 Thanks Robert. On 28 June 2017 at 14:38, Robert Sparks wrote: > 1) The draft says that expiry claims MUST NOT be more than 24 hours from the > time of the request. Consider adding some discussion of why 24 hours was chosen > (vs some other arbitrary value), especially given the MUST NOT strength of the > requirement. Frankly, the decision is a little arbitrary, but it's where we landed. It's a balance between competing concerns of reuse and the exposure to theft and abuse that comes with reuse. The overriding reason for a MUST NOT strength is that it allows the server to reject requests with bad claims. I'll add a sentence to the security considerations, which talk about the need for expiration and the implications of the MUST NOT. See https://github.com/webpush-wg/webpush-vapid/pull/40 > 2) The last paragraph of 4.2 says application servers create subscriptions, but > it means to say that user agents do. Martin already addressed when I brought it > up out-of-band with . > > 3) The last sentence of the abstract is missing a word. Perhaps s/subscription > a/subscription to a/ ? Fixed, thanks. > 4) Consider using the RFC8174 update to RFC2119. Noted.