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

Re: DPD & DPV Basics

Peter,

> > Here's my take on the basic concepts of DPD and DPV:
> >
> > The basic job of a DPV server is to validate a certification path.
>
> I disagree. The basic job of a DPV server is to say whether a given
> certificate is valid according to some validation policy. The client may not
> provide any certification path.

I second that. The server should/may provide a trustworthy
certification path but even this may be considered as not necessary
by the policy or application context.

Agreed, i.e., a compliant server must be prepared to return the path and the revocation status data, but a client may not require the return of such data, e.g., to reduce the bandwidth devoted to the response.

 > > 2) Validate the supplied certification path using the supplied inputs
 >
 > No. He will have to fetch information (certs and revocation data).

A server creates a valid/non-valid response acoording whatever information
is available. IF the server returns a certification path, this path
must be a path that can be validated even by the client or a client of
the client.

I would like the spec to require the servers (DPD and DPV) to be capable of retrieving certs and CRLs via LDAP (at a minimum), and to be able to interact with OCSP servers. Local configuration may vary ...

One question is if the client provides one intermediate CA
cert (maybe expired), and the server knows that this intermediate
CA cert is bad but has a good one, I think it is better to
let the server decide whether to honour the input CA cert.

The spec already says that the revocation status data provided by the client is advisory, but not mandatory. Presumably we could make the same statement for certs supplied by the client, other than trust anchors, or we can let the client indicate whether the supplied data is advisory or mandatory.

 > > 3) Send a response containing the results of the validation (at least,
 > >    an indication of success or failure)
 >
 > Yes, and as an option the data used for the assertion.

Note that the certification path is part of these data.

All data returned should be part of the signed structure.

Agreed.

 >
 > > Many refinements to this are possible: the client supplying only a
 > > subset of the necessary inputs (by referring to an established policy),
 >
 > .. or no subset at all.
 >
 > > the server returning supporting evidence such as CRLs and OCSP
 > > responses,
 >
 > No. The server returning a blob. The fact that the blob contains certs,
 > CRLs, delta CRLs, OSCP or whatever, is not visible.
If it is not VISIBLE, then it doesn't make sense. It is not necessary
for the client to know the complete interpretation of the 'blob'.

The client need not know it, but some ASN.1-aware and PKI-aware software, not just DPV servers, should be able to parse it.

 >
 > > the client supplying CRLs or OCSP responses that may be
 > > useful to the server, etc. But I think it may be useful to reach
 > > agreement on the basic model described above before discussing these
 > > refinements (however worthy).
 >
 > > The basic job of a DPD server is to discover a certification path.
 >
 > No. The basic job of a DPD server is to help the PKI-aware client to perfom
 > the validation itself.

In current PKI a validation always results in having a certification path, thus
I do not see what else a DPD can provide to a client other than a
certification path or some part of it.

A cert path AND matching revocation status data.

> Certification paths or/and revocation information may be returned. More than
> one certification path and one than one revocation information (e. g. both
> CRLs and OCSP responses) may be returned.

 > > In its most basic form, it will perform the following steps:
 > >
 > > 1) Receive a request containing a target certificate and inputs to the
 > >    validation algorithm (trust anchors, etc.)
 >
 > Yes.
 >
 > > 2) Attempt to discover a certification path ending in the target
 > >    certificate that will validate properly given the supplied inputs
 >
 > One or more paths.
See below. The server does not know which of many path the client likes.

 >
 > > 3) Send a response containing the results of the discovery process
 > >    (at least an indication of success or failure and, in the success
 > >    case, the discovered certification path)
 >
 > Succes or failure of finding the requested elements (i.e. certification
 > paths or/and revocation information)

Is a DPD successful when it finds at least one path or some part of it?

A path returned by a DPD server must meet the criteria established by the client, which must include reference (explicit or implicit) to one or more trust points. So, a partial path does not meet that criteria. I think returning one path suffices.

 >
 > > Most of the refinements listed above with respect to the DPV server can
 > > also be applied to the DPD server.
 >
 > No. See above.

 >
 > > In addition, other refinements might
 > > include having the client supply additional certificates that may be
 > > useful to the server (such as certificates received with an S/MIME email
 > > message).
 >
 > Yes.

The structure for sending in additional certs together with the certs
for which you ask a service, should be well defined. Both for DPV and DPD.\

Agreed. Russ has proposed the structure from S/MIME for the added certs, vs. the target cert. Carlin (I think) suggested that we keep the request simple (er?) and have just one target cert per request.

For DPD there is the question about *how* does the server know when
to stop filling up all possible cert chains that may be considered
valid by the client. (That's why there is an interative approach
in OSCP-DPD).

I think we answered this. One chain (with associated revocation status data) is sufficient, IF it matches the validation criteria supplied by the client. It's an open question whether we want to provide a facility for a DPD server to return multiple chains (and associated ...) as an option.

 >
 > > I look forward to seeing a discussion on this topic. If no discussion
 > > results, I suppose that I will conclude that there is general agreement
 > > about these basic concepts. However, simple affirmative messages
 > > agreeing with these basic concepts would be useful in judging rough
 > > consensus.
 >
 > Sorry, my message is going in the reverse direction. :-(

The direction of consensus is not necessarily defined by the chairman :-)

It is determined by the chair, but not defined by the chair, as you note :-)

Steve