Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts

[Michael Myers <mmyers@xxxxxxxxxxxx>]

Anil,


First, a couple of comments on this general state of affairs and then some
more specific comments on your analysis.

First, OCSP is on the standards track.  It has gone through several
iterations, culminating in  the recent joint authorship of myself and Rich
Ankney, which effort took into account the comments of many interested
parties.  The core concepts have been available for review for three IETFs
and have not fundamentally changed in that time, including the syntatic
approach.  A number of parties are testing the spec with trial
implementations.   At this point It is about as ready for last call as any
work product PKIX has yet produced.

Secondly, further extension of OCSP is counterproductive.  We need to get
something out that is useful in a "good enough" sense ( in the same sense
that CRLs are good enough for many needs) and address more sophisticated
needs with more sophisticated mechanisms. Let's match the size of the hammer
to the size of the nail.

Now, beyond that, your analysis provides us the opportunity to further
examine the core issues.

Mike


-----Original Message-----
From: Anil R. Gangolli <gangolli@StructuredArts.com>
To: IETF-PKIX@LISTS.TANDEM.COM <IETF-PKIX@LISTS.TANDEM.COM>
Date: Thursday, March 12, 1998 4:17 PM
Subject: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts

>Attached are some cursory comments on both the Malpani and
>PKIX OCSP drafts.  Some additional notes pertaining only to
>the Malpani draft are included at the end.
>
>--a.

>Comments on the Malpani OCSP recommendation and PKIX OCSP
>Full Validation vs. Revocation

>There appears to be an implicit motivation in the PKIX OCSP
>(draft-ietf-pkix-ocsp-02.txt) work that is missed by the Malpani spec.
>The PKIX spec seems intended to support not only revocation checking
>but full cert path validation for "thin clients" that might have only
>one trust point defined and trust OCSP servers for all more general
>cert path validation tasks.  I believe the PKIX OCSP spec requires
>further elaboration if it is intended to support this, but the Malpani
>spec doesn't provide for this at all.

If I may reiterate a point I've made several times in the past, OCSP was and
is primarily intended as a drop-in replacement for CRL processing where the
unique characteristics of OCSP lend themselves to the problem at hand.
Several commentators have noted the need for additional requirements
regarding validation.  I've agreed over the course of editing the document
to accomodate these needs.  I agree with Rich however that sophisticated
context validation schemes are beyond its scope.

>Some of the wierd hacks in the PKIX OCSP may credibly be explained by
>this motivation.  e.g. the avoidance of ASN.1 and the way the Cert ID
>hash argument is formed by straight concatenation rather than DER
>encoding a sequence.

Indeed, this is exactly the basis for the syntax and its constructions.
Whether or not they are wierd hacks or intuitively obvious implementation
choices may depend upon one's frame of reference.

>Use of ASN.1 and/or HTTP
>I expect that Malpani's revised OCSP using ASN.1 embedded within HTTP
>will be a better framework for the request/response specification than
>the PKIX OCSP scheme using ad hoc encodings over HTTP, but the "thin
>client" issue needs to be discussed.  Is the PKIX scheme trying to
>meet "thin client" requirements?

Most definitely, although not exclusively.  More generally, it addresses
requirements for simplicity in implementation within a well-defined problem
space.

The expressive power of ASN.1 is overkill in this case.  It burdens the
implementor with a steep learning curve, expensive tools, and delays in
market access just to gain access to an integer value expressing the current
state of a certificate's status.

>Is it succeeding?

Yes.  In the best IETF tradition, trial implementations are underway to
prove the concept.  I'm aware of at least two efforts that are directed
at a well-defined market need.

>What is the delta
>between what is required in a thin client that uses certs at all and a
>thin client that uses PKIX OCSP vs. Malpani OCSP?

This issue is not one of thin-client vs. full client but more with the
fundamental problem being addressed and a rational balance
between that problem's scope and the tools needed to effect
its solution.

>If the current PKIX OCSP HTTP scheme is used, the URL encoding should
>be brought more in line with current practice in browsers and other
>HTTP clients.  Use the format of application/x-www-form-urlencoded for
>attribute-value sets both in POSTed requests and all responses.
>Similarly use the more common encoding conventions for GET urls, eg.
>GET /ocsp/ver/1?arg1=value1&arg2=value2... in GET urls.

The spec enables developers of thin clients to export the complexity of CRL
processing to an external server.  I've heard this observation from several
of my larger enterprise customers and major technology partners.  This
effect has nothing to do with timeliness and everything to do with what
might be considered an indirect "feature".  In many such instances the need
for absolute timeliness is less acute.  One is then led to consider the
means by which OCSP can be further enhanced through the natural caching
effects of HTTP.  It is widely known that certain URL constructions, such as
you propose, are inherently non-cacheable. The OCSP request spec advantages
its implementors by proposing construction of a request that enables the
OCSP request to look like a cacheable object.  The ASN.1 approach eliminates
this option.

>Validity Time
>Both the current PKIX OCSP and the Malpani spec need clarification on
>the interperetation of the time interval and the assertion that the
>responder is making relative to these times.
>First, I suggest that "producedAt" be replaced by "validAt", and it be
>interpreted that way.

The intent here is to align with the same notions in CRL for "thisUpdate"
and "nextUpdate".  The corresponding semantics would apply.

