Re: [COSE] Updated message recovery algorithm text

[Benjamin Kaduk <[e-mail]>]

Hi Jim,

Overall this seems a fine tack to take, but see comments inline.

On Thu, Sep 10, 2020 at 08:09:54PM -0700, Jim Schaad wrote:
> Below is the text that I am proposing for COSE Struct.  The changes are all
> in the last 5 paragraphs.
> 
> Jim
> 
> 
> 
>    The second scheme is signature with message recovery (an example of

I wonder if we could toss in a word or two about these being "general
classes of signature scheme" where we first bring it up (i.e., for
signature with appendix).

>    such an algorithm is [PVSig]).  In this scheme, the message content
>    is processed, but part of it is included in the signature.  Moving
>    bytes of the message content into the signature allows for smaller
>    signatures; the signature size is still potentially large, but the
>    message content has shrunk.  This has implications for systems
>    implementing these algorithms and for applications that use them.
>    The first is that the message content is not fully available until
>    after a signature has been validated.  Until that point, the part of
>    the message contained inside of the signature is unrecoverable.  The
>    second is that the security analysis of the strength of the signature
>    is very much based on the structure of the message content.  Messages
>    that are highly predictable require additional randomness to be
>    supplied as part of the signature process.  In the worst case, it
>    becomes the same as doing a signature with appendix.  Finally, in the
>    event that multiple signatures are applied to a message, all of the
>    signature algorithms are going to be required to consume the same
>    number of bytes of message content.  This means that the mixing of

Not just the same number; the same actual bytes, too. (Right?)

>    the different schemes in a single message is not supported, and if a
>    recovery signature scheme is used, then the same amount of content
>    needs to be consumed by all of the signatures.
> 
>    The signature functions for this scheme are:
> 
>    signature, message sent = Sign(message content, key)
> 
>    valid, message content = Verification(message sent, key, signature)
> 
>    Since there have not yet been any message recovery signature
>    algorithms formally defined for COSE, it is very likely that there
>    are going to be issues that arise that have not been anticipated yet.

I think this should get wordsmithed a bit.  The RFC Editor can probably
help, but here's my take:

% No message recovery signature algorithms have been formally defined for
% COSE yet, and given the new constraints that such schemes impose on
% usage, it is likely that there will be additional issues that arise when
% integrating message-recovery signature algorithms with COSE.

(And to be clear, this chunk is the main part that goes to resolving my
Discuss point.)

>    There are some issues that have been identified that the first such

(This could have a better transition from the rewritten previous paragraph,
maybe "Some such issues have already been identified, and the first such
[...]")

>    algorithm is going to need to make decisions about.  These issues
>    include:
> 
>    *  The message content being signed is not the same as the message
>       content that is transported.  This is because we build a larger
>       message for the signature process.  The number of bytes contained
>       in the message may exceed the number of bytes of payload, but not

"contained in the message" means "recovered during signature validation",
right?

We may want to use a more precise term than "payload" since there are
several different variants floating around during this process.

>       the number of bytes signed.  This may lead to privacy
>       considerations if, for example, the application external data
>       contains confidential information.

(The "application external data" is the stuff that's covered under the
signature but not transmitted?)

>    *  There may be difficulties in determining where the recovered
>       message matches up with the to be signed value because bytes other
>       than the payload are included in the recovered message.  One
>       possible option would be to create a padding scheme to prevent
>       that.
> 
>    *  Not all of these signature algorithms take the recovered bytes
>       from the end of the message.  If the recovered bytes are taken

I would suggest rephrasing to not privilege the end of the message (or,
alternatively, to be more explicit about that being the COSE expectation);
perhaps "take the recovered bytes from the same position of their input".

>       from the start of the message then, by default, none of the
>       signature payload may be included in the message recovery data.

(which would, of course, entail some changes to this sentence as well...)

>       One possible option to deal with this is to reverse the to-be-
>       signed data in the event that bytes are taken from the start
>       rather than end of the message.
> 
>    Signature algorithms are used with the COSE_Signature and COSE_Sign1
>    structures.  At this time, only signatures with appendixes are

("at the time of this writing" seems to be preferred in terms of aging
well.)

>    defined for use with COSE; however, considerable interest has been
>    expressed in using a signature with message recovery algorithm due to
>    the effective size reduction that is possible.

Thanks,

Ben