RE: DPD & DPV requirements - Let us Recurse

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

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

Maybe my wording of using 'justification' wasn't good. It is
rather to indicate that the server return all information in
form of approriate return codes or statements from other
servers so that in case that the client believes the correctness
it has all necessary information available. 

There may be a problem with CRLs when they are large, but in
this case for example the server could simulate an OCSP response.

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

I don't ask for something that all kind of explanations of 'why'.

The distinction of why and whether something is good/bad
is not quite clear if one already returns values like
revoked, expired, or else.

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

I am not entering at all into that area. 

A strawman proposal: 

A server should have the ability to return in the response
a rather limited set of well-known protocol elements, certs,
crls, ocsp response, pkistatus, DPV response, at least those
that he had used to make up its decision or which it wishes
to communicate to the client for whatever reason.