Subject: RE: OCSP request

From: Ambarish Malpani <[email-masked]>
Date: Wed, 26 Jul 2000 07:10:43 -0700

Hi Juergen,

    A few issues:

1. OCSP responses are not meant to be weak at all. The meaning of
good is "not revoked" or "still good" (as long as the certificate
was correctly issued and hadn't expired before the ArchiveCutoff
date).

2. The meaning on unknown is "I don't know [or am not saying]"

By changing these meanings, you do the following:
a. You aren't doing OCSP any more - at least not as most of the
rest of the world interprets it. The problem you might run into,
is say, somebody builds an ISIS OCSP server and somebody else
tries to use it with say a Netscape Communicator OCSP client. The
two products will claim to talk OCSP, but will actually be saying
different things in their requests and responses and nobody else
will ever know.

b. The reason why the change ISIS has proposed is "wrong" is:
In an OCSP request, you identify a cert by the hash of the CA's
public key [and the hash of the CA's name] and the certificate
serial number. If somebody had compromised the CA's public key,
all they would need to do, is create a new certificate with a
serial number that corresponds to a legitimate serial number, but
a different subject public key and there goes the ability of the
OCSP responder to tell you anything useful.

Part of why it is valuable to at least pose desires to change the
interpretations of RFCs on this kind of a list, is you might
actually get some useful input from others, who might think about
a problem in different ways.

Does that make sense?

Regards,
Ambarish

P.S. Again, if you do pose the problems you want to solve, there
might be other reasonable ways of extending OCSP [within the
framework of the protocol], that might better fit in with the RFC
itself.

A

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Juergen Brauckmann [mailto:[email-masked]]
> Sent: Wednesday, July 26, 2000 5:58 AM
> To: Ambarish Malpani; 'Simon Tardell'; 'Rich Salz'
> Cc: [email-masked]
> Subject: RE: OCSP request
> 
> 
> Ambarish, Simon,
> 
> I'm a member of the group that worked on the ISIS. Comments below... .
> 
> >> -----Original Message-----
> >> From: Simon Tardell [mailto:[email-masked]]
> >> Sent: Tuesday, July 25, 2000 8:45 AM
> >> To: 'Ambarish Malpani'; Simon Tardell; 'Rich Salz'; Joerg Seidel
> >> Cc: [email-masked]
> >> Subject: RE: OCSP request
> >>
> [...]
> >> Also, in your interpretation (and mine) "unknown" means "I 
> >> don't know or
> >> will not say". As a client a perfectly reasonable reaction to 
> >> that would be
> >> to come back and check later or go to another OCSP responder 
> >> (assuming I
> >> have a list to choose from) and query that responder. 
> 
> This means that a client *never* can get an authoritive 
> answer that the
> certificate is faked (by the way of a CA key compromise) 
> because a client
> has no way of knowing whether he talked to all OCSP 
> Responders that may
> know something about the certificate.
> 
> >> However, it is
> >> possible to interpret the "unknown" definition as an 
> >> assertion that "I know
> >> that this certificate is not issued". This is the 
> >> interpretation taken by
> >> the German Trust Center Work Group in their ISIS spec. 
> 
> RFC2560:
>    The "unknown" state indicates that the responder doesn't know about
>    the certificate being requested.
> 
> ISIS:
>    	"Such a reply means that the queried directory service 
> (SigG) cannot 
> 	provide information about this certificate, since it 
> was not issued 
> 	by the corresponding certification authority or was not 
> entered into 
> 	the directory service (SigG)."
> 
> Let me try to explain why we want to have "hard" responses 
> from directory
> services. The minimum requirements to OCSP in RFC2560 are 
> "weak" in the
> sense that there is only one real answer ("revoked") and two answers
> ("unknown" and "good") which basically mean "Hm, I'm not 
> sure". Minimum
> RFC2560-OCSP only provides blacklist functionality.
> 
> This is not sufficient for systems that must be 
> robust/tolerant against CA
> key compromise or such things. It is also not sufficient for long term
> validation of signatures, where you might have, e.g., a 
> signature and a
> certificate with an expired crypto algorithm, and a chain of 
> timestamps
> with valid algorithms, and where you want to verify the state of the
> certificate that made the signature. In this situation you 
> cannot rely on
> the certificate itself as an evidence that a CA ever issued 
> it, you must
> ask the CA.
> 
> In such systems a directory service must be able to give real 
> *positive*
> answers about certificates ("Yes, my CA issued this 
> certificate."). This
> means we need white lists. This can be done by using OCSP and 
> interpreting
> "unknown" as "The certificate was not issued by this CA", and by
> interpreting "good" as "The certificate was issued by this CA and not
> revoked".
> 
> 
> The semantics of "Good" is left rather unspecified in RFC2560, why
> shouldn't also "Unknown" be the subject of profile-specific
> interpretations? Why should that be "very, very wrong"?
> 
> Juergen
> -- 
> Juergen Brauckmann             Tel.:  +49 (0)40 / 80 80 26-3 11
> TC TrustCenter GmbH            Fax.:  +49 (0)40 / 80 80 26-1 26
> Sonninstraße 24-28   	    mailto:[email-masked]
> D-20097 Hamburg 		    http://www.trustcenter.de	
>

---

From: Juergen Brauckmann <[email-masked]>
Date: Thu, 27 Jul 2000 11:34:04 +0200

Hello Ambarish.

>was correctly issued and hadn't expired before the ArchiveCutoff

From RFC 2560:
   The "good" state indicates a positive response to the status inquiry.
   At a minimum, this positive response indicates that the certificate
   is not revoked, but does not necessarily mean that the certificate
   was ever issued

By saying that OCSP responses are "weak" I had the last sentence in mind.
An OCSP responder can give me a "good" even if the CA did not issue the
certificate. Minimum-RFC2560-OCSP-responses with "Good" don't tell me
whether the certificate ever existed.

"Weak" is probably a bad word for it. 

>The problem you might run into,

Yes, I see. 

One question (mainly an attempt to try to understand rfc 2560): Why didn't
you include specifications for the issuance questions into rfc 2560?
Obviously you were aware of the problem because the description of "good"
says that such information may be delivered by extensions. And why isn't
there a fourth state "noSuchCert" besides good,revoked,unknown? I
understand that it was the intention to be able to build CRL-based OCSP
Responders, but I don't see why it should have been impossible to combine
the two things.

>OCSP responder to tell you anything useful.

Yes. Therefore the OCSP Response should contain a hash of the certificate
in an extension, see my mail
from yesterday "good in OCSP Responses. Was: Re: OCSP request". This is the
ISIS certHash extensions Simon is refering to in his mail from 10:28 today.

>a problem in different ways.

Well one problem is that it's difficult to see what the interpretation of
RFC2560 is that the authors had in mind... .

>framework of the protocol], that might better fit in with the RFC

We try that, see the certHash extension... .

Regards,
  Juergen