Subject: Re: OCSP - Public Key Dstribution

From: Peter Sylvester <[email-masked]>
Date: Sun, 20 Sep 1998 19:41:58 +0200

Anders,

the proposal of Denis solves a different problem. It makes the
syntax easier for the client, it doesn't require a field that
may be unnecessary. 

An interpretation of OCSP or OCVP is independant of the
syntax change. 

It is the interpretation of the RESULT that counts: 

- In OCSP you interprete 'good' as 'I have not information that it
  is NOT GOOD'.

- in OCSP you would interprete 'unknown' as 'I know that this CA
  has never issued the CA, or I do not know the CA'. 

Denis' proposal makes the proposal more lightweight.

You can even consider that an OCSP or OCVP does not need more 
than just a serial number (because it operated in a very
restricted environment of just one CA), but well, the protocol
should be able to cover a large range of applications.

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 22 Sep 1998 13:30:44 +0200

Denis,
> something that is nontrivial.   And "Certificate Domain" is also missing.

???
Certificate Domain is some kind of indication of what kind of certificate(s)
you want to validate.  I.e. like SET-certificates, a National ID-card, OBI-trader etc.
This could be of interest in both the request and in the response.  I.e. a trusted OCSP
server may support overlapping or disjunct domains and a typical subscriber
may be interested in just one type.  To standardize this seems unnecessary
in the same sense as defining trust models in OCSP.  It is a *deployment* issue
like certificate policies and liabilities.

Other extensions, like certificate validation might be considered
once OCSP is closed.

I assume that the "closing" of OCSP will be pretty theoretical when the definition
of extensions starts.  Already an IETF agenda item it seems

Regards
Anders