This issue documents security fixes to the identity map

[paulengland]

• I have read the CLA Document and I hereby sign the CLA.

---

This issue documents the work in signer-payload-fixes and supersedes #67

Fixes in this branch:

1. The sig_type field is signed (best practice).
2. signer_info is a new optional text field/feature that allows an ID-signer to qualify their role.
3. claim_certificate_hash is new optional field containing the hash of the certificate of the Claim Signer that the ID-assertion-creator authorizes to sign the claim. This is most useful/important to protect the manifest from modification after it has been finalized/published. Specifically, it stops the Claim Signature being stripped and replaced without the knowledge or authorization of the ID-assertion-creator.
4. id_certificate_hash is similar, but protects against later-created ID assertions being stripped and replaced without the knowledge or authorization of earlier-created ID assertions.
5. The spec now demands that all ID assertions be referenced by JUMBF-URI in referenced_assertions, however, ID-assertion-creators can omit the assertion hash if the ID-assertion generator does not want to 'claim' the assertion (or the hash is not yet known.) This ensures that assertions not authorized by the ID-assertion creator cannot be added later.

The "security goal" encoded in this change/issue is motivated by scenarios where the "butt on the line" is the entity creating the ID assertion. The changes ensure that no substantive changes to the Claim can be made subsequent to the ID assertion being signed.

A PR will be linked soon.

[puhley]

Just adding the hash of the claim signer may not sufficient. If the claim signer is a large company with thousands of users, then all I need to do is get an account with the same large claim signer as the victim in order to pass the hash check. Ensuring that the timestamps are within a window of each other probably isn't sufficient because replay attacks could be within a short interval.
Also, I wouldn't make it optional. Early developers are going to do the bare minimum which means optional fields will be left out. Once you have an identity assertion that you can paste into other content, then there is nothing in the system prevent widespread misuse. If widespread misuse occurs, then that not only causes harm to the victim, but it also undermines the trust of the C2PA ecosystem.

[paulengland]

re @puhley

replay attacks could be within a short interval.

I'm mostly concerned about Claim Signature stripping/replacement attacks, which are likely to happen long after the initial Claim Signature was generated. So, I do think that timestamps are a useful mitigation.

The reason I say this is that I hope/expect that users will pick Claim Signers that they trust for the initial signature.

[puhley]

The claim signer isn't the only one who could conduct the attack. The claim signer could just be a tool used by the attacker for the attack. That is why I said that the "trusted" claim signers would be the ideal target because they would have thousands of users. If the claim signer isn't cross-referencing the identity signature provided with a known identity in their system, then an attacker could send any existing identity signature to the claim signer. There would be claim signers who won't be able to verify that the signed identity assertions that they were provided matches the human behind the account.