Additional qualifiers for oci type

[prabhu]

Re: https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst#oci

There have been a number of recent developments with oci.

• format:string - The OCI format could be docker, OCI, or dual
• encrypted:boolean, key:string, and recipient:string - OCI image could be encrypted using ocicrypt
• signed:boolean, signType:string - Signed using cosign or notation
• distribution:string - The distribution could be over ipfs
• snapshotter:string - The image might support lazy pulling using a snapshotter such as stargz|nydus|overlaybd|soci
• acceleration:boolean - Whether the image can be accelerated using bypass4netns

My proposed qualifiers are shown highlighted. Any thoughts?

[matt-phylum]

I don't know if encrypted is useful. If you have an image that's been decrypted, I assume you wouldn't know by looking at it that it was previously encrypted and how. If the idea is that a PURL represents the location of an image to pull, putting a plain text key in the PURL seems like something not to encourage.

Is signed useful? Are signed images retrieved differently from unsigned images such that whether the image is signed or not is important to its identity? It's generally not useful to know whether something is signed without knowing what constitutes a valid signature for it. Even when doing "keyless" signing, there is a signer ID that should be verified when checking whether an image is appropriately signed.

[prabhu]

Should've clarified. Key is the name of the key file to use and not the contents. An example is here.

Encrypted is useful. Since after decryption, we can't be 100% sure if it is the exact same image or if any content got changed post-decryption. So I would treat them as separate packages indeed.

signed is useful since it would reduce the need to parse the metadata to check if it has an annotation and what type. It is a qualifier that can be used to treat signed and unsigned images differently.

However, checking the docs it feels like cosign needs either certificate-identity and oidc-issuer or public key as values. notation requires only a key name. I don't know if these should also be included in the purl. Maybe not.