Subject: [COSE] Issue - add the value type 'bstr' to counter signature

From: "Jim Schaad" <[email-masked]>
Date: Wed, 13 Jan 2016 20:47:17 -0800

At this time, I would like to discuss the details of what this means rather
than should we do this.  I will bring up the issue of yes/no on doing this
after this has seen some discussion.  (Doing this depends on issue #51 in
the database.)

How this works need to have some explanation.

What is the algorithm that is to be used for generating the 'to be signed'
bytes.  I can see two options right off the bat and there are probably more.

1.  The following are to be considered to be the same [h'', {},
h'signature'] and h'signature' are interchangeable.  This means that there
are some implicit fields that need to be described for the signature
process.  It also implies that there is a mechanical conversion between
these two forms of the counter signature data.

2.  There is a new CDDL structure to be defined for computing the counter
signature which has a more restricted set of data.  Specifically this would
create a Sig_structure of

Sig_structure = [
  context: "some context string",
  body_protected : bstr,
  external_aad : bstr,
  payload : bstr
]

This omits the same sign_protected field that is absent for the Sign0
signature processing.

The description in github correctly notes that there is an issue of needing
to have an implied algorithm.  The other question that needs to be address
is how this also implies a key to be used.  Is there an assumption that
needs to be stated that the core message and the countersignature are going
to be created by the same key context?

Jim

---

From: Francesca Palombini <[email-masked]>
Date: Thu, 14 Jan 2016 14:55:53 +0000

Hi Jim,

We suggested this modification with something similar to your point 2 in mind: a new CDDL structure should be defined for computing the counter signature with a more restricted set of data. This would be the equivalent of the COSE_Sign1 for the counter signature. You could even have a new label for this "shorter counter signature" and instead of having:

Generic_Headers = (
...
? 7 => COSE_Signature / bstr, ; Counter signature
...
)

As it was suggested in the github, we could have:

Generic_Headers = (
...
? 7 => COSE_Signature, ; Counter signature
? X => bstr, ; "Shorter" counter signature
...
)

In order to make the distinction easier, and to know what Sig_structure to use to compute the counter signature.
And to answer your question, yes, in our proposal the algorithm and the key to use are in fact defined in the same security context as the algorithm and key for the core message.

Francesca

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: den 14 januari 2016 05:47
To: [email-masked]
Cc: Francesca Palombini
Subject: Issue - add the value type 'bstr' to counter signature

At this time, I would like to discuss the details of what this means rather than should we do this.  I will bring up the issue of yes/no on doing this after this has seen some discussion.  (Doing this depends on issue #51 in the database.)

1.  The following are to be considered to be the same [h'', {}, h'signature'] and h'signature' are interchangeable.  This means that there are some implicit fields that need to be described for the signature process.  It also implies that there is a mechanical conversion between these two forms of the counter signature data.

2.  There is a new CDDL structure to be defined for computing the counter signature which has a more restricted set of data.  Specifically this would create a Sig_structure of

Sig_structure = [

This omits the same sign_protected field that is absent for the Sign0 signature processing.

The description in github correctly notes that there is an issue of needing to have an implied algorithm.  The other question that needs to be address is how this also implies a key to be used.  Is there an assumption that needs to be stated that the core message and the countersignature are going to be created by the same key context?

Jim

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 14 Jan 2016 10:35:57 -0800

> From: Francesca Palombini [mailto:[email-masked]]
> Sent: Thursday, January 14, 2016 6:56 AM
> To: Jim Schaad <[email-masked]>; [email-masked]
> Subject: RE: Issue - add the value type 'bstr' to counter signature
> 
> Hi Jim,
> 
> We suggested this modification with something similar to your point 2 in
mind: a
> new CDDL structure should be defined for computing the counter signature
with
> a more restricted set of data. This would be the equivalent of the
COSE_Sign1
> for the counter signature. You could even have a new label for this
"shorter
> counter signature" and instead of having:
> 
> Generic_Headers = (
> ...
> ? 7 => COSE_Signature / bstr, ; Counter signature ...
> )
> 
> ? 7 => COSE_Signature, ; Counter signature ? X => bstr, ; "Shorter"
counter
> signature ...
> )
> 
> In order to make the distinction easier, and to know what Sig_structure to
use to
> compute the counter signature.
> And to answer your question, yes, in our proposal the algorithm and the
key to
> use are in fact defined in the same security context as the algorithm and
key for
> the core message.

Well done, this is precisely where I wanted to go in the even that a
different Sig_structure was to be used in computing the value.

Let's wait a couple of days to see if anyone else wants to weigh in on the
this issue and move to the question of implicit algorithms then.

Jim

> At this time, I would like to discuss the details of what this means
rather than
> should we do this.  I will bring up the issue of yes/no on doing this
after this has
> seen some discussion.  (Doing this depends on issue #51 in the database.)
> 
h'signature'] and
> h'signature' are interchangeable.  This means that there are some implicit
fields
> that need to be described for the signature process.  It also implies that
there is
> a mechanical conversion between these two forms of the counter signature
> data.
> 
> signature which has a more restricted set of data.  Specifically this
would create
> a Sig_structure of
signature
> processing.
> 
> The description in github correctly notes that there is an issue of
needing to have
> an implied algorithm.  The other question that needs to be address is how
this
> also implies a key to be used.  Is there an assumption that needs to be
stated
> that the core message and the countersignature are going to be created by
the
> same key context?