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

RE: DPD & DPV requirements - Let us Recurse

Peter,

<snip>

What do you mean by revocation status not quite perfect? A server
makes a desision, and tells what it had looked at, it may happen
that another server verifier looks at the same data in a different
way, and comes to another conclusion; this tru independant of
whether the first returns its justifications or not. One entity
might validate a cert chain, another might not, etc. Returning
as much as possible data about why one decision has been made
does not change that.

What if a server has a CRL for a along the path but the CRL is old, and the server cannot get a current one? The simple answer is that the validity of the target cert is unknown, but that may not be a totally satisfying answer. You are correct that we face this problem already for DPV (for DPD we could return what we have and let the client work it out) irrespective of whether we have to return justifications. As we move into "explaining" an evaluation, I was thinking that we might want to be more sophisticated about the whole process, but that was sloppy on my part. You're right!

If a client has a user interface to explain a server decision,
it seems necessary anyway to display certificates, elements on
a CRL, OCSP reponses, PKIStatus data.

We already have the problem of user interfaces of certificate
and CRL displays, and also of how to display responses from
a OCSP server, or from the new services to be standardized.
But do we actually care? But: I don't see in other pkix standards a
description of about how a certificate chain has to be presented
or even a single certificate.

No, the last RFC to broach the subject of cert path info presentation was 1422, for PEM! If we return status, cert chains and revocation status, then we get to ignore this. But, if we return what purports to be an "explanation" of why a cert is valid, then I think we have opened up a can of worms with regard to user interface issues, because the purported customer for the explanation. This is especially true for DPV and non-PKI aware clients.

What seems useful to me is to specify a list of elements that may
be supposed to be presented to users. Such a list should be a simple
as possible, contain a small number of different data type that
allow to express a large set of situations, so that we don't have
to add new stuff each 6 months or 3 years. We have already *MANY*
standards that return 'status information' in different ways.
One question here would be: Is it more appropriate to use a
new textual format like in SCVP or something like PKIStatus as
used in several standards maybe accompanied by OCSP responses?

I think the answer has to be driven by the context in which the response is to be used. For machine consumption a binary status representation is appropriate, but for a human user, text is preferable. However, in the latter case, I think we are entering a very complex arena that, as you noted, we have avoided in the past, re HMI for PKI info.

Steve