Re: [Webpush] Voluntary application server identification

Martin Thomson <martin.thomson@gmail.com> Tue, 24 November 2015 17:03 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: webpush@ietfa.amsl.com
Delivered-To: webpush@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94FA01B2DD7 for <webpush@ietfa.amsl.com>; Tue, 24 Nov 2015 09:03:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 F6WlZ0HSawfu for <webpush@ietfa.amsl.com>; Tue, 24 Nov 2015 09:03:12 -0800 (PST)
Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (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 413F81B2DBD for <webpush@ietf.org>; Tue, 24 Nov 2015 09:03:12 -0800 (PST)
Received: by igvg19 with SMTP id g19so99669894igv.1 for <webpush@ietf.org>; Tue, 24 Nov 2015 09:03:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L3Vbw+8S7Nln3daCgLqXdJ2uZQUj400Df4vO/J4pJtQ=; b=txDYmaToSlJhGsmFkpnm8MjfKv6GmIfPCWmY1kw0bNlBfOxSTK4vTV7rg4b7WgEEtO h9yWYSJF/d219SXQ0RJxm/2JUDL5BPmH2EiYeLVjeFfJtElkt2Gpw6P/KDt3pssmj97F 6nmhv4Q4l22B7wzlrZQT4dnzjkq4mBoOrLX/aIObwE9wuc2xLEZPam0PAObFUPKE5VxX zrIfw57JK8XcUUlkE4zLGoNwBOFCpCw+/7RiUmmtJJwtjVxg24Txv6yxujn8r/Sbja1O GoDeJercKK9zlgIE6L49NM90JwN/pwtCEsqBX6Xmvh+R6of8lorUBU3jjPImExwMoYZr SNTA==
MIME-Version: 1.0
X-Received: by 10.50.30.6 with SMTP id o6mr19263957igh.94.1448384591528; Tue, 24 Nov 2015 09:03:11 -0800 (PST)
Received: by 10.36.155.139 with HTTP; Tue, 24 Nov 2015 09:03:11 -0800 (PST)
In-Reply-To: <CALt3x6=a-AQ6jqs5NhuhvKZxfdj2OCai8e8nvoqHkAvPfsU_fQ@mail.gmail.com>
References: <CABkgnnVseWsGsALwp7ZbQQ68krjiiUqGaOh8jfOXF-AN0DdAgg@mail.gmail.com> <CALt3x6=a-AQ6jqs5NhuhvKZxfdj2OCai8e8nvoqHkAvPfsU_fQ@mail.gmail.com>
Date: Tue, 24 Nov 2015 09:03:11 -0800
Message-ID: <CABkgnnVvjJ6gOj-0c8ss_Xa539iyjyReXmf4-YZyVN7nGbpAKg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Peter Beverloo <beverloo@google.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/webpush/ACUBVggx80o5LCpJhUidhP3lSq0>
Cc: "webpush@ietf.org" <webpush@ietf.org>
Subject: Re: [Webpush] Voluntary application server identification
X-BeenThere: webpush@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of potential IETF work on a web push protocol <webpush.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/webpush>, <mailto:webpush-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/webpush/>
List-Post: <mailto:webpush@ietf.org>
List-Help: <mailto:webpush-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/webpush>, <mailto:webpush-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Nov 2015 17:03:13 -0000

On 24 November 2015 at 08:45, Peter Beverloo <beverloo@google.com> wrote:
> The proposed solution, having a TLS client certificate, has the benefit
> that the certificate's public key could serve as a token for this
> association. Not all alternative solutions have similar shareable tokens.

All the signature-based options have this property (though the -cavage
option would need to be enhanced a little, unless you require the
additional step below).

> Both server identification and subscription association are important for
> us, and, at least initially, mechanisms that we will mandate use of. If
> this proposal works for everybody, we may have to consider a status code
> through which the push service can indicate this.

This is a good point.  The idea being that you could have an
application feed the public key it's application server will use to
the .subscribe() method on the API.  That would propagate up to the
push service and the push service would drop push messages that
weren't signed with the corresponding private key.

I didn't want to introduce too many new concepts at once, but this is
a good idea.  I'd like to keep it optional, of course.