Re: German Law and OCSP

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Ambarish and Simon,

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. 

If so, it thus seems to me that the problem that is attempted to be
addressed has to do with the possible compromise of a CA key.
Applying the usual security process leads to the following: this is
a rather seldom event. However, in case of the occurence of that
unlikely event a "disaster recovery plan" is needed and must be
established in advance. This means that usual operations do not
necessarilly need to be encumbered by an additional complexity (or
new protocols) and that the additional complexity should only occur
at the time the event occurs.

I also got the impression that, if this is the problem to be solved,
unless we define an alternative to address the same issue, it could
become MANDATORY to use this additional guarantee, making on-line
queries mandatory (we have all heard recently of denial of service
attacks).

I would first like to make sure that this understanding is correct.
Is it ?

Regards,

Denis

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