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. 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
