[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[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.

--
Anil R. Gangolli
Structured Arts Computing Corp.
http://www.StructuredArts.com
mailto:gangolli@StructuredArts.com
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.

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.

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?  Is it succeeding?  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?

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.


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.

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".

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.

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.

One might want to add:
        The relying party SHOULD NOT use a response indicating a
        certificate's validity beyond the nextExpectedUpdate time.
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.)



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).

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.

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.  This
starts becoming akin to the function of a notary.  It is not clear it
belongs in this spec, but I agree it is cheap to include.


Individual Signatures

I still have a lot of trouble believing that individually signed
responses, whether pre-computed or not will scale well for OCSP.
I think that the Malpani spec could be extended to include
alternate response mechanisms easily.



Additional Minor Notes on Malpani's spec
----------------------------------------

Here are some additional minor notes applying only to the Malpani
spec.

Computation of the hash value
        Be specific about the calculation of this value. e.g. The
        SHA-1 hash computed over the full DER encoding of the
        IssuerNameAndKey structure including identifier, length, and
        contents octets.

Response Syntax
        "The actual formatting of the message could vary..."  Insist
        on DER encoding at a minimum, or clarify that this is what you
        mean.

BasicOCSPResponse
        Switch the order of the signatureAlgorithm and ResponseData to
        conform to the convention of the X.509 SIGNED macro.

eventTime in SingleResponse
        I couldn't find a definition of this in the document.

CrlID
        CrlURL doesn't provide an adequate basis for defining a
        particular CRL.

Section 4 Reference to X.208
        DER encoding was defined originally in X.509 and updated in
        X.690.  It is not in X.208.

Section 4.4.4.4
        One needs to elaborate a bit on how the semantics of CRL entry
        extensions apply to the OCSP response.