RE: Call for Adoption: Encrypted Content Encoding

I suppose that the very top of the security considerations section wasn't
obvious enough for folks:
https://martinthomson.github.io/http-encryption/#rfc.section.6 :)
On Dec 5, 2015 5:56 AM, "Mike Bishop" <Michael.Bishop@microsoft.com> wrote:

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