Subject: RE: OCSP request

From: Ambarish Malpani <[email-masked]>
Date: Wed, 9 Aug 2000 08:40:09 -0700

Juergen,
    We did have a discussion about what kinds of questions OCSP
should answer when we were writing the RFC and the concensus was
that we were only providing the status of the certificate.

I am including most of the mails and different points of view
about this topic when the discussion was going on.

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: Juergen Brauckmann [mailto:[email-masked]]
> Sent: Wednesday, August 09, 2000 8:31 AM
> To: Denis Pinkas; Simon Tardell
> Cc: [email-masked]
> Subject: Re: OCSP request
> 
> 
> At 16:48 09.08.00 +0200, Denis Pinkas wrote:
> >THIS IS NOT A CORRECT INQUIRY. The protocol overview says: "The
> >Online Certificate Status Protocol (OCSP) enables applications to
> >determine the (revocation) state of an identified certificate". Good
> >means "not revoked", no less no more. Nothing about "issued" or "not
> >issued".
> 
> Well, chapter 2.2 says
>    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...
> 
> If good never means "issued", than it should not say "At a 
> minimum" and
> "not necessarily". 
> 
> The text may be correct, but it is possible to misinterpret it.
> 
> >> The other is the unclear wording of unknown. 
> >
> >This is perfectly clear. If the server says "does not know", do not
> >ask for what reasons it does not know.
> 
> It is not described in rfc2560 what the client should do if 
> it receives
> "unknown" (try later? try another responder? Tell the user that it got
> "unknown"?). It is not described when or why a server might 
> give "unknown".
> "Don't ask" may be adequate for a client programm, but is 
> definitely not
> adequate for people developing an OCSP responder.
> 
> Regards,
>    Juergen
> 

Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate
From: "David P. Kemp" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Tue, 28 Apr 1998 12:32:13 -0700

> From: Marc Branchaud <[email-masked]>
> 
> So I guess (unless I've forgotten someone) that the tally now stands at:
> 
> 	Issued / Revoked / Expired == 1
> 	Revoked only == 0
> 	Abstain == 1
> 

Add one for Revoked only, or add a new category Revoked / Expired.

As before, I don't see any rationale for Issued.

Expired could be useful if one assumes that the client does not have
a reliable clock, that the responder does have access to a trusted
time source, and that the RP uses OCSP for every verification.

Last month my wife's PC started dating files sometime in 2003 for no
apparent reason.  The lithium battery was fine, the clock has been
fine since we reset it, and the machine doesn't have a modem installed
so it's never been exposed to hackers on the net.  Gamma rays, I guess.
Anyway, OCSP Expired status may be useful.

Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate
From: Paul Hoffman / IMC <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Fri, 17 Apr 1998 14:01:34 -0700

I agree with David Kemp's analysis and take back my suggestion that
wasIssued be mandatory.

--Paul Hoffman, Director
--Internet Mail Consortium

Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate
From: SGalperin <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Fri, 17 Apr 1998 10:54:27 -0700

In a message dated 98-04-17 12:31:04 EDT, you write:

>
>  At 08:48 AM 4/17/98 -0700, you wrote:
>  >And in the event a client receives {is revoked, not issued}, which
>  >dominates?  Similarly, {not revoked, not issued}.  I remain unconvinced
> this
>  >is no problem.
>
>  To the client, "not issued" is always more important than revoked or not
>  revoked. We can put that in the OCSP spec.
>
>  >As soon as OCSP clients are out there in any volume, there
>  >are those who will seek to determine the client's behavior in fringe
cases.
>
>  I fully agree. That's why I'm I don't think that issued/not issued should
>  be a MAY: I think it has to be a MUST. We can be sure that some clients
>  will blow the comparison unless they are always told whether or not the
>  cert was even issued.
>

Are we talking about fat OCSP client here ?
Does the OCSP client in this case have full certificate chain ?
Can we safely assume that fat OCSP client will need to verify signatures on
the chain first, validity and other X509v3 constraints and only then submit
OCSP request for status of every certificate in the chain ?

If this is so then, essentially, OCSP client is already in the possession of
the well-formed certificate signed by the (indirectly or directly) trusted
CA
key. In these circumstances receiving an anwer "not issued" may only mean
that
CA key is compromised and "unathorized" certificate has been signed. But if
someone has the CA key and can sign anything with it (including
"unathorized"
certificates) then that someone can also make sure that "unathorized"
certificate has the same serial number as one of "authorized" and as long as
we only send serial number to identify a certificate in OCSP request the
substitution of the "authorized" cert with "unathorized" one will be
unnoticed. This makes "never issued" somewhat useless for fat OCSP clients.

Is this reasoning wrong ?

Also since CA archiving capacity is always finiteand we also talking about
allowing "historical" OCSP queries "never issued" will have to be replaced
with "info
unavailable" at least in some cases. This further redices the value of
"never
issued" status.

--Slava Galperin

Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate
From: "David P. Kemp" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Fri, 17 Apr 1998 10:31:04 -0700

> From: Paul Hoffman / IMC <[email-masked]>
>
> To the client, "not issued" is always more important than revoked or not
> revoked. We can put that in the OCSP spec.
>
> >As soon as OCSP clients are out there in any volume, there
> >are those who will seek to determine the client's behavior in fringe
cases.
>
> I fully agree. That's why I'm I don't think that issued/not issued should
> be a MAY: I think it has to be a MUST. We can be sure that some clients
> will blow the comparison unless they are always told whether or not the
> cert was even issued.

I disagree that an Issued bit should be a MUST.  For that matter, I
don't see that it even needs to be a MAY in OCSP, but others seem to
want it for some reason.

If you have a certificate for which the signature verifies, you have
prima facie evidence that:
  1) the certificate was issued, or
  2) the CA's private key was compromised, or
  3) the signature algorithm is broken.
