- From: Harry Halpin <hhalpin@ibiblio.org>
- Date: Wed, 26 May 2021 02:19:03 +0200
- To: Peter Patel-Schneider <pfpschneider@gmail.com>
- Cc: Aidan Hogan <aidhog@gmail.com>, Dan Brickley <danbri@danbri.org>, Semantic Web <semantic-web@w3.org>
- Message-ID: <CAE1ny+7d7bEG-rKYnVxMXWs5WJV8D3eguajc_LxFBzd0XW72Xw@mail.gmail.com>
On Wed, May 26, 2021 at 1:54 AM Peter Patel-Schneider < pfpschneider@gmail.com> wrote: > On Tue, 2021-05-25 at 18:42 -0400, Aidan Hogan wrote: > > [...] > > > The issues being discussed here relate more to the definitions of > > RDF > > datasets -- how they are serialised or deserialised, how signature > > metadata can be embedded and extracted, etc. -- than cryptography. > > > > - We are not inventing new cryptography. Rather we are black-boxing > > cryptography. The complicated stuff in terms of how the cryptography > > is > > implemented and what guarantees this provides is done for us. The > > issue > > then is to take those guarantees and reduce the current RDFy > > specifications to them. For example, the cryptography black box > > presumably will provide guarantees with respect to the difficulty of > > a > > pre-image attack. Assuming this guarantee (without necessarily > > understanding how it is implemented), one can then formalise > > guarantees > > regarding the difficulty of attacks on an RDF level that equate to a > > pre-image attack (e.g., using proof by contradiction, showing that > > the > > RDF-level attack would constitute a pre-image attack). I think that > > this > > sort of task requires a more detailed understanding of RDF than of > > cryptography. > > > > Attacks on computer security come in different flavours. There are > attacks on the fundamental crypographic primitives. There are attacks > on how these primitive are used. There are probablhy other kinds of > attacks, for example attacks that depend on the resources needed to do > RDF dataset canonicalization. > > Developing good cryptographic primitives is difficult and often > requires inspiration. Developing good usage may be even more difficult > and generally requires a lot of persperation - to enumerate all the > different ways that an opponent can take advantage of each and every > aspect of the signing/proof process. > Hi, I'd like to point out that while there are no peer-reviewed publications on the (lack of) security of the so-called Verifiable Credential architecture and the problems with this kind of standardization of things like "Linked Data Proofs", In fact, published a peer-reviewed article explaining in detail how utterly broken the entire DID and Verified Credential architecture is, and how this is damaging the credibility of the W3C, and it was presented at Mozilla. It's online here: https://arxiv.org/abs/2012.00136 Now, basically Peter is *absolutely* right and my recommendations in this article still stand (TL;DR 1. Go to the IETF 2. Don't try to add signatures to RDF as a free-standing work item). First, the W3C is not the right standards body for security, and burnt what goodwill they had from the security and privacy research community by backing DRM without a security research covenant as put forward EFF. The "audits" that Manu that he paid for and referenced earlier by "Math Ph.D.s" like Mirabolic Consulting are basically amateur at best. No actual cryptographer has bothered to look at this, and there are no proofs. Second, the problem is fundamentally conceptual, and the fact that this Working Group charter is so confused on basic concepts kinda proves it's not capable of doing the work. You can only sign bistrings, i.e. syntax. You can't sign "semantics". The use-cases of "securing RDF" just makes the above worse, even if you could get a functional canonicalization algorithm (and I'm not convinced you can). Thus, expanding the charter to signing graphs of graphs and offline graphs (where folks like Gregg are just making up terminology like "parallel signatures" rather than using the actual terms used in practice, like aggregate signatures) will only compound security problems. Also, anyone with any historical memory of standards should remember how badly XML-DSIG screwed this up, resulting in a Recommendation being retracted and the Working Group reformed, and its use in the wild basically being still broken. So, RDF has just the same problems in terms of canonicalization and signing out of band documents as XML, but *worse* due to blank nodes and semantics. Furthermore, there isn't a magic black box for this. There are well-defined security properties that signature schemes should have (EUF-CMA, etc.) and these are relative to well-defined threat models, not a grab-bag of terms in some "RDF vocabulary for security". My recommendation is not to go forward with the charter, find new editors that have actual background in the subject matter of security, and do the work at the IETF - which as a very good track record now in cryptography and access to the right experts at the CRFG, and has done a good job with actual proofs at TLS 1.3 and new MLS work that have prevented and fixed long-standing attacks in core web architecture. In the mean time, there is no real-use case for this work. You can serialize and sign JSON perfectly well, and if you really want to sign "semantics" just serialize it as JSON and sign that using JWS algorithms that use fairly well-vetted IETF work rather than re-inventing the wheel badly. If you want two "equivalent" graphs to have the same signature, I suggest you simply should probably not be using RDF due to RDF being a data model, not a data format as a bit string. You could try to reboot the whole history of RDF, but that's probably not worth doing. I apologize in advance for not answering all the emails I will get from Manu and his ilk, but honestly, I do not have all the spare time. I suggest people find other life goals that perhaps do not involve trying to prematurely optimize "the future of the Web" via writing broken standards via chartering new Working Groups, as that went quite wrong with XHTML and has hurt, rather than helped, the otherwise useful goals of the Semantic Web. yours, harry > > (Ceci n'est pas un audit de sécurité.) > > > > Best, > > Aidan > > peter > > > >
Received on Wednesday, 26 May 2021 00:19:28 UTC