Hi Anders, On 10/7/20 10:14 PM, Anders Rundgren wrote: > On 2020-10-07 19:47, Mohit Sethi M wrote: >> A strong +1 on the security issues of decode -> extract -> re-encode -> >> verify signature flow. The lack of canonical encoding can also mean that >> the resulting bytes can be different in different encoder/decoder >> implementations. >> >> It would have been nice to have canonical JSON. Some implementations >> support it with flags such as "JSON_PRESERVE_ORDER" >> (https://jansson.readthedocs.io/en/2.8/apiref.html). Some specs try to >> specify things like keys should be in alphabetical order but fail to >> realize the complication with nested structures. > > Hi Mohit, > > Since a few months back there is an RFC (8785) which specifies a > scheme for canonicalizing JSON, albeit limited to the JSON subset > supported by ECMAScript and browsers. > > It can be tested in an on-line application where it is combined with > JWS: https://mobilepki.org/jws-jcs/home
Cool ! Thanks for informing and thanks for doing the work! --Mohit > > Anders > >> >> CBOR has thankfully specified canonical representation (called as >> deterministic encoding in 7049bis). Some CBOR libraries have added >> support: https://github.com/agronholm/cbor2/issues/6. >> >> --Mohit >> >> On 10/7/20 7:30 AM, Watson Ladd wrote: >>> On Tue, Oct 6, 2020 at 10:13 AM Christian Huitema >>> <huit...@huitema.net> wrote: >>>> On 10/6/2020 10:00 AM, Michael D'Errico wrote: >>>> >>>>> It matters in X.509 certificates because the basic >>>>> encoding rules (BER) allow you to specify the same >>>>> thing in different ways. With DER, there is only >>>>> one way to encode every element, so everybody will >>>>> come up with the same string of bytes and hashes of >>>>> those strings will be the same, signatures will >>>>> verify, etc. >>>> >>>> Well, we have learned a few things since 1994. The DER rules are >>>> defined >>>> to allow a "re-encoding" workflow: >>>> >>>> * Sender side: prepare the message, encode with DER, sign the result >>>> >>>> * Receiver side: receive the message, parser with generic ASN.1 >>>> decoder, >>>> process the message using the "parsed" representation, re-encode with >>>> DER, check the signature. >>>> >>>> Experience showed that this workflow is very problematic, because the >>>> parse/reencode process may introduce subtle changes and the signature >>>> will fail. One may argue that these changes are due to implementation >>>> bugs, but fact it that this is a rich environment for growing bugs. >>>> Based on experience, the receiver side is better done as: >>>> >>>> * Receiver side: receive the message, save it, parse and process, and >>>> when it is time to verify the signature go back to the original >>>> message >>>> and check the signature. >>> Examining signed data ahead of verification, particularly to determine >>> what should have signed it, is fraught with issues. In particular >>> parser errors that would only be exploitable by trusted parties become >>> exploitable by anyone. Furthermore, you should know the expected >>> signer ahead of time. That this isn't possible in X509 due to >>> inordinate flexibility is one of many pitfalls for implementors. This >>> sort of issue periodically leads to authentication bypasses and other >>> such fun. >> A strong +1 to this. >>> >>> Sincerely, >>> Watson Ladd >>> >>> >>> >>> -- >>> Astra mortemque praestare gradatim >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
