[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Certificate suspension

The point is the usage of certificate. For authentication purposes, suspension is fine. If my certificate is suspended "now", "now" I can not authenticate myself to, say, my workstation. If the purpose is non repudiation (digital signature has a handwritten signature) the legal value of a document signed during the suspension period is not trivial to assess

Bechlaghem, Malek wrote: 
Hello there,

While I do agree that the semantic of processing a digital signature is
difficult for a relying party when the signer certificate is suspended,
I would like to point out to at least one area where certificate
suspension does have a practical use.

Having been involved in few ID card issuing projects worldwide, my
experience from these is that eID card lifecycle processes tend to be
coupled to certificate lifecycle processes. In other terms, when an ID
card holder suspects that his card is lost or stolen, we call a helpdesk
that suspend his ID card for a defined period of time. This results in
the card certificates revoked with status on-hold (i.e. suspended). If
the guy founds his card, he calls the same helpdesk that will activate
his card back which results in his certificates un-suspended.

This is at least one practical use of using certificate
suspension-unsuspension. As for the relying-party application, it shall
be developed according so that it interprets the certificate on-hold
status which should not be difficult any way.

Hope this helps.
Regards,
Malek.  
  
 
-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
On Behalf Of Todd E. Johnson
Sent: Friday, January 25, 2008 1:42 AM
To: Denis Pinkas
Cc: ietf-pkix@xxxxxxx
Subject: Re: Certificate suspension


Thanks for the insight.

Personally, I believe it is the "temporary" that is the cause of 
discomfort.  As you already know, the CA is effectively saying "We can 
not guarantee proof of possession of the private key to this end 
entity", and then it is removed without applications ever knowing.  This

is of course, only by personal experience.

Rather, I would be more comfortable if something like invalidityDate 
were added, only in the form of a date range, so the CA then says "We 
can not guarantee proof of possession of the private key to this end 
entity between the dates of [beginHold] and [endHold].  Further, 
eliminate the ability for the CA to remove the entry from the CRL, but 
allow for replacement in the event it is actually revoked in the future.

I don't feel the CA should not be in the business of suspending a 
certificate to deny access to applications.  I feel that that is more 
the application/authorization responsibility.  (i.e., certificate vs. 
key suspension)

Perhaps this seems a bit like a Rube Goldberg process, but in the end, 
it gives a true technical capability to accept, or outright deny as 
revoked depending on the application/business needs.  That's only my 
opinion though.  And of course, everybody has one ;)


Denis Pinkas wrote:
  
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