Determine the organization that the signer represents at the signing time

[yizha1]

    What's the motivation behind this? can we remove it from spec and open it as issue for discussion ?

Originally posted by @priteshbandi in #148 (comment)

Explained by @shizhMSFT
"
The motivation is that the signing key of a signer may have multiple organizations associated. How to determine which organization that the signer represents at the signing time is an issue.

Here's an example, the signer has two cert chains Company A -> Signer and Company B -> Signer.

graph TD;

a["CA (Company A)"] --> s["Signer Cert"]
b["CA (Company B)"] --> s

Loading

Consider the following scenario:

Signer signs the artifact and associates cert chain Company A -> Signer to the resulted signature. In other words, the signer signs the artifact representing the company A.
Signer publishes the artifact and the signature.
Adversary sees the signature and replaces the cert chain in the unprotected header with a cert chain Company B -> Signer.
Now, from the view of verifiers, the signature is signed by the Signer, representing the company B.
This kind of attack can be mitigated by never reusing the signing key but it is better if we can sign the signing identity in the signature itself.
"

[gillg]

I'm not sure if it's related, and I don't know if it's part of the spec (seems not) but having a counter-signature by another company (like digicert, globalsign, sectigo, etc...) to sign the timestamp where the image has initialy been signed seems very important.

This is initialy the "Microsoft Authenticode" protocol, but has been standardized/extended here https://www.rfc-editor.org/rfc/rfc5816 (to use any hash mecanism instead of forcing SHA1)

The idea is to say, if you sign a V1 of your image today with a cert expiring in 1yr, if you check the signature in 2yr, it remains valid.
Why ?

• Because the company X cert was valid at time the signature has been generated and this has been attested by a counter-signature done based on the timestamp and the cert validity.
• The counter-signature cert is valid for a super long time (10 years regulary renewed)
• Embedding the signed (by Global sign for exemple) signing time in the signature, prove the asset is authentic, even 2 years later when the company X cert has expired.

Imaged exemple in a windows binary

Maybe this point deserve another issue if it's not already covered and is not related to yours.

[yizha1]

Thanks @gillg for providing this useful information. It seems the purpose of countersignature is to extend the valid period of the original signature. This issue is about how to secure the authenticity of the signer at the signing time in the signature, so that it will not be tampered by bad actors.

[gillg]

Hum I see, without speaking about "bad actors" you don't want a user being able to "re-sign" an artifact (nevermind if it's the company A which sign again, or a company B which takes kind of ownership).
In the "binaries world", usually it's not a problem, because it's not really an attack vector until you don't tamper the artificial content. Changing the ownership is not "fair" but there is no risk.
I also see some valid uses cases or any incoming artifact in a company could only be accepted once audited and signed with the company cert to be valid and usable.

Possible solutions :

• Allow re-sign like it's the case for binaries
• Allow multiple chained signatures (with a max number limit?)

For the chained signatures I can imagine:

• To make the "root" chain signature kind of unremovable, the signing time could be countersigned, and the "verify" protocol should compare the signing time to the image creation time part of the last immutable layer. The time delta should be "reasonable" to be verified successfully.
• The second signature must counter-sign the previous one to create a chain, and it should be timestamp countersigned too.

As any blochain you can't prevent a full history rewrite as it remains valid, but we add flexibility to make the things clean in a "normal" use case.

So :

• Sign method should check if a previous signature exist
  • If not, it signs the image payload hash + counter-sign the timestamp. It fails or warn if the user took too much time to sign the image after building it.
  • if yes, it just counter-sign the previous signature + counter sign the current timestamp
• Verify method should check recursively the signing chain and the root signature time delta.

That's a random idea, free to discuss, but that seems cover reasonably your use case.
If someone really want to steal the ownership it could always alter some image layer to change the build date, but you can't definitely prevent that

[gillg]

Side notes because I was making more tests on notation.

• The COSE signature format supports counter signatures : https://datatracker.ietf.org/doc/html/rfc8152#section-4.5
• I saw there is a notation sign flag --expiry to force an expiration time, so in that case, the timestamp counter signature should just be absent

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days.