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
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
