Re: Encryption simplification

I'm not sure I understand - if symmetric keys are used:
1. They should not be sent along with the content
2. If they are for some reason, it doesn't make a difference if it's in
header or body
3. The server storing the encrypted content would need to have access
somehow to the key, if it is to be send to the user
4. If they do have access - it doesn't matter if they send it in a header
or prepend it to the body

IMHO it's very confusing to have examples of symmetric encryption where the
key is sent along -
sending a public key along with the message is fine. Not clear from the doc
is if the public-key case
 is no longer supported - but if that is the case, there would be no need
to send any key with
the message, so the Crypto-Key will not be needed ?

Again - I may miss something obvious here, is the value in the header just
a reference to a pre-shared
secret and not the actual secret ? But in this case - there is already the
id in the binary header.


Costin

On Mon, Oct 31, 2016 at 9:54 AM Kari Hurtta <hurtta-ietf@elmme-mailer.org>
wrote:

> Costin Manolache <costin@gmail.com>: (Mon Oct 31 08:13:02 2016)
> > 1. Why not add the Crypto-Key to the binary header ? If we have to deal
> > with binary encoding, we can at
> > least avoid parsing more text headers - and it doesn't have to be b64.
>
> This
>
> http://httpwg.org/http-extensions/encryption-preview.html#introduction
>
> | For example, it might be necessary to store a file on a server without
> exposing its contents
> | to that server. Furthermore, that same file could be replicated to other
> servers (to make it
> | more resistant to server or network failure), downloaded by clients (to
> make it available
> | offline), etc. without exposing its contents.
>
> does not mention it, but I think that there was hidden
> (for this draft) motivation where reponse headers was
> served from originin server via https (that include
> Crypto-Key) but actual payload is served from another
> server. That content-encryption provides encryption
> for that payload. Another Content-Encoding (Out-Of-Band)
> moves payload to other server.
>
>
> https://greenbytes.de/tech/webdav/draft-reschke-http-oob-encoding-08.html#rfc.section.3.5.3
>
> was mentioned.
>
> / Kari Hurtta
>
>