Subject: RE: Candidate for moving OCSP to a Draft Standard

From: Santosh Chokhani <[email-masked]>
Date: Fri, 1 Feb 2002 07:15:38 -0500

All:

Please note the following:

1.  producedAt will always be at or later than thisUpdate.

2.  The current RFC has a rule for thisUpdate with language similar to the
one proposed for thisUpdate.

Simple arithmetic tells me that if we want to caveat the producedAt rule, we
should have the same caveat for thisUpdate rule.

That said, I am happy with the language proposed by Ambarish for producedAt.

However, if the community feels that the language for producedAt should
change, then we should make even more of a change for thisUpdate language
(since thisUpdate is always earlier than producedAt).

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Friday, February 01, 2002 4:34 AM
To: Ambarish Malpani
Cc: [email-masked]'
Subject: Re: Candidate for moving OCSP to a Draft Standard

Ambarish,,

> Hi Guys,

>     Here is a candidate for moving OCSP to a Draft Standard. There
> are no changes in the bytes that go across the wire - basically all
> clarifications.
 
> A list of all the changes between this document and RFC 2560 are
> in Appendix D (reproduced here).
 
> I hope we can get to the Draft Standard state before this IETF.

I have the following remarks:

The current text states:

   7. The producedAt time in the response is sufficiently recent.

   8. If the request contained a nonce, the response must contain the
      same nonce (see section 4.4.1).

If the nonce is used, then the value of the producedAt field does not matter

anymore and no test needs to be made on it. So I would first propose to 
invert items 8 and 7.

Then it is questionable on how implementers can interpret what "sufficiently
recent" means for the producedAt time and set a value (a few minutes, hours 
or days ?).
 
In fact if no pre-computed response were being used, this could simply be
set to a few minutes.

If pre-computed responses are being used, setting it to a few minutes will
probably lead to rejections.

This means that using pre-computed responses is a real problem, since this
value cannot even be fixed but is even dependent upon each server supporting
pre-computed responses.

The easiest way would be to delete the support of pre-computed responses or
set a maximum limit in the standard. The basic question would first be: who
is using pre-computed responses with which retention period in the cache ?
If no-one is using it, then the solution is simple. :-)

In the following proposal, I have not yet "crossed the line".  

Proposed rephrasing:

[Prior to accepting a signed response as valid, OCSP clients SHALL
 confirm that:]

   7. If the request contained a nonce, the response contains the
      same nonce (see section 4.4.1).

   8. If the request did not contained a nonce, the producedAt time 
      in the response is considered as "sufficiently recent". 
      This means computing the difference between the current time 
      and the producedAt time and then comparing it with a time 
      period that will be set to a few minutes, or to a few hours 
      in the case where the OCSP servers accessed by the client 
      are supporting pre-computed responses. 

      Note: when pre-computed responses are being used by servers,
      it may be hard for clients to set a single maximum common value.

Denis

