Subject: [Anima] draft-ietf-anima-constrained-voucher COSE confusion

From: Toerless Eckert <[email-masked]>
Date: Tue, 20 Jul 2021 21:39:11 +0200

Wrt to the discussion today at he Hackathon, i am trying to figure out
how the header hierarchy for constrained voucher would work:

We use a CoAP session.
As a payload of CoAP, we indicate a COSE message, so
somewhere in a CoAP header we have a (hopefully ?) binary field for
the message type, and the value would be the TBD value to be assigned
for cose vouchers in https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#content-formats

e.g.:

application/voucher-cose+cbor ID=TBD3

Is that a correct understanding how CoAP would work ?

Now, there is in the COSE header also a parameter paramaeter called
"content type", and if i read RFC8152 correctly, that field SHOULD
be present and i guess also have the value TBD3, so there is
some duplication here. I am not so much worried about this,

i just don't understand RFC8152 text "Applications SHOULD provide this header
parameter if the content structure is potentially ambiguous", and i
wonder if/how that could ever be the case. I can only imagine his
would be the case if we would not use TBD3 in CoAP for the COSE
message, but instead "18" to indicate only application/cose; cose-type="cose-sign1" ID=18.

Cheers
    Toerless

---

From: Esko Dijk <[email-masked]>
Date: Wed, 21 Jul 2021 07:58:58 +0000

Hi Toerless,

> Is that a correct understanding how CoAP would work ?

Agree, the content-format is stored as a single var-length uint in a CoAP Option  (not part of the fixed header but one of the optional elements).

> Now, there is in the COSE header also a parameter paramaeter called "content type"

In my implementation I don't use the 'content type' header in COSE because it is duplicate. The type is given at CoAP level already so there is no ambiguity, so the "SHOULD" in RFC 8152 doesn't apply.
We may mention in the draft not to use this 'content type' for live-generated vouchers and voucher-requests.  If the object is created to be transported over other ways (e.g. email, USB stick, etc) then I would opt for including that 'content type' possibly. Although the filename (*.vch) in that case will indicate the exact media type.

> ... would be the case if we would not use TBD3 in CoAP for the COSE
> message, but instead "18" to indicate only application/cose; cose-type="cose-sign1" ID=18

Correct, then there might be ambiguity w.r.t. other / future Voucher and Voucher Request formats that may be transported between Pledge and Registrar in operations on the *same* resource (e.g. /rv).  But as long as such formats aren't defined it will also work in practice.
For example my servers should also accept content-format 18 just as TBD3. 
So all in all I would say leaving out the 'content type' parameter always will just work and it will only be needed once a new content type is defined that also uses COSE_Sign1 encoding and that new type is used on BRSKI resources like /rv.

Esko

-----Original Message-----
From: Toerless Eckert <[email-masked]> 
Sent: Tuesday, July 20, 2021 21:39
To: [email-masked]; Carsten Bormann <[email-masked]>
Cc: [email-masked]
Subject: draft-ietf-anima-constrained-voucher COSE confusion

We use a CoAP session.

e.g.:

Cheers
    Toerless

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 21 Jul 2021 14:04:18 +0200

On 2021-07-21, at 09:58, Esko Dijk <[email-masked]> wrote:
> 
> If the object is created to be transported over other ways (e.g. email, USB stick, etc) then I would opt for including that 'content type' possibly.

Probably not needed:

https://www.ietf.org/archive/id/draft-ietf-cbor-file-magic-02.html#name-cbor-tags-for-coap-content-f

So once you have a content-format number, you can use file-magic and that pre-registered tag to package the voucher in a file(1) compatible wrapper.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 21 Jul 2021 14:42:34 +0200

Or you can go the other way around, go for tag 18, put a content-format number that you registered (along a media-type) for an *unprotected* voucher (payload) into the protected header.  (You might still want a content-format number/media type for the entire voucher, but you may not need a tag.)

Grüße, Carsten

> On 2021-07-21, at 14:04, Carsten Bormann <[email-masked]> wrote:
>

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 21 Jul 2021 18:27:31 +0200

Thanks, Esko

I find it architecturally somewhat weird to have this "level skip":
Normally, if you have a container format, that container format itself
would have to indicate the type of its components, and you would not 
need to or want to expose the type of any component outside of the container.

