Drop top level tagging requirement #337

deeglaze · 2024-10-23T18:12:02Z

Tagged type choices are not typical.
I would go so far as to drop the 500 tag as the entrypoint to CoRIM altogether. NVIDIA is creating CoRIMs this way, but they are using a different content-type in the protected header. I think we can drop it in an follow-up.

This patch drops

the need to tag the type choice
the extensibility of concise-rim-type-choice, since extensibility is governed by a profile, and the profile is not known at this point in parsing.
the need to tag the signed corim, since it is a COSE-sign1 with an unambigiuous content-type, and COSE-sign1 already has its own tag.

Addresses Issue #333, but 500 removal is TBD.

Tagged type choices are not typical. I would go so far as to drop the 500 tag as the entrypoint to CoRIM altogether. NVIDIA is creating CoRIMs this way, but they are using a different content-type in the protected header. I think we can drop it in an follow-up. This patch drops * the need to tag the type choice * the extensibility of concise-rim-type-choice, since extensibility is governed by a profile, and the profile is not known at this point in parsing. * the need to tag the signed corim, since it is a COSE-sign1 with an unambigiuous content-type, and COSE-sign1 already has its own tag. Addresses Issue ietf-rats-wg#333, but 500 removal is TBD. Signed-off-by: Dionna Glaze <dionnaglaze@google.com>

Fixed PR so that it builds.

nedmsmith · 2024-10-23T18:53:43Z

This PR probably should have some examples that tests the new functionality.

The section "Concise Reference Integrity Manifest (CoRIM)" may need to be updated to describe the possibility for unsigned payloads.

deeglaze · 2024-10-25T03:54:18Z

Added a small change to the section about the specific #6.501 tag.

thomas-fossati · 2024-10-30T10:59:37Z

Note that this PR would allow four different tags (500, 501, 502, 18) instead of one (500) to represent a top-level CoRIM.

deeglaze · 2024-10-30T12:38:25Z

Note that this PR would allow four different tags (500, 501, 502, 18) instead of one (500) to represent a top-level CoRIM.

I think this is the pattern for CBOR though. There’s no single top level tag for COSE objects either.

500 and 502 are for theoretical encoding options that I don’t understand the justification for either.

thomas-fossati · 2024-10-30T12:54:16Z

Note that this PR would allow four different tags (500, 501, 502, 18) instead of one (500) to represent a top-level CoRIM.

I think this is the pattern for CBOR though. There’s no single top level tag for COSE objects either.

500 and 502 are for theoretical encoding options that I don’t understand the justification for either.

In fact, I'd drop 500 for sure, and may also be convinced to drop 502 if offered one or two pints of Guinness :-)

nedmsmith · 2024-10-30T13:45:07Z

Would the proposed solution allow both 500(signed-corim) and 502(signed-corim)? Would that be confusing?

corim = (tagged-concise-rim-type-choice / concise-rim-type-choice)
tagged-concise-rim-type-choice = #6.500(concise-rim-type-choice)
tagged-signed-corim = #6.502(signed-corim)
concise-rim-type-choice /= tagged-corim-map
concise-rim-type-choice /= tagged-signed-corim
concise-rim-type-choice /= signed-corim
tagged-corim-map = #6.501(corim-map)
tagged-signed-corim = #6.502(signed-corim)
signed-corim = #6.18(COSE-Sign1-corim)
COSE-Sign1-corim = [
  protected: bstr .cbor protected-corim-header-map
  unprotected: unprotected-corim-header-map
  payload: bstr .cbor (tagged-corim-map / corim-map)
  signature: bstr
]

If #6.500 is dropped then wouldn't corim be defined as:

corim = concise-rim-type-choice
concise-rim-type-choice /= #6.501(corim-map)
concise-rim-type-choice /= #6.502(signed-corim)

If 502 is used, then the cose payload would use corim-map instead of tagged-corim-map?

deeglaze · 2024-10-30T14:07:18Z

We can say 502 is for signing envelopes that don't have their own CBOR tag or need further disambiguation.

500 is generally a confusing representation choice, so I think we've lost that one..
I can be convinced to have the payload always be 501-tagged for simplicity, it'll just invalidate cocli-signed CoRIMs. That's fine.

