On Mar 11, 2023 at 9:50:02 PM, AJITOMI Daisuke <[email protected]> wrote:
> So, did the version update go well? > This was a useful, real-world story. We need more of these! Thank you for sharing! IMHO, one of the best current practices I'm thinking of is to make > standardized versatile crypto data container specs (like JOSE/COSE) be > cryptoagility-oriented as much as possible and be widely spread, and to > make the upper layer applications using these crypto data container specs > use very restricted number of algorithms or adopt versioning to mitigate > the drawbacks of the cryptoagility approach. This might be the same as the > EAT thing that Laurence mentioned. > > Shortly speaking, it means that this kind of layering is important. > I only spoke about it in passing in my article on cryptographic agility, as it is an emerging approach, but almost everything I do now is to **untangle and separate layers**, and then limit the choices in each layer. For instance, relevant to this list, the separation between dCBOR and Gordian Envelope, and then between Gordian Envelope and various data & graph structures, allowing us to use it below many other more complex cryptographic layers (such as COSE) with different requirements. Designing for separation of layers is harder than you might think, and there are many design patterns that are common that I now consider to be bad practices, but my list of these is incomplete. For instance, in W3C JSON-LD, in order to canonicalize the RDF quads, they are ordered based on the @context value, which is an RDF Schema. I feel this violates layering because when canonicalizing, you have to have some understanding of schema, which is a very different layer, a semantic layer. In Bitcoin, there is a concept of a bitcoin address, which is basically a hash of a public key, that is then encoded with an unusual base58 encoding for transport via ASCII. In addition, it is manipulated so that the original “legacy” addresses all start with 1. Later versions started with 3. The layer problem is that there are three things going on, you have to know is the root hash of a public key (what kind of hash), what kind of public key is it (what kind of public key), and what the policy is to spend it (a legacy bitcoin transaction). This pattern worked and was concise, but it became a dark pattern as more transaction types emerged, more kinds of encoding for transports (like QR code and binary), and more complex kinds of transactions emerged. In our work supporting interoperability work between various cryptocurrency and digital identity wallet developers, we use dCBOR and explicitly separate all of those aspects. More subtle are hidden layer assumptions — for instance, some of the conflicts between JSON-LD and JWT in the W3C/DID community may be due to different data structures on the backend, such lists vs. node-labeled graphs vs edge-labeled graphs. Even venerable TLS (I was editor of the IETF TLS 1.0) had lots of layer violations — it was supposed to be a “transport” layer protocol, but in reality, it was tangled both above and below that layer in many, sometimes unobvious ways. Separation design principles go even further — we work hard in our designs to have no single points of compromise, but also no single points of failure (these are subtly distinct). In cryptocurrencies, this requires untangling and separating parts of wallets that offer account policy creation, policy coordination, and policy execution — not easy! I’m not sure where the right venue/list is to share these types of security architecture discussions, and to share stories like yours and mine of real-world lessons. But we need to find a way, especially as the next generation of engineers is not learning from our mistakes, but instead are replicating them. — Christopher Allen
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