I guess COSE and its registries were designed this way because the fact that 
applications may want to know about the payload type even before wanting
to bother about its signature. I can not quite build an example workflow though
to prove that need.

Personally, i would prefer to mandate the content-format even if
duplicate, just for any type of diagnostics that may not have access to
the whole stack into which the COSE object is embedded. Unless of course size-concerns
significantly outweigh potential diagnostic benefits.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 21 Jul 2021 18:49:56 +0200

On 2021-07-21, at 18:27, Toerless Eckert <[email-masked]> wrote:
> 
> I find it architecturally somewhat weird to have this "level skip”:

Depending on the key and its usage, you may want to include the context in the signing input that this is a voucher.  So that would support Toerless’ unease.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Wed, 21 Jul 2021 20:38:39 -0400

Esko Dijk <[email-masked]> wrote:
    > Agree, the content-format is stored as a single var-length uint in a
    > CoAP Option  (not part of the fixed header but one of the optional
    > elements).

    > In my implementation I don't use the 'content type' header in COSE
    > because it is duplicate. The type is given at CoAP level already so
    > there is no ambiguity, so the "SHOULD" in RFC 8152 doesn't apply.

Agreed.
Also, we use CORE-SID encoding, which means that we essentially start off
with a SID value that is unique to voucher (or voucher-request).

Combined with the Content-format (which replaces the MIME-Type info in CoAP),
it's pretty clear what we have.

    > We may mention in the draft not to use this 'content type' for
    > live-generated vouchers and voucher-requests.  If the object is created
    > to be transported over other ways (e.g. email, USB stick, etc) then I
    > would opt for including that 'content type' possibly. Although the
    > filename (*.vch) in that case will indicate the exact media type.

Yes!

    > For example my servers should also accept content-format 18 just as TBD3.

Esko, do you think the draft needs to include this option?
I prefer not to include.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Michael Richardson <[email-masked]>
Date: Wed, 21 Jul 2021 20:43:50 -0400

> need to or want to expose the type of any component outside of the

I find the eContentType business in SMIME insecure.

It presuposes that there are very generic CMS decryption system in the OS
which will be handing the inner contents to some OS-generic thing for
display.  But, in actual email use of SMIME, we actually have an inner
Mime-Type there already. And I think, in almost all other cases, we wouldn't
want to use a generic CMS decryption thing.

So, I don't think of the COSE as a separate layer. It's not.
The thing is a voucher, and vouchers are signed artifacts.  Like protons.

They contain YANG-serialized CBOR inside (like quarks)
This stuff inside doesn't have an existence: you never get to mess with the
quarks without knowing how they are contained.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 22 Jul 2021 02:47:33 +0200

> In my implementation I don't use the 'content type' header in COSE because it is duplicate.

It is not: the REST-level (here CoAP) Content-Type is the media-type of the whole thing (as packaged in COSE-Sign1), while the COSE content-type is just the media-type of the payload.
Except in somewhat unlikely cases, these are not the same.

> For example my servers should also accept content-format 18 just as TBD3.

No, no, no…  You just created busywork for interoperability testing.
Please decide for one option here and stick with that!

Grüße, Carsten

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 22 Jul 2021 08:06:21 +0200

> Except in somewhat unlikely cases, these are not the same.

Argh! (as in: why was this not obvious to me until you said so...)

So: if we wanted to support the COSE content-type field semantically correctly,
we should ask for another registry entry:

application/voucher-cbor  TBD4

I can not find a single example with content type in https://github.com/cose-wg/Examples

crazy..

Cheers
    Toerless

---

From: Esko Dijk <[email-masked]>
Date: Thu, 22 Jul 2021 08:23:11 +0000

> It is not: the REST-level (here CoAP) Content-Type is the media-type of the whole thing
Thanks, I overlooked this aspect. That implies that the parameter should, instead of 'TBD3' what I thought, describe 'voucher in cbor' for which there is no CoAP cf defined. I assume that the number would then fallback to CBOR cf=60, which is true (it is 'plain CBOR' even though a specific thing - voucher request - is encoded in that CBOR).
I don't see much benefit in including a COSE parameter 'content type = 60' into the COSE container to be frank.  A Registrar will anyhow try to decode the payload as CBOR and if that fails, it returns 4.00.

