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

Reply via email to