Subject: [COSE] COSE Struct Discuss

From: Jim Schaad <[email-masked]>
Date: Thu, 23 Jul 2020 13:26:17 -0700

During the IESG review of draft-ietf-cose-rfc8152bis-struct a DISCUSS was
raised that it took a while to convince me was a real problem and I have
been since looking at this to try and figure out if there were any good
answers.  Unfortunately I did not find anything that I really liked.  So
this is going to the list to try and get some type of resolution for the
problem.

All of the structures start out the same
* bstr w/ protected attributes
* map w/ unprotected attributes
* bstr w/ some type of content
* Array of items above (i.e. recipients) or nothing

For all but four of the COSE message structures, what goes into the second
bstr is some type of cryptographically computed value and thus applying a
countersignature to that value provides additional benefits. 

COSE_Signature has this layout, but it does not have any cryptographically
computed values so the document describes putting a countersignature on this
structure as being the same as adding a parallel signature.  

The last three structures have one additional bstr added so that you get
* bstr w/ protected attributes
* map w/ unprotected attributes
* bstr w/ some type of content
* bstr w/ cryptographic value
* Array of items above (i.e. recipients) or nothing

In these cases if you wanted to provide additional value with the
countersignature you need to be computing it on the fourth value in the
structure and not the third.  This was correctly indicated for COSE_Mac and
COSE_Mac0 in the current document, but it was not correctly indicated for
COSE_Sign1.  The following are the options that I have come up with so far:

1.  Change the text so that it indicates that a countersignature on
COSE_Sign1 does not provide a countersignature but only provides an
additional signature as is currently done for the two MAC structures.   This
is going to be somewhat non-intuitive as a countersignature on a signature
structure does not produce a countersignature.  This is what my current code
base does.

2.  Change the countersignature algorithm to use the first and last bstr in
the structure.  This will change the behavior for countersignatures on
COSE_Mac and COSE_Mac0, but I would not expect this to have any significant
real world issues.  Changing the algorithm does mean that any future
structures defined for COSE (perhaps some type of combined
signature/encryption algorithm) are going to need to be designed so that if
a new bstr is added, it needs to ensure that the last one is where the
cryptographic value is added to the structure.

3. Change the countersignature algorithm to use every bstr value in the
structure.   Again, this will change the algorithm for countersignatures on
COSE_Mac and COSE_Mac0.  The benefit is that every new item added is going
to be included in the countersignature so you don't need to have a single
value which contains all of the new cryptographic value.

4.  Change the countersignature algorithm for COSE_Sign1, but leave it alone
for the COSE_Mac and COSE_Mac0 structures.  This has the benefit that a
countersignature on a COSE_Sign1 produces the type of value one would
expect, and it does not change what you get for the current MAC structures.
The downside is that you suddenly need to look at the structure before you
can do the validation in the cases where the fourth bstr is in the
structure.  An additional downside is that if a new structure is created
with the extra bstr value, the validator will not know which of the two
extraction algorithms is to be used.

I don't have any preference between the options above.  They all have good
points and bad points.  The first one is the easiest to implement as it
would only require adding some text to the document.  But the frisson
between what one would expect a countersignature to be and what it is in
actuality for a COSE_Sign1 is jarring.

Please look at this and give me opinions about the correct way to go
forward.

Jim

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Jul 2020 18:08:06 -0400

I'm sorry, I've been pretty much unaware of the 8152bis effort.
I feel rather embarrassed about that, having written some code that did not
(yet) fully interoperate with Jim's code (That TODO item shouts at me daily)

    > countersignature to that value provides additional benefits.

I found your words "second bstr" mystyfing because it maps to "* bstr w/ some type of content"
rather than the "second" item, "map w/ unprotected attributes" :-)
Next time, can we number the items...

    > structure as being the same as adding a parallel signature.

I understand this part.

    > * Array of items above (i.e. recipients) or nothing

"Last three structures"... I think you must mean COSE_Encrypt, COSE_recipient
and COSE_Mac.
(Why on page 16 are they:
      COSE_Sign1, COSE_Signature, COSE_Encrypt,
      COSE_recipient, COSE_Encrypt0, COSE_Mac, and COSE_Mac0.

In this order, rather than:
      COSE_Signature, COSE_Sign1,
      COSE_Encrypt0,  COSE_Encrypt,
      COSE_recipient, COSE_Mac, and COSE_Mac0.
)

But, COSE_Encrypt combines:  "* bstr w/ some type of content"/"* bstr w/ cryptographic value"
because it's encrypted, right?

    > COSE_Sign1.  The following are the options that I have come up with so far:

Can you give a use case here?

I think that I get that we are either breaking COSE_Sign1 (which has been
rarely used so far), or COSE_Mac*, in-so-far as they need countersignatures
with additional values.
If no additional values, then not a problem.

    > actuality for a COSE_Sign1 is jarring.

I think that I'm okay with breaking/updating COSE_Sign1.
Don't we need Sign1 for SUIT?
I believe that Henk's SBOM proposal (outside of the IETF), does.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 24 Jul 2020 02:23:19 +0200

> I think that I'm okay with breaking/updating COSE_Sign1.

Well, we wouldn’t break Sign1, but would break countersignatures with Sign1.

> I believe that Henk's SBOM proposal (outside of the IETF), does.

Yes, we shouldn’t break Sign1.
Now, about countersignatures:
Do SUIT or SBOM use countersignatures on Sign1?

We could always (and probably should) put in another structure that is called countersignature1 that does what we want while leaving the old one alone.

Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Fri, 24 Jul 2020 04:22:50 -0700

> -----Original Message-----
> From: Michael Richardson <[email-masked]>
> Sent: Thursday, July 23, 2020 3:08 PM
> To: Jim Schaad <[email-masked]>; [email-masked]
> Subject: Re: [COSE] COSE Struct Discuss
> 
> 
> I found your words "second bstr" mystyfing because it maps to "* bstr w/
some
> type of content"
> rather than the "second" item, "map w/ unprotected attributes" :-) Next
time,
> can we number the items...
> 
>     > computed values so the document describes putting a countersignature
on
> this

No - The last three structures were COSE_Sign1, COSE_Mac and COSE_Mac0 -
they are enumerated below

>     > structure and not the third.  This was correctly indicated for
COSE_Mac
> and

I think there have been a fair number of possible standards that are using
or planning to use COSE_Sign1.  However, as Carsten said we are not breaking
COE_Sign1, COSE_Mac0 or COSE_Mac1.  We are breaking how countersignatures
are applied to them.  

> 
>     > I don't have any preference between the options above.  They all
have
> good

Does knowing that only countersignatures are being broken change how you
would weight the options?

Jim

---

From: Michael Richardson <[email-masked]>
Date: Fri, 24 Jul 2020 20:06:38 -0400

> would weight the options?

Yes, it makes me less able to express a preference :-)

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