Subject: RE: some thoughts re DPD and DPV

From: [email-masked] (Peter Gutmann)
Date: Sat, 24 Mar 2001 14:02:28 (NZST)

Speaking of OCSP, I have a suggestion for v2: Currently the status values which
are returned are not-revoked, revoked, and unknown (note that I've used "not-
revoked" rather than "OK" because what's called "OK" doesn't actually mean the
cert is OK).  I've had a request from a user in Germany for an addition to this
which provides a true-OK response (that is, a response of "This certificate was
definitely issued and is valid as of the time the response was sent") as well
as a true-invalid response ("This certificate wasn't issued/has been
revoked/has expired").  My suggestion for providing this was to create a
(private) extension which contains this information, but given that things like
ISIS are doing something similar by overloading RFC 2560 it might be useful to
make this a bit more standardised by adding it to the RFC rather than having
everyone invent their own incompatible, ad-hoc solutions.

Note that this isn't any infringement on DPD/DPV's territory, all this is doing
is providing more useful status information than the current return values do.
For the extension I'd proposed the following:

  ExtendedStatus ::= BOOLEAN

  If set to true, the responder is indicating that the certificate has been
  issued and is curently valid.

  If set to false, the responder is indicating that the certificate has not
  been issued, has not become valid yet or has expired, or has been revoked
  (more information is contained in the certStatus field) or otherwise
  withdrawn from use.

This doesn't do any path validation or anything else provided for in DPD/DPV,
all it is is an assertion from the CA/responder that as far as they're
concerned it's valid or it's not valid.  This is a very simple fix to OCSP
which is fully backwards-compatible and helps avoid the problems caused by the
limited ability of the certStatus value to report certain certificate
conditions.

Peter.

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 26 Mar 2001 11:07:47 +0200

Peter,

> cert is OK).  

I fully support this. I have been making the same request to Mike for months
(years ?) and I do hope that we will finally get that change done. :-)

> I've had a request from a user in Germany for an addition to this

Everyone can make its own private extensions and in that case, and we are
not going to stop this. It would be the right thing to do. Supporting a
standardised way to advertise these status goes well behind the simple
addition of two status and is thus much more than " a very simple fix to
OCSP". These additions would not be compatible with our basic model
described in RFC 2459 or son-of-RFC2459. 

The main objection is the following:

If you rely on "this certificate was definitely issued [by the CA] and is
valid as of the time the response was sent", then there is no more need for
the client to check for the signature of the certificate since this check
will/can be done by the server. Furthermore, there is no need for a
signature itself on the certificate since the server will/can make a bit to
bit comparison with the certificate stored in its database or against a hash
of the full content of the certificate stored in its database. So going into
that direction would negate the need to sign certificates ! We could
certainly design a new architecture where certificates are no more
certificates since they do not need to be signed anymore, but I would
recommend to study these alternatives in a forum different from the IETF
PKIX WG.

There are other objections, since the model you are referring is also making
additional major changes from the PKIX model, in particular about the way to
check the validity of a certificate chain and the nomination of the OCSP
servers responsible for a given CA. Once again, we are in the PKIX WG with a
well defined model based on X.509. There are certainly alternatives to this
model. Alernatives may have their own merits. However, they should not be
progressed in the PKIX WG. Note that this topic has already been brought up
to the PKIX list and discarded.

Regards,

Denis

---

From: "Michael Myers" <[email-masked]>
Date: Mon, 26 Mar 2001 10:36:18 -0800

Peter,

It's not clear to me that a separate, perhaps private, extension to OCSP
is needed to enable a CA to indicate a certificate's validity beyond that
currently defined by the DPV I-D (now folded into the OCSPv2 I-D along
with the DPD I-D).

Note that there exists DPV as a concept and DPV as specified over OCSP.
The later defines a value of id-pkix-ocsp-valid-rsp for use in
ResponseBytes.ResponseType field vs. the value of id-pkix-ocsp-basic
defined by RFC 2560.  The effect is that that values of CertStatus
become context sensitive against the value of ResponseBytes.ResponseType
but in a fashion that enables full backwards interoperability with
RFC 2560.  For example,

   IF   {certStatus == 0 AND responseType == id-pkix-ocsp-basic }
   THEN the certificate is NOT REVOKED as defined by RFC 2560bis

while

   IF   {certStatus == 0 AND responseType == id-pkix-ocsp-valid-rsp }
   THEN the certificate is VALID as defined by OCSPv2.

The latter means at a minimum that the responder confirms that
subject certificate passes the path validation algorithm defined
by RFC 2459.

Does this work for your needs?

Mike