Subject: RE: DPD & DPV requirements - Let us Recurse

From: Peter Sylvester <[email-masked]>
Date: Mon, 8 Jan 2001 19:27:22 +0100 (MET)

> 
> Peter,
> 
> >  >
> >  > Returning info that explains why a server believes that the returned
> >  > data supports validation is an interesting notion. The first example
> >  > of that I saw was in work performed by colleagues here at BBN, on a
> >  > project calls IOS, in the early 90s, where servers did that.  But, I
> >  > think this is still an R&D topic for now, not yet ready for
> >  > standardization.
> >
> >Isn't part of this 'interesting notion' the cert chain itself. The
> >certificate chain return by a DPV server is the chain that has
> >been used to validate it, and the server believes that this chain
> >is valid.
> 
> The interesting part of the notion is using a common representation, 
> which can then be translated into human readable language, to express 
> the validation chain assertions, especially when the validation 
> process is incomplete, or not exact, e.g., outdated CRLs.

There are several interesting things IMHO:

- what statements are to be returned, 

- whether ALL elements that contribute to a decision are returned.

- how can they be translated into whatever a client tells.

There exist already a data structure which is used in other
protocols, i.e. PKIStatus, that can be used to carry additional
information. 

It just seems to me that if one starts to create a DPV response that
by itself already contains information about whether or not the
certificate is valid, then one should try to return all the information
that might be appropriate. This includes CRLs, OCSP reponses, 
statement expressed in PKIStatus or an attribute certificate.

A validation server makes it decision in some linear way, or at
least it can assemble all the results in a linear way. Thus,
a simple list of statements, "I've looked at this", "I consider it
to be valid/invalid/incomplete" seems to me a good starting point.
A cert chain is just a subset of that. 

> 
> Well, there is already a suggestion (that I need to look into 
> further) that proxied OCSP responses may pose problems. if one has to 
> assemble a mix of serial and parallel signed responses to satisfy a 
> query, that adds complexity both syntactically and semantically. But, 
> for the most part, my allusion to R&D issues has to do with the 
> problems that arise when the revocation status data is not quite 
> perfect and one wants to respond with something more that "NP" and 
> with the human interface presentation issues.

Just because it create complexity, this is one reason that these things
are discussed and standardized. I have just given a provoking
example of parallel or enbedded signatures by borrowing some
ideas from CMS; it may be sufficient that a relaying server just embeds
a response from another server, and parallel CMS signedData are
not necessary.  

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.

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.

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? 
 
Peter

---

From: Stephen Kent <[email-masked]>
Date: Tue, 9 Jan 2001 18:51:39 -0500

Peter,

><snip>

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!

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

>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