On Wed, Oct 7, 2020, at 04:12, Christian Huitema wrote: > * 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.
I think that you mean: receive the message, check the signature, then parse and process if that passes > If we do that, then there is no reason to mandate minimal length > encoding. And TLS already does that. For example, we do not reorder > extensions according to some canonical rules before placing them in the > transcript. This I agree with. But cTLS doesn't work that way because the signature - such as it is - applies at the next layer, which appears after the encoding is erased. And that is important here. The encoding we're talking about is a compression function only. Not having a canonical form means adding an inefficiency, but it has little bearing on the process you describe, which would be modified to: receive the message, decompress the message, check the signature, then parse and process if that passes In TLS we don't follow that ordering either because we all routinely process tons of stuff before we get to the Finished/CertificateVerify. Having those at the end makes a ton of sense, for a variety of reasons, but it does mean that we build a protocol on credit. And we have plenty of experience, I hope, in dealing with bad credit in TLS. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
