Re: On Hold

["Bob Jueneman" <BJUENEMAN@xxxxxxxxxx>]

Juergan,

I believe that most of these issues fall in the area of APIs, and/or program behavior, and not the PKIX protocol.

PKIX, AS A PROTOCOL, may specify a particular behavior, but that doesn't mean that the implementation is required to do something stupid, or against the user's wishes.

Take the case of a code signing functions. Suppose Microsoft's code signing key were compromised, either in fact or merely a suspicion.  In order to protect against potentially misleading code signatures, Microsoft would surely revoke that certificate.  

But what would happen to all of the previously signed modules?  One thing that they surely would NOT do is make new versions of every module available for a free download, for that would mean effectively giving away their entire product line!

What should the loader do in this case, then?

The only reasonable action would be to alert the user:  "The key/certificate used to validate this software module has been revoked. What do you want to do: (1) Skip this module; (2) Accept this module; (3) Suspend module checking; (4) Fail."

At least the "Hold" condition makes it possible for this to be a temporary condition, as opposed to a permanent rejection.

Bob


> 
> 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".

I agree completely. I think that the current PKIX draft requires this
result.
> 
> 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.

It sounds well.
> 
> 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.

Thanks for example. I don`t like this approach. When I have unterstood
correct, as a result we have the MAYBE at the end. If the CA revokes a
certificate used for code signing and set the reason code "on hold",
then the certificate validation software i. e. the software loader must
create an "invalid", in my opinion. Hence, the software is not loading.
At the moment, I don`t see the worth of "yellow-valid" in software
validation. Provided that the software loader accepts a "yellow-valid",
the output contains a corresponding warning "may be wrong". What does
the human recipient now?  

I would argue that there is not a unique PKI solution. There exists at
least three models:
(i) cash 
(ii) charge 
(iii) software validation.
All these models have their own requirements, obviously. Otherwise, we
need interoperability. So, I see the requirement for generally binding
policy information in the issued certificates. I don`t know what is
happened if PKI components that are intended for usage within different
models are mixed. If you should happen to know it, please let me know.

> 
> 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
> >

-- 

with regards

--------------------------------------------------------------------
Juergen Walter                  PoP Leipzig/Halle/Jena
DEH information systems GmbH    WWW: http://www.deh.de 
Weissenfelser Strasse 46a       Germany
D-06217 Merseburg               Tel.: +49 3461 3318-25
Email: walter@deh.de            Fax:  +49 3461 415072
--------------------------------------------------------------------

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
bjueneman@novell.com
1-801-861-7387