[ Speaking with no hats ] I think this text is an improvement to what's there today.
- m&m Matthew A. Miller > On Sep 10, 2020, at 9:09 PM, Jim Schaad <[email protected]> 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 > 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 > 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. > There are some issues that have been identified that 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 > the number of bytes signed. 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 > 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 > from the start of the message then, by default, none of the > signature payload may be included in the message recovery data. > 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 > 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. > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
