Subject: RE: OCSP request

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

Hi Simon,
    Again, we mostly agree... :-)

I like the idea of asking a separate question about whether a
cert is in a directory (or ever issued) and getting a separate
answer for that.

However, I don't agree that the B-and-W approach taken by ISIS
is reasonable, because of the hole I talked about in my previous
mail.

Also, it is unclear that the "big bang" thing works where
somebody uses the compomised CA's private key to issue a cert to
an "imposter OCSP responder". Now, if a CA's key is compromised,
the client still won't know, because it will see an OCSP response
issued by an apparantly legitimate responder [unless you insist
on the Direct Trust model in OCSP].

---------------------------------------------------------------------
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: Simon Tardell [mailto:[email-masked]]
> Sent: Wednesday, July 26, 2000 7:16 AM
> To: 'Juergen Brauckmann'; Ambarish Malpani; Simon Tardell; 'Rich Salz'
> Cc: [email-masked]
> Subject: RE: OCSP request
> 
> 
> Jürgen,
> 
> The black-list AND white-list approach taken by German 
> signature legislation
> is good by me. It addresses the potential "big-bang" of CA 
> key compromise in
> ways that are reasonable. However, I don't think you need to 
> change OCSP
> semantics to do this. I see the German ISIS OCSP variety as a 
> change rather
> than a profile, because an OCSP client has to behave differently when
> talking to an ISIS OCSP responder than when talking to a world OCSP
> responder.
>  
> > 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"?
> 
> One problem with altering the definition of "unknown" from "I 
> don't know" to
> the assertion "I know this certificate has not been issued" 
> is that you may
> have several OCSP responders to choose from (for availability 
> reasons) and
> if one of them is unable to answer one or more of the 
> requests in an OCSP
> request, it should be possible to go down the list, or come 
> back later. If
> you don't distinguish between the "no" and "???" answer, you 
> don't have that
> possibility. Even if an ISIS compliant PKI may not use this, 
> the end-user
> may be part of other PKIs that do, and it'd be convenient to 
> be able to use
> the same clients.
> 
> Basically there are two independent assertions: revoked - 
> yes/no/don't-know
> and issued - yes/no/don't-know. My suggestion is to treat 
> them on equal
> footing. Restrict CertStatus to represent the first assertion
> (yes/no/don't-know on revocation) and introduce an extension 
> for the second
> assertion ("being inserted into the directory (SigG)") with the same
> structure (yes/no/don't-know). Let this extension be critical 
> if the value
> is "no" or "don't-know". In this way, non-ISIS compliant 
> clients will work
> together with ISIS PKIs and vice versa, without losses. Of 
> course, some
> combinations are unreasonable (you hardly revoke a 
> certificate that was
> never issued) or may be disallowed by policy (maybe the 
> "don't-know" answers
> are not possible due to policy).
> 
> Orthogonality between assertions means that further 
> assertions ("was valid
> at time X" was suggested) can be introduced in the same 
> manner, without
> breaking unaware clients. That is probably the biggest advantage.
> 
> One more comment:
> 
> > >> 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.
> 
> Sure he can. It's a matter of policy. Since you can't trust 
> the list of
> responders in the AIA extension (because you fear CA key 
> compromise) you
> have to have a hard-coded list. This is true whether you 
> allow for one or
> several responders.
> 
> Regards,
> 
> Simon
> 
>  
> Simon Tardell, Software Architect, iD2 Technologies
> voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319
> [email-masked], http://www.iD2tech.com
> Securing the Internet economy
>  
>

---

From: Rich Salz <[email-masked]>
Date: Wed, 26 Jul 2000 10:52:18 -0400

> cert is in a directory (or ever issued) and getting a separate

But then you need something like draft-salzr-ldap-repsig to ensure that
nobody has tampered with, or interecepted the communications to/from,
the repository.
	/r$