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