Subject: Re: some thoughts re DPD and DPV

From: [email-masked] (Peter Gutmann)
Date: Thu, 29 Mar 2001 15:29:46 (NZST)

Denis Pinkas <[email-masked]> writes:

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

Uhh, I think you're reading way too much into my suggestion.  All I was doing
was making the observation that currently when you query an OCSP responder it
replies with "I could tell you all sorts of things about this cert, but instead
I'm going to return a partial response and leave you to guess the rest".  By
adding a small amount of additional information (which the client is free to
ignore if they want) the responder may provide a more complete response than
they currently can.  If the client wants to stick religiously to the current
OCSP/PKIX/whatever model they're free to ignore the extra information - all
this is is supplementary data, if you don't like it you can ignore it, if you
think it's useful and it saves you some work, you can use it.

>Everyone can make its own private extensions and in that case, and we are not
>going to stop this. 

The problem is that since there appears to be at least some demand for this,
everyone *will* add their own private extension, all of which will have
slightly incompatible semantics, all of which will be completely different, and
most of which will be undocumented.  Even worse, some groups may decide to
override the semantics of OCSP itself (eg ISIS).  Rather than allow things to
degenerate to the point where you need to handle a dozen different ways of
doing the same thing, the RFC should include a single standard way of doing it
with well-defined semantics which everyone can follow (or ignore if they feel so
inclined).

Peter.

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 28 Mar 2001 20:18:21 -0800

Peter,

Given that the current debate largely centers around various OPTIONAL
elements to enable clients to assert in-band controls/filters/etc. if they
choose, what are your thoughts on the minimal interpretation of OCSP-based
DPV?  That is,

"A DPV response SHALL contain a value of id-pkix-ocsp-valid-rsp in the
ResponseType field of the ResponseBytes syntax.

id-pkix-ocsp-valid-rsp    OBJECT IDENTIFIER ::= { id-pkix-ocsp X }

DPVCertStatus ::= CHOICE {
    valid       [0]     IMPLICIT NULL,
    invalid     [1]     IMPLICIT NULL,
    unknown     [2]     IMPLICIT NULL  }"

where:

"The "valid" state SHALL be interpreted as indicating that the certificate
at a
minimum satisfies the path validation rules defined in [RFC2459]."

Mike