From RFC 8152  and draft-8152-bis I don't see that 'content type' is a mandatory header parameter. The SHOULD requirement for it doesn't apply to our case. (And probably this SHOULD requirement is too vague, if it ought to apply to our case.)
Maybe draft-8152-bis text could be updated if me and Michael understand it wrongly?  Toerless was also in favor of including the parameter in our case.

> No, no, no…  You just created busywork for interoperability testing.
The idea was not to test additional payload formats (like 18); I just do this to let the server be liberal in what it accepts. Technically a cf=18 is not wrong here. But agree we don't want to specify any additional format options.
You're right that for current interop testing, to find the bugs, it is better to *not* be too liberal.   Further reasons were that TBD3 was not yet defined during the testing past years; and that I have some legacy Pledges that use cf=18 still.

Esko

-----Original Message-----
From: Carsten Bormann <[email-masked]> 
Sent: Thursday, July 22, 2021 02:48
To: Esko Dijk <[email-masked]>
Cc: Toerless Eckert <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Anima] draft-ietf-anima-constrained-voucher COSE confusion

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 22 Jul 2021 10:39:28 +0200

On 2021-07-22, at 10:23, Esko Dijk <[email-masked]> wrote:
> 
> be liberal in what it accepts

Well, Postel’s principle doesn’t apply to wanton extension of the protocol (~ somebody might decide to do something different from the standard, so I’ll implement my idea of what that could be).  If it says you need to have X, allowing Y just to get clients to rely on that and make life harder for other server implementations is also known as a common standards-busting strategy…
(Not accusing you of this, just trying to explain my strong reaction.)

[1]: https://datatracker.ietf.org/doc/draft-iab-protocol-maintenance/

The reason I was bringing up the benefits of identifying the payload as a voucher is that it would serve to fulfill number one of the Abadi-Needham principles: context-free messages ("Explicit communication" [2]).

Grüße, Carsten

[2] M. Abadi and R. Needham. Prudent Engineering Practice for Cryptographic Protocols. In 1994 IEEE Computer Society Symposium on Research in Security and Privacy, pages 122–136. IEEE Computer Society, May 1994. DOI 10.1109/RISP.1994.296587.

Principle 1
Every message should say what it means:
the interpretation of the message should depend only on its content.
It should be possible to write down a straightforward English
sentence describing the content-though if there is a suitable 
formalism available that is good too.

[Note that “describing” here is semantic, a CDDL description is good too, but just structural.]

---

From: Peter van der Stok <[email-masked]>
Date: Thu, 22 Jul 2021 10:44:34 +0200

Hi,

To add my few words,

I am a proponent to explicitly state that the payload is a voucher and 
its signature production.
Actually, my code decides what routines to invoke on the basis of that 
information.

Peter
Carsten Bormann schreef op 2021-07-22 10:39:

