> On Aug 14, 2020, at 3:35 PM, Jim Schaad <i...@augustcellars.com> wrote: > > > > From: Laurence Lundblade <l...@island-resort.com > <mailto:l...@island-resort.com>> > Sent: Friday, August 14, 2020 1:59 PM > To: Jim Schaad <i...@augustcellars.com <mailto:i...@augustcellars.com>> > Cc: Ace Wg <a...@ietf.org <mailto:a...@ietf.org>>; cose <cose@ietf.org > <mailto:cose@ietf.org>> > Subject: Re: [COSE] Gap in registration of application/cwt? > > 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 > [JLS] Yes > > 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 > [JLS] Yes, the label could be internal to the CBOR object or external such as > an media-type
I was being very specific with the term label, meaning a label/key identifying an item in a CBOR map. > > 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 > [JLS] Yes that would be fine > > 4) Application/CWT identifies content as CWT, tagging for COSE type > - No CWT tag > - Has a COSE tag > [JLS] This is the same as 2? I don’t think that it would be restricted to > just that media type. You mean there could be other media types that also identify the content as CWT? > > 5) Application/CWT identifies content as CWT > - Has CWT tag even though it is redundant > - Has a COSE tag > [JLS] Yes Additionally, one might interpret CBORbis 4.2.2 to say the the CWT tag should not be present. > > 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) > [JLS] Yes you could do that, and as I stated in a previous mail this is not a > good idea for the CoAP world. > > 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 > [JLS] yes > > 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 > [JLS] yes > > The one thing you can’t do is have a CWT tag without a COSE type tag. 8392 > section 6 forbids this. > > [JLS] There however is a set of nested cases that you might need to look at. > That is 6.CWT ( COSE_Encrypt_Tagged ( COSE_Sign )) You would also need to > think about the requirements for nested COSE layers. All but the most outer COSE type are always identified by a tag, per 7.1 step 5 and 7.2 step 6, right? LL > > Jim > > > LL > > > > > > >> On Aug 11, 2020, at 12:20 PM, Laurence Lundblade <l...@island-resort.com >> <mailto:l...@island-resort.com>> wrote: >> >> >> >> >>> On Aug 10, 2020, at 5:49 PM, Jim Schaad <i...@augustcellars.com >>> <mailto:i...@augustcellars.com>> 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 > a...@ietf.org <mailto:a...@ietf.org> > https://www.ietf.org/mailman/listinfo/ace > <https://www.ietf.org/mailman/listinfo/ace>
_______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose
