Re: Encryption content coding simplification

["Poul-Henning Kamp" <[e-mail]>]

--------
In message <[e-mail]>, Martin Thomson writes:
>Based on the review from ekr and the discussion at the last meeting,
>I've put together a pull request on the encrypted content coding spec
>that proposes to remove a bunch of the complexity from the spec. I
>think that it's a lot simpler:
>
>https://github.com/httpwg/http-extensions/pull/218

It certainly is.

But relative to the discussion about how many specialized parsers
we have forced people to write, this draft seems to add yet another
for the new headers.

I think we should try to, and easily can avoid that.

	Content-Encoding: aesgcm, aesgcm
	Encryption: keyid="mailto:[e-mail]";
		    salt="NfzOeuV5USPRA-n_9s1Lag",
		    keyid="bob/keys/123";
		    salt="bDMSGoc2uobK_IhavSHsHA"; rs=1200

Keyid, salt and rs are parameters to the Content-Encoding,
so in a perfect world, we would send this as:

	Content-Encoding:
		aesgcm;keyid="mailto:[e-mail]";
		    salt="NfzOeuV5USPRA-n_9s1Lag",
		aesgcm;keyid="bob/keys/123";
		    salt="bDMSGoc2uobK_IhavSHsHA";
		    rs=1200

That is a non-trivial extension of RFC7231's "content-coding", which
may or may not cause existing implementations to needlessly reject
these transactions.

I suggest we run a few tests to see what happens in the real world.

If extending C-E is impractical, we should put the Encryption header
on "common structure" form, by having it reference its corresponding
token from the C-E header explicitly:

	Content-Encoding: aesgcm, aesgcm
	Encryption: aesgcm;keyid="mailto:[e-mail]";
		    salt="NfzOeuV5USPRA-n_9s1Lag",
		    aesgcm;keyid="bob/keys/123";
		    salt="bDMSGoc2uobK_IhavSHsHA"; rs=1200

That has the added advantage of being a clean extension point
past aesgcm down the road:

	Content-Encoding: aesgcm, caesar
	Encryption: aesgcm;keyid="mailto:[e-mail]";
		    salt="NfzOeuV5USPRA-n_9s1Lag",
		    caesar;shift=52

But if we've come all this way, we might as well generalize
"Encryption" to a "CE-params", that can carry parameters for any
C-E:

	Content-Encoding: aesgcm, caesar, supercompress
	CE-params: aesgcm;keyid="mailto:[e-mail]";
		    salt="NfzOeuV5USPRA-n_9s1Lag",
		    caesar;shift=5,
		    supercompress;dictionary=11

With this approach the new Crypto-Key header surplus to
requirements: The key is simply another parameter, and
we avoid having to match the key-id from two different
headers with each other, and all the corner-cases that
brings:

	Content-Encoding: aesgcm, caesar, supercompress
	CE-params: aesgcm;key="csPJEXBYA5U-Tal9EdJi-w";
		    salt="NfzOeuV5USPRA-n_9s1Lag",
		    caesar;shift=5,
		    supercompress;dictionary=11

And finally, we want a "binary blob" type in the common structure,
the two we have here would be marked as such, for instance with
the "\#" I proposed in my strawman:

	Content-Encoding: aesgcm, caesar, supercompress
	CE-params: aesgcm;key="\#csPJEXBYA5U-Tal9EdJi-w";
		    salt="\#NfzOeuV5USPRA-n_9s1Lag",
		    caesar;shift=5,
		    supercompress;dictionary=11

Please ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[e-mail]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.