Subject: Re: On Hold

From: Mike Smith <[email-masked]>
Date: Wed, 16 Dec 1998 08:49:49 -0700

I separated out my response to the "on hold"  question.

In my opinion, there are valid business reasons to suspend or put a certificate on hold.  Two of which incude:
1. Someone other than the certificate holder (say, her business competitor) reported a compromised private identitiy key.  Suspended until holder and owner could be notified and confirmed or disavowed.  The suspension would become revocation as default after specified time (say, 24 hours).  It would only be reinstated if the holder or owner denied the compromise.
2.  The holder or subscriber did not pay their bill, check bounced or other business reason between the issuer, repsository, holder and owner.  Again, revocation after a specified time period is the default, reinstatement by the CA and/or repository once again when holder or owner are in good standing.

With systems that only work (validate signatures and trust) while a certificate is still valid, then suspected compromised key situations would not be sufficient reason to suspend instead of revoke.  This model invalidates all signed objects, not just those signed within the suspension period.

If the system was implemented with a time stamp authority and requirement, which based the validation and trust verification on time the object was signed, then a record of the suspension would also have to be archived for these systems to work.  I believe that the current models for suspension have the record of the suspension dropping off the CRLs after one or two generations past the end of the suspension.

Michael

>>> Juergen Walter <[email-masked]> 12/16/98 03:37AM >>>
******************  InterScan Message (on zbc2)

noname is scanned and no virus found
*********************************************************
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !

---

From: Russ Housley <[email-masked]>
Date: Thu, 17 Dec 1998 11:46:25 -0500

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

At 08:49 AM 12/16/98 -0700, Mike Smith wrote:
>In my opinion, there are valid business reasons to suspend or put a 
>certificate on hold.  Two of which incude:
>1. Someone other than the certificate holder (say, her business competitor) 
>reported a compromised private identitiy key.  Suspended until holder and 
>owner could be notified and confirmed or disavowed.  The suspension would 
>become revocation as default after specified time (say, 24 hours).  It would 
>only be reinstated if the holder or owner denied the compromise.
>2.  The holder or subscriber did not pay their bill, check bounced or other 
>business reason between the issuer, repsository, holder and owner.  Again, 
>revocation after a specified time period is the default, reinstatement by 
>the CA and/or repository once again when holder or owner are in good standing.
>
>With systems that only work (validate signatures and trust) while a 
>certificate is still valid, then suspected compromised key situations would 
>not be sufficient reason to suspend instead of revoke.  This model 
>invalidates all signed objects, not just those signed within the suspension 
>period.
>
>If the system was implemented with a time stamp authority and requirement, 
>which based the validation and trust verification on time the object was 
>signed, then a record of the suspension would also have to be archived for 
>these systems to work.  I believe that the current models for suspension 
>have the record of the suspension dropping off the CRLs after one or two 
>generations past the end of the suspension.
>
>Michael
>

---

From: [email-masked]
Date: Thu, 17 Dec 1998 12:23:27 -0500

>the path is valid or it is not valid.  To me, "on hold" creates a >maybe.

I view path processing as a separate (prior) step to checking on
certificate status.  I also do not see it as being appropriate
for a CA, only "end-user" (or server) certs.  Given that, it seems highly
appropriate, at least in the financial area.
	/r$

---

From: David Solo <[email-masked]>
Date: Thu, 17 Dec 1998 17:20:21 -0500

Russ,

While I, too, detest "on hold"; it appears to have a large enough
constituency (and some reasonable arguments in the smart card arena
where cert/key reissuance may be more expensive) that killing it is
unlikely.  Since I agree with your statement about cert path validation,
I think the conclusion is that it is essential that the semantics and
usage of hold allow validation/RP software to treat it exactly the same
as other revocation (essentially ignore CRL reason other than possibly
displaying it).  One instance of this is the previously mentioned
statement on revocationDate.  Also, I think it implies we should
strongly deprecate the holdinstruction extension.  I'm not sure what
other consequences are.

Dave

---

From: Juergen Walter <[email-masked]>
Date: Fri, 18 Dec 1998 12:34:41 +0100

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.