> Well, Postel's principle doesn't apply to wanton extension of the 
> protocol (~ somebody might decide to do something different from the 
> standard, so I'll implement my idea of what that could be).  If it says 
> you need to have X, allowing Y just to get clients to rely on that and 
> make life harder for other server implementations is also known as a 
> common standards-busting strategy…
> The reason I was bringing up the benefits of identifying the payload as 
> a voucher is that it would serve to fulfill number one of the 
> Abadi-Needham principles: context-free messages ("Explicit 
> communication" [2]).
> 
> Grüße, Carsten
> 
> [2] M. Abadi and R. Needham. Prudent Engineering Practice for 
> Cryptographic Protocols. In 1994 IEEE Computer Society Symposium on 
> Research in Security and Privacy, pages 122-136. IEEE Computer Society, 
> May 1994. DOI 10.1109/RISP.1994.296587.
> 
> Principle 1
> [Note that "describing" here is semantic, a CDDL description is good 
> too, but just structural.]

---

From: Esko Dijk <[email-masked]>
Date: Thu, 22 Jul 2021 12:06:43 +0000

> Well, Postel’s principle doesn’t apply to wanton extension of the protocol (~ somebody might decide to do something different from the standard, so I’ll implement my idea of what that could be).  
> If it says you need to have X, allowing Y just to get clients to rely on that and make life harder for other server implementations is also known as a common standards-busting strategy…

Yes I read the IETF specs and then implement my idea of what these are trying to say.  It helps if more people are looking at it, as we do in this case :)  to avoid interpretation errors.
From what I read, a COSE_Sign1 object can be adequately described by cf=18 so that's what I implemented. There seems to be nothing wrong with that, except that draft-constrained-voucher says to use TBD3 for the case that this object is a Voucher/VR. So to be compliant to the draft I can remove support for cf=18 as soon as TBD3 is allocated. I still don't see how cf=18 could be 'wanton extension of the protocol' as it is just using CoAP/COSE defined mechanisms that apparently are overruled by draft-constrained-voucher.

> The reason I was bringing up the benefits of identifying the payload as a voucher is that it would serve to fulfill number one of the Abadi-Needham principles: context-free messages ("Explicit comm…
In this perspective and considering security it would be good if the COSE structure would have the 'content type' parameter inside set to 60 (CBOR). This way the server would never fall into the trap to parse a valid VR with non-CBOR payload as a CBOR payload (which in a rare case might trigger some bug/overflow and compromise security).

Esko

-----Original Message-----
From: Carsten Bormann <[email-masked]> 
Sent: Thursday, July 22, 2021 10:39
To: Esko Dijk <[email-masked]>
Cc: [email-masked]; Toerless Eckert <[email-masked]>; [email-masked]
Subject: Re: [Anima] draft-ietf-anima-constrained-voucher COSE confusion

Grüße, Carsten

Principle 1

---

From: Esko Dijk <[email-masked]>
Date: Thu, 22 Jul 2021 12:11:15 +0000

PS created issue https://github.com/anima-wg/constrained-voucher/issues/143 to add the COSE 'content type' header parameter requirement to the draft. (Authors still need to discuss it)

-----Original Message-----
From: Carsten Bormann <[email-masked]> 
Sent: Thursday, July 22, 2021 10:39
To: Esko Dijk <[email-masked]>
Cc: [email-masked]; Toerless Eckert <[email-masked]>; [email-masked]
Subject: Re: [Anima] draft-ietf-anima-constrained-voucher COSE confusion

Grüße, Carsten

Principle 1

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 22 Jul 2021 15:04:17 +0200

> From what I read, a COSE_Sign1 object can be adequately described by cf=18 so that's what I implemented.

A sign1 object is pretty much self-checking when you check the signature.
More interesting is — what was actually signed?

> There seems to be nothing wrong with that, except that draft-constrained-voucher says to use TBD3 for the case that this object is a Voucher/VR.

Exactly, so if it says that, and someone sends me ct=18, I shouldn’t use that, because something went (accidentally or surreptitiously) wrong.

> So to be compliant to the draft I can remove support for cf=18 as soon as TBD3 is allocated. I still don't see how cf=18 could be 'wanton extension of the protocol' as it is just using CoAP/COSE defined mechanisms that apparently are overruled by draft-constrained-voucher.

Overruled they are.
(Unless/until we decide to change to them!)

> In this perspective and considering security it would be good if the COSE structure would have the 'content type' parameter inside set to 60 (CBOR). This way the server would never fall into the tr…

The payload would need to be validly signed before a sane implementation tries to consume it, so I think that is a smaller concern.  (Can the attacker validly sign?  Possibly…)

I still think it is important to solidly identify the signed part of the message as a voucher, unless the keys are earmarked ONLY for this kind of signature, in which case the voucherness would be implicit.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Thu, 22 Jul 2021 16:55:59 -0400

Toerless Eckert <[email-masked]> wrote:
    > So: if we wanted to support the COSE content-type field semantically
    > correctly, we should ask for another registry entry:

    > application/voucher-cbor TBD4

I don't understand what that would be for.

We already are registering application/voucher-cose+cbor in section 13.5.1
We fit voucher-request into the same content.
(that's distinguished by the SID values)

I think you are overthinking this.
And we transport constrained-vouchers with that MIME type over HTTPS between
Registrar and MASA.  And we use it in the Accept: header.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 22 Jul 2021 17:01:49 -0400

Esko Dijk <[email-masked]> wrote:
    > object is a Voucher/VR. So to be compliant to the draft I can remove
    > support for cf=18 as soon as TBD3 is allocated. I still don't see how
    > cf=18 could be 'wanton extension of the protocol' as it is just using
    > CoAP/COSE defined mechanisms that apparently are overruled by
    > draft-constrained-voucher.

The issue of interopability only comes up if there are clients which escape
into the wild which use cf=18.

If your server continues to accept cf=18, that's your problem :-)

When we switches from /.well-known/est to /.well-known/brski, I left the
processing in my server at first, because I needed to run through testing the
client code (pledge and Registrar).  And unit testing.  And then I fixed all
the clients and unit tests to use the new thing.  (I do need to remove the old
path now: Make before Break)

Anyway, let's ask for an early allocation.
We'll be 3-6 months before we get past the IESG and into IANA land to get a
number.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 22 Jul 2021 23:07:28 +0200

On 2021-07-22, at 22:55, Michael Richardson <[email-masked]> wrote:
> Signed PGP part

If the intent is to use header parameter 3 (content type) to identify the payload of the COSE-Sign1, as has been discussed here, this only works if there is a media-type (and preferably also a content-format) for that payload.

There may be other ways to provide that identification, but *if* the parameter 3 is chosen, a second media type for an unprotected voucher will be required.

(Obviously with +cbor etc.; naming to be decided later.)

> (that's distinguished by the SID values)

So that is also a COSE-Sign1 payload?
(Too lazy to check, sorry.)

> Registrar and MASA.  And we use it in the Accept: header.

But these are all protected vouchers, so they don’t need the additional media type, right?

(When I say “additional media type”, this of course also could be a content-type parameter, “; protected=no” or some such.  Still need a second content-format number.)

Grüße, Carsten

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 23 Jul 2021 01:54:46 +0200

Overthinking is a result of underspecification in the COSE RFC/bis-draft.

I simply would like for the constrained voucher document to make a statement
about the use of the COSE content type field. I have no strong opinions by now
as to what it should say, but i would like our RFCs not to be underspecified
and leave implementers guess about use of fields, leading to possibly more complex
interop matrixes.

As a reader i also like explanation/justification text for the requirements described.

My sugestion for the constrained voucher text is:

  Constrained vouchers (application-type/voucher-cose+cbor, TBD3) SHOULD NOT use the
  COSE header "content type" field because the encoding is never "ambiguous"
  according to RFC8152 Section 3.1.  If a constrained voucher contains this field, it MUST
  be ignored by the processing described in this document.

Aka: i don't know what purpose it serves and if we wanted it to serve a purpose it
sounds as if we would need to assign more useless code points.
  
Cheers
   Toerless

-- 
---
[email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 23 Jul 2021 03:15:09 +0200

> Overthinking is a result of underspecification in the COSE RFC/bis-draft.

This is not underspecification; this is leaving decisions to the protocol using COSE.  I am trying to get you to make those decisions.

>  COSE header "content type” field

They CANNOT unless you allocate a media type for an unprotected voucher.

Are you also saying that they should/should not use “countersignature”?  Maybe a single sentence that explains that there are no header parameters in use expect those that you specify would be enough.

> because the encoding is never "ambiguous"
>  according to RFC8152 Section 3.1.  

Well, that is actually not true, as far as I know.  How do you *know* that the signed payload is a voucher?  (Remember that the attacker can repackage anything that is not protected ad nauseam, so a tag/media type *outside* the signature is not such an indication.)  Abadi-Needham #1.

Grüße, Carsten

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 23 Jul 2021 04:31:47 +0200

On Fri, Jul 23, 2021 at 03:15:09AM +0200, Carsten Bormann wrote:
> This is not underspecification; this is leaving decisions to the protocol using COSE.

Underexplained how/why to make specific decisions based on underspecified semantics
of the header fields and missing examples ?

> I am trying to get you to make those decisions.

Sure, thats what we're doing here.

> They CANNOT unless you allocate a media type for an unprotected voucher.

There is application/cbor, ID=60

I am not saying i find that useful, i was just suggesting the SHOULD NOT
instead of your MUST NOT because i couldn't figure out how to, nor
cared why to suggest a pithy explanation why something like application/cbor
in content type is useless.

> Are you also saying that they should/should not use “countersignature”?  Maybe a single sentence that explains that there are no header parameters in use expect those that you specify would be enou…

I have not looked at any other COSE header parameters that might
be underspecified in the constrained voucher spec. I just stumbled
into the ones i discussed because of the early allocation request.

If you have opinions/suggestions, please offer them here
(e.g.: about countersignature).

Shortening the text to apply for multiple parameters is fine editorializing,
but should not come at the expense of dropping explanations of
decisions made by the document whose absence could leave implementers/readers
wondering.

> Well, that is actually not true, as far as I know.  How do you *know* that the signed payload is a voucher?

The way i see it, The COSE object is useless standalone, because
it does not even describe in its own structure what it is.
So you need to have somewhere else the media-type
application/voucher-cose+cbor and/or binary TBD3 to
know what it is.

But as soon as you know what it is, you have nailed down
the fact that the semantic is voucher and the COSE content
type is a CBOR encoded voucher.

>  (Remember that the attacker can repackage anything that is not protected ad nauseam, so a tag/media type *outside* the signature is not such an indication.)  Abadi-Needham #1.

I do not follow. Rephrase with step by step workflow example ?

But if i may guess: the constrained voucher draft does not need
to care if/how a non-COSE encapsulated CBOR encoded "voucher"
blob would be identified. That type of object is not used or needed
anywhere in the spec, and i would argue that the CBOR part
by itself isn't even a real voucher because the signature
in the COSE part is a core core part of a voucher.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Fri, 23 Jul 2021 08:36:55 -0400

Carsten Bormann <[email-masked]> wrote:
    >> We already are registering application/voucher-cose+cbor in section
    >> 13.5.1 We fit voucher-request into the same content.  (that's
    >> distinguished by the SID values)

    > So that is also a COSE-Sign1 payload?  (Too lazy to check, sorry.)

Yes.

    >> I think you are overthinking this.  And we transport
    >> constrained-vouchers with that MIME type over HTTPS between Registrar
    >> and MASA.  And we use it in the Accept: header.

    > But these are all protected vouchers, so they don’t need the additional

Additional to voucher-cose+cbor? No.

    > (When I say “additional media type”, this of course also could be a
    > content-type parameter, “; protected=no” or some such.  Still need a
    > second content-format number.)

Ah, then definitely no.
(We had an unsigned voucher request, but we axed it in 2019)

---

From: Michael Richardson <[email-masked]>
Date: Fri, 23 Jul 2021 08:38:31 -0400

Toerless Eckert <[email-masked]> wrote:
    > I simply would like for the constrained voucher document to make a
    > statement about the use of the COSE content type field. I have no
    > strong opinions by now as to what it should say, but i would like our
    > RFCs not to be underspecified and leave implementers guess about use of
    > fields, leading to possibly more complex interop matrixes.

Already done.

    >   Constrained vouchers (application-type/voucher-cose+cbor, TBD3)
    > SHOULD NOT use the COSE header "content type" field because the
    > encoding is never "ambiguous" according to RFC8152 Section 3.1.  If a
    > constrained voucher contains this field, it MUST be ignored by the
    > processing described in this document.

I don't think that this is useful to add.
  "Unknown headers are ignored"

---

From: Michael Richardson <[email-masked]>
Date: Fri, 23 Jul 2021 08:39:59 -0400

Carsten Bormann <[email-masked]> wrote:
    > Are you also saying that they should/should not use “countersignature”?
    > Maybe a single sentence that explains that there are no header
    > parameters in use expect those that you specify would be enough.

AFAIK, mechanically, we can't use counter signatures, because we use
CoSESIGN1, and not not CoseSign0.

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 23 Jul 2021 18:35:10 +0200

>   "Unknown headers are ignored"

I disagree. Headers for which we do not specify behavior will be handled
however implementers like. Especially when there is a reference (rfc8152/bis)
that does describe something potentially confusing about this header.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 23 Jul 2021 18:38:56 +0200

> CoSESIGN1, and not not CoseSign0.

You can guess that i do prefer to read explanations like these in the
draft instead of a mailing list ;-)

Cheers
    Toerless