RE: German Law and OCSP

[Simon Tardell <simon.tardell@xxxxxxxxxxx>]

Ambarish wrote:

>     There are ways of profiling the spec that work within the
> parameters defined by OCSP. In other ways, you break the design
> of the basic protocol. In my opinion, this is the latter, not
> the former.

The German requirements raise the question what would be the "canonical" way
of extending OCSP. This is not quite clear to me from reading the RFC. In my
mind the scope of OCSP is to answer binary status queries on certificates
(good, bad and possibly "don't know"). The natural question to ask is that
of revocation. The Germans need to answer that of issuance. Still more can
be imagined.

In RFC2560 CertificateStatus can be set to "good", "revoked" or "unknown".
The wording is a bit unclear here: Does "unknown" mean that "I don't know
whether this certificate is revoked" or "I know this certificate does not
exist"? The Germans seem to have opted for the latter interpretation. Now,
assuming the former interpretation we have three answers to the revocation
question (good, bad, don't know). How do we extend OCSP to assert the answer
to other questions? I see two possible approaches:

1)
CertificateStatus is generalized so that it contains the logical sum of all
properties that the client wants to have asserted (or that the responder
wants to assert in response to a query). E.g. assume two properties A and B
that both have to be "good" for a certificate to be valid for use, then
CertificateStatus is "good" if both of them are "good", "bad" if (at least)
one of them is "bad" unless one of them is "unknown" in which case
CertificateStatus is "unknown". Extensions to the respective statuses can be
used to qualify the answer (e.g. to tell _what_ properties were bad), if the
client really cares.

2)
CertificateStatus is defined to only provide good, bad and unknown answers
to the revocation question. SingleExtensions are defined for each property
(except for revocation status) and each such SingleExtension can take the
value "good", "bad" and "unknown". The problem then arises that the client
can perhaps not be expected to understand new properties (extensions) as
they are implemented on the server. To solve that, these extensions should
be marked critical if they are "bad" or "unknown", but not if they are
"good".  

Now, this is not quite what it says in the RFC (for example, the answer
"good" allows to be qualified with other types of goodness, but there is
seemingly no way to answer "not revoked, but bad in some other sense"). The
former method seems more attractive from the perspective that it allows
making the clients simpler, but it would require some changes to the current
protocol. The latter solution would work with current clients (how widely
deployed are they anyway?) but is less appealing (an error in the client
would have the meaning "no, you can't do that"...).

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