Subject: RE: German Law and OCSP

From: Simon Tardell <[email-masked]>
Date: Wed, 9 Feb 2000 11:10:34 +0100

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

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

---

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 10 Feb 2000 01:22:22 +0100

All,

We have submitted a new, and hopefully final, draft profile for Qualified
Certificates.

In this draft we have included the consensus from the latest intensive
discussions.

I would like to draw the attention to the fact that there are some
substantial changes in this document which includes:
- The personalData solution is removed from the draft
- Use of subjectDirectoryAttributes extension is added as replacement.
- The pseudonym attribute has got a new standard OID (X.520)
- dnQualifier is replaced with the serialNumber attribute

In addition to this there are some minor changes and ASN.1 updates.

Due to a broken link error in the IETF web page, you must follow this URL to
find the new draft (the current pointer on the IETF page is pointing to the
old non-existing draft)

http://www.ietf.org/internet-drafts/draft-ietf-pkix-qc-03.txt

At this moment I don't know of any unsolved issues.

/Stefan

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 10 Feb 2000 14:34:06 +0100

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