[core] Media type for OSCORE in HTTP (Was: AD review of draft-ietf-core-object-security-08)

[Göran Selander <[e-mail]>]

All,

The AD review pointed at the omission of media type to use in the header
field Content-Type of an HTTP message carrying an OSCORE encrypted message.

>> If we decide to include a Content-Type header field, the main options
>>are:
>>
>> - reuse of "application/cose” defined in RFC 8152 (if appropriate)
>> - new media type e.g. “application/oscore” to be defined in this draft.
> Either of these work for me.


Does anyone have an strong opinion here (or deviating opinion about the
necessity of having this header field)?

BR
Göran 



On 2018-02-19 15:00, "Alexey Melnikov" <[e-mail]> wrote:

>
>>> 5) In Section 10.2: which media type is used for the OSCORE-encrypted
>>> payload transported in HTTP?
>>>
>> [GS] Good question, there are a few things to note here. First, the CoAP
>> option Content-Format is Inner so the CoAP payload media type is
>> encrypted. Second, the Outer Content-Format option is not present in
>> OSCORE protected CoAP messages (in the interest of saving message
>> overhead). Third, when CoAP-mappable HTTP is protected with OSCORE, the
>> message is first mapped to CoAP and then processed with OSCORE, so the
>> media type of the OSCORE encrypted payload is carried in the encrypted
>> Content-Format option also in the case of HTTP. However, we may still
>>want
>> to have a Content-Type header field in the HTTP message transporting the
>> OSCORE message. Was this what you were referring to?
>Yes. Applications or plugin frequently get invoked based on media types.
>So if you want to allow for decoding of OSCORE payloads in a plugin, you
>should define a media type.
>
>> According to RFC 7231
>> (https://tools.ietf.org/html/rfc7231#section-3.1.1.5):
>>
>> 'A sender that generates a message containing a payload body SHOULD
>>     generate a Content-Type header field in that message unless the
>>     intended media type of the enclosed representation is unknown to the
>>     sender.  If a Content-Type header field is not present, the
>>recipient
>>     MAY either assume a media type of "application/octet-stream”
>> ([RFC2046]) or examine the data to determine its type.'
>>
>>
>> While Content-Type is recommend, noting that in the case of OSCORE we
>>want
>> to encrypt the Content-Type for the other CoAP endpoint, so whatever
>>media
>> type we would potentially include in the “Outer” message would only be a
>> dummy.
>
>Yes, but it signals to applications that "this payload is
>OSCORE-encrypted".
>
>>   Furthermore, the destination endpoint would anyway first have to
>> process the OSCORE message to recreate the HTTP message before handing
>> over for HTTP processing.
>> As I read the text above it is possible to leave Content-Type out, but
>> would that be an issue in existing networks?
>I think unlabelled content is a bad form :-).
>>   Who would be able to give
>> some advice her?
>>
>> If we decide to include a Content-Type header field, the main options
>>are:
>>
>> - reuse of "application/cose” defined in RFC 8152 (if appropriate)
>> - new media type e.g. “application/oscore” to be defined in this draft.
>Either of these work for me.