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

[Jim Schaad]

 

 

From: Laurence Lundblade  
Sent: Thursday, August 27, 2020 1:06 PM
To: Jim Schaad 
Cc: Ace Wg ; cose 
Subject: Re: [Ace] [COSE] Gap in registration of application/cwt?

 

In a CBOR thread it became clear (to me anyway) that in the context of CBOR a 
“tag" is not a prefix, badge, identifier or such. It is the combination of the 
identifier and the content. In the CBOR context when you say “tag 1” or 
“epoch-based date tag” you mean the major type 6 and the number content.  The 
encoded CBOR for a tag 1 with value for Jan 1, 1970 would be 0xc1 0x00.

 

RFC 8392 uses the terminology incorrectly in section 5 
<https://tools.ietf.org/html/rfc8392#section-5> . It refers to the tag as a 
prefix. Maybe errata should be filed on this?

 

[JLS] I would be fine with you filing an errata to this effect.  It would get 
marked, probably, as editorial not technical but that should be fine.

 

Jim

 

 

 

Going back to the identification of a CWT and/or COSE, my understanding is that 
a “CWT” is a protocol message. A “CWT Tag” is a type 6 item value 61 and the 
CWT protocol message.  The definition of the CWT protocol message stands apart 
from the definition of tag 61. (This is not true of a tag 1 epoch date; the 
definition of the date is intwined with the definition of tag 1).

 

I believe the definition of the CWT protocol message allows the type of COSE 
used to secure it to be identified in many ways. You can do it with CBOR tags 
or you can do with externally such as my Application/CWT; cose-type=COSE_Sign1 
content type example.

 

Further, I think nesting of COSE works as follows. It doesn’t have to be 
identified with COSE tags. Several levels of COSE can be required by some top 
level media type or even by some CBOR tag that is not a COSE defined tag. For 
example, I could define application/very-secure-string as follows.

  - Start with string of bytes

  - Encrypt it with COSE_Encrypt (the string of bytes is the payload) (note 
that this is not COSE_Encrypt_Tagged)

  - Sign it COSE_Sign1 (the COSE_Encrypt is the payload) (note that this is not 
COSE_Sign1_Tagged

  - Mac it with COSE_Mac0 (the COSE_Sign1 is the payload) (note that this is 
not COSE_Mac0_Tagged)

 

I could make the payload at some level in this example some newly defined tag 
that requires a COSE_Sign1 with EdDSA and indicates something about its payload 
format.

 

LL

 

 

 

 





On Aug 15, 2020, at 11:42 AM, Jim Schaad mailto:i...@augustcellars.com> > wrote:

 

 

 

From: Laurence Lundblade mailto:l...@island-resort.com> > 
Sent: Saturday, August 15, 2020 10:58 AM
To: Jim Schaad mailto:i...@augustcellars.com> >
Cc: cose mailto:c...@ietf.org> >; Ace Wg mailto:ace@ietf.org> >
Subject: Re: [Ace] [COSE] Gap in registration of application/cwt?

 

 






On Aug 14, 2020, at 3:35 PM, Jim Schaad mailto:i...@augustcellars.com> > wrote:

 

 

 

From: Laurence Lundblade mailto:l...@island-resort.com> > 
Sent: Friday, August 14, 2020 1:59 PM
To: Jim Schaad mailto:i...@augustcellars.com> >
Cc: Ace Wg mailto:ace@ietf.org> >; cose mailto:c...@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?

[JLS] Yes this could be done in the future.   One would normally expect this to 
be an application specific profile, but funny things happen.

 

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.

[JLS] For deterministic encoding, but not  for general encoding.

 

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 paramet

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

[Laurence Lundblade]

In a CBOR thread it became clear (to me anyway) that in the context of CBOR a 
“tag" is not a prefix, badge, identifier or such. It is the combination of the 
identifier and the content. In the CBOR context when you say “tag 1” or 
“epoch-based date tag” you mean the major type 6 and the number content.  The 
encoded CBOR for a tag 1 with value for Jan 1, 1970 would be 0xc1 0x00.

RFC 8392 uses the terminology incorrectly in section 5 
<https://tools.ietf.org/html/rfc8392#section-5>. It refers to the tag as a 
prefix. Maybe errata should be filed on this?


Going back to the identification of a CWT and/or COSE, my understanding is that 
a “CWT” is a protocol message. A “CWT Tag” is a type 6 item value 61 and the 
CWT protocol message.  The definition of the CWT protocol message stands apart 
from the definition of tag 61. (This is not true of a tag 1 epoch date; the 
definition of the date is intwined with the definition of tag 1).

I believe the definition of the CWT protocol message allows the type of COSE 
used to secure it to be identified in many ways. You can do it with CBOR tags 
or you can do with externally such as my Application/CWT; cose-type=COSE_Sign1 
content type example.

Further, I think nesting of COSE works as follows. It doesn’t have to be 
identified with COSE tags. Several levels of COSE can be required by some top 
level media type or even by some CBOR tag that is not a COSE defined tag. For 
example, I could define application/very-secure-string as follows.
  - Start with string of bytes
  - Encrypt it with COSE_Encrypt (the string of bytes is the payload) (note 
that this is not COSE_Encrypt_Tagged)
  - Sign it COSE_Sign1 (the COSE_Encrypt is the payload) (note that this is not 
COSE_Sign1_Tagged
  - Mac it with COSE_Mac0 (the COSE_Sign1 is the payload) (note that this is 
not COSE_Mac0_Tagged)

I could make the payload at some level in this example some newly defined tag 
that requires a COSE_Sign1 with EdDSA and indicates something about its payload 
format.

LL





> On Aug 15, 2020, at 11:42 AM, Jim Schaad  wrote:
> 
>  
>  
> From: Laurence Lundblade  <mailto:l...@island-resort.com>> 
> Sent: Saturday, August 15, 2020 10:58 AM
> To: Jim Schaad mailto:i...@augustcellars.com>>
> Cc: cose mailto:c...@ietf.org>>; Ace Wg  <mailto:ace@ietf.org>>
> Subject: Re: [Ace] [COSE] Gap in registration of application/cwt?
>  
>  
> 
> 
>> On Aug 14, 2020, at 3:35 PM, Jim Schaad > <mailto:i...@augustcellars.com>> wrote:
>>  
>>  
>>  
>> From: Laurence Lundblade > <mailto:l...@island-resort.com>> 
>> Sent: Friday, August 14, 2020 1:59 PM
>> To: Jim Schaad mailto:i...@augustcellars.com>>
>> Cc: Ace Wg mailto:ace@ietf.org>>; cose > <mailto:c...@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?
> [JLS] Yes this could be done in the future.   One would normally expect this 
> to be an application specific profile, but funny things happen.
>>  
>> 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.
> [JLS] For deterministic encoding, but not  for general encoding.
>>  
>> 6) Application/CWT; cose-type=COSE_Sign1 (or Mac0 or …)
>> - No tags are used
>> 

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

[Jim Schaad]

 

 

From: Laurence Lundblade  
Sent: Saturday, August 15, 2020 10:58 AM
To: Jim Schaad 
Cc: cose ; Ace Wg 
Subject: Re: [Ace] [COSE] Gap in registration of application/cwt?

 

 





On Aug 14, 2020, at 3:35 PM, Jim Schaad mailto:i...@augustcellars.com> > wrote:

 

 

 

From: Laurence Lundblade mailto:l...@island-resort.com> > 
Sent: Friday, August 14, 2020 1:59 PM
To: Jim Schaad mailto:i...@augustcellars.com> >
Cc: Ace Wg mailto:ace@ietf.org> >; cose mailto:c...@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?

[JLS] Yes this could be done in the future.   One would normally expect this to 
be an application specific profile, but funny things happen.

 

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.

[JLS] For deterministic encoding, but not  for general encoding.

 

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?

[JLS] Yes I guess that is true.  I think my code is more generous that this in 
terms of what is accepted.

Jim

 

 

LL

 





 

Jim

 

 

LL

 

 

 

 






On Aug 11, 2020, at 12:20 PM, Laurence Lundblade mailto:l...@island-resort.com> > wrote:

 

 






On Aug 10, 2020, at 5:49 PM, Jim Schaad 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 determi

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

[Laurence Lundblade]

> On Aug 14, 2020, at 3:35 PM, Jim Schaad  wrote:
> 
>  
>  
> From: Laurence Lundblade  > 
> Sent: Friday, August 14, 2020 1:59 PM
> To: Jim Schaad mailto:i...@augustcellars.com>>
> Cc: Ace Wg mailto:ace@ietf.org>>; cose  >
> 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 > > wrote:
>>  
>>  
>> 
>> 
>>> On Aug 10, 2020, at 5:49 PM, Jim Schaad >> > 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 
>>>  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 
>>> 
>>>  and this thread 
>>> .
>>>  
>>> I summarized this behavior in this email 
>>>  
>>> 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 receive

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

[Jim Schaad]

 

 

From: Laurence Lundblade  
Sent: Friday, August 14, 2020 1:59 PM
To: Jim Schaad 
Cc: Ace Wg ; cose 
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

 

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.

 

5) Application/CWT identifies content as CWT

