Subject: [COSE] Signing Structure

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 1 Oct 2015 09:57:20 +0200

Hi all,

in an attempt to create a signed payload I read version -05 of the
document.

The introduction starts with long description of various sophisticated
features and this intro raises a few questions.

Example #1: Text describes features that are actually not provided by
the specification.

Here is text:

"Examples of
   parameters about the content would be the type of content, when the
   content was created, and who created the content.  Examples of
   parameters about the signature would be the algorithm and key used to
   create the signature, when the signature was created, and counter-
   signatures.
"

Content type, algorithm and counter signature are existing header
parameter but there is nothing that describes when the content was
created, when the signature was computed or who created the signature
based on the table in Section 3.1.

I suggest to not talk about features the specification does not provide
or to add those features.

Example #2: Multiple signatures

For example, the COSE_Sign structure might include signatures generated
with the RSA signature algorithm and with the Elliptic Curve Digital
Signature Algorithm (ECDSA) signature algorithm.

As indicate in a reference to RFC 5752 this features was copied from CMS.

I have been wondering about the complexity of an implementation. What
functionality is mandatory to implement and what can be omitted? For
example, do we need to create profiles of the COSE spec to only
implement a subset of the functionality that does not process multiple
signatures?

Furthermore, I noticed that several IPRs have been filed for RFC 5752
and I am wondering what this means for the COSE work. I would like to
avoid running into patent problems with features that I don't even see a
need for.

Is it possible for implementations to not support those features?

When I tried to create an example signature COSE message based on the
description on page #15 I came up with something like this:

   [
     1,  // signed message
     h'', // no protected header	
     {}, // no unprotected header
	 // payload with message "This is the content."
	 h'546869732069732074686520636f6e74656e742e',
     [	
        [
         h'',  // Protected header - none
         {
		 1: 2, // kty (mandatory parameter
             # - EC2 for Elliptic Curve Keys w/ X,Y Coordinate pair)
		 2: h'43010233', // key id value of 0x01,0x2,0x3
		 1:-7 // algorithm value for ES256
		 },  // Unprotected header
         // signature
    h'6d9d88a90ef4d6d7c0079fb11a33c855e2274c773f358df43b68f7873
   eeda210692a61d70cd6a24ba0e3d82e359384be09faafea496bb0ed16f02091c4
   8c02f33574edab5b3e334bae68d19580021327cc131fbee38eb0b28289dbce118
   3f9067891b17fe752674b80437da02e9928ab7a155fef707b11d2bd38a71f224f
   '
     ]
   ]
]

Is my understanding of the description correct?

The placement of the attributes in the header parameter is less clear to
me. What if an implementation places them in the wrong place? Imagine if
I put the kid in the example above in the outside header?

In the above example I am wondering whether the kty is indeed a
mandatory algorithm. It does not seem to be needed at all.

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 01 Oct 2015 10:33:24 +0200

> Example #2: Multiple signatures

Different algorithms are one example for using this, but more important
may be protecting the same information within different security contexts.

Re profiles: Generally, I would expect individual specifications such as
OSCOAP to specify how they want to use COSE.  Some COSE implementations
will then be specific to one such use, others will try to be generic.

Re mandatory parameters:  Again, I think many of these should be able to
come out of the security context (or possibly protocol context) if desired.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 1 Oct 2015 11:05:39 +0200

Hi Carsten,

I would have thought that you are receptive to this concern given that
you always want to reduce code size, message size, etc.

Clearly this feature does not reduce complexity.

I personally have not heard about the use case where IoT devices send
and receive messages that are covered with signatures computed by
different algorithms because they have so many implemented.

I don't recall that our use case document points to such a use case
either.

I believe our task is not to find all theoretically possible approaches
but rather to find out whether this is an absolutely necessary feature.
Otherwise I fear that we have CMS + extensions in a different binary
encoding.

Ciao
Hannes

On 10/01/2015 10:33 AM, Carsten Bormann wrote:
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 01 Oct 2015 11:21:06 +0200

We are talking about signatures, so we are mostly in class-2 land.
You would do signatures to do third-party verifiability.
But you also may have operational reasons to sign.
So that might make two signatures (OK, one might often be a MAC.)

We certainly want to avoid loading simple implementations with
complexity.  But it is still OK to enable more complex implementations
to have complexity as long as the cost is zero or near zero for the
simple ones.

Simple things should be simple, complex things should be possible.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 1 Oct 2015 11:27:10 +0200

Hi Carsten,

I am perfectly fine with using digital signatures and I expect them to
be used in many circumstances. The use of public key cryptography offers
many benefits over symmetric key cryptography.

However, the described functionality in the COSE draft goes way beyond
that simple scenario. It talks about adding
* multiple signatures for multiple recipients, and
* multiple signatures for a single recipient where the same message is
signed with different algorithms (RSA and ECDSA is mentioned as an
example).

I just have not seen those use cases.

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 01 Oct 2015 12:15:00 +0200

> I just have not seen those use cases.

