<snip>
The quote you cite is based on advice from the late Jon Postel, someone I knew well for over 20 years, and with whom I served on the IAB for over 12 years.The Internet protocol design rule is "be strict in what you send, tolerant in what you receive". It has been known for decades that this is the correct rule. (That doesn't keep some other standards bodies from ignoring it, unfortunately. Then again, there are still standards bodies that use two-way connection setup handshakes...)
If we can be confident that a failure to check certain inputs will not result in adverse effects under any circumstances, then we need not check them. However, when a TTP such as a TSA is signing a token it is not clear that this is true.Protocols should check those invariants that have to be valid for correct operation to result, or for interoperability to be possible. Checks beyond that are counterproductive.
Agreed. But our primary focus is security, so the issue is what constitutes the right tradeoff. New hash algorithms do not arise so quickly that a TSA can't anticipate them and the associated size of the hash value. Looking at the time it takes for a standards bodies to approve such things and assign OIDs, this does not seem hard. Also, we're not talking about changes to client software, but rather server software/hardware, which is much more amenable to such change management.In particular, the more you check, the more often you have to ECO your specs and your implementation as new extensions are registered. And the more often you have to release bugfixes.