Re: RIP: Crypto-Key header field

Julian Reschke <> Tue, 22 November 2016 08:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A3A5C12967B for <>; Tue, 22 Nov 2016 00:33:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.398
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hVo5S7-XnyIA for <>; Tue, 22 Nov 2016 00:33:09 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BFD211293FB for <>; Tue, 22 Nov 2016 00:33:08 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1c96SB-0002go-Og for; Tue, 22 Nov 2016 08:29:23 +0000
Resent-Date: Tue, 22 Nov 2016 08:29:23 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1c96S6-0002fB-98 for; Tue, 22 Nov 2016 08:29:18 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <>) id 1c96S0-0005fS-28 for; Tue, 22 Nov 2016 08:29:13 +0000
Received: from [] ([]) by (mrgmx003 []) with ESMTPSA (Nemesis) id 0MWk7n-1cGep81zEh-00XvQB; Tue, 22 Nov 2016 09:28:41 +0100
To: Martin Thomson <>, HTTP Working Group <>
References: <>
From: Julian Reschke <>
Message-ID: <>
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: <>
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=;;
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: 1c96S0-0005fS-28 4d015a374c9c00c1e8cf2dc00e8755ed
Subject: Re: RIP: Crypto-Key header field
Archived-At: <>
X-Mailing-List: <> archive/latest/32956
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-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.
> There was also a comment about how to pad.  I ripped off some text
> from other protocols:
> 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.


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 

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 

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

Best regards, Julian