Re: German Law and OCSP

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Simon,

Thanks a lot for your response. However, I do not believe that the
interpretation you make will be the same as the interpretation from
Andreas. :-)

> > Before discussing the modifications or enhancements to be made to
> > OCSP I would like that we go back to the rational of making them.
> >
> > I have not been able to follow in details all the E-mails exchanges
> > on that topic, so if this has already be posted on the mailing list,
> > please indicate me in which message it is mentioned.
> >
> > I would like to go behind arguments like "this is required in
> > specification XXX". I would like to understand the rational of the
> > requirements and, once these are identified, if there would be other
> > solutions that could solve the same requirements.
> 
> > Changing a status in a spec. is an easy thing to do. Before doing
> > anything like this, we (i.e. the WG) have to understand the
> > implications.
> >
> > Once said, let us come to the technical side.
> >
> > It seems to me that the purpose of this new service is to offer an
> > additional guarantee which is that the certificate has really been
> > issued by the right CA and is not a forgery of a certificate made
> > using the CA compromised key.
> 
> This discussion is first and foremost about how to express additional
> assertions in OCSP (apart from revocation) in general, not any particular
> assertion.

A said above: Changing a status in a spec. is an easy thing to do.
Before doing anything like this, we (i.e. the WG) have to understand
the implications. 

> As you say, issuance is not a question if you have the certificate at hand
> and trust the CA certificate. However:

Sorry, this is not what I said. I considered the case of a CA key
compromise. In that case the certificate that you have at hand might
be a forged one, if the CA key has been compromised. So you do not
know whether it comes from the right CA or from the bogus CA.

> Andreas Berger wrote:
> > We had to extend the functionality (it was mid 1998 if I remember
> > correctly). OCSP supports (supported) only the CRL-like "CRL on-line"
> > design. We needed (as Hans has written)
> 
> > 1. Certificate was created, is in the service since T,
> > and is not revoked
> > 2. Certificate was created, is in the service since T, and is revoked
> > 3. Certificate is unknown
> 
> > which was not possible with then the OCSP.
> 
> In my understanding "is in service" means that the certificate can be
> produced at one time, but should not be usable until some later time, e.g.
> when the intended user confirms receipt of the corresponding token.

I do interpret "in the service since T" in the same way, so let us
ask the original writer (if he listens to the PKIX mailing list) to
say in a few words what this means, but also ask him to provide the
rational of the requirements that lead to the inclusion of that
sentence.

Denis


> Simon.
> 
> Simon Tardell, Software Architect, iD2 Technologies
> simon.tardell@iD2tech.com, http://www.iD2tech.com/
> voice +46 8 7755225, cell +46 70 3198319, fax +46 8 7267912
> European IT-prize grand winners 1998 -- http://www.it-prize.org
> AU-System Group Swedish IT-company of the year 1999