Thanks John. > 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 > <https://github.com/cose-wg/countersign/pull/7> I just merged this PR.
> - Just refering to section 4.2 of RFC8949 might not be enough as section 4.2 > of RFC8949 specifies different deterministic encodings. I am not sure what additional things to add. Section 4.2 of RFC8949 says that applications can specify restrictions to ensure that a deterministic format is produced. I think that means these restrictions are "above" COSE. > - "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. Does this resolve your concerns: ... It should be noted that there is a big difference between attesting to the encrypted data as opposed to attesting to the plaintext data. Usually, the signer wishes to countersign the plaintext data, and then encrypt the data along with the countersignature. This approach prevents an attacker from stripping countersignatures. In addition, this approach prevents an observer from linking the public keys needed to verify the countersignatures across different payloads. It is always possible to construct cases where the use of two different keys will appear to result in a successful decryption (the tag check success), but which produce two completely different plaintexts. This situation is not detectable by a countersignature on the encrypted data. > - 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. I think that Jim intended the same set of steps to be used. For example, Section 3.3, Step 3, says: "This field is omitted for the Countersignature0V2 attribute." Russ
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
