Scenario updates, incorporating scenarios, addressing PR feedback

[SteveLasker]

Incorporates feedback from #12
Signed-off-by: Steve Lasker [email protected]

[SteveLasker]

Can we get some 👀 on this so we can close these out?

[SteveLasker]

@JustinCappos, can you ack that we've captured the scenarios portion

[JustinCappos]

The document is really design heavy now. This covers a few cases but things like 7 only make sense in the context of a specific design, whereas 8 and 9 are much more general.

[SteveLasker]

The document is really design heavy now. This covers a few cases but things like 7 only make sense in the context of a specific design, whereas 8 and 9 are much more general.

Are you referring to the scenario or implications? Do you have a proposed edit so we can merge?

[JustinCappos]

The document is really design heavy now. This covers a few cases but things like 7 only make sense in the context of a specific design, whereas 8 and 9 are much more general.

Are you referring to the scenario or implications? Do you have a proposed edit so we can merge?

It's more of a conceptual change to parts of the document. Some of the content like this feels like it is quite specific to the technologies and not the goals / scenarios. I'm just going to cut and paste a few example, but the conceptual difference is something I'm seeing throughout.

"The ACME Rockets environment enforces various company policies prior to any deployment, evaluating the content in the SBoM. The policy manager trusts the content within the SBoM is accurate, because they trust artifacts signed by wabbit-networks. The src content isn't evaluated at deployment time and can be left within the registry.

1. Once the policy manager completes its validation, the deployment to the hosting environment is initiated. The SBoM is no longer needed, allowing the image to be deployed separately. A deploy artifact, referencing a specific configuration definition, may also be signed and saved, providing a historical record of what was deployed. The hosting environment also validates content is signed by trusted entities."

"The local environment has a policy by which it states the set of keys it accepts.

• The signing and validation of artifacts does not require a registry. The local host can validate the signature using the public keys it accepts.
• The key used for validation may be hosted in a registry, or other accessible location.
• The lack of a registry name does not infer docker.io as a default registry."

"Users may reference the sha256 digest directly, or the artifact:tag. While tag locking is not part of the [OCI Distribution Spec][oci-distribution], various registries support this capability, allowing users to reference human readable tags, as opposed to long digests. Either reference is supported with Notary v2, however it's the unique manifest that is signed."

I don't really know if this should be moved to a separate document, if general text should replace it, or if I'm just keying in on things that I shouldn't.

Perhaps @justincormack should weigh in also and say whether what I'm objecting to makes any sense.

[SteveLasker]

I don't really know if this should be moved to a separate document, if general text should replace it, or if I'm just keying in on things that I shouldn't.

@JustinCappos I think we're possibly seeing a view from different perspectives. There's a perspective that we need a signature solution to artifacts in a registry. A solution that can move with the artifact as it moves within and across registries. That does define a sandbox by which we're working within. In the call last week we discussed how we may need to tweak the sandbox, but we are scoping to storing signatures in a registry.
The work you've done in Tuf is about taking validation to a another confidence level. We've been talking about scope creep quite a bit, and how we can minimize that scope creep, working from a base that covers the scenarios and building upon it. For instance the generic SBoM references may refer to a Tuf implementation, a RedHat implementation or others.
Now I know @justincormack was thinking it might be more broad, and he was writing up something. This seems like the conversation we should be having. What is the scope of what we want to carve out here.

[directionless]

Forgive me if this is covered elsewhere, I'm quite new here -- what are the implications, and verifications, needed for this new key authenticity? I don't see it in the implications below.

[SteveLasker]

I'm leaving this open to see if we cover this in the key management working group.

[SteveLasker]

Thanks @tsaarni, great feedback I've incorporated into the latest update.

[SteveLasker]

I'm leaving this open to see if we cover this in the key management working group.