Here’s a series of scenarios that I think are legal CWT. These are allowed by RFC 8392, right?
1) Explicitly tagged, no external type info needed - Has CWT tag - Has COSE type tag 2) CWT identification by label, COSE type tagged - The CWT is a CBOR data item with a label. The definition of the label says the contents of the label are always CWT - No CWT tag necessary as it is implied by the label - Has a COSE type tag 3) CWT and COSE by label - The CWT is an item with a label. The definition of the label says the contents of the label are always CWT and of a specific COSE type - No tags necessary 4) Application/CWT identifies content as CWT, tagging for COSE type - No CWT tag - Has a COSE tag 5) Application/CWT identifies content as CWT - Has CWT tag even though it is redundant - Has a COSE tag 6) Application/CWT; cose-type=COSE_Sign1 (or Mac0 or …) - No tags are used - Identification is completely by the MIME type header - (I understand that the cose-type MIME parameter is not defined, but it could be. 8392 doesn’t forbid it) 7) A protocol like FIDO identifies a protocol element that is an attention type the type of which is CWT with COSE_Sign1 - No tags are used 8) A protocol like FIDO identifies a protocol element that is an attention type the type of which is CWT; the COSE type is determined by tag - No CWT tag - Has a COSE tag The one thing you can’t do is have a CWT tag without a COSE type tag. 8392 section 6 forbids this. LL > On Aug 11, 2020, at 12:20 PM, Laurence Lundblade <[email protected]> > wrote: > > > >> On Aug 10, 2020, at 5:49 PM, Jim Schaad <[email protected] >> <mailto:[email protected]>> wrote: >> >> This is all based on my understanding that the surrounding protocol for must >> specify exactly when CBOR tags are to be used and when they are not to be >> used and that the surrounding protocol must not leave it as an optional >> implementation choice. In this case application/cwt is the supporting >> protocol. >> >> [JLS] What is the text that says that this is true. This would be a >> surprising statement for me. > > Here’s three things that lead me to this. > > CBORbis > The sentence of the first paragraph in 4.2.2 > <https://tools.ietf.org/html/draft-ietf-cbor-7049bis-14#section-4.2.2> very > clearly states this, though this is only for deterministic encoding. > > Typical CDDL > Most CDDL that describes tagged data describes it only as tagged or untagged, > not as optionally tagged. COSE is one example of this. > > Email threads > This thread > <https://mailarchive.ietf.org/arch/browse/cbor/?gbt=1&index=Hz7VjeBab9DxPas9E5_KfOmZwN0> > and this thread > <https://mailarchive.ietf.org/arch/browse/cbor/?gbt=1&index=y1EZ-IylFpJ3_MndQGADSbKhx0s>. > > I summarized this behavior in this email > <https://mailarchive.ietf.org/arch/msg/cbor/Hz7VjeBab9DxPas9E5_KfOmZwN0/> and > no where in the rest of the thread was it indicated differently. > > So, it is not a hard requirement because 4.2.2 is only for deterministic > encoding, but seems like a “should" in spirit. It is the preferred way to > design a CBOR protocol. > > However you slice it, I think it is up to the surrounding protocol to say > whether a tag is always required, never required or optionally required. If > the protocol doesn’t say, then it defaults to optionally required. > > Defaulting or explicitly allowing optional tagging means the receiver has to > allow for all the tagging scenarios and makes possible the error case where > the surrounding protocol says the data is of one type and the tag conflicts > with it. (e.g. an application/cwt that contains a tagged CoSWID). > > I don’t think optional tagging is of any advantage in a protocol design. It > doesn’t enable anything. > > It has some disadvantage because it introduces error conditions and potential > confusion. > > I think there are several scenarios with section 6 and application/cwt that > could be more clear. > > Can you use tag 61 or not? I think the current answer is that in > application/cwt, tag 61 is optional. > > How do you know what the COSE type is? It is somewhat obvious that COSE tags > will work, but there is no requirement to use them. A MIME parameter or other > is entirely allowed here. > > Section 6 does say that determination that something is a CWT is application > dependent, but doesn’t say that the COSE type is also application dependent. > Section 7 does address this. > > Said another way, my fully general CWT decoder that is called by some > application needs an input parameter to indicate the COSE type because there > is no requirement in 8392 that a CWT indicate which COSE type is in use. > Sometimes the caller will be able to provide the COSE type and sometimes they > won’t. Sometimes there will be an error of conflicting COSE type and > sometimes the error will be that the COSE type can’t be determined. > > I think it would have been cleanest if CWT always indicated the COSE type be > used and the tagging optionality didn’t span two protocol layers, but that > would be an incompatible change. Maybe a recommendation that CWT’s SHOULD > always indicate their COSE type? > > LL
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