- Has CWT tag even though it is redundant 

- Has a COSE tag

[JLS] Yes

 

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.

 

Jim

 

 

LL

 

 

 

 





On Aug 11, 2020, at 12:20 PM, Laurence Lundblade mailto:l...@island-resort.com> > wrote:

 

 





On Aug 10, 2020, at 5:49 PM, Jim Schaad 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 
  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 

  and this thread 

 .

 

I summarized this behavior in this email 
  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 othe

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

[Laurence Lundblade]

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  
> wrote:
> 
> 
> 
>> On Aug 10, 2020, at 5:49 PM, Jim Schaad > > 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 
>  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 
> 
>  and this thread 
> .
> 
> I summarized this behavior in this email 
>  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 t

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

[Laurence Lundblade]

> On Aug 10, 2020, at 5:49 PM, Jim Schaad  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 
 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 

 and this thread 
.

I summarized this behavior in this email 
 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
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Jim Schaad]

 

 

From: COSE  On Behalf Of Laurence Lundblade
Sent: Monday, August 10, 2020 1:25 PM
To: Ace Wg ; cose 
Subject: [COSE] Gap in registration of application/cwt?

 

It doesn’t seem clear what the CBOR tagging requirements are when 
application/cwt is used to indicate a message is a CWT.

 

This is the text that I think it missing:

 

The CBOR CWT tag (61) must NOT be used. It is unnecessary because the media 
type already indicates it is a CWT.

 

The COSE type indicating tag MUST be present. It is necessary to determine 
whether what the COSE type is, whether it is COSE_Sign1, COSE_Mac0...

 

Another solution could be a MIME parameter added to the application/cwt 
indicating the COSE type.

 

[JLS] Yes that would have been an alternative that would work – However this 
option would require either that you use text content types for CoAP or you 
allocate N different integer content types one for each possible set of options 
that could be placed there.  The current solution is cleaner and smaller.

 

Step 3 in section 7.2 also seems wrong. It doesn’t make it an error for the 
COSE type tag to be absent when the CBOR CWT tag is present.

 

 

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.

 

Jim

 

 

LL

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace