Hi, Some comments on draft-ietf-cose-countersign-04
- References: OLD: [I-D.ietf-cbor-7049bis] NEW: RFC8949 OLD: [I-D.ietf-core-groupcomm-bis] NEW: [I-D.ietf-core-oscore-groupcomm] - "In order to always regenerate the same byte string for the "to be signed" value, the deterministic encoding rules defined in Section 4.2 of [I-D.ietf-cbor-7049bis]. These rules match the ones laid out in Section 11 of [I-D.ietf-cose-rfc8152bis-struct]." Section 11 is now IANA. Should be section 9. I made a PR to fix the above things https://github.com/cose-wg/countersign/pull/7 - Just refering to section 4.2 of RFC8949 might not be enough as section 4.2 of RFC8949 specifies different deterministic encodings. - "It should be noted that there is a big difference between attesting to the encrypted data as opposed to attesting to the unencrypted data. If the latter is what is desired, then one needs to apply a signature to the data and then encrypt that." I think the draft should give some more security consideration here. At least point out the problems/properties of countersigning a COSE_Encrypt: - It does not prove that the signer had any knowledge the plaintext. An attacker might remove a countersignature and resign a ciphertext. - An attacker can link a countersignature to a specific public key and therefore also link different countersigned COSE_Encrypt with each other. The paper from USENIX 2001 might be good reference: https://theworld.com/~dtd/sign_encrypt/sign_encrypt7.html - The order of COSE_Countersignature0 processing at the receiver seems undefined. The order should either be mandated or it should be stated that the receiving part can process things in any order. Cheers, John
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
