- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Tue, 07 Jun 2016 07:10:31 +0000
- To: Mark Nottingham <mnot@mnot.net>
- cc: HTTP Working Group <ietf-http-wg@w3.org>
-------- In message <828F4861-FCC3-456B-9DB9-C35960B752BF@mnot.net>, Mark Nottingham wri tes: >Please have a careful read through and raise any issues you find, and >state your support (or lack thereof) on list. In particular, if have >implemented it, or intend to, it would be helpful to know this. People do stupid things based on examples, when they don't fully grasp the subject matter. Therefore examples should be designed to not inspire trouble. For instance 5.1: HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Encoding: aesgcm Connection: close Encryption: keyid="http://example.org/bob/keys/123"; salt="XZwpw6o37R-6qoZjw6KwAw" [encrypted payload] Here, a successful HTTP GET response has been encrypted using input keying material that is identified by a URI. Keyid is defined as "a string" (BTW: Not obvious if 'string' should be understood as some ABNF term), and a URI is a perfectly valid string. But by overspecializing the example, some idiot, somewhere, will interpret it to mean that the actual key should be fetchable at a URL - and create a gaping hole in one million consumer devices. Yes, it says "identified by a URI" right there, and that is perfectly clear - provided you understand english well enough. The use of "mailto:" URI's is even worse: I can see people scratching their head wondering how long their program should wait for the reply before timing out, and decide to use the http: variant instead "because it will be much faster". I propose that we do not use URIs as keyid in any of the examples, but rather plain strings with no overloaded context such as keyid="key01294". People should be smart enough to realize on their own that URIs are valid strings, but a footnote could remind them. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Received on Tuesday, 7 June 2016 07:11:02 UTC