Document rationale for DSSE vs COSE etc. #62
Comments
|
Hi @nealmcb! My 2 cents (I've since left the SSL so take this with a grain of salt). I think that document was insightful, but for reasons beyond the raw content in it. I honestly don't think it really articulates a rationale for using COSE other than it being an IETF endorsed "standard". In fact, I can't still answer this, but now that their charter does describe the NEED to use COSE/RATS for no reason other than the authors of that RFC being co-authors of that other one, then I believe there's your answer. When I asked repeatedly that they'd be willing to use other cryptographic standards instead of COSE (e.g., PKCS9 or PGP) they had no answer other than "we want to use COSE". To me, it feels like the requirement was to have one standard, rather than provide certain fundamental security/performance properties. As for my side --- I don't speak for the SSL! --- most of the pushback to using COSE (at least from my side) fell within not adding unnecessary complexity, as well as COSE's pedigree of massive CVE's from its ancestor JOSE. They say they fixed those issues, by issuing yet another RFC where they document the common mistakes people do when implementing JOSE. I'm not exactly satisfied with this. I believe in security by default, and I know knobs can also serve as footguns, thus the minimal specification around DSSE (Speaking of which, you may be interested in PASETO as well). I think it'd be valuable to bring some clarity into the issue as you point out, and perhaps working on fleshing out that document is it. I unfortunately don't have the cycles for something like this, but I'd be happy to chime in whenever possible. I'd be happy to participate to the extent possible! P.S. Oh, and to clarify. Sigstore didn't add support for COSE because of any enlightening conversation with the SCITT folks (as they seem to hint in that issue), but rather because it already supported a bunch of other standards (such as GPG and PKCS9 mentioned above) so why not. |
|
I'm closer to someone who speaks for the SSL, but would really say that we
broadly discuss all decisions.
From my reading of the document and comments, you conclude that DSSE
provides a much simpler envelope format than COSE. DSSE has a smaller and
simpler code base (which is good for security), but lacks some COSE
features which as I understand it, we either aren't using or are
implemented at a different level.
At the risk of parroting Santiago, I agree that what is missing is the
rationale for why we would adopt COSE. What problem does it solve for our
users? How would integrating change our security risk? Is it better,
worse, different?
…On Mon, Sep 4, 2023 at 5:42 PM Santiago Torres ***@***.***> wrote:
Hi @nealmcb <https://github.com/nealmcb>!
My 2 cents (I've since left the SSL so take this with a grain of salt). I
think that document was insightful, but for reasons beyond the raw content
in it. I honestly don't think it really articulates a rationale *for*
using COSE other than it being an IETF endorsed "standard". In fact, I
can't still answer this, but now that their charter does describe the NEED
to use COSE/RATS for no reason other than the authors of that RFC being
co-authors of that other one, then I believe there's your answer. When I
asked repeatedly that they'd be willing to use other cryptographic
standards instead of COSE (e.g., PKCS9 or PGP) they had no answer other
than "we want to use COSE". To me, it feels like the requirement was to
have one standard, rather than provide certain fundamental
security/performance properties.
As for my side --- I don't speak for the SSL! --- most of the pushback to
using COSE (at least from my side) fell within not adding unnecessary
complexity, as well as COSE's pedigree of massive CVE's from its ancestor
JOSE. They say they fixed those issues, by issuing yet another RFC where
they document the common mistakes people do when implementing JOSE. I'm not
exactly satisfied with this. I believe in security by default, and I know
knobs can also serve as footguns, thus the minimal specification around
DSSE (Speaking of which, you may be interested in PASETO as well).
I think it'd be valuable to bring some clarity into the issue as you point
out, and perhaps working on fleshing out that document is it. I
unfortunately don't have the cycles for something like this, but I'd be
happy to chime in whenever possible. I'd be happy to participate to the
extent possible!
P.S. Oh, and to clarify. Sigstore didn't add support for COSE because of
any enlightening conversation with the SCITT folks (as they seem to hint in
that issue), but rather because it already supported a bunch of other
standards (such as GPG and PKCS9 mentioned above) so why not.
—
Reply to this email directly, view it on GitHub
<#62 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGRODYVO7HW3UXAB6JISTTXYZDNBANCNFSM6AAAAAA4K3GZXY>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
A related observation. It seems that Sigstore bundle was invented purely because DSSE has limits on the metadata you can embed in the signature. I have no proof of the claim, but after working with cose it would be a similar thing I'd miss. |
|
The Sigstore bundle format is also needed for non-DSSE cases to ship the additional verification information. On the DSSE side, we're actively working to support the additional information on a case-by-case basis. See: #59, #61, and sigstore/protobuf-specs#145. I can't speak for how COSE handles this though. |
The IETF SCITT working group is working on an effort related to sigstore. They decided to base their work on the RFC 9052 - CBOR Object Signing and Encryption (COSE) envelope format.
Having noted a bit of discussion on perceived benefits of DSSE over JOSE and COSE, I opened an issue there: Document rationale for COSE vs DSSE etc. · Issue #57 · ietf-wg-scitt/draft-ietf-scitt-architecture.
That yielded a link to a draft document with some insightful rationales and unresolved discussions that may be of interest to those exploring these and related envelope formats: Digital Artifact Signing Envelope Format Comparison
I wonder if there is any interest in the DSSE community to bring that document to something worth noting in this repository, or publishing elsewhere, or to continue to clarify the technical rationales and tradeoffs.
The text was updated successfully, but these errors were encountered: