Re: RIP: Crypto-Key header field

Julian Reschke <julian.reschke@gmx.de> Tue, 22 November 2016 08:33 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A5C12967B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 22 Nov 2016 00:33:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.398
X-Spam-Level:
X-Spam-Status: No, score=-8.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 hVo5S7-XnyIA for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 22 Nov 2016 00:33:09 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFD211293FB for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 22 Nov 2016 00:33:08 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1c96SB-0002go-Og for ietf-http-wg-dist@listhub.w3.org; Tue, 22 Nov 2016 08:29:23 +0000
Resent-Date: Tue, 22 Nov 2016 08:29:23 +0000
Resent-Message-Id: <E1c96SB-0002go-Og@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <julian.reschke@gmx.de>) id 1c96S6-0002fB-98 for ietf-http-wg@listhub.w3.org; Tue, 22 Nov 2016 08:29:18 +0000
Received: from mout.gmx.net ([212.227.15.19]) by mimas.w3.org with esmtps (TLS1.2:DHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <julian.reschke@gmx.de>) id 1c96S0-0005fS-28 for ietf-http-wg@w3.org; Tue, 22 Nov 2016 08:29:13 +0000
Received: from [192.168.178.20] ([93.217.100.105]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MWk7n-1cGep81zEh-00XvQB; Tue, 22 Nov 2016 09:28:41 +0100
To: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
References: <CABkgnnXQ7jFX+U0Ziai_kmja740h-6MBmBG5vxNF5Tr2fpTX3w@mail.gmail.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <41b1ccf6-32ff-c450-9f61-8f51feb99dad@gmx.de>
Date: Tue, 22 Nov 2016 09:28:40 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0
MIME-Version: 1.0
In-Reply-To: <CABkgnnXQ7jFX+U0Ziai_kmja740h-6MBmBG5vxNF5Tr2fpTX3w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:Via/bGmb8aqSatBj0RLUGbdUnDVxLoomGqim1wRkmDVIPG4Z8Bw z1xRy7ZA3UuXmUtTVuxI1oxB0SDvFsmj4qQw8FLC/dltmhRGv+uOrIcMDtGamcFdUy61BGm 3nV4EHLu6biVPENrLF8dfIl1UvAxn52f6RiWMiCgIiITTJIK1I+REHV7ExVbmHcdya6lY/A d8nB+4LSQbxItRzT59NXQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:a9wz66n5JXI=:UHzm0BKwkjlPoke/c0acmL Ds8D4zJKGEe3mx81TN67wUyEq3hvSH2zu5ymQZTozbnAZzdbnR74Brn6IQ6L15BvRLl1msX1o Ig+NnUwLSWPXsAiLDppXdxzPdH2D7cR6twlTVey7Sydj10QmDdR6R7kW5649cQObuWY2e67C7 p/dnULYpFZeLEOwoFb8pxT6T/YLy89p/+vG+cPS3MjxuJ2+HMYjICdQ1BA3L5d7Lgailgq094 uteQ3tWr/rk7hkvjHWD2V8z1E1sCnO6EgiGd9pnlDm9z4xCpafFV9ztH65IL4jt247pD5zUt3 El6qNhYz1/C/ye48rv+ityIGdggPaaZR1ntTdpOoiso1abTRYeUZZPNJGPn0W7t9++LF6brAq iqBkJFEVtz7UFCK3Wk4nbgx1KyPqQjdqJEIDpHffoN0jDx6McOeBAD/c0khlY54i4Q7uf1Gy+ 8Vqn10taiBAz7TDjXCvkULRGaaxzNdpZ3h7jLpuS0dyy9L4bDGQtHKKOlyMnxhH+REsGhH6F/ jMv0bPIUhgfC9XIcfYER8YFtFaqOC+B+zyC9mReRYjNTPdm326i93KgRF9Ubajh6mGh+Y1Fq6 JTNLVWVvWV9PyGCmEftQHPLEUv/vZnKseLv+UJxQ2wubrdO1z3WaQvxTjIHxoBrb+JIYTzisM YuKvqlm+ZVljDBE/JLqrWH+bA9k/2yoOhw0NXC5Yhn8pTg+u/QXbSzGc5x2U4RDKOdFvFV3MB Skm7CVtfXRwzHwlF2UIUC+dAr6HeM/f9IvjNAxhgnukTC1sd6HU4alSuh01B5cwwyHsVvRHJZ l3p1hzzpaLc0v+PFuEy83MDf0bI9g==
Received-SPF: pass client-ip=212.227.15.19; envelope-from=julian.reschke@gmx.de; helo=mout.gmx.net
X-W3C-Hub-Spam-Status: No, score=-6.6
X-W3C-Hub-Spam-Report: AWL=-0.016, BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1c96S0-0005fS-28 4d015a374c9c00c1e8cf2dc00e8755ed
X-Original-To: ietf-http-wg@w3.org
Subject: Re: RIP: Crypto-Key header field
Archived-At: <http://www.w3.org/mid/41b1ccf6-32ff-c450-9f61-8f51feb99dad@gmx.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32956
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On 2016-11-21 04:56, Martin Thomson wrote:
> As we discussed in the meeting (and before that, on the list), I've
> created a PR to remove the Crypto-Key header field.  As a result, the
> document is much, much smaller and cleaner.
>
> https://github.com/httpwg/http-extensions/pull/271
>
> There was also a comment about how to pad.  I ripped off some text
> from other protocols:
>
> https://github.com/httpwg/http-extensions/pull/272
>
> In the spirit of "you know when you are done when there is nothing
> left to remove", I think we are ready.  I'll give people a chance to
> read these, then post a new revision.

I remain a bit concerned about the vagueness with respect to key 
dictionaries. I understand why we don't specify them here precisely, but 
then any other spec that makes use of them will have to do the extra work.

Specifically:

1) The way "keyid" is currently specified makes it an octet sequence, 
that may or may not be valid UTF-8 and could even include NUL. Is that 
really the intention? We've seen the consequences of this with ALPN 
identifiers, which required us to define a funky escaping mechanism in 
alt-svc, so we could put them into places that take strings. This not 
only affects related specs, but also APIs for code that handles 
encryption encoding (such as: what's the datatype for the key in 
dictionaries?)

2) Is there a notion of uniqueness? Can there be multiple dictionaries, 
which might contain different information for the same keyid? What's the 
suggest behavior when there's more than one? Pick first? Pick first that 
works?

3) Is there any spec that uses encryption encoding and uses 
dictionaries? If so, how does it interface with key dictionaries?

Best regards, Julian