In the latter two cases, all bets are off and OCSP isn't going to
help -- why would you trust a signed OCSP response any more than a
signed certificate?
In the first case, you know the answer before you even ask the
question.

If you have a certificate for which the signature does not verify,
what are you going to do with it, regardless of OCSP's claim that
it has or has not been issued?

And if you don't have a certificate and are just trolling the OCSP
server by issuer/serial, subject name, or some other search criteria,
why should it feel obliged to disclose which guesses are valid?

Dave Kemp

Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate
From: Marc Branchaud <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Fri, 17 Apr 1998 09:52:47 -0700

-----BEGIN PGP SIGNED MESSAGE-----

Content-Type: text/plain; charset=us-ascii

Michael Myers <[email-masked]> scrawled:
>
> And in the event a client receives {is revoked, not issued}, which

I think you mean {is revoked, issued} here...

> dominates?  Similarly, {not revoked, not issued}.  I remain unconvinced
this
> is no problem.  As soon as OCSP clients are out there in any volume, there
> are those who will seek to determine the client's behavior in fringe
cases.

I agree that the implications are not trivial.  For one thing, as I've said,
a responder working solely with CRL information can not determine a
certificate's existance if the cert has not been revoked.  One bit is not
enough to capture the semantics.

                Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate
From: Andreas Berger <[email-masked]>
To: 'pkix' <[email-masked]>
Date: Tue, 21 Apr 1998 02:40:54 -0700

Paul Hoffman / IMC wrote:
> 
> At 08:48 AM 4/17/98 -0700, you wrote:
> >And in the event a client receives {is revoked, not issued}, which
> >dominates?  Similarly, {not revoked, not issued}.  I remain unconvinced
this
> >is no problem.
> 
> To the client, "not issued" is always more important than revoked or not
> revoked. We can put that in the OCSP spec.
> 
> >As soon as OCSP clients are out there in any volume, there
> >are those who will seek to determine the client's behavior in fringe
cases.
> 
> I fully agree. That's why I'm I don't think that issued/not issued should
> be a MAY: I think it has to be a MUST. We can be sure that some clients
> will blow the comparison unless they are always told whether or not the
> cert was even issued.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
Paul, I disagree.

The issued/not issued flag can only be answered by a small set of OCSP
responders. Let's take - for example - a company that operates an OCSP
responder of some of the most frequently used CAs in the world. It load
their CRLs to reduce communication cost and offers these "CRLs on-line"
to the internal client software (thus lowering the maintainance cost to
distribute CRLs to all clients). Given a specific certificate, such an
OCSP responder can only answer the question of revocation (revoked/not
revoked) on the basis of the CRL (so revoked is: on the list, not
revoked is: not on the list).

So probably we need some kind of "don't know" of the OCSP responder.

Regarding the question above: when a certificate was "not issued" this
is a no-go for the verification process. I think that we could drop any
other answers if the certificate was never issued. This is different for
"issued: don't know" and "issued: yes".

