Signature Format Specification #93

shizhMSFT · 2021-07-23T16:09:43Z

Resolves #86

Signed-off-by: Shiwei Zhang <shizh@microsoft.com>

sudo-bmitch

General accessibility note: the math symbols used in the markdown are not readable with dark-mode enabled.

sudo-bmitch · 2021-08-04T18:14:59Z

signature-specification.md

+
+- Payload (![m](https://render.githubusercontent.com/render/math?math=%5Ctextstyle+m)): The data that is integrity protected - e.g. container image descriptor.
+- Signed attributes (![\mu](https://render.githubusercontent.com/render/math?math=%5Ctextstyle+%5Cmu)): The signature metadata that is integrity protected - e.g. signature expiration time, signing time, etc.
+- Unsigned attributes (![\hat\mu](https://render.githubusercontent.com/render/math?math=%5Ctextstyle+%5Chat%5Cmu).): The signature metadata that is not integrity protected - e.g. keyid, publickey, etc.


I'm not certain these are a requirement for the signature envelope unless the entire artifact wrapper is the envelope. E.g. if DSSE or JWT is the envelope, then unsigned data can be packaged external to that in the artifact object.

sudo-bmitch · 2021-08-04T18:17:58Z

signature-specification.md

+
+1. The signature envelope payload MUST contain a [descriptor](https://github.com/opencontainers/image-spec/blob/master/descriptor.md#properties) of the target manifest.
+    1. A descriptor MUST contain `mediaType`, `digest`, `size` fields.
+    2. A descriptor MAY contain the `artifactType` field for artifact manifests, or the `config.mediaType` for `oci.image` based manifests.


artifactType is not a known field in a descriptor. It should be included within the artifact object at a higher level.

/cc @SteveLasker for artifactType.

Please see artifact-descriptor to track the addition, starting the decoupling of artifacts and distribution spec from a particular artifactType - The container image

sudo-bmitch · 2021-08-04T18:19:59Z

signature-specification.md

+    1. A descriptor MUST contain `mediaType`, `digest`, `size` fields.
+    2. A descriptor MAY contain the `artifactType` field for artifact manifests, or the `config.mediaType` for `oci.image` based manifests.
+    3. descriptor MAY contain a `annotations` field.
+2. The signature envelope MUST be self contained to validate the integrity of the payload and signed attributes.


We may want to allow the certificate chain to be transmitted via a secondary method (e.g. a separate blob from the envelope). And the trusted signatures (roots, CA, etc) stored in the client trust store MUST be transmitted separately.

I have explored the idea of X.509 certificate blob caching in an unrelated project of mine (https://github.com/Devolutions/picky-rs/blob/master/docs/PICKY.adoc). It would be relatively simple to push individual X.509 certificates in ASN.1 DER binary format as raw blobs, and then refer to the certificate chain as a simple array of digests. In my implementation I have used multibase-encoded multihashes, but the regular digest notation used in OCI manifests should probably prevail. In all cases, please use the binary representation of the certificate, it's just simpler for blobs - all textual representations only exist to transfer the binary format over text. This being said, my own PKI server would use the certificate digest as the key and support calls to fetch the certificate in various formats - raw binary or PEM, to accomodate clients.

sudo-bmitch · 2021-08-04T18:22:28Z

signature-specification.md

+2. The signature envelope MUST be self contained to validate the integrity of the payload and signed attributes.
+3. The signature envelope MAY contain arbitrary user supplied information, as key value pairs. If included, it MUST be integrity protected.
+4. The signature envelope MAY contain information to determine the signature expiration time. If included, it MUST be integrity protected.
+5. The signature envelope MAY contain information to determine the signature revocation status. If included, it MUST be integrity protected.


Is this pointing to internet accessible revocation servers, and if so, how would a disconnected environment without access to the internet process this? Will clients be able to create a mapping from a public server to a private server that mirrors this information?

/cc @gokarnm for revocation

In the case of an X.509 certificate chain, revocation server URLs for CRLs and OCSP are already encoded as attributes in the certificate - encoding them in two places would create ambiguity. I don't know about the other formats but we should probably make it mandatory that we obey the data contained in the X.509 certificate with regards to revocation servers

sudo-bmitch · 2021-08-04T18:26:31Z

signature-specification.md

+3. The signature envelope MAY contain arbitrary user supplied information, as key value pairs. If included, it MUST be integrity protected.
+4. The signature envelope MAY contain information to determine the signature expiration time. If included, it MUST be integrity protected.
+5. The signature envelope MAY contain information to determine the signature revocation status. If included, it MUST be integrity protected.
+6. The signature MUST be detached a signature, with respect to the target manifest being signed.


What is the reasoning behind this requirement? This implies the signed data is the json subjectManifest field, and so we cannot verify that signature if the json parsers format the data differently than the original tool used to sign that manifest. I'd prefer we either:

bundle the data with the signature

make the signed data a string/byte array in the json envelope to avoid the need for canonical json

make the signed data a separate blob that does not need to be parsed and re-serialized back into a byte array

To see a potential ugly solution to this problem, Docker's signed manifest generated a canonical version of the json as a byte array https://github.com/distribution/distribution/blob/main/manifest/schema1/manifest.go#L102

Similar json formating is needed in in-toto to encode the json consistently to be able to sign those blocks: https://github.com/in-toto/in-toto-golang/blob/844d1a6ee032377281ff90da772f8b642e3eca08/in_toto/canonicaljson.go#L123

Assuming the signed data here refers to the payload, I did put the payload in the envelope as a byte array and sign that byte array so that there is no need for canonical json.

The payload has a descriptor of the signed manifest in the subjectManifest field. We use this descriptor to verify the signed manifest. We should have named subjectManifest in the payload as descriptor to avoid confusion. /cc @gokarnm

I think we should add a requirement to avoid the need for canonical json.

sudo-bmitch · 2021-08-04T18:28:35Z

signature-specification.md

+5. The signature envelope MAY contain information to determine the signature revocation status. If included, it MUST be integrity protected.
+6. The signature MUST be detached a signature, with respect to the target manifest being signed.
+7.  The signature MUST be stored and transferred in a signature envelope.
+8.  If the signature was produced by a X.509 certificate, the signature MUST contain a certificate chain of the signing certificate as an unsigned attribute. This MAY be a partial certificate chain.


The other option is to include this in the artifact as a separate blob, outside of the signature envelope. The advantage of the separate blob is that clients can cache the certificate chain in their trust store by digest, and avoid pulling it multiple times.

sudo-bmitch · 2021-08-04T18:29:06Z

signature-specification.md

+6. The signature MUST be detached a signature, with respect to the target manifest being signed.
+7.  The signature MUST be stored and transferred in a signature envelope.
+8.  If the signature was produced by a X.509 certificate, the signature MUST contain a certificate chain of the signing certificate as an unsigned attribute. This MAY be a partial certificate chain.
+9.  The signature MAY be timestamped by TSA, and this counter signature MUST be stored as an unsigned attribute.


Unsigned attribute or a separate blob in the artifact.

I actually want to avoid multiple blobs for a single signature or a single signature envelope as the signature might not be transferred via registries but files. If there are multiple blobs, we need to make a tarball first.

We already have at least 2 files today, the artifact json, and the envelope with the signature. Possibly 3 with the certificate chain. Those can be packaged back into 1 file with the data field on the descriptor (there's a PR for this in OCI image-spec). Or there's the OCI layout that's already used for packaging images as a tar.

sudo-bmitch · 2021-08-04T19:42:13Z

signature-specification.md

+1. The signature format MUST be able to store payload.
+2. The signature format MUST be able to store cryptographic signature.
+3. The signature format MUST support referencing and in-lining of different signing identity types represented as keyIds or X.509 certificate chains.
+4. The signature format MUST be able store unsigned signature attributes such as timestamp signature (TSA).


Unsigned attribute or a separate blob in the artifact.

sudo-bmitch · 2021-08-04T19:48:18Z

signature-specification.md

+3. The signature format MUST support referencing and in-lining of different signing identity types represented as keyIds or X.509 certificate chains.
+4. The signature format MUST be able store unsigned signature attributes such as timestamp signature (TSA).
+5. Signature format SHOULD be easy to implement using existing Go libraries (Docker CLI is implemented in Go).
+6. The signature format MAY be able store signed attributes. In case signature format doesn't support signed attributes, they can be combined with the payload before signing. Since the payload contains the signature specific metadata, the signature format loses the ability to store multiple signatures.


My preference is we assume the payload include all attributes being signed since that gives us flexibility to use different signature formats.

shizhMSFT · 2021-08-06T08:52:49Z

General accessibility note: the math symbols used in the markdown are not readable with dark-mode enabled.

@sudo-bmitch GitHub does not support LaTeX / KaTeX rendering natively. Do you have any suggestions on this?

sudo-bmitch · 2021-08-06T09:35:56Z

@sudo-bmitch GitHub does not support LaTeX / KaTeX rendering natively. Do you have any suggestions on this?

We should use images with a solid, rather than transparent background. Or consider removing the symbols and describe the content some other way.

Signed-off-by: Shiwei Zhang <shizh@microsoft.com>

dlorenc · 2021-08-11T14:23:29Z

I want to strongly voice my disagreement with this decision. JWS is a broken standard, and the rationale of "has an RFC" is not meaningful from a security perspective.

trishankatdatadog · 2021-08-11T14:25:00Z

I want to strongly voice my disagreement with this decision. JWS is a broken standard, and the rationale of "has an RFC" is not meaningful from a security perspective.

Which is why I'm in favour of supporting multiple signature formats. The real world is too messy to support only one.

dlorenc · 2021-08-11T16:35:05Z

Is there a decision making process here to get consensus?

I'd still really really like to agree on an interoperable signature format between cosign and notary v2, but I haven't seen any valid reasons to use JWS. Support for multiple formats as @trishankatdatadog suggested or a non-broken one would be ideal.

sudo-bmitch · 2021-08-11T18:16:11Z

signature-specification.md

+
+### Red Hat's Simple Signing - [Simple Signing](https://www.redhat.com/en/blog/container-image-signing)
+
+It is used by Red Hat for signing container image. Simple signing is *not a signature format* instead defines the payload format which is then signed using PGP to create detached signature. The payload format is adapted by atomic and later by [cosign](https://github.com/sigstore/cosign#payload-formats).


We should delete this section since it is not talking about a signature format. At most, include it in a "not considered" section of the doc with a reason why we didn't consider it.

sudo-bmitch · 2021-08-11T18:17:16Z

signature-specification.md

+
+### Signature format
+
+Recommendation is to **use JWS JSON Serialization** because of following reasons:


We should clarify this is the recommendation of the Microsoft and AWS crypto boards, and not that of the general Notary project community, unless we get consensus among the community.

sudo-bmitch · 2021-08-11T18:20:14Z

signature-specification.md

+
+- No published RFC (or draft).
+- New format that is used in few projects.
+- Does not currently support TSA signature and certificate(s) chain as part of the envelope. See [secure-systems-lab/dsse#42](https://github.com/secure-systems-lab/dsse/issues/42),  [secure-systems-lab/dsse#33](https://github.com/secure-systems-lab/dsse/issues/33).


I'd remove this as a concern since there are various ways to resolve this, including a wrapper around the DSSE envelope, keeping in mind that the OCI artifact layout is already a wrapper around what we're creating here.

sudo-bmitch · 2021-08-11T18:22:37Z

signature-specification.md

+- No published RFC (or draft).
+- New format that is used in few projects.
+- Does not currently support TSA signature and certificate(s) chain as part of the envelope. See [secure-systems-lab/dsse#42](https://github.com/secure-systems-lab/dsse/issues/42),  [secure-systems-lab/dsse#33](https://github.com/secure-systems-lab/dsse/issues/33).
+- Additional effort required to certify implementations with security groups of cloud service providers before adoption.


This seems like it should either be the only concern, with the other points nested below, or we should be listing the concerns of the crypto boards, rather than listing the board's approval as a concern.

+1 here, the reverse is also a concern. JWS does have a track record, but it's unfortunately not a good one. Many experts in the field explicitly recommend against it.

sudo-bmitch · 2021-08-11T18:24:13Z

signature-specification.md

+- New format that is used in few projects.
+- Does not currently support TSA signature and certificate(s) chain as part of the envelope. See [secure-systems-lab/dsse#42](https://github.com/secure-systems-lab/dsse/issues/42),  [secure-systems-lab/dsse#33](https://github.com/secure-systems-lab/dsse/issues/33).
+- Additional effort required to certify implementations with security groups of cloud service providers before adoption.
+- Being a new format, additional effort is involved to get the implementations reviewed and certified by the compliance & security boards of cloud service providers before its usage. This is a part of component governance which is considered as a strict requirement to adopt technologies and implementations in cloud environments.


This looks like repitition of the above.

sudo-bmitch · 2021-08-11T18:46:20Z

signature-specification.md

+
+Cons:
+
+- No published RFC (or draft) and not commonly used. Only known usage is [in-toto](https://in-toto.io) and that [implementation also diverges from specification](https://github.com/secure-systems-lab/dsse/issues/40#issuecomment-882771124).


TUF and cosign are also DSSE users (or at least considering), and each of those are CNCF or LF projects that would benefit from interoperability with Notary. I would consider that list of projects to be a strong Pro. It also means any organization that gets the approval to use one of these other projects will have an easier time getting other DSSE projects approved for use by their review boards.

lachie83 · 2021-08-12T20:35:03Z

Thanks for the feedback @dlorenc @trishankatdatadog. As stated during the discussion on the Notary community call on August 11 (recording and notes) JWS was proposed by both AWS and Microsoft after evaluating multiple formats for the following reasons:

JWS is an IETF proposed (RFC 7515) standard, RFC standards are arrived after industry wide review and consensus, and recognized by compliance bodies. A solution that is not built on well recognized standards can create additional friction for end customers, especially for ones operating in financial, healthcare, or government sectors who have specific regulatory and compliance requirements.
The concerns regarding vulnerabilities for JWS are well known, this was ackowledged in the evaluation, and can be addressed with an implementation that restricts usage of JWS to a specific subset (profile). These can be provided as libraries and specs for the Notary project that people can use as reference.
DSSE is a new standard (first public commit in Sep 1, 2020) without broad industry adoption, testing, or reviews (two projects with pending usage). There are few DSSE libraries available and a library that implements DSSE would likely need to be built to support Notary requirements. Given the high likelihood of compliance requirements from regulatory bodies as stated in point 1, leveraging an immature standard requires additional certifications which will delay usage and adoption of Notary. Using JWS allows Notary to leverage a mature standard that has broad adoption and libraries that have been tested by independent security auditors. We could use the initial implementation of JWS to create requirements and criteria to onboard subsequent standards like DSSE.

As Steve stated on the community call, we aren’t trying to shut the door on the DSSE. We are simply proposing a solution based on a mature standard while the DSSE standard gains more industry adoption. In addition, we are tracking a list of action items for DSSE support in Notary in the following PR.

SantiagoTorres · 2021-08-12T20:58:25Z

JWS is an IETF proposed (RFC 7515) standard, RFC standards are arrived after industry wide review and consensus, and recognized by compliance bodies. A solution that is not built on well recognized standards can create additional friction for end customers, especially for ones operating in financial, healthcare, or government sectors who have specific regulatory and compliance requirements.

I wonder if we should all just use PGP (rfc4880). It is approximately 2600 RFC units better and came earlier then.

If cryptography on PGP is an issue we can also come up with a special profile to avoid subpacket spam on keyservers and the use of MD5 and 3DES through a special profile for nv2.

dlorenc · 2021-08-12T21:01:25Z

My questions here are still mostly around the actual decision making and consensus process. It's clear this recommendation from AWS and Microsoft does not actually reflect broad community consensus, and this project still has no documented governance or process.

I also disagree with the original framing - the choice is not "JWS vs. DSSE", there are many other options, including just not using a signature wrapper at all (which is how cosign, minisign, signify, and many other tools work today, for example).

lachie83 · 2021-08-12T21:23:41Z

My questions here are still mostly around the actual decision making and consensus process. It's clear this recommendation from AWS and Microsoft does not actually reflect broad community consensus, and this project still has no documented governance or process.

Just to iterate as you were on the Notary community call yesterday. Justin stated that he is working with the maintainers on the governance process here.

I also disagree with the original framing - the choice is not "JWS vs. DSSE", there are many other options, including just not using a signature wrapper at all (which is how cosign, minisign, signify, and many other tools work today, for example).

I hear that you disagree with the framing. This is a proposal and we were providing some background on why we were proposing JWS vs DSSE as DSSE was one other standard that was proposed and investigated. An outcome could be that the maintainers decide to not use a signature wrapper at all as you mentioned.

trishankatdatadog · 2021-08-12T21:32:56Z

As Steve stated on the community call, we aren’t trying to shut the door on the DSSE. We are simply proposing a solution based on a mature standard while the DSSE standard gains more industry adoption. In addition, we are tracking a list of action items for DSSE support in Notary in the following PR.

Thanks for your reply, Lachlan. Like Dan said, my opinion is not even about JWS vs DSSE. It's about: how do we ensure that we don't lock-in users to one specific format from the beginning, and that we allow for a variety of formats in the first place? In other words: can we get an assurance right out of the gate that we won't be locked in to JWS? I understand that interoperability is a concern, but there are ways to work around it.

I also have two meta-questions:

Who are the "we"?
Does consensus really depend only on Microsoft and AWS? If so, it's not much of a governance.

SantiagoTorres · 2021-08-12T21:33:12Z

An outcome could be that the maintainers decide to not use a signature wrapper at all as you mentioned.

Which maintainers? what is there on notary v2 to maintain? The only contribution I've seen from Microsoft in this whole fiasco is trying to shoehorn a terrible standard (yes, they exist) into a project they've commited 0 commits to.

santiago at ~/.../programas/notary ✗ git shortlog -se | grep -i microsoft
santiago at ~/.../programas/notary ✗ git shortlog -se | grep -i coreos
     3	Luca Bruno <luca.bruno@coreos.com>
santiago at ~/.../programas/notary ✔ git shortlog -se | grep -i redhat
    33	Miloslav Trmač <mitr@redhat.com>
santiago at ~/.../programas/notary ✔ git shortlog -se | grep -i fujitsu
     1	Hu Shuai <hus.fnst@cn.fujitsu.com>
     3	Kim Bao Long <longkb@vn.fujitsu.com>
     3	Li Zhijian <lizhijian@cn.fujitsu.com>
     1	Nguyen Hai Truong <truongnh@vn.fujitsu.com>
     2	Vu Cong Tuan <tuanvc@vn.fujitsu.com>
santiago at ~/.../programas/notary ✗ git shortlog -se | grep -i huawei
     2	Hu Keping <hukeping@huawei.com>
   170	HuKeping <hukeping@huawei.com>
     2	Qiang Huang <h.huangqiang@huawei.com>

This is all but an open source project, let alone community.

dlorenc · 2021-08-12T21:38:45Z

Just to iterate as you were on the Notary community call yesterday. Justin stated that he is working with the maintainers on the governance process here.

Is this proposal on hold until after the governance is defined and maintainers are agreed upon?

lachie83 · 2021-08-12T21:45:04Z

As Steve stated on the community call, we aren’t trying to shut the door on the DSSE. We are simply proposing a solution based on a mature standard while the DSSE standard gains more industry adoption. In addition, we are tracking a list of action items for DSSE support in Notary in the following PR.

Thanks for your reply, Lachlan. Like Dan said, my opinion is not even about JWS vs DSSE. It's about: how do we ensure that we don't lock-in users to one specific format from the beginning, and that we allow for a variety of formats in the first place? In other words: can we get an assurance right out of the gate that we won't be locked in to JWS? I understand that interoperability is a concern, but there are ways to work around it.

I also have two meta-questions:

Who are the "we"?

Obviously that depends on the context but if I had to guess in the context of this proposal I would say "we" as in the community working on the Notary project.

Does consensus really depend only on Microsoft and AWS? If so, it's not much of a governance.

No, not at all but given that the Microsoft team created this PR we were sharing our perspective as part of this proposal. Has it been stated somewhere that consensus depends on Microsoft and AWS?

lachie83 · 2021-08-12T21:45:55Z

Just to iterate as you were on the Notary community call yesterday. Justin stated that he is working with the maintainers on the governance process here.

Is this proposal on hold until after the governance is defined and maintainers are agreed upon?

That's my understanding

trishankatdatadog · 2021-08-12T21:48:31Z

No, not at all but given that the Microsoft team created this PR we were sharing our perspective as part of this proposal. Has it been stated somewhere that consensus depends on Microsoft and AWS?

Unfortunately, it feels like it. Do Santiago, Dan, and I have reasons to believe otherwise?

lachie83 · 2021-08-12T21:50:51Z

An outcome could be that the maintainers decide to not use a signature wrapper at all as you mentioned.

Which maintainers? what is there on notary v2 to maintain? The only contribution I've seen from Microsoft in this whole fiasco is trying to shoehorn a terrible standard (yes, they exist) into a project they've commited 0 commits to.
santiago at ~/.../programas/notary ✗ git shortlog -se | grep -i microsoft
santiago at ~/.../programas/notary ✗ git shortlog -se | grep -i coreos
     3	Luca Bruno <luca.bruno@coreos.com>
santiago at ~/.../programas/notary ✔ git shortlog -se | grep -i redhat
    33	Miloslav Trmač <mitr@redhat.com>
santiago at ~/.../programas/notary ✔ git shortlog -se | grep -i fujitsu
     1	Hu Shuai <hus.fnst@cn.fujitsu.com>
     3	Kim Bao Long <longkb@vn.fujitsu.com>
     3	Li Zhijian <lizhijian@cn.fujitsu.com>
     1	Nguyen Hai Truong <truongnh@vn.fujitsu.com>
     2	Vu Cong Tuan <tuanvc@vn.fujitsu.com>
santiago at ~/.../programas/notary ✗ git shortlog -se | grep -i huawei
     2	Hu Keping <hukeping@huawei.com>
   170	HuKeping <hukeping@huawei.com>
     2	Qiang Huang <h.huangqiang@huawei.com>
This is all but an open source project, let alone community.

Thanks for the feedback @SantiagoTorres. There is work currently happening to define a governance structure happening in this PR.

dlorenc · 2021-08-25T12:34:58Z

Even more recent discussion from security experts on why not to use JWTs, and some alternatives: https://fly.io/blog/api-tokens-a-tedious-survey/

DSSE and the cosign strategy of "no wrapper" are most similar to the "protobuf tokens" approach outlined here. DSSE takes a further step of protecting the payload format at the expense of simplicity. Cosign stores the fields separately rather than concatenating strings because we have plenty of fields to store things in.

shizhMSFT · 2021-09-26T08:29:51Z

signature-specification.md

+    - `reserved`: Collection of attributes reserved for notary v2 use such as artifact revocation list (ARL), identity, etc.
+    - `custom`: Collection of user defined attributes such as buildId, imageScanned, etc. Use of this field is OPTIONAL.
+- `iat`: Issued at identifies the time at which the JWT was issued. This claim MUST be present.
+- `exp`: Expiration time identifies the expiration time on or after which the JWT must not be accepted for processing. This claim MUST be present.


@priteshbandi The field exp is inconsistent with the specificaiton.

In the specification, it is OPTIONAL but here is a MUST.
It also conflicts with the section Artifact Expiry Validation in #98

shizhMSFT added 4 commits July 23, 2021 23:28

initial spec

d12e8e8

Signed-off-by: Shiwei Zhang <shizh@microsoft.com>

render LaTeX symbols

3a19453

Signed-off-by: Shiwei Zhang <shizh@microsoft.com>

refine format

91abf80

Signed-off-by: Shiwei Zhang <shizh@microsoft.com>

sync with latest HackMD

691f367

Signed-off-by: Shiwei Zhang <shizh@microsoft.com>

sudo-bmitch reviewed Aug 4, 2021

View reviewed changes

shizhMSFT added 5 commits August 11, 2021 19:51

replace latex with simple letters for dark mode

d25333a

Signed-off-by: Shiwei Zhang <shizh@microsoft.com>

amend recommendation

b0d7850

Signed-off-by: Shiwei Zhang <shizh@microsoft.com>

reword jwt library in the recommendation section

5041d0f

Signed-off-by: Shiwei Zhang <shizh@microsoft.com>

add explored signature formats

3267491

Signed-off-by: Shiwei Zhang <shizh@microsoft.com>

beautify code

47655b8

Signed-off-by: Shiwei Zhang <shizh@microsoft.com>

sudo-bmitch reviewed Aug 11, 2021

View reviewed changes

shizhMSFT changed the title ~~Discuss Signature Specification~~ Signature Format Specification Sep 8, 2021

sudo-bmitch mentioned this pull request Sep 8, 2021

Finalize the signature/envelop spec #99

Closed

shizhMSFT mentioned this pull request Sep 24, 2021

JWS-based Notation Go Library notaryproject/notation-go#11

Merged

shizhMSFT commented Sep 26, 2021

View reviewed changes

iamsamirzon added alpha-1 and removed alpha-1 labels Sep 28, 2021

iamsamirzon added this to the alpha-1 milestone Sep 28, 2021

iamsamirzon modified the milestones: alpha-1, Artifacts: RC1 Sep 28, 2021

SteveLasker mentioned this pull request Oct 12, 2021

Signature specification #102

Merged

shizhMSFT closed this Oct 13, 2021

priteshbandi mentioned this pull request Oct 14, 2021

Release Candidate Signature Format #105

Closed

2 tasks


		### Red Hat's Simple Signing - [Simple Signing](https://www.redhat.com/en/blog/container-image-signing)

		It is used by Red Hat for signing container image. Simple signing is not a signature format instead defines the payload format which is then signed using PGP to create detached signature. The payload format is adapted by atomic and later by [cosign](https://github.com/sigstore/cosign#payload-formats).


		### Signature format

		Recommendation is to use JWS JSON Serialization because of following reasons:


		Cons:

		- No published RFC (or draft) and not commonly used. Only known usage is [in-toto](https://in-toto.io) and that [implementation also diverges from specification](https://github.com/secure-systems-lab/dsse/issues/40#issuecomment-882771124).

Signature Format Specification #93

Signature Format Specification #93

Conversation

shizhMSFT commented Jul 23, 2021

sudo-bmitch left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

shizhMSFT commented Aug 6, 2021 • edited Loading

sudo-bmitch commented Aug 6, 2021

dlorenc commented Aug 11, 2021

trishankatdatadog commented Aug 11, 2021

dlorenc commented Aug 11, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lachie83 commented Aug 12, 2021

SantiagoTorres commented Aug 12, 2021

dlorenc commented Aug 12, 2021

lachie83 commented Aug 12, 2021

trishankatdatadog commented Aug 12, 2021

SantiagoTorres commented Aug 12, 2021

dlorenc commented Aug 12, 2021

lachie83 commented Aug 12, 2021

lachie83 commented Aug 12, 2021

trishankatdatadog commented Aug 12, 2021

lachie83 commented Aug 12, 2021

dlorenc commented Aug 25, 2021

Choose a reason for hiding this comment

shizhMSFT commented Aug 6, 2021 •

edited

Loading