RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH

[Paul Koning <pkoning@xxxxxxxxx>]

>>>>> "Stephen" == Stephen Kent <kent@bbn.com> writes:

 Stephen> Jim, I support Denis in his desire to have the TSA check
 Stephen> everything it can (syntactically) in a request.  Not
 Stephen> checking allows the TSA to sign tokens that are just broken.
 Stephen> We have seen many examples of broken certs signed by CAs, so
 Stephen> I think it worthwhile that we put language in RFCs to
 Stephen> require, where possible, that appropriate consistency checks
 Stephen> be performed.  RFC 2459 has a few statement about
 Stephen> relationships among extensions, which gets to the same
 Stephen> concerns.  We could put in more, or collect them in one
 Stephen> place, and make for a better document.

 Stephen> I may have lost track of the counter argument here.  Why
 Stephen> would one not want to have a TSA do the best possible job
 Stephen> when it comes to ensuring syntactic consistency re its
 Stephen> inputs?

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...)

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.

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.

    paul