Subject: Re: <draft-ietf-pkix-dpv-dpd-req-04.txt>

From: Peter Sylvester <[email-masked]>
Date: Fri, 26 Apr 2002 17:57:26 +0200 (MET DST)

> > 
> > This would lead to :
> >    In order to obtain the revocation status information of any
> >    certificate from the certification path, the DPV server might use,
> >    ...
> >    or a response from another DPV server.
> > 
> > I proposed:
> > 
> >    The DPV server MUST produce certificate status information for
> >    the validation time in the client request. In order to do this,
> >    the DPV server might use,  ...
> > 
> >    or a response from another DPV server.
> > 
> > The first sentence was changed.
> > 
> > In the seceond paragraph the two words indicated by XX above are indeed
> > can be deleted.
> 
> There is no basic diffence between the two proposals. The current changed
> text is sufficient. We cannot argue at length on the style of the wording.

May I remind you that since 4 years you are repeating that 
'negative revocation information' is not the same as 
'positive status information'. 

May I also remind you to the lengthy debates about how to interprete
"GOOD" in OCSP. 

Well, if everybody thinks that "obtaining revocation information"
is the same as "producing status information", ... 

> 
> Validating against one validation policy cert B from the chain (cert B +
> cert C) cannot help for validating cert A against a different policy (or
> even the same if it could work on a shorter chain) from the chain (cert A +
> cert B + cert C). Thus DPV responses on CA certificates would not be
> "useful" information. 

The fact that a French policeman may not be able to read an ID card
from country XYZ does not mean that we MUST NOT have a procedure to validate
French cards. 

Who says that this is "another" policy? How do you know that an OCSP
response obtained by some server is useful. It may not be one
that can be used for the given policy. 

The DPV server receive a certA plus a DPV response concerning the
path certB, certC. The DPV server uses the DPV response to 
to establish a path to some trusted root. It may, or may not
simply trust the DPV response to tell the truth about the current
validity, and use other services. 

At elast, the information had been useful to establish a path.  

> 
> > You might also add 'time stamps' to your list (as in ES-F).
> 
> As this is only a list of examples, do we need to say so ? As we already
> know a DPV response alone will be insufficient for validating a digital
> signature. Let us keep the mention of time-stamp tokens when we will address
> DSV requirements , ... which is the next step as soon as we finish this
> document.
Why do you talk about signature validation. You can for example have 
time stamp on "encryption cert status information" allowing you to
find out whether it was ok to encrypt data at that time or whether
you have violated some confidentiality requirement.