Russ and Todd,
I do not share your opinions.
The U.S. Treasury does not support suspension mainly due to obvious
issues encountered with digital signature related transactions, and
future validation of those transactions. The problem is, if you are
willing to honor signatures produced using certificates from an
infrastructure that does support suspension, you wind up in the same
boat. It has been a topic of much debate.
At the very begining, I was reluctant to support suspension, but there is no security flaw
both for authentication and for non repudiation.
In general, if a relying party application does not support suspension,
then it will treat suspension as (definitively) revoked.
In the case of non repudiation (which mandates the use of either a time-stamping or
a time-marking mechanism) there is however a slight difference:
- If the relying party application supports suspension, the (electronic) signature will be considered
as (temporary) invalid. In some cases, it MAY try again *at a later time* to gather new revocation
information which demonstrate that the electronic signature is *now* valid. These applications
may thus know when it is no more necessary to attempt to validate temporary invalid signatures.
- If the relying party application does not support suspension,
the (electronic) signature will usually be considered as (definitiveley) invalid.
However, this class of applications could be designed to support suspension, without supporting
the suspension extension. The relying party application MAY attempt to validate at a later time,
e.g. two or three days later, electronic signatures that were invalid because the signer's certificate
was revoked. So they may end up with the same result, but not necessarilly within the same time frame.
Denis