Subject: [COSE] New countersign model potential issue

From: Jim Schaad <[email-masked]>
Date: Tue, 22 Sep 2020 14:58:35 -0700

At the moment the following is not an issue at all, but looking at it we
might want to re-think the order in which items are constructed for doing
countersignatures.  Using a message recovery signature algorithm, which is
currently discouraged for countersignatures for a number of reasons, needs
to steal bytes from the right end of the to-be-signed bytes because that is
where the message content is.  Stealing bytes in the event of a
countersignature does not make a great deal of sense, but the new proposed
structure no longer places the "message content bytes" at the end of the
message as the "other binary values" are currently appended after the
message content.  

There currently are not any issues raised by this, but it does raise some
interesting questions for a future new base COSE message type.  I don't know
if this should be changed, it should be noted, or it should be ignored.

Jim

---

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Sep 2020 19:38:07 -0400

Jim Schaad <[email-masked]> wrote:
    > Using a message recovery signature algorithm, which is
    > where the message content is.

I feel that some words might be missing from this "sentence"?
I also don't know what a message recovery signature algorithm is, but I'll
ask google.

    > Stealing bytes in the event of a

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 22 Sep 2020 18:04:10 -0700

> I also don't know what a message recovery signature algorithm is, but I'll

If you're using a message-recovery signature algorithm, you steal some
bytes from the message being signed and pack them into the signature value,
to be recovered later when the signature is validated.

Jim is assuming (fairly naturally, but IIUC without actual hard basis) that
the stolen bytes will come from the end of the input to the signature
algorithm...

>     > message as the "other binary values" are currently appended after the

...and noting that when you're making a countersignature the bytes that are
packed into the (counter)signature are no longer message content bytes, but
rather "other binary values".  This is weird, but not necessarily
fundamentally flawed.

>     > if this should be changed, it should be noted, or it should be ignored.

Personally, I would be surprised to see signature-with-recovery on
countersignatures, since in my mind one of the nice properties of
countersignatures is that you can ignore them and just trust the primary
signature if you don't need the extra assurance.  Using
signature-with-recovery for a countersignature is pretty likely to force
you into validating the countersignature as well as the "primary"
signature.

-Ben