[User Story] - Notation sign/verify Tag to Digest translation

[iamsamirzon]

As a signer or verifier, I want to specify a tag and ensure there is a translation to the digest so that I can properly sign and verify images.

• [x] https://github.com/notaryproject/notation-go/issues/81
• [x] https://github.com/notaryproject/notation/issues/194
• [x] https://github.com/notaryproject/notation/issues/304
• [x] https://github.com/notaryproject/notation/issues/303
• [ ] Update docs/help to ensure people are aware of this capability/behavior

Original text: Desire : To help scenarios where users want to sign with Tag, but base Notation only supports digest signing, this wrapper layer will bridge the gap. Outcome : A reference implementation in Notation that allows users to pass a tag ( with a --force flag) that clearly articulates that is not a recommended approach. For signing, Notation should return the digest it signed and not the tag the user passed.

[iamsamirzon]

@SteveLasker - This is the one we were thinking of pushing out of RC-1.

[dtzar]

Migrate to https://github.com/notaryproject/notation/issues/194

[SteveLasker]

notation sign registry.wabbitnetworks.io/net-monitor:v1 is already implemented to convert :v1 to a digest and sign the digest. If the ask is to change the behavior to requiring a --force flag, I'm not sure what that really does to change the behavior. If the step in the workflow only has a tag, how would the user get the digest for the tag? How is that any different than passing in the tag and having notation sign do the conversion? From a doc perspective, we could, and should show notation sign registry.wabbitnetworks.io/net-monitor@sha256:abc123... so the users that have digests would be promoted to do so. Even the helper text for notation sign should emit the example. Just not sure I buy the value of --force.

[iamsamirzon]

@gokarnm - Could you capture your concern about including "tag to digest" capability with our without the "force" flag as described above by @SteveLasker . Are you recommending we not include this capability at all for RC-1 ? Could you point out the threat model here if we ship with this capability here?

[dtzar]

@iamsamirzon Closing since this is now on the RC-1 roadmap - issue linked above.

[iamsamirzon]

@dtzar - I suggest we reopen it and close it after the actual work is completed in Notation.

[dtzar]

Reopening until we potentially land on something other than roadmap. https://github.com/notaryproject/notaryproject/issues/104

[iamsamirzon]

Thanks @dtzar - I have moved it back in the "To do" column in the project board.

[iamsamirzon]

We need to define the CLI Spec to ensure the experience is agreed on what users will have to do.

[dtzar]

@iamsamirzon @gokarnm @yizha1 - Per what Steve says above, I'm still unsure of what is missing in implementation since today as I understand it - if you specify a tag, we translate it and sign a digest.

As a related side note I do believe we need to have a better experience than spitting out the SHA/digest after a sign/verify so they have more details as to what they're signing - but this is a separate concern.

[iamsamirzon]

@dtzar - What's missing is the agreed on spec on what we want as the behavior for translation from tag to digest translation. If we agree on the spec, and then the current implementation matches the spec we agree to, then we can say no work is required

As an example, if at some point, we want to natively support "Tag signing" ( Refer #16 and https://github.com/notaryproject/notaryproject/issues/43) , then we can't go back and change the behavior we agree here for this roadmap item.

[dtzar]

Per community call today, converting this to implementing the UX experiences so people understand what it is that they signed or verified. We already today do the tag to digest translation for sign and verify. However, people have no confirmation of what they signed or verified with what certificate(s).

We also need to do a pass on the documentation to ensure this is properly reflected.

[yizha1]

Closed as completed