Andreas
-- 
Erst kommt das Fressen, dann kommt die Moral
 -- Bertolt Brecht

Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate
From: Denis Pinkas <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Fri, 17 Apr 1998 14:26:09 -0700

Andreas,

Your conclusion is:

" I think we should not restrict OCSP in its semantics to CRL like
  semantics."

I may agree with this. However, I think we should not mandate more than
what is available by access to CRL information only. This means that we
have to distinguish between a set of mandatory status and a set of
optional status.

> > Ambarish Malpani wrote:
> >
> > > Here is a list of the different kinds of status information that an
OCSP
> > > responder may want to return:
> > >
> > > 1. Revocation status of a certificate
> > >     - revoked
> > >     - on hold
> > >     - not revoked
> > >     - don't know about this CA
> > >     - know about this CA, but not about this cert (??? I am not sure I
> > >         think this state should ever be returned, but this corresponds
> > >         to the state where the responder is looking up the CA's
database
> > >         and can't find this entry in the database. Mike, I believe you
> > >         think this is an important state - is that correct?)
> >
> > The later would mean that the OCSP responder has access to more
> > information than just  the CRL. I do not think that this response
> > usefull for the client. If there were good arguments for keeping it (I
> > have not been convinced by the arguments from Paul), then this status
> > should be optional (no guarantee to get it back at any time).
>
> Sorry that I bring that up again: the answer about knowing about a CA
> but not about the referenced certificate would be a good one for use of
> OCSP in the German Signature Law, where such a service is required.

As long as this is optional.

> Short overview: When asking a CA for the status of a certificate, it
> answer with two booleans: certificate was issued / was not issued and
> certifcate is revoked / is not revoked (the latter only when the
> certificate was issued). The signature key is related to the CA but is
> not the CAs certifcate signing key.

More exactly:

it MUST issue one booolean  : certificate is revoked / is not revoked
it MAY issue another boolean: certificate was issued / was not issued

> What we then need is a clarification between "not revoked": Let us
> assume that an OCSP responder answers with "not revoked" based on a
> decision of a CRLs where the certificate is NOT listed. This is a
> different answer from "not revoked and I know about the certificate",
> perhaps looked up on a CA database (see 3).
>
> > > 2. Expiration status of a certificate
> > >     - not yet valid (will be valid in the future)
> > >     - valid (in its validity period)
> > >     - expired
> > >     - don't know about the expiration status
>
> I think we have to rephrase that: not yet valid - certificate validity
> period begins after the designated point in time.

We will have to support some date as originally requested by Stephen.

> > > 3. Issued status of the certificate
> > >     - never issued (no cert with this serial number was ever issued by
> > >       this CA)
> > >     - issued
> > >     - don't know if it was ever issued
> >
> > > My take on this issue: I believe OCSP is just a revocation status
> > > protocol, so we should restrict the return status to just revoked,
> > > onHold, notRevoked, and dontKnowAboutThisCA. This would leave the
> > > syntax of the protocol simple and the semantics very clear - OCSP
> > > basically returns the same information that you would get if you
> > > had a CRL from the CA at the  instant of the response (NOTE: I am
> > > NOT implying that a CRL is ever issued).
> >
> > Agreed. Let us keep it simple.
>
> I think we should not restrict OCSP in its semantics to CRL like
> semantics.
>
> Andreas

See above.

Regards,

Denis

--
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate
From: Marc Branchaud <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Tue, 14 Apr 1998 15:29:19 -0700

-----BEGIN PGP SIGNED MESSAGE-----

Content-Type: text/plain; charset=us-ascii

Michael Myers <[email-masked]> scrawled:
>
> A related question:
>
> Given Marc's proposal for separate fields, should we provide guidance
> towards the uniform resolution of ambiguous states in a multi-valued
> response?  I'm concerned about this protocol otherwise introducing into
> clients exploitable behavior caused by less than full coverage of error
> cases.
>

That's a valid concern, and I believe some guidance is required.  As a
start,
it might help to list those combinations which should be considerd as
malformed.  First, recall the three status vectors:

    Revocation Status     Expiration Status     Issued Status
    -----------------     -----------------     -------------
    revoked               not yet valid         issued
    on hold               valid                 never issued
    not revoked           expired               unknown
    unknown CA            unknown
    unknown cert

 - If Issued Status is "never issued" then the revocation status MUST be
"unknown cert" and the expiration status MUST be "unknown", otherwise the
response is malformed.  If the responder knows that the cert was never
issued, then the other values are indeterminable.  Note that a responder
can't determine if a certificate was never issued using only CRLs, so a
responder working with CRLs only will never create a "never issued"
response.

 - If Issued Status is "unknown" then the response is well-formed only if
