Hi Russ, See inline
From: Russ Housley <[email protected]> Date: Wednesday, 2 June 2021 at 21:54 To: John Mattsson <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [COSE] Some comments on draft-ietf-cose-countersign-04 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://protect2.fireeye.com/v1/url?k=d65df8c0-89c6c022-d65db85b-86073b36ea28-e78c77dfebf70d7f&q=1&e=08f606cc-fbb7-4eff-90f1-9462b5069998&u=https%3A%2F%2Fgithub.com%2Fcose-wg%2Fcountersign%2Fpull%2F7> 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. John: Ok, I think the current text is fine. Section 4.2 of RFC8949 specifies two different orders for maps but that is probably not important for 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. John: Yes, the suggested text looks good. - 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." John: I was thinking about the order of decryption (in the case of COSE_Encrypt) and signature verification. If the receiver starts doing decryption or even using the plaintext before verifying the signature it could lead to security problems. Russ
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
