Subject: RE: OCSP request

From: Ambarish Malpani <[email-masked]>
Date: Tue, 25 Jul 2000 07:55:38 -0700

Hi Simon,
    Here is the text from RFC 2560:

---------------Start quote from RFC----------------------
 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 or that the time at which the response was produced
   is within the certificate's validity interval. Response extensions
   may be used to convey additional information on assertions made by
   the responder regarding the status of the certificate such as
   positive statement about issuance, validity, etc.

   The "revoked" state indicates that the certificate has been revoked
   (either permanantly or temporarily (on hold)).

   The "unknown" state indicates that the responder doesn't know about
   the certificate being requested.

---------------End quote from RFC----------------------

Good means that it is not on the revoked list. If you wish to
assert other things, you can do so with extensions.

Revoked means that it is on the revoked list (you can still assert
other things with extensions - nothing says you can't do that,
although I agree, it would have been better to say so explicitly.

Unknown means you don't know - aren't willing to say either good
or bad (again, you can still use extensions to say more things).

I am not sure which part of the language you are objecting to. Would it have
been satisfactory if we had the line starting "Response extensions...
validity, etc." in each of the 3 states? Would you have
preferred that we not have allowed for any extensions in responses?

I agree that we should have indicated that extensions could be used
to convey additional information in any type of a response (which
was the whole point of using extensions in responses IMHO). I
disagree that we should not have allowed people to put extensions in
responses that are not defined in the RFC - people are using OCSP
for a wide variety of applications that have different needs - I
would not want them to discard OCSP because they can't convey
anything other than revocation status in responses.

As a server or client, my attitude to extensions is: If the
information in the extension is something that you don't want the
recipient to ignore, mark it critical. Otherwise mark it
non-critical.

Regards,
Ambarish

---------------------------------------------------------------------
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: Tuesday, July 25, 2000 7:41 AM
> To: 'Rich Salz'; Joerg Seidel
> Cc: [email-masked]
> Subject: RE: OCSP request
> 
> 
> > > The problem is that OCSP does not tell you whether the 
> > certificate was already
> > > issued at the time of the signature. It only says it was 
> > not revoked.
> > 
> > Depends on the OCSP implementation.  Some (e.g., Valicert 
> > last I looked)
> > can only say "not revoked" while some (e.g., CertCo last I 
> looked) can
> > also say "not known"
> 
> The problem with the OCSP protocol is that there are three 
> non-orthogonal
> answers: good, revoked, unknown. It'd all be well if "good" 
> was identical to
> "not revoked" and "unknown" meant "I can't tell if it is 
> either, go ask
> someone else, or come back later, I might find out". But that 
> is not the way
> it is expressed in the RFC. In the RFC "good" is an assertion 
> that A && B &&
> C .. any number of conditions is true, while revoked only means !B and
> unknown could be interpreted to mean !C ("I KNOW this cert was never
> issued"). Different groups have different requirements and 
> will want to
> include different assertions in OCSP or something very 
> similar (e.g. some
> want to assert that a cert was ever issued) in a way that 
> will make the
> clients un-interoperable. That is, they will comply in the 
> sense that the
> bits on the wire are the same, but the intended 
> interpretation is different.
> Since end-users may very well be members of different PKIs this is
> unfortunate. 
> 
> 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: Simon Tardell <[email-masked]>
Date: Tue, 25 Jul 2000 17:45:20 +0200

Ambarish, 

Let me just start by pointing out that I agree with you (mostly). But not
everybody agrees with me....

> I am not sure which part of the language you are objecting 
> to.

The problem I have is that a responder may through "good" assert that any
number properties are true, *without* qualifying with extensions. On the
other hand "revoked" means a negative assertion to only one of these
properties.

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. 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. Under those
semantics, I can't expect any other responder to have better information.

> Would it have

The preferred way would have been to restrict CertStatus to carry
information only on revocation and force issuance, validity or any other
property that you want to assert into extensions. Preferrably those
extensions should have the same structure (assertion true, assertion false,
i-don't-know). 

Simon.

---

From: Ambarish Malpani <[email-masked]>
Date: Tue, 25 Jul 2000 10:04:43 -0700

Hi Rich,
    Not true. We have the ability to say unknown also. We can
also do secondary checks, where you actually look for the
existance of a cert in a directory, if that is what people want.
People just need to decide that they want that functionality.

Regards,
Ambarish

> From: Rich Salz [mailto:[email-masked]]
> Sent: Tuesday, July 25, 2000 7:13 AM
> To: Joerg Seidel
> Cc: [email-masked]
> Subject: Re: OCSP request
> 
> 
> can only say "not revoked" while some (e.g., CertCo last I looked) can
> also say "not known"
> 	/r$
>

---

From: Khaja Ahmed <[email-masked]>
Date: Tue, 25 Jul 2000 14:18:03 -0400

Karl,

I would like to second your request for this capability.  This is a very
important feature/capability and should really be added to the standard.  

To answer your question, I am aware of work being done to add this to OCSP.
However, it is in the way of proprietary implementations.  The proprietary
nature of any soluion poses it's challenges and so it is best if this body
could take this on as an enhancement to the standard.  

It would be great if someone could propose a revision to the protocol to
included this capability.

It is probably not much more than:

- Stating that a signer may make an OCSP reqest for the status of his
certificate and attach the response to the signature in a specified format.

- Requiring that a relying party OCSP client recognize the proof that the
certificate was not revoked when the signature was made (or within some
reasonable tolerances).

Some other things that would need to be and could easiliy be accomodated
are:

-If the relying party does not trust the OCSP response (Freshness Proof)
attached to the signature it may do it's own checking regardless.  

The nice thing about this is that along with the signed data (which may be
archived) exists proof that the signature was valid when it was made.

An example application that would benefit greatly is: A notebook user /
travellers who downloads her e-mail and reads it off line.  No online access
to OCSP server is needed.  The "Freshness Proof" with each message shows
that the certificate was good when the message was signed.

I recognize that that this will not accomodate all needs and cover all cases
but it covers enough cases that it would constitute a substantial
iimprovement.

Khaja

-----Original Message-----
From: Karl Scheibelhofer
To: IETF PKIX Mailing List
Sent: 7/25/00 9:03 AM
Subject: OCSP request

to verify a signature, it is necessary to find out, if the certificate
used
for signing was valid when the signature was created. normally it is
only
possible to fix the time the signature was created in a time interval;
e.g.
between two timestamps.
to find out, if the certificate was valid during this time interval, i
see
two options:

1. i can get the certificate status information when i create the
signature,
timestamp it, and attach the whole thing to the signed document.

2. have a extended OCSP protocol that allows to request this information

are there any attempts to integrate such a feature to OCSP?
i think that this would be a valuable feature for OCSP. it would avoid
the
necessity to attach all this verification stuff to all signed documents.

with best regards,

  Karl Scheibelhofer

--

Karl Scheibelhofer, <mailto:[email-masked]>
Institute for Applied Information Processing and Communications (IAIK)
at Technical University of Graz, Austria, http://www.iaik.at
Phone: (+43) (316) 873-5540