Subject: [COSE] my comments on countersign-00

From: Michael Richardson <[email-masked]>
Date: Wed, 23 Sep 2020 13:11:14 -0400

There is a &gt; lurking in section 1.2

I found section 3.0 very dense reading.
I think that there are several use cases listed, and I'd like them split up
in numbered sections that I can refer to.

In the fourth paragrah:

   When done on
   a COSE_Sign, this is the same as applying a second signature to the
   payload and adding a parallel signature as a new COSE_Signature is
   the preferred method.

I feel like s/COSE_Signature/COSE_Countersignature/ here?

section 3.1:

   This also means that the countersignature can itself be
   countersigned.  This is a feature required by protocols such as long-
   term archiving services.

I'd like to see this use case expanded somewhere, perhaps with a short example.
RFC4998 is from 2007 and is full of ASN.1 goo.  But section 4 (of 4998)has a
nice way to represent the trees with concentric boxes.  It wasn't obvious to me
how to translate things.  I'm not asking you to do redo 4998 though.

[okay, in context, of 3.1, I now understand why signature algorithm with
message recovery makes no sense]

When you write:
   *  Using the same key for two different algorithms can leak
      information about the key.  It is therefore recommended that keys
      be restricted to a single algorithm.

I think that where you say "algorithm" you actually mean protocol.
That is, I shouldn't use the same ECDSA secp256k1 key with both OpenPGP and
COSE.  I think that "ECDSA" is the algorithm, so the statement would
otherwise be a tautology.  But, maybe you are saying that I shouldn't
use the same point with a 256-bit ECDSA and a 384-bit ECDSA?

   *  Use of 'direct' as a recipient algorithm combined with a second
      recipient algorithm exposes the direct key to the second
      recipient.

I have no idea what this means.  I guess it applies to ECDH more than ECDSA.
I found that the security considerations are not particularly specific to
counter signatures.

A question that I had when reading, is what is the key value to be
used when putting a counter-signature into the unprotected bucket.
I see in the examples that you use 7, which is the same as for RFC8152.
I think that this might warrant more emphasis back in section 2, and
also at the end of section 3.2.

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