Hi Jim, I didn't extract the text to do a side-by-side diff, but overall this looks fine. Your suggestion about "general schemes" is appreciated, so if that could make it in that would be great.
I am still a bit unclear about the "application external data", though. Thanks, Ben On Mon, Sep 21, 2020 at 12:18:04PM -0700, Jim Schaad wrote: > > > -----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 _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
