RE: German Law and OCSP

[Ambarish Malpani <ambarish@xxxxxxxxxxxx>]

Hi Simon,
    You describe the situation very well. If I were trying to provide
additional semantics, I would do them through extensions. 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.

We went through a long discussion on how best to do this when OCSP
was being defined and figured that the best way of keeping the spec
clean, was to have a very specific meaning for status, which is just
revocation status.

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.

Hope this helps,
Regards,
Ambarish 

> -----Original Message-----
> From: Simon Tardell [mailto:simon.tardell@iD2tech.com]
> Sent: Tuesday, February 08, 2000 2:26 AM
> To: 'Ambarish Malpani'; 'Andreas Berger'
> Cc: 'ietf-pkix@imc.org'
> Subject: RE: German Law and OCSP
> 
> 
> 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
>