OCI image SHOULD contain current and N future (X25519/ED25519) public keys

[taqtiqa-mark]

TL;DR: Stay focused/specialized. Make the spec compatible with OpenBSD type workflows, i.e using signify|minisign type tools and permit self trusted updates/upgrades of containers.

Adopt X25519/ED25519 alone and put in place the data for the emergency when you have to abandon that. Force tools like rkt to put in place mechanisms to deal with the emergency that comes once in 'the heat death of one universe' :)

Isolate transport-protocol/source-of-image issues from trust of image issues.
That is don't care how an image gets to me. Allow me to easily trust an image and once trusted, allow that image to contain the public keys that then permit auto-trusted updates/upgrades.

Background, these rkt issues:
rkt/rkt/issues/3753, rkt/rkt/issues/3757

I doubt I could say more than you get from reading these sources, [1], [2], [3]
[1]: http://www.openbsd.org/papers/bsdcan-signify.html
[2]: https://www.tedunangst.com/flak/post/signify
[3]: https://jedisct1.github.io/minisign/

Hope that helps?

[wking]

Cross-linking earlier signing discussion in #22, #176, #400, and #445. For this proposal in particular, I'd rather have the OCI approach to signing (whatever it happens to be) be generic enough so that users can use OpenPGP/signify/minisign/… as they see fit. I expect all you'd need to support that would be media types for each signature format. OpenPGP already has a application/pgp-signature media type [1], but I'm not sure about signify/minisign. Then the OCI can recommend implementations support as many formats as it sees fit to encourage compatibility. *Forcing* support for anything in this space is unlikely. For example, the scope table lists “Specifying way to attach signatures” as an optional layer [2]. And consumers will always be able to add extension media types to cover features they think are missing or poorly done (hopefully striking a good balance between fragmenting the community and pushing it forward). [1]: https://tools.ietf.org/html/rfc3156#section-9.2 [2]: https://www.opencontainers.org/about/oci-scope-table

[stevvooe]

While OCI isn't opinionated about signing method, content digests provide a solid base for whatever signing method that users may choose. Such a provision also does a great job of separating transport and trust. Note that this works in practice in conjunction with Docker Notary.

Apart from that, mandating a particular algorithm for signing crypto is way outside the scope of this project.

Lacking a concrete proposal, I move that this be closed.

[taqtiqa-mark]

[update]: @stevvooe, I just had look at Docker Notary, now in CNCF. I don't think there is a need for all that overhead. The OpenBSD model works as best I can tell. I has the benefit of encouraging establishing initial trust at the only level it counts - person to person. Notary might solve a problem, I just don't see that the problem is here.

Can you identify something in the OpenBSD model that is exploitable that Notary solves? If not, then why drag all that overhead in? Of course if you need notary to have a secure set up, or tools only support notary, or some such service, then things just get very complex for me and I probably would start to think about paying someone to take care of all these complex moving parts. But that isn't the purpose of the spec.

Ack there is no appetite for requiring a particular signing algorithm. However, if you read the OpenBSD reasoning the logic is hard to argue with as a minimum requirement. This would also simplify one part of the implementation that can get very comlpex:

The complexity of the code is also a factor. All those complex features require lots of complex code, which balloons the size of the import and makes auditing nearly impossible. Even if a perfect PGP codebase existed, how would we be able to identify it? Or as Prof. Green put it, "Can someone who built GnuPG 2.1.1 on Debian/Ubuntu give me a hint on which libgpg-error you used?" If he doesn't which libgpg-error to use, I doubt I'm going to pick the right one.

There is no permanent lock-in, you change change the spec if someone can identify some functionality that is thwarted by the algorithm choice.

Additionally, we have an automatic upgrade path established if we need to switch to a different algorithm.

Does the OCI spec have this upgrade path?

Next, I can't see what is objectionable with the spec requiring tools support the following sound practice:

So, if you upgrade every release, you will have an unbroken chain of keys back to your initial installation. We don't directly sign keys with keys, however, but the next key is implicity signed by its inclusion in a signed release. Each key is tied to a release and only used for artifacts relating to that release.

Of course requiring the tool chain support this practice, does not mean the tools support only this practice. Thats a false choice.

Finally,

There are no key servers for signify. No web of trust. Just keys. The good news is the keys are pretty small. As demonstrated. We can stick them just about everywhere, and we do. They're on the web site, they're on twitter, they're on the top side of CD. 56 base64 characters. You can read it out loud over the phone in under a minute.

No servers? - yeah! Human to human verification? - yeah!
But not so much yeah if someone is contemplating a business model where you charge for running keyserver as part of the 'convenience of hosted SaaS infrastructure'.

Really, lets keep it secure and simple.

No keyservers leaking into the infrastructure. - please can the spec make sure they can't creep in ?

[vbatts]

In reviewing this, while I do like the signify approach and glad that OpenBSD is hardening it, it does also make it difficult that there is no portable project for it. With that code living in a massive CVS tree, intending only to be built on OpenBSD, it makes for a stunted broader conversation.

I personally do not like requiring keyservers.

Regardless, a couple of approaches here would be:
A) establish for your image build, a known path inside the extracted/applied rootfs. (/etc/image/release.N.key)
B) use image-index annotations where the hashmap key (not crypto key..) name is some reverse dns schema (like com.example.release.key.N) and the value is the base64 contents of the public key
C) tack on a field to the image index, like X-keys (X prefix like experimental HTTP headers) and then have a list of structures with info about the key (date, monotonically increased number, etc) and then the contents of the public key.

With all three approaches you have the content you are wanting/needing, and it still doesn't break any other implementation that your image may pass through.

[vbatts]

Furthermore, are you away of container-like efforts for openbsd? or is vmctl the closest thing?

[taqtiqa-mark]

Apologies, given the response from @stevvooe I didn't pursue this. I think I understand your point about signify not living in its own project.

Would this be enough?:
https://github.com/aperezdc/signify

I'm not aware of container-like efforts for openbsd, but I also haven't looked for that effort.

Hope that helps?

[vbatts]

That is a shame that Stephen's response would shutter the idea. I think the approach is still viable, regardless of whether some tool like Docker notary has its own approach.

Thanks for that link to a portable version. Curious I didn't find it in my searches.

I'll close the issue for now, but do think that those looking to leverage multiple approaches should be encouraged to do so. I'm interested in seeing signify get broader usage than just the openbsd project.

Thanks!

[taqtiqa-mark]

I still stand by this idea as an element for the OCI spec, see my April 11 response.
As best I can tell all the required pieces are available for an implementation.

Does closing this now mean it has been considered for inclusion in the spec, and rejected?

[vbatts]

@taqtiqa-mark the closing is not a rejection of the concept, but for the specific guidance to be included in the spec itself. As I see it, nothing is stopping anyone from using the OCI image spec in the ways outlined #717 (comment)
So, my recommendation stands that anyone looking to pursue a signify + OCI implementation try their hand at an implementation, and publish a write up on it.