-----Original Message-----
From: Benjamin Kaduk <[email protected]>
Sent: Tuesday, September 15, 2020 10:55 AM
To: Jim Schaad <[email protected]>
Cc: [email protected]
Subject: Re: [COSE] Updated message recovery algorithm text
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).
[JLS] The terms classes and scheme seem to be the same word to me. Other
than that I have no problems with this. Would this work?
There are two general signature algorithm schemes. The first of these
general schemes is 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?)
[JLS] Done.
> 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.
[JLS] Rather than try to figure out how to break things out in the above set
of comments you just get the entire new section:
Signature algorithms provide data origination and data integrity
services. Data origination provides the ability to infer who
originated the data based on who signed the data. Data integrity
provides the ability to verify that the data has not been modified
since it was signed.
There are two signature algorithm schemes. The first is signature
with appendix. In this scheme, the message content is processed and
a signature is produced; the signature is called the appendix. This
is the scheme used by algorithms such as ECDSA and the RSA
Probabilistic Signature Scheme (RSASSA-PSS). (In fact, the SSA in
RSASSA-PSS stands for Signature Scheme with Appendix.)
The signature functions for this scheme are:
signature = Sign(message content, key)
valid = Verification(message content, key, signature)
The second scheme is signature with message recovery (an example of
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
bytes of message content. This means that the mixing of 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)
Schaad Expires 25 March 2021 [Page 38]
Internet-Draft COSE Structure September 2020
No message recovery signature algorithms have been formally defined
for COSE yet, and given the new constraints arising from this
schemes, while some of these issues have already been identified
there is a high probability that additional issues will arise when
integrating message recovery signature algorithms. The first
algorithm defined is going to need to make decisions about these
issues and those decisions re likely to be binding on any further
algorithms defined.
We use the following terms below:
message content bytes: The byte provided by the application to be
signed.
to-be-signed bytes: The byte string passed into the signature
algorithm.
recovered bytes: The bytes recovered during the signature
verification process.
Some of the issue2 that have already been identified are:
* The to-be-signed bytes are not the same as the message content
bytes. This is because we build a larger to-be-signed message
during the signature processing. The recovered bytes length may
exceed the message content length, but not the length of the to-
be-signed bytes. This may lead to privacy considerations if, for
example, the application external data contains confidential
information.
* There may be difficulties in determining where the recovered bytes
match up with the to-be-signed bytes, because the recovered bytes
contains data not in the message content bytes. One possible
option would be to create a padding scheme to prevent that.
* Not all message recovery signature algorithms take the recovered
bytes from the end of the to-be-signed bytes. This is a problem
because the message content bytes are at the end of the to-be-
signed bytes. If the bytes to be recovered are taken from the
start of the to-be-signed bytes then, by default, none of the
message content bytes may be included in the recovered bytes. One
possible option to deal with this is to reverse the to-be-signed
data in the event that recovered bytes are taken from the start
rather than end of the to-be-signed bytes.
Signature algorithms are used with the COSE_Signature and COSE_Sign1
structures. At the time of this writing, only signatures with
appendixes are 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.
[/JLS]
I think this has addressed all of your issues, but not necessarily in the
way you suggested.
Jim
Thanks,
Ben
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
