Re: Call for Adoption: Encrypted Content Encoding

shouln't you then think about the REQUIREMENTS before and then thinking 
of this draft;

you wouldn't build the roof of a building first, would you?

I'd say that it is a MUST to ensure, that the keys won't be retrieved 
without the knowledge of the user and only with user's permission;
else this will become a security desaster;

take it serious and help to make internet smarter;

Thanks


On 04.12.2015 19:46, Mike Bishop 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
>
I'd say this is a REQUIREMENT not just something non-normative;