RE: German Law and OCSP

[Simon Tardell <simon.tardell@xxxxxxxxxxx>]

> Hi Simon,
>     You describe the situation very well. If I were trying to provide
> additional semantics, I would do them through extensions. 

Thanks, Ambarish. If this is the intention behind RFC2560 [model 2) below]
then then perhaps a clarification should be made to the RFC. This to avoid
several OCSP profiles that are mutually incompatible.

There are a couple of points that come to mind: The last few paragraphs of
3.2 where the possible certificate status values are described indicate that
"good" means "cert is not revoked" && good_A && good_B ... and that the
answer MAY be qualified by extensions. That is contradicting what you just
said (since CertStatus would not be orthogonal to the extensions). On the
other hand it does not say that "revoked" means "cert is revoked" || bad_A
|| bad_B ... In other words, the definition of "good" and "revoked" are not
the positive and negative answers to the same question! 

In addition, "unknown" should perhaps be redefined as "the responder does
not have enough information to answer the question" to remove all doubt.

> For example,
> if a client wanted to know whether a cert was issued or not, in
> addition to its revocation status, I would recommend putting that
> additional status information in singleExtensions, rather than
> trying to overload the meaning of good.

Now, I think there are fairly good arguments for model 1). In the end, what
matters if it is ok to use the certificate or not, the reason may really
vary, but is of less importance to whoever is refusing service as a result
of the reply. In model 2) you would put an equivalence between "error -- I
don't understand what it says here" and "no, you can't do that". But the
important message is the "no, you can't do that" not the "because ...", so
making the "because ..." part critical seems unnecessary. Also, you would
loose the distinction between "if you don't understand why you can't do
that, it doesn't matter, just don't" and "you really should understand
this". The latter is an exceptional condition while the former is not.
Treating exceptional conditions (unhandled critical extensions) as a normal
condition would require a quite clear wording about this in the RFC to make
sure all clients understand the semantics in the same way.

But, either model is fine with me, as long as a clear choice is made in the
RFC.

> The issue of whether a cert was ever issued or not, did come up, but
> the group concensus was that a client either had the cert in hand and
> could verify the signature on the cert and so know whether it was
> issued or not.
> 
> If the CA's cert signing key was compromised and you wanted to deal
> with that case, you need to either directly trust the OCSP responder
> and ask it about the CA's self signed cert, or check the CA's cert
> if it is part of a larger hierarchy, or try to deal with the issue in
> an out of band way.

Agreed. However, "issuance" has a slightly different semantics in the German
specs. The certificate may not be valid for use until some time after its
actual production (an unknown amount of time). That property needs to be
answered by a German OCSP responder. 

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


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