Subject: RE: German Law and OCSP

From: Simon Tardell <[email-masked]>
Date: Thu, 10 Feb 2000 16:46:13 +0100

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

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

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.

Simon.

Simon Tardell, Software Architect, iD2 Technologies
[email-masked], 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

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 10 Feb 2000 16:59:24 +0100

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. :-)

> assertions in OCSP (apart from revocation) in general, not any particular

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. 

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

> 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

---

From: Andreas Berger <[email-masked]>
Date: Wed, 23 Feb 2000 15:59:54 +0100

I will try to give some of the rationale behind the design of the German
Signature Law as I understand it. You have to understand that the
requirements were (and still are) not laid down in technical term and
that - of course - there are different interpretations.

One basic design was the differentiation between the CA and the
"information service". The CA issues the certificates and the
information service - an entity that is a distinct organizational unit
from the CA - revokes them. This can be interpreted as a technical
realization of a division of duty which probably could have be solved
with a requirement for the organizational procedures inside a CA.

Once such a division is made technically, it was extended to the idea
that a certificate should only be valid once it is inserted in the
information service database.

The law mentions the information service at one point:

Give that a CA ceases to operate, e.g. when being bankrupt or for what
reason ever, the certificates are still valid (which is true, a
revocation of the CA key is not necessary) iff the CA finds another
trusted party that continues the operation of the information service
and handles revocations. Accept that this is not a technical idea we
had, it is an idea that the lawmakers had. But I do think that it has
some truth in it.

Another point is that the compromise of a CA key may be a very seldom
event but the potential cost, even with a desaster plan in place (anyone
heard about one from any CA?) it may be desirable to have simple
technical fallback position.

And a last remark to our OCSP extension: We extended basically the "not
revoked" case to include extension. This should not disturb other
systems that use the "not revoked" answer in the original CRL based way

Andreas
-- 
Keine Zeit haben wir genug!

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 23 Feb 2000 16:51:50 +0100

Andreas,

Thank you for attempting to provide some explanations.

> with a requirement for the organizational procedures inside a CA.

Up here this is fine. There are two distinct entities, each one
using its own signing key, one for issuing certificates, and another
one for revoking certificates.

What is not said is whether a relying party will trust *directly*
only the CA key or both the CA key and the Revocation Authority key.
It has deep implications, in particular if the CA key is
compromised.

> information service database.

I do not understand. To be "valid" a certificate does not (even)
have to be published. It may be given back to the user who may
decide to send it to whatever entity he wishes.

> and handles revocations. 

It only means that there must be "some way" to indicate which
Revocation Authority will continue to keep track of revocation
information for the already issued certificates from a given CA.
There is no need for a notion of insertion of certificates in a
public database.

> Accept that this is not a technical idea we

For that case, there exists simple fallback solutions that do not
require the use of an "information service database". The whole
Directory model from which X.509 certificates emerged is making the
assumption that there may be a Repository and, when that this
Repository exists, it is not trusted (this is why certificates are
signed by CAs).

> systems that use the "not revoked" answer in the original CRL based way

The problem is more important than simply adding an additional
status.

Denis