thomas-fossati · 2024-10-30T14:25:21Z

We can say 502 is for signing envelopes that don't have their own CBOR tag or need further disambiguation.

500 is generally a confusing representation choice, so I think we've lost that one.. I can be convinced to have the payload always be 501-tagged for simplicity, it'll just invalidate cocli-signed CoRIMs. That's fine.

The easiest, and most consistent, would be to always require 501 (even when found in 502) and 502.

deeglaze · 2024-10-30T14:53:07Z

Am I to understand that the MUST language in sec-corim-signed is not intended, and 502 is an anything-goes tag so long as the protected payload is a 501-tagged CBOR-encoded corim-map?

thomas-fossati · 2024-10-30T15:02:07Z

Am I to understand that the MUST language in sec-corim-signed is not intended,

Which MUST-language are you referring to?

and 502 is an anything-goes tag so long as the protected payload is a 501-tagged CBOR-encoded corim-map?

Not sure, but at the moment we seem to have an inconsistency between CDDL and prose. In S4.2 we say: "payload: A CBOR encoded tagged CoRIM.", whilst the CDDL allows a "naked" corim-map alongside the tagged one. Besides, "CoRIM" should be "corim-map".

yogeshbdeshpande · 2024-10-30T15:43:25Z

It was concluded in CoRIM Meeting 30th october to drop tag for #6.500 and propose the same change in TCG.

Also remove type extensibility from top level $concise-rim-type-choice, i.e. make it
only: concise-rim-type-choice

deeglaze · 2024-11-20T15:28:50Z

We should return to this when the DICE errata has been accepted to remove the top level tags as well.

deeglaze · 2024-12-18T15:21:12Z

cddl/cbor-tags.txt

 tagged-corim-map = #6.501(corim-map)
-tagged-signed-corim = #6.502(signed-corim)
+tagged-signed-corim = #6.502($signed-corim)


I think we've agreed to drop the extensibility of the signing format.

deeglaze · 2024-12-18T15:27:03Z

draft-ietf-rats-corim.md

@@ -259,7 +259,7 @@ For more detail, see {{sec-corim-profile-types}}.

 A CoRIM can be signed ({{sec-corim-signed}}) using COSE Sign1 to provide end-to-end security to the CoRIM contents.
 When CoRIM is signed, the protected header carries further identifying information about the CoRIM signer.
-Alternatively, CoRIM can be encoded as a CBOR-tagged payload ({{sec-corim-map}}) and transported over a secure channel.
+Alternatively, CoRIM can be encoded as a #6.501 CBOR-tagged payload ({{sec-corim-map}}) and transported over a secure channel.


TODO: Drop 500, 502, deprecate 501 but allow it for the TCG spec conformance.

We change the IANA request to have a single content type, application/rim+cbor.

TODO: Drop 500, 502, deprecate 501 but allow it for the TCG spec conformance.

We change the IANA request to have a single content type, application/rim+cbor.

IIUC, the gist of the proposed way forward is:

media type CBOR tag data item

application/rim+cbor 501 tagged-corim-map

application/rim+cbor 18 signed-corim

This looks asymmetrical because in the case of 18, absent a media type indication from the transport/wrapping channel, the parser needs to unpack the potential signed-corim, unpack the protected header, fetch the content-type element value, and make sure it's application/rim+cbor.

