3 ms·

That's true if you have the luxury of a traditional tag on the outside, but falls apart when you have systems where signatures are in-band, like SAML, which is

by lvh 7y ago

That's true if you have the luxury of a traditional tag on the outside, but falls apart when you have systems where signatures are in-band, like SAML, which is where canonicalization shows up. (Both for UTF-8 itself, which isn't canonical, but especially for your serialization format e.g. XML/JSON, which is usually far hairier.)

tracker1 7y ago
If you treat the original UTF8 as bytes, then you still have that as bytes... this is part of why JWT uses base64 around the JSON string's bytes. In any case, you don't create a signature on a string per se, you create it on bytes, even if those bytes are derived from a string. Also, you don't validate a signature by re-creating the bytes in question... that's a flawed approach, and not the approach for example JWT takes.
- lvh 7y ago
  > In any case, you don't create a signature on a string per se, you create it on bytes, even if those bytes are derived from a string. Everyone is on the same page that at some point bytes go into a hash function. That's not the problem. You mention JWT, but JWT only does external signing, which doesn't trigger the problematic case several people are describing to you. Perhaps an example would be more useful. If you start with a JSON like: {"a": 1} how do you build a JSON like: {"a": 1, "tag": "deadbeefdeadbeefdeadbeef"} with a signing and verification algorithm that works? > Also, you don't validate a signature by re-creating the bytes in question... that's a flawed approach, and not the approach for example JWT takes. Can you describe an HMAC validation process that doesn't involve recreating the bytes in the HMAC tag?
  - tracker1 7y ago
    You don't... you could create one like... {"body":"base64-json","tag":"hash"} It seems to me that trying to do what you're saying is a flawed approach.
    - lvh 7y ago
      That is literally the first thing suggested in the post. You can say the other thing is a "flawed approach" but that's the design problem being solved, so your answer is simply not responsive to the question.
    - Vendan 7y ago
      Don't worry, multiple people (including me) have told the community in question that it's a flawed approach. Doesn't seem to have done much to fix it though... :shrug:

by lvh 7y ago

tracker1 7y ago

If you treat the original UTF8 as bytes, then you still have that as bytes... this is part of why JWT uses base64 around the JSON string's bytes. In any case, you don't create a signature on a string per se, you create it on bytes, even if those bytes are derived from a string. Also, you don't validate a signature by re-creating the bytes in question... that's a flawed approach, and not the approach for example JWT takes.

lvh 7y ago
> In any case, you don't create a signature on a string per se, you create it on bytes, even if those bytes are derived from a string. Everyone is on the same page that at some point bytes go into a hash function. That's not the problem. You mention JWT, but JWT only does external signing, which doesn't trigger the problematic case several people are describing to you. Perhaps an example would be more useful. If you start with a JSON like: {"a": 1} how do you build a JSON like: {"a": 1, "tag": "deadbeefdeadbeefdeadbeef"} with a signing and verification algorithm that works? > Also, you don't validate a signature by re-creating the bytes in question... that's a flawed approach, and not the approach for example JWT takes. Can you describe an HMAC validation process that doesn't involve recreating the bytes in the HMAC tag?
- tracker1 7y ago
  You don't... you could create one like... {"body":"base64-json","tag":"hash"} It seems to me that trying to do what you're saying is a flawed approach.
  - lvh 7y ago
    That is literally the first thing suggested in the post. You can say the other thing is a "flawed approach" but that's the design problem being solved, so your answer is simply not responsive to the question.
  - Vendan 7y ago
    Don't worry, multiple people (including me) have told the community in question that it's a flawed approach. Doesn't seem to have done much to fix it though... :shrug: