Add field for certificate chains, or explain alternative solution

[MarkLodato]

(Forked from #39.)

There are several use cases for transmitting a certificate chain alongside the signature. We should either:

• Add a certificate field with clearly defined semantics that avoids known pitfalls; or
• Reject this idea and add a FAQ explaining what alternatives we recommend.

Personally I have no objections to adding a field, but I'd like to hear from others to explain what the concerns are.

/cc @trishankatdatadog @laurentsimon @shizhMSFT @gokarnm @TomHennen @dlorenc

[trishankatdatadog]

My concern is that if we slowly add more and more optional, unsigned fields like this, we risk accidentally turning DSSE into SSE (and eventually SE).

At the same time, I realize that this is a common use case with other signing envelopes, especially JWS. Maybe we could an add an optional attribute called "custom" or something similar, where people can stick in whatever extra metadata they like, such as cert chains, with the understanding that none of this stuff is signed. What do others think?

[mikhailswift]

The main issue with putting it in a custom field would be interoperability between applications using DSSE. An informal agreement would have to be made upon which custom field to use versus being able to refer to a standard.

[trishankatdatadog]

The main issue with putting it in a custom field would be interoperability between applications using DSSE. An informal agreement would have to be made upon which custom field to use versus being able to refer to a standard.

Right, my point is to agree (or not) on a standardized custom field under which you can store anything you like.

[mikhailswift]

I suppose when I hear "custom field" my mind jumps immediately to everyone doing it in slightly different incompatible ways. If we agree upon some specific custom field it's not much functionally different than adding the optional field to the spec from the spec's perspective.

Edit: I think by having a loose agreement on a specific field in a custom bag of fields instead of taking a hard opinion one way or the other the risk becomes making DSSE signatures more complex to use in practice for the sake of keeping the spec simple.

[trishankatdatadog]

I suppose when I hear "custom field" my mind jumps immediately to everyone doing it in slightly different incompatible ways. If we agree upon some specific custom field it's not much functionally different than adding the optional field to the spec from the spec's perspective.

Correct!

Edit: I think by having a loose agreement on a specific field in a custom bag of fields instead of taking a hard opinion one way or the other the risk becomes making DSSE signatures more complex to use in practice for the sake of keeping the spec simple.

I think it's taking a hard opinion in that we say here's your optional custom attribute living next to payloadType, payload, and signatures, and it's obviously unsigned payload. You can completely choose the ignore it, or reject it, or parse it according to application-specific logic.

But I can also see a hard opinion the other way saying, "nope, can do, bad idea for various good reasons." My concern here is that if people really want it, they will find a way around it (e.g., forking and extending DSSE, or maybe just use JWS I guess).

[mikhailswift]

I think it's taking a hard opinion in that we say here's your optional custom attribute living next to payloadType, payload, and signatures, and it's obviously unsigned payload. You can completely choose the ignore it, or reject it, or parse it according to application-specific logic.

As an end user of DSSE the value of adding the certificate chain to the spec would be that I could be assured any other application using DSSE would know how to use my certificate chain.

My concern here is that if people really want it, they will find a way around it (e.g., forking and extending DSSE, or maybe just use JWS I guess).

I think by taking the stance of “here’s a custom field you can use as you wish” invites all the negative aspects of fragmenting the spec that people forking or writing extensions would also carry.

Maybe the answer for solutions that need to transport a certificate chain alongside their signature is to just use JWS or a separate payload to transport the chain. @TomHennen had some ideas about a separate bundle that could be a good compromise here. Folks who need to transport their certificates along side their signature could implement this separate theoretical specification which leaves DSSE simple but still provides a common agreed upon format. Additionally certificate chains would only have to be sent once per key instead of once per signature.

However that does nothing to solve the worry of people forking or extending DSSE.

[gokarnm]

My concern is that if we slowly add more and more optional, unsigned fields like this, we risk accidentally turning DSSE into SSE (and eventually SE). At the same time, I realize that this is a common use case with other signing envelopes, especially JWS

I think there will be request from time to time for DSSE to add other fields which would be debated on a case by case basis and taken if it aligns with DSSE. It's not clear what aspects of DSSE design philosophy adding a field for cert chain would deviate from. Currently DSSE supports keyid which supports certain types of trust distribution schemes where client has access to fully a defined trust hierarchy (like Notary root.json). In X.509 certificates and related PKI which is used in a broad range of applications, this is not always the case, a client can use a leaf signing certificate, an intermediate or a root as their trust anchor (and will not have access to the signing cert before hand). Therefore signing cert is distributed with the signed artifact.

From Notary V2 stand point we only expect a top level unsigned attribute for TSA and Certificate chain. All other attributes including other custom attributes will be in the signed payload. I think this is a reasonable requirement if DSSE is used in similar context or application that uses X.509 certificates. I'd prefer a certificate field with defined semantics instead of a custom map.

As an end user of DSSE the value of adding the certificate chain to the spec would be that I could be assured any other application using DSSE would know how to use my certificate chain.

I think by taking the stance of “here’s a custom field you can use as you wish” invites all the negative aspects of fragmenting the spec that people forking or writing extensions would also carry.

Totally agree.

Additionally certificate chains would only have to be sent once per key instead of once per signature.

@mikhailswift, this does not work in cases like where short lived signing certificates are used to generate signatures, and the trust anchor is the issuer of these certificates, more context here.

[MarkLodato]

FWIW I have no objection to a cert field. To me it is the most straightforward option. @gokarnm and others have laid out a case for it.

I believe the arguments against are:

• General concern about scope creep or added complexity - that DSSE might keep growing.
  • IMO here the benefits outweigh the concern. I don't think there are many other examples beyond this (cert) and the timestamp authority. (@gokarnm said this explicitly of Notary v2 in the previous comment.)
• Worry that implementations will blindly verify the sig against cert but not check that cert itself rolls up to a valid root CA. implementations of JWS and others have made this mistake.
  • Valid concern, but it's not clear to me why having a different cert distribution mechanism would be any better in this regard.
• Redundancy if several envelopes are all signed by the same cert.
  • I imagine this is not the common case. Shouldn't we optimize for the common case, and allow alternate mechanisms for those special cases?

[dlorenc]

Anything that can be done as an unauthenticated top-level field could also be done as another data structure next to the DSSE envelope. Maybe it would be a good idea to iterate on the exact certificate semantics that way, then propose a merge into DSSE when the validation semantics and behavior are clearly defined and validated in some designs.

[mnm678]

Could the keyid field be used to distribute the certificate chain? It is designed to be a 'hint' as to the key that should be used for verification, with the understanding that the client must verify this hint. The certificate chain is also a hint as to which key to use, though one that also includes the verification information.

This has the benefit of maintaining simplicity of DSSE, while allowing for multiple methods of delegation.

[TomHennen]

I like @dlorenc's idea. Is anyone planning to pursue this? Should this issue be assigned to them? :)

[mikhailswift]

I put some thought into it over last night and wouldn't putting something together