Closed thomas-fossati closed 2 years ago
If the third 'application/corim+cbor' is registered but nobody uses it, is that a problem? Is there a down side to registering it other than it uses up one of the values in the namespace?
BTW: I think the expression is slightly incorrect. Should be: 'application/corim+cbor' '#6.500 (#6.501 (corim-map))' or '#6.500 (#6.502 (#6.18 (COSE-Sign1-corim)))'
If the third
application/corim+cbor
is registered but nobody uses it, is that a problem?
no
Is there a down side to registering it other than it uses up one of the values in the namespace?
I don't think so
BTW: I think the expression is slightly incorrect. Should be: 'application/corim+cbor' '#6.500 (#6.501 (corim-map))' or '#6.500 (#6.502 (#6.18 (COSE-Sign1-corim)))'
It's correct, CDDL-wise :-)
Plus this (although we are not completely sure it is needed):
application/corim+cbor
<=>#6.500(#6.501(corim-map) / #6.502(#6.18(COSE-Sign1-corim)))
I think we should not register this because the underlying type is extensible and therefore the semantics may change in the future:
corim = #6.500($concise-reference-integrity-manifest-type-choice)
tagged-corim-map = #6.501(corim-map)
$concise-reference-integrity-manifest-type-choice /= tagged-corim-map
$concise-reference-integrity-manifest-type-choice /= #6.502(signed-corim)
Good point. Is it possible to create a file that contains '#6.500 (
Good point. Is it possible to create a file that contains '#6.500 ( )' ? If yes, then would it make sense to define a content type for that thing?
The problem is, before registering the type, IANA wants us to define well-defined semantics associated with that type. At present we could only say: "it's either a COSE Sign1 signed CoRIM, or a clear-text CoRIM, or something else that we don't yet know", which is not acceptable.
One interesting thing that came out in today's Veraison is the idea of exposing the CoRIM profile via a media type parameter in addition to the media type proper.
Where is media type parameters defined?
Where is media type parameters defined?
inline, as an optional bit. The complete grammar is:
type "/" [tree "."] subtype ["+" suffix]* [";" parameter]
So, in our case, it may be something like:
application/signed-corim+cbor; profile=psa
Has this been decided?
@thomas-fossati My question is in relation to our enact-demo: Should we use application/corim-unsigned+cbor or simply application/corim+cbor ?
Has this been decided?
@thomas-fossati My question is in relation to our enact-demo: Should we use application/corim-unsigned+cbor or simply application/corim+cbor ?
PR #171 added media types for unsigned. Check 'files changed' tab for exact changes.
We need to define the media types for transporting CoRIMs (both the signed version and the unprotected one).
application/corim-unsigned+cbor
<=>#6.501(corim-map)
application/corim-signed+cbor
<=>#6.502(#6.18(COSE-Sign1-corim))
Plus this (although we are not completely sure it is needed):application/corim+cbor
<=>#6.500(#6.501(corim-map) / #6.502(#6.18(COSE-Sign1-corim)))
The same, modulo typography, applies to XCoRIM.
We also need to have CoAP Content Formats aliases for the media types above.
Once that is done, we need to register those through IANA. For CoAP too.