[websec] Public-Key-Pins-Report-Only
Trevor Perrin <trevp@trevp.net> Fri, 21 February 2014 08:24 UTC
Return-Path: <trevp@trevp.net>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54411A0031 for <websec@ietfa.amsl.com>; Fri, 21 Feb 2014 00:24:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.079
X-Spam-Level:
X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 uqejnm6-uZ-w for <websec@ietfa.amsl.com>; Fri, 21 Feb 2014 00:24:33 -0800 (PST)
Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 000B31A0009 for <websec@ietf.org>; Fri, 21 Feb 2014 00:24:32 -0800 (PST)
Received: by mail-wi0-f180.google.com with SMTP id hm4so541461wib.1 for <websec@ietf.org>; Fri, 21 Feb 2014 00:24:28 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=u/W/har1rKWfEsAYYdvSmKBgJXfMtwVWvCVBHz92icE=; b=JDjxInJrT/cuMb5oHC0sGDFRAYl1l5f2qvvN3nhdnz7bJJjcWt/azuLNtgVt5K5Q5z xZrfMaV5yVz5Dx6utjU1b7VNvLfVwIFoRojlNqSJSKraN9C/2RaLT/wVRlzGHacMowmP oUtaoY0TnXiQV7FXGOPKVgsbPsg9PjKp47NKvtKoHvW/sXawviocK/MjbBLmq4S+vDBX zkDsZLqhbRVX98cVZ9axKshzWIkZiop4WkQsQNlfCdhBNkjQdvDueskjeodhIrOgQE3w IelroFCn/CsOuJUfozyTo4vHAu4J1J25SWmPXd0uVgB4PJT2+n3zPJLOIa+bGeGkSaO7 t0/w==
X-Gm-Message-State: ALoCoQkQO1pdTLavPkXEcOS87mJEUDrL/vIYbiJMUhZs6ek0Mk4ZHESVCD3T77UfRjVOxmpgh3XK
MIME-Version: 1.0
X-Received: by 10.180.187.237 with SMTP id fv13mr2030100wic.26.1392971068662; Fri, 21 Feb 2014 00:24:28 -0800 (PST)
Received: by 10.216.45.146 with HTTP; Fri, 21 Feb 2014 00:24:28 -0800 (PST)
X-Originating-IP: [166.137.185.75]
Date: Fri, 21 Feb 2014 00:24:28 -0800
Message-ID: <CAGZ8ZG1VNHVWx2xbW_CGJvNBMmrw7vGZ5uLxCo4Si9ZPv-7ihg@mail.gmail.com>
From: Trevor Perrin <trevp@trevp.net>
To: IETF WebSec WG <websec@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/EQvYQHg5mnVTDbG0XKk637hESTY
Subject: [websec] Public-Key-Pins-Report-Only
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec/>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Feb 2014 08:24:34 -0000
Hi websec, How should HPKP's Public-Key-Pins-Report-Only header work? Does it only apply a check to the current TLS connection, or is the UA is expected to remember the pins and apply them to future connections? If the UA is expected to remember them, how do "Report-Only" pins interact with regular pins? Do they override each other or are Report-Only pins tracked separately, so that a browser might have a Report-Only pin and a "regular" pin for the same site? Trevor
- [websec] Public-Key-Pins-Report-Only Trevor Perrin
- Re: [websec] Public-Key-Pins-Report-Only Chris Palmer
- Re: [websec] Public-Key-Pins-Report-Only Trevor Perrin
- Re: [websec] Public-Key-Pins-Report-Only Tom Ritter
- Re: [websec] Public-Key-Pins-Report-Only Chris Palmer