Re: [COSE] Gap in registration of application/cwt?

Laurence Lundblade <lgl@island-resort.com> Fri, 14 August 2020 20:58 UTC

Return-Path: <lgl@island-resort.com>
X-Original-To: cose@ietfa.amsl.com
Delivered-To: cose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A74D3A0658 for <cose@ietfa.amsl.com>; Fri, 14 Aug 2020 13:58:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.884
X-Spam-Level:
X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVHi9MZmkJhb for <cose@ietfa.amsl.com>; Fri, 14 Aug 2020 13:58:47 -0700 (PDT)
Received: from p3plsmtpa08-05.prod.phx3.secureserver.net (p3plsmtpa08-05.prod.phx3.secureserver.net [173.201.193.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0BB23A08D1 for <cose@ietf.org>; Fri, 14 Aug 2020 13:58:45 -0700 (PDT)
Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 6gmikrwMSeip66gmjkFNJw; Fri, 14 Aug 2020 13:58:45 -0700
X-CMAE-Analysis: v=2.3 cv=b5LMHeOx c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=K6EGIJCdAAAA:8 a=VrHXGImtAAAA:8 a=48vgC7mUAAAA:8 a=PXcJJhn042mYNjhRpNEA:9 a=ooK1ZYYnHGwGP9pd:21 a=8S_NYmHccqdHhq-g:21 a=QEXdDO2ut3YA:10 a=ehQ0wd4UoleRMcFXBYsA:9 a=anr6qqSgD_S8I-ad:21 a=5s7gydGq379n2PzS:21 a=20_1RYVDE6hz34o0:21 a=_W_S_7VecoQA:10 a=L6pVIi0Kn1GYQfi8-iRI:22 a=rjybpTLx1R2UrS7S5igv:22 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: lgl@island-resort.com
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <66829A45-EDC1-4317-AA0A-FD335B6CF820@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A1CAA8C5-5E59-4B02-830E-4326A93A8EAF"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 14 Aug 2020 13:58:43 -0700
In-Reply-To: <D2ADF917-F69E-40E4-AA03-DFF6DB8BB9B3@island-resort.com>
Cc: Ace Wg <ace@ietf.org>, cose <cose@ietf.org>
To: Jim Schaad <ietf@augustcellars.com>
References: <D964158E-4895-4C75-A27F-0141D4EDCE5A@island-resort.com> <004201d66f79$3d95ed10$b8c1c730$@augustcellars.com> <D2ADF917-F69E-40E4-AA03-DFF6DB8BB9B3@island-resort.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfPCOW6soSC8d5JmY4vX4PHwXnZDR5VFHxrAdywRTaLWR5bO+Gd9+afHtO5ZFsGu2MJleX1qptlmpyiKE5fU5rN0smIRXD7tNqINCujdruwnPLvTGCTcc fFJCF19S8iFbhAmHVfVpswfxBwxqa38MbM+Owsu2VQB21yJv/AWsvfMimON2NzlmXl7AjEa3S0xvFyCHejAMwqRqnvPU/78NRfvmkK3Ke9/o8z1DsMeFkMZj
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/DLP_1ILcyuCKgIQgLPVY6yNNf-I>
Subject: Re: [COSE] Gap in registration of application/cwt?
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cose>, <mailto:cose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cose/>
List-Post: <mailto:cose@ietf.org>
List-Help: <mailto:cose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cose>, <mailto:cose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Aug 2020 20:58:54 -0000

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 <lgl@island-resort.com> wrote:
> 
> 
> 
>> On Aug 10, 2020, at 5:49 PM, Jim Schaad <ietf@augustcellars.com <mailto:ietf@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