I suggest instead (as I did in #337 (comment)) to keep both 501 and 502.

The media type for signed-corim would be application/cose. The unprotected header for the payload's media type would be application/rim+cbor.

Update

media type CBOR tag data item

application/rim+cbor 501 tagged-corim-map

application/rim+cose 18 signed-corim

Also

The content type (key=3) in the protected-corim-header-map is application/rim+cbor

The .corim extension is registered for both rim+cbor and rim+cose

Tagged type choices are not typical. I would go so far as to drop the 500 tag as the entrypoint to CoRIM altogether. NVIDIA is creating CoRIMs this way, but they are using a different content-type in the protected header. I think we can drop it in an follow-up. This patch drops the need to tag the type choice the extensibility of concise-rim-type-choice, since extensibility is governed by a profile, and the profile is not known at this point in parsing. the need to tag the signed corim, since it is a COSE-sign1 with an unambigiuous content-type, and COSE-sign1 already has its own tag. Addresses Issue ietf-rats-wg#333, but 500 removal is TBD.

deeglaze · 2024-12-18T20:02:48Z

Discussed in our meeting that we're going with 1 content type and dropping 500 and 502.

CI doesn't have envsubst or openssl tools.

nedmsmith

I basically approve but need to resolve thread related to which media type string to request.

deeglaze · 2025-01-17T17:20:38Z

I'm guessing we're delaying merging due to dropping 502, so I'm opening a dialogue with IANA MIME types and RFC9052 to consider adding content-type as an optional parameter for application/cose.

deeglaze · 2025-01-21T16:08:44Z

Discussed in the thread that application/rim+cose with CoRE C-F registration and without the 502 tag in the CoRIM representation is the most viable path forward.

Tagged type choices are not typical. I would go so far as to drop the 500 tag as the entrypoint to CoRIM altogether. NVIDIA is creating CoRIMs this way, but they are using a different content-type in the protected header. I think we can drop it in an follow-up. This patch drops the need to tag the type choice the extensibility of concise-rim-type-choice, since extensibility is governed by a profile, and the profile is not known at this point in parsing. the need to tag the signed corim, since it is a COSE-sign1 with an unambigiuous content-type, and COSE-sign1 already has its own tag. Addresses Issue ietf-rats-wg#333, but 500 removal is TBD.

CI doesn't have envsubst or openssl tools.

fix broken section reference

draft-ietf-rats-corim.md

cddl/examples/payload-corim-4.diag

thomas-fossati

LGTM, apart from a couple of editorial fixes.

draft-ietf-rats-corim.md

Co-authored-by: Thomas Fossati <tho.ietf@gmail.com>

draft-ietf-rats-corim.md

Co-authored-by: Thomas Fossati <tho.ietf@gmail.com>

yogeshbdeshpande

LGTM!

Co-authored-by: Andrew Draper <andrew.draper@altera.com>

Co-authored-by: Dionna Amalie Glaze <drdeeglaze@gmail.com>

thomas-fossati

LGTM, thanks!

deeglaze requested review from yogeshbdeshpande, nedmsmith and henkbirkholz October 23, 2024 18:12

Update corim.cddl

630b205

Fixed PR so that it builds.

deeglaze force-pushed the topleveltag branch 2 times, most recently from 00f2fe3 to 74cd2da Compare October 25, 2024 03:36

deeglaze requested a review from thomas-fossati as a code owner October 25, 2024 03:36

deeglaze force-pushed the topleveltag branch from 74cd2da to b450f6d Compare October 25, 2024 03:53

deeglaze force-pushed the topleveltag branch from b450f6d to f0c91e5 Compare October 25, 2024 04:07

deeglaze commented Dec 18, 2024

View reviewed changes

deeglaze added 3 commits December 18, 2024 19:29

Fix CoRIM examples with CDDL changes.

d401fbf

Create signed example in Makefile.

ae65445

deeglaze force-pushed the topleveltag branch from 7f35ed6 to ae65445 Compare December 18, 2024 20:02

Remove signing from Makefile

e11242b

CI doesn't have envsubst or openssl tools.

nedmsmith approved these changes Jan 7, 2025

View reviewed changes

deeglaze added 5 commits January 21, 2025 16:08

Fix CoRIM examples with CDDL changes.

2f9134d

Create signed example in Makefile.

f1c8825

Remove signing from Makefile

c32e13d

CI doesn't have envsubst or openssl tools.

Add rim+cose with CoAP registration and magic numbers

20c5222

deeglaze force-pushed the topleveltag branch from 67aaaa4 to 20c5222 Compare January 21, 2025 17:09

nedmsmith added 2 commits January 21, 2025 13:58

merged conflicts

ad14823

Update draft-ietf-rats-corim.md

28b18d6

fix broken section reference

thomas-fossati reviewed Jan 22, 2025

View reviewed changes