Re: On Hold

["Bob Jueneman" <BJUENEMAN@xxxxxxxxxx>]

Russ, Juergan,

To the extent that the RP software is making a decision as of the 
moment as to whether to accept or reject a certificate, "on 
hold" functions like a CRL, and the binary result, if there is
or must be a binary result, is "invalid".

However, if the RP software caches CRLs, or if the same 
signature/certificate might be processed in the future,
either for nonrepudiation purposes or just because some
file is processed repeatedly (such as a signed code module),
then the CRL status must be checked afresh.

Obviously, just because the certificate is either on hold or 
actually revoked does not mean that the relying party is 
denied any discretion as to whether to accept the 
signature or not. It may be sufficient to merely raise the level
of scepticism considerably, and hence my concern about a 
binary result. I prefer a Red, Yellow, Green type of 
indication, where Yellow may be that the information is presented 
to a human for further review.

If you consider the possible denial of service implications
of revoking a widely used certificate under a merest suspicion
of a possible compromise, I think you will come to a better 
understanding of why "hold" is necessary.

Consider the implications of revoking say a popular code signing
certificate based on the suspicion that a compromise had 
occurred, when that signature is checked every time a popular 
program is downloaded. Or worse yet, imagine a situation where
in order to prevent viruses, every program is cryptographically 
validated by the loader.  Suddenly hundreds of millions of programs
would stop working until a new certificate could be created 
and new load modules distributed.

Rather than raising the bar to the extent that absolute certainty is
required in the case of a possible compromise because of the 
almost catastrophic consequences, a hold allows those 
certificates to be viewed with suspicion until a final determination 
can be made.

Bob


>>> Juergen Walter <walter@deh.de> 12/18/98 04:34AM >>>
I disliked "on hold" one year ago. One of the reasons why I changed my
view was the following. In my opinion, a certificate revoked once must
not valid at any time in the future. So, I consider the "on hold" reason
code like a revocation. I only allow a "on hold" certificate to becomes
valid when there was no reason for revocation at any time in the past.

The certificate path validation software retrieves then the CRL. Why the
software can only generate "valid" or "invalid" the answer must be
"invalid", even though the certificate status is "on hold".
Alternatively, the answer may be somewhat like "invalid - please read on
hold information. plase contact CA XY".

I agree with you, a fast revocation handling is quite better. Therefore,
an "on hold" status would become dispensable. But, I don`t see it next
time. Even if you have a fast technical equipment, the revocation
procedure may slow for bussiness and legal reasons.

Another way you mentioned is the restriction of certificate usage as a
"digital ID". All other attributes like "credit card limit" are moved to
a data base. Now, the data base management has to deal with the "on
hold" when the underlying bussiness model needs "on hold".

An example follows. A corporate CA issues certificates on the behalf of
their employees, i. e. the organization field contains the corporate
name. The employees are spread over the world. The private key is kept
in a smart card. The corporate control unit detects suspected
transactions done by identity A. The risk model requires to revoke A`s
certificate. Consequently, the corporate CA revokes the certificate
immediately. Provided that the transactions no longer are suspicious,
the employee needs a valid certificate. The procedure takes time because
the private key is kept in a smart card. What is to do? Should the CA
renewal the certificate including the same key? 

Provided that the corporate CA wants to pay the price for "on hold" in
the sense described above, the CA had to remove the CRL entry. No
renewal is required.

 

Russ Housley wrote:
> 
> X.509 identiy certificates bind a public key to an identity (subject DN
> and/or subject alt names).  A CRL entry indicates that this binding is no
> longer appropriate.  It might be inapproriate due to key compromise, name
> change, or a number of other reasons.
> 
> Certificate path validation software it trying to generate a binary answer:
> the path is valid or it is not valid.  To me, "on hold" creates a maybe.
> For this reason, I really dislike "on hold."
> 
> We need to have straight forward path validation if we are going to see
> wide spread implementation in clients.
> 
> Often certificate path validation is part of some overall system founction,
> like authentication to a web site.  Based on the output of certificate path
> validation and other data, the clinet will be admitted to the web site or
> refused access.  I suggest that bad check history is "other data," not a
> reason to revoke the binding of the user's identity to the public key.
> 
> Similar arguments can be made for e-mail, remote access, e-payment, and
> other environments.
> 
> Russ
>