> Regards,
> Ambarish
> 
> Appendix D. Changes
> 
>    This section contains the differences in this document from RFC 2560
> 
>    - Mention Appendix D in Section 1 and added an appendix D.
>    - Added a paragraph in Section 1 equating a client with a requestor and
>      server with responder
>    - Section 2.2 - clarified the explanation of good, revoked and unknown
>    - Added Section 2.8 requiring clients and responders to support HTTP
>    - Added a note at the end of section 3.2, which allows a client to
>      accept a response that provides statuses for only some of the
>      certificates requested.
>    - Clarified the issuerKeyHash in Section 4.1.1
>    - Added "DER encoding of the" in the third paragraph Section 4.1.2
>    - Section 4.2.1 - clarified that the signature is on the DER encoding
>      of tbsResponseData (and not its hash)
>    - Section 4.2.1 - specified the use of the certs field in
>      BasicOCSPResponse
>    - Section 4.2.1 - clarified how you compute KeyHash when providing
>      the ResponderID byKey.
>    - Section 4.2.2.2 - removed an extra quote in point 3
>    - Section 4.3 - Made RSA mandatory. Also changed the references to
>      point to the appropriate documents. Added the references to the
>      References section
>    - Section 4.4.1 - Clarified that a nonce in the request MUST be
>    - included in the response for the response to be trusted.
>    - Appendix A - A.1.1. - Got rid of support for GET - not sure that
>      anybody does it. It is also unclear how a server would tell a
>      client to ever use GET in the URL specified in the AIA
>    - Add the module tag for the ASN.1 in OCSP
>    - Made SEQUENCE OF Certificate OPTIONAL to SEQUENCE SIZE(1..MAX) of
>      Certificate OPTIONAL in the ASN.1 defintions. The avoids the
>      ambiguity of whether the optional sequence may be present, but
>      with 0 elements. This was done by definining a new element called
>      Certificates, which is used. Look at the defintion of both
>      Signature and BasicOCSPResponse.
>    - Clarified the meaning of nextUpdate being absent (Section 2.4)
>    - Fixed typo where we referred to id-ad-ocspSigning, to reflect the
>      correct OID - id-kp-OCSPSigning
>    - Clarified criteria for response acceptance (Section 3.2)
>    - Added a line in Section 5 indicating that nonces can be used to
>      prevent prevent attacks using replays of precomputed responses
>    - Added a paragraph in Section 5 requiring nonces to be unique for
>      replay protection
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [email-masked]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
> 
>
----------------------------------------------------------------------------
>                         Name: OCSP-draft-03.txt
>    OCSP-draft-03.txt    Type: Plain Text (text/plain)
>                     Encoding: quoted-printable

---

From: "Florian Oelmaier" <[email-masked]>
Date: Fri, 1 Feb 2002 19:50:54 +0100

Thanks for the good work. I am looking forward to an OCSP Draft Standard.

--
Dipl.Inf. Florian Oelmaier
Head of Development
syTrust S.A.

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Ambarish Malpani
> Sent: Thursday, January 31, 2002 9:31 PM
> To: [email-masked]'
> Subject: Candidate for moving OCSP to a Draft Standard
>
>
>
> Hi Guys,

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 9 Feb 2002 07:06:33 +1300 (NZDT)

"Housley, Russ" <[email-masked]> writes:

>If the extension is specified in an IETF document, then I will gladly issue an
>OID from the PKIX arc.  Otherwise, it is a private extension, and it should
>not be issued an OID from the PKIX arc.

It's not specified anywhere, I'm just nervous about using private OIDs because
(historically) they've proven awkward for implementors to deal with because no-
one knows where they're defined.  This particular one's a bit of a grey area,
it's not specified in an RFC, but since others are going to use it it's not
really private either.  I'm not really fussed about it, it just seemed a bit
cleaner to have a well-known OID.

Peter.

---

From: Ambarish Malpani <[email-masked]>
Date: Fri, 08 Feb 2002 12:08:46 -0800

Hi Peter,
     I was hoping to stay out of this discussion, but I suppose I
need to get back in.

About responders working off CRLs:

In a lot of cases, people have set up our VA (Validation Authority/
OCSP Responder), to run next to a CA, operated by the CA operator.

They have set up the system, so that as soon as there is a new
revocation event, a new CRL is produced, with is immediately
shipped to the VA. The VA now provides revocation information
based on this new CRL.

As I have stated many time before - the problem with CRLs is not
that it takes long to produce them - the problem is with
getting client applications new CRLs as soon as they are
produced. Because of their size, most client applications cache
old CRLs and CAs like this behavior because otherwise their
directory will get overloaded.

With the combination I talked about above, a CA can produce new
CRLs as soon as there is new information, pass that on to the VA
and get the new information to all OCSP clients as they need it.

