Subject: RE: OCSP request

From: Simon Tardell <[email-masked]>
Date: Thu, 27 Jul 2000 11:46:49 +0200

Denis,

> > This is not sufficient for systems that must be  robust/tolerant against
CA
> > key compromise or such things. 
> 
> Key compromise is an exceptional event (that should not happen, but
> might happen) that must be addressed under a disaster recovery plan
> (i.e. revoke the CA whose key has been compromised in all the
> certificates that has been issued for that CA by other CAs). 

I see the disaster, but I don't see the recovery in this.

As I see it, the problem the German model tries to tackle is that a CA which
has issued lots of certificates to the public (say millions) gets it keys
compromised somehow. Time-stamping services secure documents signed before
this moment, but there is another problem. Millions of germans are now
unable to go about their daily business. Potentially the German economy
grinds to a halt while the CA reissues millions of smart cards. Obviously
this would be a very bad thing. I'd hate to know that this scenario has not
been prepared in advance. Since the end-user keys did not get compromised
they can still be trusted. What is a problem is the linkage between the
holder and his keys, embodied in the certificates. The "directory service
(SigG)" essentially works as a time-stamping service for certificates,
ensuring that the certificates may still be used after the "big bang", just
as a general time-stamping service may protect signed documents against
problems that occur after the original signature, so that they may still be
used.

There are some obvious requirements following from this line of reasoning,
e.g. that the keys for OCSP responses have to be independent from the
issuing keys, and you have to have direct trust in the OCSP responder.

> This
> does not mean using means that *permanently* address that case. If
> you mandate an OCSP response in the sense you mention, then this
> means two things: 
> 
> 1) you deny the use of CRLs, and 

For this purpose, yes.

> 2) you also deny the local checking of the digital signature 
>    from a CA over any certificate (it means that a local checking 
>    by a RP is never sufficient since anyway an access to a trusted 
>    copy certificate is necessary in a trusted database from the CA 
>    which has issued it). So your model is *very* different from the 
>    path validation model that is currently described in RFC 2459 
>    (or its successor). 

Definitely an extra step, and different from "ordinary PKI".
 
Simon.

Simon Tardell, Software Architect, iD2 Technologies
voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319
[email-masked], http://www.iD2tech.com
Securing the Internet economy

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 27 Jul 2000 15:16:42 +0200

Simon,

> Denis,
> 
> > > This is not sufficient for systems that must be  robust/tolerant 
> > > against CA key compromise or such things.

 
> As I see it, the problem the German model tries to tackle is that a CA which

Someone from Germany told me not to call it the "German model". Let
us talk of that *other* model, which means that this model is
different from the current X.509/PKIX model and therefore is using
mechanisms that are different from PKIX. I am not saying that the
other model is bad or good, simply that it is different.

> grinds to a halt while the CA reissues millions of smart cards. 

Ambarish said:

"P.S. Again, if you do pose the problems you want to solve, there
might be other reasonable ways of extending OCSP [within the
framework of the protocol], that might better fit in with the RFC
itself".

Juergen responded: "We try that, see the certHash extension ..." .

My comments is that the certHash extension is one *solution* to the
real *problem* that you describe.

> Obviously
> they can still be trusted. 

True.

> What is a problem is the linkage between the

This is *one* solution to the problem, ... but not the single
solution.

That solution is also not compatible with RFC 2560, section 2.2. 
where it is stated:

"All definitive response messages SHALL be digitally signed. The key
used to sign the response MUST belong to one of the following:

 -- the CA who issued the certificate in question
 -- a Trusted Responder whose public key is trusted by the requester
 -- a CA Designated Responder (Authorized Responder) who holds a
    specially marked certificate issued directly by the CA,
    indicating that the responder may issue OCSP responses for 
    that CA".

This means that the OSCP server is either directly known by out of
bands means or designated by the CA. For that "other model" to work,
the OCSP would need to be designated by an *upper* CA. This is not
allowed with the current text, because in the current PKIX model
only the CA that has issued the certificate is allowed to nominate
the server in charge of providing revocation status information. 

We are pretty far away of deciding whether we should add or not a
certHash to an OCSP response, but whether this WG is ready to
develop
a model that is not compatible with PKIX. In the past we had SPKI.
The basic question might be whether some interrested people would 
like to form a BOF for developping such a new model.

> Definitely an extra step, and different from "ordinary PKI".

So we strongly agree that this *other* model is fairly different
from
"ordinary PKI".

Denis