WGLC comment on draft-ietf-httpbis-encryption-encoding-03, was: Encryption content coding simplification

On 2016-09-28 09:28, Martin Thomson wrote:
> I apologize for letting this email slip through the cracks.
>
> I see two requests here:
>
> 1. add a token to the header field syntax, i.e. go from:
>   Encryption = #encryption_params
> to:
>   Encryption = token #encryption_params
>
> 2. Fold the two header fields into one.
>
> For 1, adding the token doesn't, as you claim, gain you forward
> compatibility, due to the nature of content codings.  There's little
> point in the redundancy: if you don't understand the content coding,
> you don't get to decode/decrypt it, so order is sufficient to
> disambiguate which parameters go with which coding.  A receiver that
> decodes the content necessarily understands all of the content codings
> that it needs to acquire parameters for.
>
> For 2, while it seems like largely a matter of taste, a separable
> dictionary of keys is more flexible.  That flexibility enables the use
> of the header field in detached modes (some of the more advanced blind
> cache scenarios benefit from this).
>
> There might be a third request (use your strawman encoding), which I
> will respectfully decline.  At least until I've seen it, and maybe
> after we've had some more discussion.
> ...

While I agree with what Martin said here, I think I found another issue 
with the way Encryption is defined.

Here's a modified example:

 Content-Encoding: aesgcm, aesgcm
 Encryption: keyid="mailto:me@example.com";
      salt="NfzOeuV5USPRA-n_9s1Lag"

The issue is that for aesgcm, the information in the Encryption header 
field is optional, it could be provided outside the HTTP message (such 
as when using the out-of-band encoding). In this case, for the message 
above, it's not clear to which of the two aescgm applications the 
parameters apply.

I believe this can be fixed by not introducing a placeholder syntax, for 
instance:

 Content-Encoding: aesgcm, aesgcm
 Encryption: keyid="mailto:me@example.com";
      salt="NfzOeuV5USPRA-n_9s1Lag",
                     null

I also agree with PHK that if we add a new header field to specify 
content coding parameters, it should be applicable to any new encoding, 
not just Encryption codings (yes, that's just a naming issue).

With that, I actually end up with something similar to one of PHK's 
proposals:

 Content-Encoding: aesgcm, aesgcm
 CE-params: aesgcm;key="csPJEXBYA5U-Tal9EdJi-w";
      salt="NfzOeuV5USPRA-n_9s1Lag",
                    aesgcm

...where the only difference is that any content coding that *can* have 
parameters MUST have an associated entry in CE-params.

Best regards, Julian

Received on Thursday, 13 October 2016 07:23:59 UTC