On 10/6/2020 5:23 PM, Martin Thomson wrote: > 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 You would think that, but the X.509 design meant that the application would received all its data in parsed form, and then re-serialize the parts that it needed to check, such as for example certificates. And if you do that, you must absolutely guarantee that parse and serialize are bijections between the application representation and the byte sequences. Which leads to requiring "distinguished encoding rules", including not just the coding of integers but also ordering of elements in sets or representations of character strings. And yes, this turned out to be a really bad idea. >> 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.
Yes. And I do also agree with your statement that *not* requiring minimal length encoding makes some of the code paths much simpler. I use that for example to encode the length field of Quic packets. -- Christian Huitema
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