the
revocation status is either "not revoked" or "unknown CA".  This is because
if the cert is "revoked" or "on hold" then it is listed in a CRL, and so the
responder knows the cert was issued regardless of whether it is using CRLs
or
has direct access to the CA's database.

Also, if Issued Status is "unknown" then "unknown cert" implies "unknown
CA".  Either the responder couldn't find a CRL or database for the cert's
CA, or the responder has a CRL from the CA but the cert isn't listed (so
it's really "not revoked").

 - If Issued Status is "issued" then use the following table to determine if
the response is malformed ("bad") or acceptable ("OK").

  Revocation   ||----------------- Expiration status ---------------
  status       ||  not yet valid  |  valid  |  expired  |  unknown
  =============||=================|=========|===========|===========
  revoked      || OK              | OK      | OK        | OK
  on hold      || bad             | OK      | OK        | OK
  not revoked  || OK              | OK      | OK        | OK
  unknown CA   || bad             | bad     | bad       | bad
  unknown cert || bad             | bad     | bad       | bad

The only way for a responder to know with any certainty that a cert has been
issued is if it has direct access to the CA's database or if the cert is
listed on a CRL.  In either case, responding with "unknown CA" or "unknown
cert" would be wrong.  "Unknown cert" would really mean "never issued" (if
the responder had direct access to a CA's database) or "not revoked" (if the
responder were using CRLs).

Also, I don't believe that a cert would be marked "on hold" before it became
valid.  Either it wouldn't appear on a CRL, or it wouldn't be marked as "on
hold" in the CA's database.  Hence the single "bad" entry in the "on hold"
row.  I'm willing to admit I'm wrong, though.  "On hold" has always been a
semantic riddle to me...

All of this is only to determine if the client should reject a response out
of hand.  The behaviour of a client upon accepting a response -- whether or
not it should accept the cert -- is a matter for the client's local
policies.

One thing this exercise has showed me is that "unknown cert" is really a
useless response value, since it is either bogus or subsumed by other values
(like "unknown CA").

                Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

Subject: [IETF-PKIX] OCSP Status Information on a Certificate
From: Ambarish Malpani <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Mon, 13 Apr 1998 18:04:14 -0700

Here is a list of the different kinds of status information that an OCSP
responder may want to return:

1. Revocation status of a certificate
    - revoked
    - on hold
    - not revoked
    - don't know about this CA
    - know about this CA, but not about this cert (??? I am not sure I
        think this state should ever be returned, but this corresponds
        to the state where the responder is looking up the CA's database
        and can't find this entry in the database. Mike, I believe you
        think this is an important state - is that correct?)

2. Expiration status of a certificate
    - not yet valid (will be valid in the future)
    - valid (in its validity period)
    - expired
    - don't know about the expiration status

3. Issued status of the certificate
    - never issued (no cert with this serial number was ever issued by
this CA)
    - issued
    - don't know if it was ever issued

My take on this issue: I believe OCSP is just a revocation status
protocol,
so we should restrict the return status to just revoked, onHold,
notRevoked
and dontKnowAboutThisCA. This would leave the syntax of the protocol
simple and the semantics very clear - OCSP basically returns the same
information that you would get if you had a CRL from the CA at the
instant of the response (NOTE: I am NOT implying that a CRL is ever
issued).

However, if the consensus of the group is that it is important that all
three types of states be returned, I would prefer there to be 3
separate state fields, one for each of the different statii. This would
allow us to add more states in the future (e.g. whether this certificate
can be used for a specific kind of operation, or maybe some information
about the CA of this cert) without affecting these basic status fields.

What do the rest of you on the list feel about this issue:
    - Should OCSP support one or more of these statuses?
    - If we support multiple of these states, should we define separate
        fields, or should we merge all states into one field?

Ambarish

--
---------------------------------------------------------------------
Ambarish Malpani
Architect                                              (650) 849-9880
ValiCert, Inc.                                  [email-masked]
3160 W. Bayshore Road                         http://www.valicert.com
Palo Alto, CA 94303

---

From: Juergen Brauckmann <[email-masked]>
Date: Thu, 10 Aug 2000 08:13:11 +0200

>that we were only providing the status of the certificate.

I think you misunderstood me. I did definitely not want to start another
discussion what OCSP is.

Juergen