Ben, See below.
-----Original Message----- From: Benjamin Kaduk via Datatracker <[email protected]> Sent: Wednesday, June 10, 2020 6:44 PM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; Matthew Miller <[email protected]>; [email protected] Subject: Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis-struct-10: (with DISCUSS and COMMENT) Benjamin Kaduk has entered the following ballot position for draft-ietf-cose-rfc8152bis-struct-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-struct/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (Arguably a "discuss discuss".) If we don't have any worked examples of signatures with message recovery, should we include that possibility in the Internet Standard version of the protocol? Some of the description around how the details of this would work remain unclear to me. Ben, I have been a bit of a busy beaver over the last few days trying to get things done for this draft. One of the things that has come out of that is a fast implementation of two different signature recovery algorithms in my code base. I think I will leave it on an orphaned github branch when I am sure that I have all of the bugs out, which I don't seem to for the RSA-PSS version yet. The first version I did is a "toy" algorithm where I just grabbed 32 bytes of message and appended them to the end of an EdDSA signature. 98([ h'A10300', {}, h'546869732069732074686520636F6E74656E742E20416E642077652061726520676F696E6720746F20', [[h'A1013A000A27CD', {4: h'3131'}, h'FB358BF0E32EBECDDACD8F15B60EA8A8E7F7DC334F86E370575A64B486BA919874F5CA1B202EE2AF7A51A1E169F1772330FCA1BA3349AD91172288EEC57ADE0A657874656E642074686520636F6E74656E7420746F206265206C6F6E6765722E']]]) Above is an example where the payload is longer than 32-bytes so that only the last 32-bytes are included in the signature. 98([ h'A10300', { }, h'', [[h'A1013A000A27CD', {4: h'3131'}, h'A742D60E0899BE5689BE122EE4D95E734201CEBBCA148D53F58895B6DCE6F0F6A884A875D230820BD0CAEC87791EDD629FCFC4936000711E9231493C2D291204030047A1013A000A27CD4054546869732069732074686520636F6E74656E742E']]]) The above is a signature where there were 21 bytes of payload from the application. I did get a minor surprise when I did the implementation as I realized that the message signed is the constructed payload and thus the message that is signed is longer than 21 bytes. This means that portions of the external data or protected header fields are included in the message recovery data. It does mean that there is a minor issue in correlating exactly where the message starts and the extra recovered data matches the bytes from the constructed message. To date I have not found this to be any problem, but I would think that this better goes into the algorithm description rather than here as it may be slightly different for different algorithms. I also pulled out a really old document which had and RSA-PSS w/ message recovery. As I knew already, there is a minor issue where this algorithm uses the first n bytes of the message signed rather than the last n bytes as the signature algorithm above did. This is simple to deal with by reversing the sequence of byte in the signed message before doing the signature operation. This means that the last n bytes of the original message payload are going to be what is encoded into the signature. I don't see any changes that I believe would be needed to be added to the current text to talk about either of these issues. Jim _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
