Subject: Re: I-D ACTION:draft-ietf-pkix-cvp-01.txt

From: Peter Sylvester <[email-masked]>
Date: Fri, 8 Nov 2002 13:34:19 +0100 (MET)

> 
> The answer is quite simple.
That was a rhetoric question anyway.

> 
> Everything which is in the core protocol (i.e. what MUST be supported either 
> for DPD or DPV) is not designed using extensions.

But since you answered: This does not mean IMO that other things
should  be designed using extensions.

  "A server may support either DPV or DPD, or both DPV and DPD."

A DPV implmentation can consider all DPD functionality as
optional feature. 

--

> I let you make a proposal.

Since you have already 
requesterName        [1]  EXPLICIT GeneralName       OPTIONAL,

to indicate identities, I suggest that you change this to 

requesterNames        [1]  GeneralNames       OPTIONAL,

A server MUST add its own identity to the list of clients when 
forwarding the request.

A server that supports relaying performs tests: 

- It checks whether the requests already contains it own identity,
  and SHOULD reject the request if so.

- In case it knowns the identity of a relay to which it forwards
  the request, it MAY checks whether the request already contains
  the identity of the next server and MAY reject the request.

change 

     cVPServerCert              ESSCertID                 OPTIONAL,

into GeneralNames indicating the identities of the servers
that paricipated in creating the response.  

add a corresponding optional field to the request allowing a
client to indicate to a server to indicate for example the
identity of other servers that are known (to the client) to
be able to perform the service. 

change "requesterData" to be a SEQUENCE, allow a relay to add elements
to the list. 

Provide a similar list of text for the responses. 
---

Can you clarify the relation between signtures of the individualRepsones
and the global one. Does this mean for example that you can have 
individualresponses signed by other entities? 

--

It is intended that the policy discovery is a MUST for
both protocols, I guess, as sepcified in the requirements
doc. I object to this. policy discovery should be an optional
feature.
---
Additional hint (in order to further comment some points
that you havn't addressed).

  Provide a complete ASN1 module and run it through some 
  compiler before publishing.

--

Peter