ace-wg / est-oscore

Other
0 stars 0 forks source link

Clarify the use of HTTP #59

Open malishav opened 3 months ago

malishav commented 3 months ago

Based on @EskoDijk 's review in https://mailarchive.ietf.org/arch/msg/ace/I70MHcCzSfPIy28lDqxEOcllgJw/:

Introduction

Paragraph 3 explains that EST can be carried over HTTP protected with OSCORE. This part could still be clarified: I initially thought the intention was to enable HTTP transport without needing CoAP at all i.e. in none of the communication legs. This interpretation then conflicts with many following parts of the document that only mention CoAP and not HTTP used by the client. For example, paragraph 5 mentions “… context, the CoAP exchange carrying … “ which then triggers the question whether this is really a CoAP exchange, or whether it can also be a HTTP exchange? Maybe the intention was to support only CoAP for the client side; which might be carried as HTTP for a particular network segment? (e.g. from proxy to EST server). Not sure how to resolve this; it depends on the intention of how HTTP is supposed to be used and this is not yet fully clear to me.

malishav commented 3 weeks ago

OLD:

This document describes a method for protecting EST payloads over CoAP or HTTP with OSCORE [[RFC8613]. OSCORE specifies an extension to CoAP which protects messages at the application layer and can be applied independently of how CoAP messages are transported. OSCORE can also be applied to CoAP-mappable HTTP which enables end-to-end security for mixed CoAP and HTTP transfer of application layer data. Hence EST payloads can be protected end-to-end independent of the underlying transport and through proxies translating between CoAP and HTTP.

NEW:

This document describes a method for protecting EST payloads over CoAP with OSCORE [RFC8613]. OSCORE specifies an extension to CoAP which protects messages at the application layer and can be applied independently of how CoAP messages are transported. OSCORE can also be applied to CoAP-mappable HTTP which enables end-to-end security for mixed CoAP and HTTP transfer of application layer data [Section 11 of RFC 8613]. Hence EST payloads can be protected end-to-end independent of the underlying transport and through proxies translating between CoAP and HTTP.