[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Certificate suspension
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
>
--
Regards,
Todd E. Johnson
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.