Extending DSSE to accept optional signature specific metadata

[shizhMSFT]

Is it possible to extend the DSSE spec to have optional fields in order to support signature specific metadata like TSA (discussed in #33)?

The signature specific metadata includes authenticated signature metadata and unauthenticated ones. For example, TSA data are unauthenticated by the signing key as it is authenticated using other keys. Authenticated signature metadata can contains signature expiry, signature revocation information, etc..

References: Notary V2 - Signature Format

[shizhMSFT]

/cc @gokarnm

[MarkLodato]

This seems to be the same request as #36, which we have closed as "wontfix". Adding arbitrary header support would essentially be reinventing JWS. If those features are needed, could your application use JWS instead? Or am I misunderstanding the request?

It seems fine to consider specific headers on a case-by-case basis, but we should set the bar high for doing so. The whole idea of a "dead simple signing envelope" is that it's simple and hard to screw up. The more complexity we add, the more room for mistakes. Again, the simplicity is a differentiator from JWS.

For the specific features listed:

• TSA is indeed being considered in Design: Where to put timestamps in envelope? #33.
• Signature expiration seems to me like an anti-pattern (though I could be mistaken).
  1. Inconsistency between libraries leads to vulnerabilities. Just look at https://jwt.io/#libraries-io - some libraries honor the timestamp fields, some don't. If your application assumed expiration was taken care of but wasn't, you'd be vulnerable.
  2. In most cases, I believe the expiration should be application-specific, thus part of the payload. For example, what does it mean for an in-toto attestations to be expired? In most cases, what is really desired is to set a policy on the maximum age of the attestation. In this case, the expiration doesn't belong in the attesation at all but instead in the policy (layout).
• Signature revocation - not sure what you mean here. Usually I think of certificate revocation.

[mnm678]

Also, as discussed in #35, metadata about signatures, including the algorithm and expiry, should be distributed alongside the key using a secure mechanism (such as delegation, etc), and not protected by the key itself.

[shizhMSFT]

Also, as discussed in #35, metadata about signatures, including the algorithm and expiry, should be distributed alongside the key using a secure mechanism (such as delegation, etc), and not protected by the key itself.

Here the expiry means the signature expiry not the key expiry. Literally, the signature expiry controls the expriy of the signature, not the key.

[gokarnm]

Hi @MarkLodato, I'll add some more context for this request. We are considering if DSSE can be used for container signing using Notary V2 and here are the draft requirements - Notary V2 - Signature Format. The basic payload is an OCI descriptor.

• Signature Expiry - Allows customers to define validity of the signature that is shorter and independent of the signing key validity. Details here Notary V2 Signature Expiry. The requirement is for signature expiry to be a signed attribute. Signature expiry probably should be part of wrapped payload as it is application specific. And there may be issues to support it as a top level signed header, like being misinterpreted or ignored by different libraries for this simplified signature format.

• Signature revocation - Allows customers to invalidate individual artifacts without requiring them to invalidate a key in cases where a single artifact is affected (e.g. incorrect artifact was signed, or a vulnerability exists in the artifact). Details here - Notary V2 Rescinding signatures. The requirement is for storing metadata to support querying for signature revocation (like an OCSP endpoint, details not finalized) as a signed attribute. This too can go in wrapped payload.

• Custom metadata - These are customer defined key-value pairs containing any attributes that should be signed, these can be informational or customers can use these to perform additional validation after the signature is validated (e.g. machine name, did artifact pass tests and scanning). This can go in the wrapped payload.

There is another ask, we want to store the x.509 certificate or certificate chain of the signing entity in the envelope, KeyID does not seem to be the correct attribute to store it, can this be supported through another top level attribute?

/cc: @shizhMSFT , @mnm678 , @dlorenc

[dlorenc]

IMO this doesn't need a top-level field, and we can do all of this inside the "payload", by adding another level of indirection. Here's roughly how I would structure it:

[gokarnm]

I agree we could use a wrapped payload that has the descriptor and other metadata fields (signature expiry, custom metadata etc.)

What about the certificate chain, it will contain the public key and will be used to validate the signature.

[dlorenc]

We discussed storing this in a separate blob on Friday.

[shizhMSFT]

IMO this doesn't need a top-level field, and we can do all of this inside the "payload", by adding another level of indirection. Here's roughly how I would structure it:

It is less optimal solution, rendering the envelope can only contain 1 signature if the payload contains signature specific metadata.

If we wrap the signature specific metadata for signature A in the payload. Later, we cannot add another signature to the envelope since we cannot wrap the signature specific metadata for signature B in the payload as the payload is immutable.

[TomHennen]

@dlorenc do you have any more details about storing the certificate chain as a separate blob?

[trishankatdatadog]

@dlorenc do you have any more details about storing the certificate chain as a separate blob?

I don't understand this comment either. Dan, do you mean distributing the PKI metadata inside the signed payload, ala TUF?

[trishankatdatadog]

It is less optimal solution, rendering the envelope can only contain 1 signature if the payload contains signature specific metadata.

If we wrap the signature specific metadata for signature A in the payload. Later, we cannot add another signature to the envelope since we cannot wrap the signature specific metadata for signature B in the payload as the payload is immutable.

There is some confusion here, I believe.

We need to strictly separate signature-specific metadata (such as #33) from signature-agnostic metadata (such as public key distribution and revocation). Please see the TUF specification (for example, the root role) to see how you may distribute and revoke keys inside signed payloads without signature-specific metadata.

[dlorenc]

I don't understand this comment either. Dan, do you mean distributing the PKI metadata inside the signed payload, ala TUF?

Sorry! This was about the notary use case specifically. The PKI metadata does not actually need to be stored in the DSSE envelope, it can be stored somewhere else. In Notary/OCI use cases, we have no real limitation to get everything into one envelope, we can use multiple "blobs" that are all within the same image.

[gokarnm]

We need to strictly separate signature-specific metadata (such as #33) from signature-agnostic metadata (such as public key distribution and revocation)

@trishankatdatadog, the X.509 certificate chain is for the party that produced the signature, similar to PKCS#7 (CMS) cert_info or JWS x5c attribute. Would that fall under signature-agnostic metadata? In Notary V2 usecases consumers of the signed image who use a PKI will probably configure trusted keys/roots (which the signing party may chain to) and revocation information through an out of band mechanism.

@dlorenc, it may be simpler for a specific signing component (say a PKCS#11 provider, or a signing service which knows about the certificate chain/PKI metadata) to produce a single DSSE envelope which includes all the information including PKI metadata, and Notary V2 CLI or Docker CLI (which offloads the sign operation to the signing component and does not know about the certificate chain) to create the signature manifest for the signature envelope (blob). At least that's the way I've been thinking about this.

[TomHennen]

I thought I'd replied to this earlier today, but it seems to have gotten lost. :(

What if we defined another format that could carry the cert-chain along with a bundle of attestations (in-toto/attestation#38).

E.g.

# Both <in-toto provenance> and <container native provenance> are likely built by the same
# builder and so would very likely use the same cert chain.
{
  "payloadType": "application/vnd.in-toto+json",
  "payload": "<in-toto provenance>",
  "signatures": [{"keyid": "certchain://my-cert-chain-name", "sig": "<Base64(Signature)>"}]
}
{
  "payloadType": "application/vnd.in-toto+json",
  "payload": "<container native provenance>",
  "signatures": [{"keyid": "certchain://my-cert-chain-name", "sig": "<Base64(Signature)>"}]
}
{
  "payloadType": "application/vnd.dsse-cert-chain+json",  # Or maybe this could just go in an in-toto Statement, /shrug
  "payload": "<encoded cert chain>",
   # No DSSE signatures necessary since I gather that's handled by X.509 cert chains.
  "signatures": []
}

might look something like this before encoding

{
  "_type": "certchain" # or whatever
  "name": "my-cert-chain-name"
  "chain": "<the chain>"
}

This would allow the chain to be propagated with all attestations (after we get bundling figured out) and remove duplication of chains. People that don't care or want it stored in a separate place (like Notary/OCI) could easily grab the chain payload and then stick it in the place they want without impacting anything else.

Thoughts?