Why not use COSE?

[cyberphone]

Rationale for not using COSE

Standards should of course be used whenever possible. For cryptographic containers that would probably mean using COSE. However, Gordian Envelopes introduce another take on cryptographic containers:

200(   / envelope /
   [
      200(   / envelope /
         [
            24("Alice"),   / leaf /
            {
               24("knows"):   / leaf /
               24("Bob")   / leaf /
            }
         ]
      ),
      {
         3:
         24(   / leaf /
            40020(   / signature /
               h'f6daae4e6bc18a61503b26fe72372e5effc6625385c2349aed4a72d2a25b3101917d42db052a77a250da4f8d1209ac4580d5bc29d30a65609706d5f18c7cb91d'
            )
         )
      }
   ]
)

How would that look in COSE? Well, the entire payload to be signed would be stuffed into byte-string which obviously breaks the nice structure of envelopes. This is where deterministically encoded CBOR comes in. Signatures depend on that the data to be signed doesn't change, even if processed like would be case when envelopes are embedded in other envelopes.

In case an encoder fails to generate proper deterministic encoding, possible signatures would not verify or the document gets rejected already during parsing.

In short: the use of enveloped signatures makes documentation, logging, and debug easier.

Using good software practices, this scheme should not be less secure than COSE.

[ChristopherA]

Using good software practices, this scheme should not be less secure than COSE.

I don't believe that the aphorism "given enough eyeballs, all bugs are shallow" applies to cryptographic code, and "good software practices" is insufficient. There are too many examples in the past where this has not been true. It requires specialized skills, humility, and an adversarial coding mindset that is not easily categorized or taught. I have met people who have it, but it takes years of experience (and mistakes) to earn it. An example of this is the review of our Shamir & SSKR code, only little over a 100 lines of code, which was quite difficult to get the right kind of people to write, and was expensive to properly review.

Thus there is a lot of value in the past serious cryptographic review of COSE, but at a huge price of architecture problems, both inherited from the JOSE and OAuth 2.0 stack, and more recently, other architectural gaps and problems with integrating COSE with other standards like HPKE.

We could support some forms of COSE, especially with COSE_Sign1, if they were willing to enforce deterministically encoded CBOR and not force us to use byte-string. But it would still be at the cost of being able to elide data signed by CBOR. We are seeing that elision (either through hash trees like Gordian Envelope, or hash lists like ISO's mDL/mDOC) is an essential requirement for the future.

I also feel that all of these 'legacy' signature formats lose the emerging opportunities of leveraging cryptographic threshold and MPC signature techniques like Musig & FROST https://developer.blockchaincommons.com/frost/ — these are the real future.

At this time, unfortunately, Blockchain Commons does not have the financial resources to "roll our own crypto". I am VERY conservative about cryptography (see this week's breaks of many RSA keys in SSH because of non-open source SSH in Cisco, etc. https://www.cryptopolitan.com/major-crypto-wallet-vulnerability-uncovered/, and a major flaw found in old Bitcoin javascript code https://bitcoinist.com/btc-fatal-bitcoin-flaw/), so we are reliant on others.

In particular, I'm following the new threshold cryptography libraries, such as the Zcash FROST library, which is being used as reference code for an IETF IACR informational draft (and recently passed its first NCC security review), and the Musig library being reviewed by a broad consortium of Bitcoin-related companies. We hosted an Implementers Round Table related to this topic last week: https://developer.blockchaincommons.com/frost/meeting1/

Our current reference implementation of Gordian Envelope does have an optional extension that supports signing, but it is more of a proof of concept, and should not be used for production code. But we do plan on doing more with it in 2025.

[cyberphone]

I'm simply claiming that your take on signature containers is straightforward and should therefore present few problems. COSE is way more complex.

Deterministic CBOR is also quite simple. In fact, the strictness adds qualities of its own since there is only one way encoding a particular item.

Regarding cryptographic algorithms, I have no deep insights; I follow the crowd :)

[ChristopherA]

I'm simply claiming that your take on signature containers is straightforward and should therefore present few problems. COSE is way more complex.

Thanks, being straightforward was the intent, as well as being multisig and privacy friendly. My hope is that as we mature the code base and after security reviews, we can keep that elegance.

Regarding cryptographic algorithms, I have no deep insights; I follow the crowd :)

I don't consider myself an amateur here, but I also am no longer able to review cryptographic proofs in academic papers — they have moved significantly beyond my skills. That being said, I can read them and be impressed by some. The FROST paper from 2019 was one such. But even in my appreciation, I know that was somewhat positively biased toward it because it leverages Schnorr (see my Layperson's Intro to Schnorr.

[cyberphone]

Another example

The following example illustrates what can be accomplished with deterministic CBOR in more traditional signature contexts:

From https://datatracker.ietf.org/doc/html/rfc8392#appendix-A.3 we take an example of a CBOR Web Token (CWT):

18([h'a10126', {
    4: h'4173796d6d65747269634543445341323536'
}, h'a70175636f61703a2f2f61732e6578616d706c652e636f6d02656572696b77037818636f61703a2f2f6c696768742e6578616d706c652e636f6d041a5612aeb0051a5610d9f0061a5610d9f007420b71', h'5427c1ff28d23fbad1f29c4c7c6a555e601d6fa29f9179bc3d7438bacaca5acd08c8d4d4f96131680c429a01f85951ecee743a52b9b63632c57209120e1c9e30'])

The very same object using an enveloped signature:

18({
    1: "coap://as.example.com",
    2: "erikw",
    3: "coap://light.example.com",
    4: 1444064944,
    5: 1443944944,
    6: 1443944944,
    7: h'0b71',
    / Signature container /
    -1: {
      / alg = ES256 /
      1: -7,
      / kid /
      3: h'4173796d6d65747269634543445341323536',
      / signature value which encompasses all data including the top level tag /
      6: h'ffb944aef83cac4fcfab3c5a8e5ecc1bf725a75d0e8014687ae7a7b611c1c238e145e43bbea9cb229d360a85224fb439c2cc25cda922e5e54965f6c9626bad59'
    }
})

Getting this into COSE is probably not realistic since the unwrapping applies not only to the "payload", but to "header" elements like algorithm as well. However, COSE algorithms and key descriptors can (with advantage) be reused.

[wolfmcnally]

Closing due to inactivity.