Subject: Re: Cautionary Period ...

From: Peter Sylvester <[email-masked]>
Date: Fri, 11 Jan 2002 17:27:35 +0100 (MET)

> view on the issue.  My view is that cautionary period is a not a 
> requirement for DPV or DPD.  However, cautionary periods might be used as 
> part of an application-specific risk mitigation mechanism when trying to 
> determine the validity of a particular signature.  For example, waiting for 
> cautionary period before considering a signature to be valid on a 
> high-value electronic contract may be prudent.  Therefore, cautionary 
> periods might be supported in DSV (delegated signature validation).

I agree with this point of view.

> 
> Since Denis and I were unable to resolve this issue in an author-to-author 
> dialogue, I am bring this issue to the whole mail list.  As far as I know, 
> this is the only open issue with the DPV and DPD Protocol Requirements 
No. See later. A great deal of the list of requirements for DPV
that I have send in December has not been adressed at all.
I don't know whether there is consensus that what I have send does 
not contain necessary/optional/useful requirements at all. If so, so
be it. 

> document.  I hope that this issue can be quickly resolved so that we can 
> get on with the protocol development.
Or 'protocols development'. 

Here are some editorial comments. 

The abstract says:
 "This document specifies requirements for two main request/response   
  pairs."

  followed by actually five, with two of them 'optional'.

what means 'optional' in this case? 

In fact there five different services, all of them are independant,
thus optional. 

I don't think that 'request/response pairs' is a good wording.
All occurences should be replaced by 'services' or something like that. 

And a sentence added like:

"All services are initiated by a client sending a request
 to a server; the server answers by one or more responses."

( There can be more than one response to a request. Just one
  example would be a request to determine the validity of
  a very old cert which requires some offline action, thus
  an initial response could indicate that another answer
  will be send by mail or else. 
)

> Because validation software is controlled by many parameters which, 
> if incorrectly set, may result in insecure behavior, it is useful
                                                       ------------
> to rely on pre-defined policies that are already known by the servers, 
  ---------------------------------------------------------------------
> where system security administrators carefully manage them. 
  -----------------------------------------------------------

This and the next paragraph sounds ok. But:

> Alternatively, system security administrators MAY also define policies.
What 'alternative' ? What means 'MAY also define policies'?

> However, such policy definition may be quite complex and only some 
> forms of policies can be defined in this way, otherwise testing all 
> the possible variations would lead to non-interoperable implementations
> or would increase the time necessary to ensure that two implementations 
> are interoperable.
How does 

  "testing all the possible variations would lead to
   non-interoperable implementations" ?

I would rather think the contrary ???

> Since policy definitions can be quite long and complex, all the 
> parameters SHOULD NOT be passed with each individual request; rather,  
                                          'individual DPV or DPD request'

> they SHOULD be defined using a separate policy definition 
> request/response pair. In response to a successful policy definition 
> request, the server SHALL return a policy reference (e.g. an OID).

Why SHOULD they be defined using another management protocol?
They MAY be defined in that way.  

> The certificate to be validated MUST either be directly provided in 
      certificates 

> The client MUST be able to provide to the validation server, associated
> with each certificate to be validated, "useful certificates", as well 
I don't know whether my German understanding of the English language
hits me here. Does the sentence mean: 

  "The protocol MUST provide a means to a client to provide ..."

> "The Delegated Path Validation (DPV) protocol allows a server to 
> validate one or more certificates according to a validation policy."

I suggest: 

  "The Delegated Path Validation (DPV) protocol allows a client to
   ask a server to validate one or more certificates and to provide
   a status to the client. The validation is made according to
   a validation policy." 

> The validation policy SHALL be known by the DPV server.
> The validation policy MAY be defined using an additional request/
> response pair (see section 10) prior to the DPV request. In this way 
> clients only need to be aware of the reference of the validation 
> policy to be used by a given application.

Could one try and avoid turning around phrases three times.
'in this way' refers to what? 

I propose:

"The validation policy SHALL be known by the DPV server and 
 identifed by unambiguous reference usable by the client."

And maybe :
 "In this way clients only need to be aware of the reference 
 of the validation policy to be used by a given application.
 The definition of policies and the allocation of a reference
 is outside the scope of DPV. Section 10 proposes a policy
 management protocol/service."  although this seems to be
 a repetition of text elsewhere.