Re: Certificate suspension

["Denis Pinkas" <denis.pinkas@xxxxxxxx>]

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 

>Russ Housley wrote:
 
>> I have said many times that I wish we had deprecated certificate 
>> suspension in RFC 2459 and all of its successors.  As you say, it is 
>> riddled with difficulties, and those have been discussed many times over 
>> the years.
>> 
>> When we were working on RFC 2459 someone from the financial community 
>> argued that it was needed.  So, it was not deprecated.   You can look at 
>> the archives for the recurring discussion.
>> 
>> Russ
>> 
>-- 
>Regards,
>
>Todd E. Johnson