Document rationale for COSE vs DSSE etc.

[nealmcb]

Re: #40:

The SCITT charter says:

reuse existing work from IETF WGs such as COSE and RATS, as appropriate,

The words "as appropriate" suggest to me that we should have some discussion of the pros and cons of mandating COSE, and address alternatives.

In particular, there is already deployment experience with the closely-related effort Sigstore which uses DSSE: Dead Simple Signing Envelope. Some googling will surface a comparison of Signature Formats. Envelopes and Wrappers and Formats, Oh My! by Dan Lorenc which recommends DSSE over the family of JOSE standards, which includes COSE to some extent, though COSE is not covered in that article.

I think we'd should try to promote interoperability with Sigstore.

Is there some background info somewhere on advantages of mandating COSE?

[SteveLasker]

Thanks @nealmcb,
Here's some background that was in the comment on #16:

---

Thanks, @nealmcb. COSE is intrinsic to SCITT as an extensible means to capture headers and payload in a consistent/standards-based format. The evaluation was captured here: Digital Artifact Signing Envelope Format Comparison
As a result, sigstore/rekor added support through a draft then subsequent merged PR

[nealmcb]

Thank you @SteveLasker, that document is very helpful. What is the status and plan for the document, which is undated, marked as a "Draft", and has a note that it had been perhaps 1/3 reviewed as of a 2022-03-16 meeting.

I'll note that Dan Lorenc and Laurent Simon have a number of critiques from last year which I find insightful, and which have not been addressed yet.
Though, as you note, it was also Dan who signed off on supporting COSE in Sigstore's Rekor last June....

[roywill]

Neal, comparing an industry standard to arbitrary proprietary proposals seems to be a never ending game. The current implementation of DSSE by SigStore as a starting point seems to be a weak reason to not use COSE. From a technology point of view hoping the words Simple equals simple is not always true. The future needs and extensibility of this space begs for mechanisms that pre-exist in COSE. Having the IETF entertain a different signing serialization format pushes for it to be within the IETF. Which COSE is. I want to push back that before entertaining DSSE or something else bringing it to the IETF is the place to start.

Asking if we should use S/MIME does meet that requirement listed above but picking one is a fair goal. The COSE format is required for IOT devices and is built with all the knowledge of where S-MIME (and other formats) struggled, leads to it being top contender. If you want to make a case why it is NOT a great choice, then please take pen to paper and make a case.

If the argument is that COSE is frozen and thus cannot be extended, that has been proven false in the current meetings. The working groups have been very thoughtful and accepting of requirements such as Merkle proof receipts.

If the argument is that we should support more than one, we really need to have you explain your reasoning.

[OR13]

Building on IETF standards ensures widely available tooling and an expert community that can provide reviews, and support for profiles and extensions.

There is also an IETF procedural detail on citing envelope formats that are not RFCs or of an equivalent maturity level.

I don't think we should support an envelope format other than COSE.

[hannestschofenig]

Closing the issue since there are not further actions.

[nealmcb]

I appreciate the discussion here to date - it is helpful! And I don't mean to detract from SCITT progress, or question the decision to build on IETF signature format standards

But I still see value in getting more clarity on the technical tradeoffs between COSE and DSSE, as the current title of this issue reflects.

A comment above describes DSSE as "proprietary". It may not be under change control of a recognized standards-making body, but it is licenced via Apache License 2.0 and thus quite open and not proprietary.

I note that the draft discussion document at Digital Artifact Signing Envelope Format Comparison still has lots of unresolved issues.

I'll also note that I've added a similar comment to DSSE at Document rationale for DSSE vs COSE etc.

In my mind, ideally the discussion document would end up published in a cleaned-up, if not fully agreed-upon form.

If nothing else, perhaps future web searches will more easily surface one of these documents, leading to useful insights.

If there is any hope that some folks may continue to engage on those fronts, I'd request that this issue be reopened, to help encourage that.

[hannestschofenig]

I closed this issue because I do not see a need to add text comparing a proprietary technology with standardized technology. If there is a decision in SCITT then it is about whehter to use JSON or CBOR (with the corresponding security wrappers).

As far as I know there is no ongoing work in the IETF to standardize DSSE.

[nealmcb]

Again, I think it is very misleading to describe DSSE as "proprietary". No one has exclusive rights to use it. From everything I see, it is an open spec designed by recognized experts and used by e.g. sigstore and in-toto, which are themselves managed by the Linux Foundation. The documents are licenced via Apache License 2.0, making the whole thing more open from my standpoint than e.g. ISO standards.

It's ok for SCITT and IETF to decide to stick to formats they have better change control over. But I hope others take up the task of an inclusive technical comparison of the relevant signature envelope formats.