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

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

> 
> I have issued a new version of CVP "Certificate Validation Protocol".
> 

To some degree the critique that you made about functionality
implemented by extensions may also apply to your text.

It is not quite clear to me why just for relaying and referal you
use an extension mechanism and for example you have
a direct option serverContextInfo which is not an extension.
it seems that you are distinguishing optional service
features from optional parameters in this way. 

"Using "Dump ASN.1" would allow to easily debug CVP, but not SCVP."
Since you also use Extensions, this is true for your version, too.

Not encapsulating data into an octet string but defining them
as ANY DEFINED BY (to use an outdated asn1 term), is a mechanism that
correct ASN1 implementations can handle. 

You don't specify explicitely what to put into the ESScertid of a 
relaying extension. 'RelayInfo unambigously allows to identify the server'
mean what? the requesting or the receivin gserver? Well, it may 
be deduced from the loop detection procedure.

What identifier should be set for servers that do not sign their
responses?

-- 

It is not possible to use a DPV response from a relay server
in a reponse from a server UNLESS the initial server does not
sign anything, authenticates itself via SSL, and just forwards
the obtained relayed reponse as is. 

--

The usage of 'minorstatus MinorStatus OPTIONAL' probably needs a tag. 


can you tell why you use 

  version [0] EXPLICIT INTEGER DEFAULT v1 

and in the PolicyRequest instead of simply using an INTEGER as
in request: 

  version INTEGER DEFAULT v1 

In fact, it is not important because the field will never be present anyway,
and since all possible extensions are done with Extensions, there is 
probably never a requirement for a version v2. Othewise the syntax should
have a ... in any sequene with a version field. ...
 
--

There are many places whether CHOICES and optional fields cannot be detected. 

--

The PolicyResponse should probaly be better defined as

PolicyResponse ::= SEQUENCE (1..MAX) CHOICE { [0] valPolicy ValOrDiscPolicy ; [1] dispolicy ValOrDisPolicy 

--

ValOrDiscPolicy contain an ambigouos CHOICE. 

What is 'NAME' and 'Name'. Who do define a URL as 'NAME'?

-- 

A policy request cannot be replay protected? 

--
I think you have misunderstood the requirement of putting the identification 
of the server identity in the response. The ESScertid is not an identification 
of the server, but an identification of a signing certificate.
 
--

How are the number of time stamps and the TSAs indicated in the policy?

The definition of simplePolicy does not contain this.

--

I think it would have been better to separate the signature authentication
mechanism from the rest for example by using a CMS security envelope, unless
you believe that time stamp will never be used.

-- 

not saying anything about the rest doesn't mean that I agree with it. 

---

regards