>For example an OCSP responder may be producing a response based on a
>CRL that was generated somewhat earlier.  It cannot reasonably extend
>its assertion of validity beyond that of the CRL's "thisUpdate" time.
>The validUntil name is also misleading.  It should, as for CRLs, be
>"nextUpdate" or better "nextExpectedUpdate".

You must not be referencing the latest version as posted to the PKIX group's
link off the IETF web page. The current draft has a "nextUpdate".  The only
change left is to do the right thing and change the "producedAt"
non-terminal to "thisUpdate."

>The validity assertion claimed by the response holds only at any the
>"validAt" time.  In general the relying party must decide whether the
>difference between its current time and the "validAt" time of response
>meets its application requirements.

In general the relying party must decide whether or not to accept  *any*
assertion regarding the fitness of a certificate for a given purpose.  In
particular, RPs should pay attention to unilateral assertions of a
certificate's reliability when those assertions are not provably sourced
by the issuer of the certificate.  Those RPs also have a compelling
need to know when they may next expect or means by which they
may acquire fresher information from the issuing CA.

>The time "nextExpectedUpdate" provides a hint to the relying party on
>the time that new information is expected to be available from the
>responder.  The responder MAY generate new information before the time
>expressed in nextExpectedUpdate.  The responder SHOULD generate new
>information no later than the time expressed in nextExpectedUpdate.

We looked at this problem going into the last IETF.  To summarize those
discussions, if a CA makes revocation information available
asynchronously--that is, before RPs otherwise expect it to be available as
represented by a nextUpdate field--certain of those RPs may be led into
concluding that they have no need to go after fresher information than that
which they've currently cached (either locally or via proxy mechanisms).
Knowing this, an attacker could trick an RP into accepting a signature
as valid--substantiate by local cache and not refreshed due to nextUpdate
logic--when in fact the attacker has a priori recieved a reponse from
the CA showing the certificate as revoked.  Thus CAs that generate new
information before it is expected risk causing their RPs to incorrectly rely
on a certificate.

The situation is analogous to the CRL suppression problem.

These considerations led to the following requirement:

"If responses are pre-produced, then for a given certificate, the
periodicity of this pre-production SHOULD match the response validity
interval of the most recently produced response."

One way of solving this problem is go into a complete "push" mode, but that
still wouldn't solve the problem of the offline RP.

>One might want to add:
>        The relying party SHOULD NOT use a response indicating a
>        certificate's validity beyond the nextExpectedUpdate time.

This seems a reasonable requirement on RPs, but the OCSP spec
cannot place requirements on humans.

>but one should considier that this might better be left to
>application-level standards.
>The only thing that may be important to
>the application is the difference between current time and validAt
>time, if the cost of getting updated information is too hight.  (see
>related notes on Nonce below.)

I agree that it remains within the scope of implementations to determine
what to do in this instance.  It does seem however that there are only two
course of action: either enable users to override the trust engine of their
software, or to automatically cease further processing if the value for
nextUpdate is earlier than the machine's current time.  This later case no
doubt would obtain in the case of machines processing certificates.
IPSEC comes to mind.

>Nonce
>The assertion being claimed by a signed OCSP response is not changed
>by replay.  So it would seem that the purpose of the nonce is not to
>prevent replay attacks but rather to bind the response to a particular
>request in order to allow the relying party later to claim some
>sequence of events (e.g. the relying party must have done the OCSP
>check specifically for transaction X, because it included hash(X) in
>the nonce).

It is the replay of an error responses that's at issue here in the event
when the CA failed for some reason to successfully process a prior request.
This response can be captured for subsequent replay in instances when
subsequent successful requests would have yeilded a VALID response.

>In general I believe that applications and application-level standards
>should define a minimum requirement on revocation checking based on a
>"maximum tolerance window" specifying the maximum allowed difference
>between the current time and a revocation check on that certificate,
>rather than a per-transaction check.

But what if a signer's key is compromised, and the transaction being
processed within this so-called "safe window" is a high-value transaction
worthy of immediate status?  I doubt that applications are going to be
configurable to the granularity of attributes of single transactions.
In fact, I suspect that all we're likely to get in the near term is an
on/off switch on revocation.

>The nonce would be useful in situations where the application or
>application-level standard requires a per-transaction check against
>one of an approved set of responders.  I expect that this will prove
>costly to scale up with OCSPs individually-signed responses.

Rather, any online mechanism must address reliability and availability, from
IP routing networks to DNS name resolution.  The fundamental question is:
who pays for the infrastructure implied by the quite obvious means to
achieve responsive service levels?  This is an open question at this point,
but it is well beyond the scope of the OCSP draft to articulate such
answers.

>This
>starts becoming akin to the function of a notary.

I wholeheartedly agree.

>It is not clear it
>belongs in this spec, but I agree it is cheap to include.

Agree.

>Individual Signatures
>I still have a lot of trouble believing that individually signed
>responses, whether pre-computed or not will scale well for OCSP.

As I've said before, OCSP is not a systems-level design document.  It is an
interface specification between two endpoints such that any requestor A can
interoperate with any responder B.  In this regard it is no different than
any other pairwise interface protocol.  SMTP comes to mind; HTTP; DNS.  I
would further offer that OCSP can be used to actually *improve* the
scalability of some security protocols.  Consider for example the instance
when an OCSP response is included in an S/MIME message or in an ISAKMP main
mode exchange.

>I think that the Malpani spec could be extended to include
>alternate response mechanisms easily.

As your analysis implies, this spec is clearly vectored towards statements
of context validation and as such is much more closely linked to the Notary
Protocol.

Mike