I think we are in agreement. On 10/6/20 13:12, Christian Huitema wrote:
* 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.
I recall that at least one root certificate had a SEQUENCE encoded using BER-but-not-DER (?) Yeah if your software re-encoded that, it would no longer be the same sequence of bytes.
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.
This is how I did X.509 verification, though I was late to the game and the advice was already there to accept a BER-encoded certificate. Not sure if I would have done the DER re-encoding bit if that was the current advice at the time since it seems like the wrong thing to do, but maybe I would have.
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.
I was disappointed to see that the TLS 1.3 spec now has a requirement to put one of the ClientHello extensions in a specific place (last in the list). We discussed this at length during the development of either TLS 1.2 or one of the extensions (maybe renegotiation-info?) and we ultimately came to what I believe was the correct decision never to require any ordering of the extensions. Sad to see the group capitulated to whomever said it would make their software easier to write (which I doubt). Mike _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls