On May 21, 2022, at 8:26 AM, Ilari Liusvaara <[email protected]> wrote: > >> >> The same argument can be made for COSE, here for COSE_Sign1: >> >> The signature input is the CBOR serialization of the Sig_structure >> array: >> ["Signature1", body_protected, sign_protected, aad, payload, [signature]] >> >> In hex, the array length is 86, the context string length is 6A, and >> the context string is 5369676E617475726531. This means the first three >> bytes are always 86 6A 53, which is different than zero bytes and also >> different from the SSH signature preamble ("SSH" which is 53 53 34). >> >> Is this a sensible analysis? Anything else to watch out for? > > That Sig_structure does not match my reading of RFC 8152. The RFC seems > to have Sig_structure to have either 4 or 5 elements, not 6. And there > are context strings other than just "Signature1". The new counter- > signatures draft adds possibility to have 6 element sig_structure.
Sig_structure is internal to COSE. It never appears on the wire. It is constructed and hashed independently by both the sender and the receiver. If you’re putting COSE in a file, it would probably be good to always use a COSE tag so you know if it signed, encrypted or what. Then the first bytes will be 0xD2, 0x84, or 0xd8 0x62, 0x84, or 0xd8 0x60, 0x84 or a few others. Seems like it would still never be “SSH”. LL
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