That would have more bearing on the question at hand if the difference
between providing the encoding possibility for 1 or n signatures were
significant.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 1 Oct 2015 12:23:57 +0200

Hi Carsten,

if my implementation has to be prepared to receive and process multiple
signatures then this obviously has a significant implication on the
performance and the code size.

That's why I asked what the story is to create a profile of the COSE
spec that says "MUST NOT send" or MUST discard payloads with multiple
signatures.

Of course, not having multiple signatures in the first place would make
the basic spec easier.

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 01 Oct 2015 12:54:55 +0200

> spec that says "MUST NOT send" or MUST discard payloads with multiple

Ah, good.  That is exactly what I was assuming we were doing.

Indeed, it is worth having some introductory material in the draft that
explains that not all implementations will need all functions and that a
specific usage of COSE may want to constrain it.

(This also has a bearing on the question of "mandatory to implement"
algorithms -- what does that even mean when a specific usage rules them
out again?)

> Of course, not having multiple signatures in the first place would make

(Yes, but not by much.  The pain we'll have when we finally integrate
this will be much higher.  YAGNI, I know, but this one is too easy.)

Grüße, Carsten

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 2 Oct 2015 23:01:48 -0700

> -----Original Message-----
> From: COSE [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
> Sent: Thursday, October 01, 2015 12:57 AM
> To: [email-masked]
> Subject: [COSE] Signing Structure
> 
> Hi all,
> 
> in an attempt to create a signed payload I read version -05 of the document.
> 
> The introduction starts with long description of various sophisticated features
> and this intro raises a few questions.
> 
> Example #1: Text describes features that are actually not provided by the
> specification.
> 
> Here is text:
> 
> "Examples of
> Content type, algorithm and counter signature are existing header parameter
> but there is nothing that describes when the content was created, when the
> signature was computed or who created the signature based on the table in
> Section 3.1.
> 
> I suggest to not talk about features the specification does not provide or to add
> those features.

That makes total sense.   I will make a note to update the spec to meet this requirement.

> For example, the COSE_Sign structure might include signatures generated with
> the RSA signature algorithm and with the Elliptic Curve Digital Signature
> Algorithm (ECDSA) signature algorithm.
> 
> functionality is mandatory to implement and what can be omitted? For example,
> do we need to create profiles of the COSE spec to only implement a subset of
> the functionality that does not process multiple signatures?

My expectation is that applications are going to need to make profiles of the COSE spec.  They are going to need to say which of the top level things need to be supported - not everybody needs encryption, not everybody needs signatures.  They are going to need to say which algorithms need to be supported.  Do you do 2 different AEAD algorithms and at what sizes of authentication tags and key sizes?

> 
> Furthermore, I noticed that several IPRs have been filed for RFC 5752 and I am
> wondering what this means for the COSE work. I would like to avoid running into
> patent problems with features that I don't even see a need for.

If you had looked at the IPR statements filed you would have noticed that they all had to do with EC cryptography.  If you want to avoid these then I guess we should avoid EC cryptography.  

> Is my understanding of the description correct?

I don't think that you need to have the kty parameter.  In fact I think that it is not defined to be in that location. Why do you think it is mandatory?  There is a difference between a key structure and a recipient structure.  Where do I need to make this more clear.

> 
> The placement of the attributes in the header parameter is less clear to me.
> What if an implementation places them in the wrong place? Imagine if I put the
> kid in the example above in the outside header?

This ties back to your original comment in this message.  Attributes are supposed to be at the correct level for when they are needed and used.  If you placed the kid in the wrong location, my implementation would fail to find the key because it has no way to identify the key.  If you did this with two different signers, then either one would overwrite the other, leading to a failure to validate in the event you were willing to look in other locations for the kid.

> 
> In the above example I am wondering whether the kty is indeed a mandatory
> algorithm. It does not seem to be needed at all.

As noted above - I do not think the text says that it should be there.  Please tell me what lead you to think it was.  (It is not present for any of the examples

Jim

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 3 Oct 2015 13:44:45 -0700

I went through your example with a fine tooth comb and have some more comments

> description on page #15 I came up with something like this:
yes
>      h'', // no protected header
yes
>      {}, // no unprotected header
yes
> 	 h'546869732069732074686520636f6e74656e742e',
yes
>          h'',  // Protected header - none
yes
>              # - EC2 for Elliptic Curve Keys w/ X,Y Coordinate pair)
No - this field should not be present in this context - note that you also have an id number conflict with algorithm below

As I said earlier - please let me know why you thought this field should be here.  It is coming from the wrong table.  I would like to get this cleared up in the document.

> 		 2: h'43010233', // key id value of 0x01,0x2,0x3
No - this should have a id number of 4 (from the table in section 3.1) - thus
                              4:h'43010203', // key id value of 0x01, 0x02, 0x03

> 		 1:-7 // algorithm value for ES256
Yes

>    3f9067891b17fe752674b80437da02e9928ab7a155fef707b11d2bd38a71f224f
Right type of thing here

Jim