- From: David Chadwick <D.W.Chadwick@kent.ac.uk>
- Date: Thu, 1 Nov 2018 16:50:24 +0000
- To: public-credentials@w3.org
On 01/11/2018 15:51, Dave Longley wrote: > On 10/29/2018 06:20 PM, Chris Boscolo wrote: >> IMO, it just seems unsafe to allow data that has been signed to be >> modified in any way and still produce the same signature. > > Could you give a concrete example for how this is related to > canonicalization? This sounds like a general problem with any signature > system -- and I think we all would agree that different data should hash > differently and produce different signatures. > > Canonicalization is about representing information that is semantically > the same in just one way; only if you change the meaning of the data > should it change the signature. Which, I'd argue, is exactly what one > wants, particularly for information that has multiple concrete syntax > choices or graph-based information that can be represented in a number > of different ways. To put it another way, I'd find it quite frustrating > to have information that is semantically the same hash *differently*. > That usually makes more work for me. This is the original X.509 DER way of looking at signing. The alternative approach is to say, let the signer encode the data in any one of the accepted concrete syntaxes, then sign the encoded data. When you receive the signed data, validate the signature on the encoded data Finally decode the data. But do not expect to be able to reconstruct the encoded data and signature. Rather keep a copy of the received signed data if you want to pass it onto a third party. The trade off here is storage vs. more complex processing. David > > Note: JWTs mutate data prior to signing as well, the function used is > `base64url`. That is certainly a simpler mutator than other choices, but > there are always trade offs. Anyway -- without making your attack more > concrete it's difficult to understand or respond to. > > On 10/29/2018 07:36 PM, Mike Lodder wrote: >> Anytime a message can be modified and result in the same signature is >> very bad. This means you can’t trust the data because it could be any >> number of possible things. >> >> If that is the case the implementation is bad or the crypto is bad. >> We’ve seen cases where even experienced crypto engineers get it wrong. >> Look at RNCryptor V1 for Apple and iMessage. >> >> I’d love to have this fixed and help but I may not be understanding >> everything going on here. > > I don't think there's anything to fix. Chris was merely speculating via > a theoretical attack -- one that I didn't completely follow... and my > first thought was essentially the same as yours here. > > On 10/29/2018 09:08 PM, Melvin Carvalho wrote: >> iirc JSON-LD is canonicalized into ntriples >> >> taking a hash of ntriples should be safe, the only thing that could >> change being white space or comments outside of the data >> >> maybe there is some literature on this, too? > > A canonical form of N-Quads is used -- and to be clear, there's no known > issue. > >
Received on Thursday, 1 November 2018 16:50:57 UTC