-
Notifications
You must be signed in to change notification settings - Fork 643
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
signing: start discussion on signing #22
Comments
@stevvooe Is there a doc somewhere that describes the notary API in detail not just the CLI tool. Reading through the docs I couldn't find anything that someone wishing to verify name example.com/app with hash |
@philips Check out the advanced documentation. It demonstrates the use of a text file. For signatures, the key will be to focus on the signing target, be it a primary artifact or a hash. This is the commonality of all these schemes. In general, we found inline signatures to be problematic, as it changes the artifact. We've mostly deprecated the original inline signatures in Docker HTTP Registry API V2. Using the manifest list is an interesting proposition, but it may be as problematic in practice, as updates need to be coordinated. In general, manifest lists aren't necessarily on the happy path, since they are more likely to be used when distributing multi-platform artifacts. |
On Wed, Apr 13, 2016 at 11:01:25PM -0700, Brandon Philips wrote:
This sounds like “non-CAS stuff in the CAS engine”, which seems like a
This seems like the best approach to me. It's still going to have the |
For a take on this, take a look at https://cyberphone.github.io/openkeystore/resources/docs/jcs.html It specifies ordering and scope of subobjects that are signed. |
As another alternative in this space, there's the approach taken by TUF, which creates an object like:
where they use Canonical JSON to form the byte sequence to be signed based on the |
On Wed, Apr 20, 2016 at 08:15:37PM -0700, Kamal Marhubi wrote: That sounds like a reasonable approach as far as signing sub-objects For a more detailed sketch of how signing might work, see 2. And |
One time artifact generation with unattached signatures is the sweet spot for content addressable, sign-able content. Anything else creates too high of an engineering burden to maintain flexibility under future changes. @kamalmarhubi We employed something similar in docker, except we used "prettyjws" version of it. The primary problem is that the target of the signature needs to be unpacked from that format and indexed separately. Otherwise, each time you sign it, you get a different id. This makes the JWS format worthless for CAS applications since to get any benefit, you have to disassemble the content. |
@stevvooe I think that makes sense. Since we're distributing multiple blobs and manifests as part of an image, it sounds simpler to have "sidecar signatures". |
Moving to v0.2.0 as I don't think anything actionable has come out of this yet. |
Actually, moved to v1.0.0 as I don't think anyone has really stepped up to own/help here on OCI signing. |
fair. It does make me think, once examples like this bubble up and folks have options to choose from, there may need to be additional media-types/MIME-types for signature objects. |
On Tue, May 24, 2016 at 02:12:32PM -0700, Vincent Batts wrote:
I expect these already exist. For example application/pgp-signature |
I meant to move this to post-v1.0.0 as no one has stepped up and as it is an optional layer of the spec. Please discuss if anyone objects to this change @opencontainers/image-spec-maintainers. |
@philips According to the proposal, this is part of the 1.0 specification. While it is optional for implementors, that proposal is unclear whether it is optional to specify the features for a first release of the specification. Technically speaking, I'm fine with moving this past 1.0. We know how to do signatures and naming in the current object layout without introducing backwards incompatibility. |
On Wed, Jun 08, 2016 at 04:39:59PM -0700, Brandon Philips wrote:
I've pulled some of my previous suggestions on signed name assertions |
@wking , are you working on signature spec? I've read the sign issues and related technology. It seems that |
@wking May I take on this? I think I may implement signature spec and present a draft pr later, referred to issues discussion. Thanks a lot! |
On Mon, Aug 29, 2016 at 06:36:40PM -0700, xiekeyang wrote:
I'm not a maintainer or PR gatekeeper ;). But I'm if you want to take |
@wking , @opencontainers/image-spec-maintainers Here I want to confirm 3 points with you, thanks lots. 1. signature targetTechnically, we can sign any object. 2. signature list[1] shows that you suggest to build signature list in spec. I'm not sure the use case on it. 3. TUFIf oci signature must comply with TUF? Or just match fields definition in Json Web Signature? [1] #23 (comment) |
On Tue, Aug 30, 2016 at 06:56:01PM -0700, xiekeyang wrote:
I think it's better to make the definition generic and emphasize that I agree that signed name-assertions will frequently be on individual As long as manifest-lists are not signed, you'll want any Publishers should be free to pick whichever of these approaches works
Multiple signatures allows you to support situations like:
|
@opencontainers/image-spec-maintainers I investigate the technology and present my understanding here. It is my draft document, with brief description in each section. If there is any missing point in my comment, please point out directly. The reference document includes,
CAS Content Signature SpecificationThe mainly goal of spec is:
Content Signature ListThe signature list points to the individual signatures for specific image manifests for one or more platforms. Content Signature List Property Descriptions[...] (these refer to manifest list field desc) Example Content Signature List{
"schemaVersion": 2,
"mediaType": "application/vnd.oci.image.signature.list.v1+json",
"signatures": [
{
"mediaType": "application/vnd.oci.image.signature.v1+json",
"size": 7143,
"digest": "sha256:e692418e4cbaf90ca69d05a66403747baa33ee08806650b51fab815ad7fc331f",
"platform": {
"architecture": "ppc64le",
"os": "linux"
}
},
{
"mediaType": "application/vnd.oci.image.signature.v1+json",
"size": 7682,
"digest": "sha256:5b0bcabd1ed22e9fb1310cf6c2dec7cdef19f0ad69efa1f392e94a4333501270",
"platform": {
"architecture": "amd64",
"os": "linux",
"features": [
"sse4"
]
}
}
],
"annotations": {
"key1": "value1",
"key2": "value2"
}
} Content SignaturesThe content signatures is based on TUF. Signatures patten involves one or more signatures, because that image publisher and observer may co-sign the object, and client should validate all of which. Content Signatures Property Descriptions[...] Example Content Signatures{
"signatures": [
{
"keyid": "7fc757801b9bab4ec9e35bfe7a6b61668ff6f4c81b5632af19e6c728ab799599",
"method": "ecdsa",
"sig": "Q2YkzUU2dTwanLhtiKd+FogRxi33GmFiX9EreHcyvRNjDU+2hPQwpoKSxlILAoXLxhqA9d7ixDmxmZhyXAzjiQ=="
}
],
"signed": {
<signed object>
}
} As for Name Delegation Design issue, tuf presents the way to design name delegation, which is applied in Docker Notary. I've not solid idea yet. Maybe we can start this section after first signature spec presented. |
On Tue, Sep 06, 2016 at 04:24:38AM -0700, xiekeyang wrote:
This should probably be a PR so it's easier to keep track of review |
Per the face-2-face at LinuxCon.EU, it was generally agreed that the spec ought to at least mention the points that are signable, even if not declaring a method to do the signature. Like the manifest as primary target to be signed, even though nothing is stopping from detached-signatures on all the blobs. |
On Thu, Oct 06, 2016 at 10:27:14AM -0700, Vincent Batts wrote:
I think there are valid cases for signed name-assertions on both the You can sign a name-assertion for the config too and can use diff_ids So I don't think there's a clear winner for a generic
|
I can't stress the importance of #22 (comment) by @vbatts. For signatures to work and be compatible across implementations, we need to define two aspects:
Number 1 must come before number 2 or we risk a vertically integrated, incompatible mess. To be clear, this will not be successful if this becomes a file-format discussion, as that won't solve the problem. TL; DR We need to define an interface to the signing world. |
On Tue, Oct 18, 2016 at 11:59:19AM -0700, Stephen Day wrote:
I don't think there's one clear thing to sign 1. And I don't think a. Adding information to the original descriptor. For example (a) is one fewer type to define and one less round-trip when fetching, |
I believe the work with the subject and referrers API in distribution-spec has created the bridge needed by signing tools to attach signatures to images. That would be option number 1, the detached signature. This is currently used by sigstore/cosign and notary/notation. I'm going to close this for now, but if there's anything missed, let me know and we can reopen it. |
This project should "specify a way to attach signatures". There are a few different approaches that could be taken based on prior art:
1 Detached signature sitting alongside each CAS object (this is the approach appc takes)
2. Inline signatures in the manifest list, putting things into the JSON objects themselves won't work, obviously.
3. Completely external signing with a signing server (this is the approach notary takes).
The text was updated successfully, but these errors were encountered: