Re: Certificate suspension

["Anders Rundgren" <anders.rundgren@xxxxxxxxx>]

Alfredo,
The problem you are referring is relevant regardless if you support certificate suspension or not since a valid certificate may
indeed be in the wrong hands without the legitimate user knowing or having reported it.

Since the majority of signatures these days are performed in on-line scenarios, certificate suspension for signatures and
authentication is essentially the same thing.

Regarding legality the fact is that people are actually convicted based on IP address associations and e-mail addresses.

The difference between signatures and authentication is that only the latter cannot be revoked which is why authentication remains
the most critical operation regardless of its legal status.

I wouldn't outlaw certificate suspension, it seems appropriate in an on-line world.

thanks
Anders Rundgren

----- Original Message ----- 
From: Alfredo Esposito
To: Bechlaghem, Malek
Cc: Todd E. Johnson ; Denis Pinkas ; ietf-pkix@xxxxxxx
Sent: Saturday, January 26, 2008 17:13
Subject: 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