RE: Call for Adoption: Encrypted Content Encoding

Likewise on the non-normative text.  The draft shouldn't specify how the key to decrypt the content is obtained.  This is a building block for a larger solution which would have to describe how/where clients obtain keys securely and validate them -- this draft isn't something you'd implement stand-alone.  Pointing out that when you use this building block in a system, that's something you have to handle properly is a reasonable cautionary note to add.

-----Original Message-----
From: Eliot Lear [mailto:lear@cisco.com] 
Sent: Friday, December 4, 2015 5:01 AM
To: Cory Benfield <cory@lukasa.co.uk>; Poul-Henning Kamp <phk@phk.freebsd.dk>; Mike Bishop <Michael.Bishop@microsoft.com>; grahame@healthintersections.com.au
Cc: Mark Nottingham <mnot@mnot.net>; HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: Call for Adoption: Encrypted Content Encoding

Hi Cory,

On 12/4/15 11:53 AM, Cory Benfield wrote:
> (Replying to Poul-Henning, but this is a question for Mike and Grahame as well):
>
> Earlier in this thread I raised a concern I have about the way this draft accesses keys. In particular, it does not appear to specify any requirement that keys be tied to specific origins or in some way limited in scope: a conforming implementation would be able to have a single global registry of keys that can be used to decrypt content coming from anywhere.
>
> I believe this represents a security risk and should either be addressed in Section 6, or this draft should be accompanied by another that specifies key management in this case.

I'm not particularly certain of your specific concern, but I would suggest that at least some non-normative mention of key management would be a helpful addition.

Eliot

Received on Friday, 4 December 2015 18:51:47 UTC