Re: Working Group Last Call: Encrypted Content-Encoding for HTTP

--------
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