Hope this helps,
Regards,
Ambarish

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, February 08, 2002 10:42 AM
> To: [email-masked]; [email-masked]
> "David P. Kemp" <[email-masked]> writes:
> 
> >>The reasoning as I recall was that OCSP shouldn't include 
> facilities which
> >>aren't bug-compatible with CRLs.  Since CRLs can only 
> provide a negative
> >>response, and even that only for some cases of invalid 
> certs, OCSP doesn't
> >>include a straighforward yes/no indication.
> >
> >Say what?  CRLs provide positive and negative responses, and 
> the positive
> >response is optimized down to 0 bytes.
> 
> They don't provide a positive response, only a negative one.  
> If a cert is ever
> rendered invalid for *any* reason other than CA revocation, a 
> CRL can't
> indicate this.  Examples of this include the fact that it 
> hasn't become valid
> yet or has expired and the client doesn't realise because its 
> time is out
> (standard practice in the Windows world, the worst I've seen 
> was a system with
> its clock out by several decades), it wasn't regarded as 
> being issued by the CA
> and therefore can't be revoked (which can occur in CMP, see 
> the postings about
> a neverValid CRL status from a while back), or a number of 
> other situations.
> 
> The problem with CRLs is that they ask entirely the wrong 
> question - "Has this
> been revoked?" - when what's really of interest is an answer 
> to the question
> "Is this currently valid?".  This can't really be fixed, 
> because that's the
> only question a blacklist is capable of answering.
> 
> >The reason OCSP can't say that a cert is valid has nothing 
> to do with CRLs.
> >It's crippled by the fact that the request does not include 
> a cert, so the
> >responder can't validate the signature unless it fetches the 
> cert itself.
> >Presumably the OCSP authors made a conscious decision not to 
> require the
> >responder to validate certification paths before providing a 
> response.
> 
> It doesn't need to validate anything.  That's why my text 
> summary went to such
> pains to point out that it was strictly an "account in good 
> standing" query.
> The CA acknowledges that it issued the cert, and that it's 
> currently in good
> standing.  That's all.  There's no validation, path checking, 
> or anything else.
> 
> >>(IMHO any poor guy who's stuck with feeding their online 
> status service from
> >  offline CRLs has bigger things to worry about than this...).
> >
> >Speaking as one such poor guy :-), what's the problem?
> 
> The fact that you're feeding a real-time status process from 
> a source updated
> hourly or daily or whatever (I've seen CAs which issue CRLs 
> in half-day or
> full-day intervals, or which guarantee a CRL age of not more 
> than 24 hours, 8
> hours average-case).
> 
> >What could be more elegant than having your LAN-based OCSP 
> server replicate
> >the PKI revocation database by fetching delta CRLs from the 
> central server
> >every 15 minutes?
> 
> What could be more sensible than having your OCSP responder 
> process queries by
> consulting the central server directly?  If I'm using certs 
> for financial
> transaction authorisation then it may be elegant to introduce 
> a 15-minute delay
> in order to give the crooks a sporting chance, but it's not 
> financially
> satisfying in the long run :-).
> 
> Why do CRLs even need to feature in the process, except to 
> highlight their
> deficiencies?  Someone (probably the aforementioned Lynn 
> Wheeler) once said
> that the only reason you'd use an offline mechanism to feed 
> online queries is
> to point out how broken it is.
> 
> Peter.
>

---

From: Ambarish Malpani <[email-masked]>
Date: Fri, 08 Feb 2002 14:21:16 -0800

Hi Peter,
    Here is an earlier response to your issue with OCSP responses
about certificate/account exists etc.

Regards,
Ambarish

In a mail sent to the PKIX list in April 1998, here is what I had
asked:

------------------Begin Included Mail------------------------

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

-----------------------End Included Mail-----------

The concensus at that time was that the only status needed was whether
the certificate was revoked or not.

