MUST Add a 'content type' parameter to COSE_Sign1 object?

[EskoDijk]

See discussion on the list; some think an explicit 'content type' parameter is needed in the COSE_Sign1 object.

Logically this would then have value 60 (CBOR). (There is no cf number allocated for "Voucher in CBOR". And value TBD3 is not correct. ). This will add 3 bytes to the Voucher Request and Voucher sizes.

[EskoDijk]

Points from list dicussion:

• CF=60 alone is not useful enough because the object in a self-contained way needs to express that it represents a Voucher(Request). For this a new CF number would be needed "Voucher in CBOR".
• Some like to avoid a needless declaration of a new cf "Voucher in CBOR", as only the signed structure can be called a voucher. See RFC 8366 definition.
• The SID that is encoded in the CBOR also encodes the type as either "Voucher" or "Voucher Request" based on YANG/SID semantics. So there may not be a need anymore to indicate again this same information in the COSE 'content type' parameter.
  • more detailed security design point based on this: detecting SIDs assumes that it is safe for the receiver to start parsing the data as CBOR. In general, it would be safest to assume this only when the COSE payload 'content type' is marked as cf=60 (CBOR) and the COSE object is properly signed.
  • more detailed security point for previous: a receiver cannot verify that the object is properly signed if it doesn't know which key to use for validation. And the key-to-use is not mandatory to indicate within the COSE object. For example a MASA will look up the proper key based on a serial number that Registrar is passing to MASA and then verify a Pledge-VR.

[mcr]

I don't think we need additional things in the COSE_Sign1 level of things. We will be getting a TBD3, Content-Format allocated which the Pledge ought to be into the CoAP Accept (17) Option (on the request), and the Registrar ought to be putting into the CoAP Content-Format (12) option.

The Pledge POST operation should perhaps be marking the Content of the POSTed object. It may be that we need a TBD4 to designate voucher-request, but we did not do that in RFC8995. Perhaps that was a mistake.

Note that https://www.ietf.org/archive/id/draft-ietf-cbor-file-magic-03.html#name-cbor-tags-for-coap-content- means that if we have a Content-Format, then we also have a cbor-file-magic Tag number that we can use on disk. We may wish to specify if we recommend CBOR Seq or CBOR Tag mechanism.

[EskoDijk]

Regarding CBOR Tags, the CBOR data may start with a Tag 18 (COSE_Sign1) so this already tells a parser of the standalone Voucher object that it is a COSE-sign1-signed CBOR data. By design a COSE_Sign1 object includes CBOR data so including an additional CF=60 within the sign1 structure (first bullet in my prev comment) would be utterly useless - it's always CBOR.

In my view the additional inclusion of a CF=TBD4 in the sign1-object doesn't add much benefit in terms of security or context-less format representation, as the CBOR payload already encodes whether it is a voucher or voucher-request using the YANG/SID semantics. This is something a parser of the sign1 object could and should easily detect without risk.

If we use that Tag 18 (COSE_Sign1) as usual on the sign1 object, then I don't think we need a CBOR file magic tag.

[petervanderstok]

Usually, in other drafts, it is a choice to use a tag or a content format to announce what is transported. Limiting to a tag I have not seen examples of.