Drop top level tagging requirement #337
Conversation
|
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
force-pushed
the
topleveltag
branch
2 times, most recently
from
00f2fe3 to
74cd2da
Compare
|
Added a small change to the section about the specific #6.501 tag. |
|
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 :-) |
|
Would the proposed solution allow both If #6.500 is dropped then wouldn't corim be defined as: If 502 is used, then the cose payload would use |
|
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.. |
The easiest, and most consistent, would be to always require 501 (even when found in 502) and 502. |
|
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? |
Which MUST-language are you referring to?
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" |
|
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 |
|
We should return to this when the DICE errata has been accepted to remove the top level tags as well. |
cddl/cbor-tags.txt
Outdated
| tagged-corim-map = #6.501(corim-map) | ||
| tagged-signed-corim = #6.502(signed-corim) | ||
| tagged-signed-corim = #6.502($signed-corim) |
There was a problem hiding this comment.
I think we've agreed to drop the extensibility of the signing format.
| @@ -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. | |||
There was a problem hiding this comment.
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.
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
force-pushed
the
topleveltag
branch
from
7f35ed6 to
ae65445
Compare
|
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 @henkbirkholz @thomas-fossati @yogeshbdeshpande @andrew-draper please take a look. |
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
Addresses Issue #333, but 500 removal is TBD.