> Sent: Thursday, February 07, 2002 11:23 PM
> To: [email-masked]; [email-masked]; 
> [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: RE: Candidate for moving OCSP to a Draft Standard
> 
> 
> "Khaja E. Ahmed" <[email-masked]> writes:
> 
> >This sounds like a perfectly reasonable solution. Surprised 
> it was rejected.
> >After-all this would be an optional extension, why not add it?  
> 
> aren't bug-compatible with CRLs.  Since CRLs can only provide 
> a negative
> response, and even that only for some cases of invalid certs, 
> OCSP doesn't

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 11 Feb 2002 19:56:01 +1300 (NZDT)

Ambarish Malpani <[email-masked]> writes:

>In a lot of cases, people have set up our VA (Validation Authority/ OCSP
>Responder), to run next to a CA, operated by the CA operator.
>
>They have set up the system, so that as soon as there is a new revocation
>event, a new CRL is produced, with is immediately shipped to the VA. The VA
>now provides revocation information based on this new CRL.

Which just seems bizarre to me.  The CA maintains a centralised record of
what's valid and what isn't, why do you need to jump through all these hoops
just to do what you could do directly without all the overhead?

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 12 Feb 2002 02:04:24 +1300 (NZDT)

"David P. Kemp" <[email-masked]> writes:

>You don't like CAs who update their CRLs every 24 hours, then suggest that
>they update them every 15 seconds (to a select group of redistributors, not
>every end user) instead.

In practice (or at least with many of the CAs I know of) you don't really have
much choice, if they decide they're going to give you a CRL once a month you
can either sit there and grin ("You got the right to shut up and do wot yor
told") or (at best) set up and run your own CA.

>If I were a CA bidding on a Service Level Agreement to provide 15-second
>revocation freshness and 1 second response time for 1 million users, I would
>bid less to do it using delta CRLs than using Oracle or Sabre or whatever
>acceptance system Lynn has in mind.

The model I have in mind is Berkeley DB (fully in-memory) and a pile of SSL
accelerators to do the signing [0].  I bet I can make it faster, cheaper, and
more scalable than anything that uses CRLs.

Peter.

[0] And by "SSL accelerators" I'm thinking of the ones made by AMD and Intel as
    well as the usual nCipher and Broadcom.

---

From: "Simon Tardell" <[email-masked]>
Date: Mon, 11 Feb 2002 17:13:23 +0100

> I agree that there is no great need for an OCSP server to
> tell a PKI enabled client that a certificate exists or was 
> issued if the PKI enabled client has first performed the 
> required verification of the CAs signature on the cert and 
> done proper path validation and is now only checking the 
> revocation status.  My initial reaction was that it might not 
> do any harm to have an optional extension to satisfy some 
> corner cases.  One such case, that was put forth was of a 
> situation where the CA's private key was stolen and being 
> used to mint certificates by an attacker.  Such certificates 
> would not be in the CA's database. An optional extension like 
> the one proposed by Peter could afford some limited 
> protection against this.

Khaja,

This case is already catered for in RFC2560:

"2.7  CA Key Compromise

   If an OCSP responder knows that a particular CA's private key has
   been compromised, it MAY return the revoked state for all
   certificates issued by that CA."

Simon.

Simon Tardell, Software Architect, SmartTrust
voice +46 8 6853174, fax +46 8 6856530
cell +46 70 3198319, [email-masked]

---

From: "Simon Tardell" <[email-masked]>
Date: Tue, 12 Feb 2002 10:52:21 +0100

> Simon,
> 
> I am afraid I did not describe the scenario and it's 
> assumptions in full detail but the solution you are pointing 
> out would not apply.  In this (ISIS envisioned scenario...I 
> think) the OCSP responder and the CA do not know that the 
> CA's private key has been stolen/copied and is being used to 
> mint certificates.  Thus the OCSP responder would respond 
> that the certificate was good because it was not known to be 
> revoked.  In fact even if the CertificateOK extension is used 
> this problem may not be caught if duplicate serial numbers 
> were being used.  Indeed even a delegated path validation 
> capable server may not catch this particular problem 
> depending on the nature of the checking done prior to 
> generating a response.  The solution envisioned, as explained 
> to me by some German and other EU bank PKI folks, was that 
> the OCSP responder would have access to some sort of a 
> database that contains all the certificates issued by the 
> legit CA and will check against this database.  The 
> validation server would have to be given the entire 
> certificate or at least the public key or identifier and 
> confirm that that precise key, was certified in a certificate 
> with that exact serial number, etc.
> 
> Anyway, where I had left it was that it would be fine to do 
> anything over and above basic OCSP (via extensions) so long 
> as it did not change/overload the semantics of the OCSP 
> status itself from that specified in RFC2560.  My own 
> inclination was, and remains, to settle for people doing ANY 
> checking of status at all to get started.
> 
> Anything beyond that is probably best handled by some 
> standardized (hopefully easy to use) protocol the list comes up with.
> 
> 
> Khaja

Khaja,

As I have understood it the driver for the ISIS scenario can be
described in these terms: Imagine a CA that issued a large number of
certificate to smart cards (lets say millions). If the CA key is
compromised replacing millions of certificates would take a significant
amount of time (the end-entity keys are still ok). During that time the
German economy can not be let grind to a halt. 

Hence they introduce an extension whereby the OCSP responder asserts
that a certain certificate (identified by its hash) was known to the
responder before a certain time. In effect they turn the responder into
a certificate time stamping service.

Unfortunately, they do it by modifying the OCSP semantics so as to make
ISIS OCSP somewhat incompatible with RFC2560 OCSP (using the vague
language of "unknown" -- in ISIS "unknown" is an affirmative assertion
"I know that this certificate does not exist").

IMHO a better way to achieve redundancy, would have been to mandate that
more than (independent) CA should certify the same keys. 

I tend to believe that ISIS is a lost case, the "profile" will likely
remain incompatible with ordinary OCSP. I am not sure that there will be
enough "certificate time stamping" needs outside of the ISIS sphere to
warrant a PKIX extension to this effect, but I might be wrong. However I
do not rule out additional "goodness" assertion extensions in general
(issuance, within validity, ...).

Simon

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 13 Feb 2002 02:38:18 +1300 (NZDT)

"Khaja E. Ahmed" <[email-masked]> writes:

>I am afraid I did not describe the scenario and it's assumptions in full
>detail but the solution you are pointing out would not apply.  In this (ISIS
>envisioned scenario...I think) the OCSP responder and the CA do not know that
>the CA's private key has been stolen/copied and is being used to mint
>certificates.  Thus the OCSP responder would respond that the certificate was
>good because it was not known to be revoked.  In fact even if the
>CertificateOK extension is used this problem may not be caught if duplicate
>serial numbers were being used.  
>
>[...]
>
>The validation server would have to be given the entire certificate or at
>least the public key or identifier and confirm that that precise key, was
>certified in a certificate with that exact serial number, etc.

A simple fix for this would be to submit a hash of the cert as the ID.  The
client gets a cert, hashes it, submits it as the OCSP ID, and responder sends
back a copy of the hash as the ID and a CertificateOK = TRUE/FALSE.  Simple,
straightforward, and stirring up such a hornet's nest that it's unlikely to
ever get mentioned in any CertificateOK draft :-).

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 13 Feb 2002 06:49:23 +1300 (NZDT)

Al Arsenault <[email-masked]> writes:

>Further, what happens if, as Michael McIntosh suggested, the CA private key
>that issued the OCSP responder certificate is compromised, and the attacker
>creates a new OCSP responder (and points all new/bogus certificates to it).
>Now we have two communities, with two OCSP responders, each of which claims
>the OTHER is invalid.  How is this resolved?

In the same way that two monotheistic religions consign their believers to the
other side's hell for reason of heresy :-).

Peter.