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

From: Peter Sylvester <[email-masked]>
Date: Mon, 4 Nov 2002 20:15:00 +0100 (MET)

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

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 07 Nov 2002 12:17:11 +0100

Peter,

Thank you for your interest in CVP.

> features from optional parameters in this way. 

The answer is quite simple.

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

We specify here the client-to-server protocol. Extensions are being used for 
the server-to-server protocol, which is clearly an option.

serverContextInfo is necessary for DPD and thus MUST be supported by a DPD 
server since there may more than one path that satisfies the (path) 
discovery policy.

> Since you also use Extensions, this is true for your version, too.

Only the server to server protocol (which is an option that you requested 
and which is not present in SCVP) will be more difficult to look at.

> relaying extension. 

ESSCertID is defined in RFC 2634 as:

    ESSCertID ::=  SEQUENCE {
         certHash                 Hash,
         issuerSerial             IssuerSerial OPTIONAL
    }

The OPTIONAL field is not necessary, but if it is there, it will not hurt, 
so why no further explanations have been given.

 > 'RelayInfo unambigously allows to identify the server'

The text that is present provide many explanations, which seem to be sufficient:

"When a CVP server wishes to relay a request towards another CVP server
using this protocol, then, for each single request, it SHALL support
the relaying extension.

If a relaying extension was present in the request, then an additional
RelayInfo SHALL be added to the content of the Relaying extension and
included in the next request.

If a Relaying extension was not present in the request, then a Relaying
extension field shall be created and included in the next request."

If you still find the wording not clear enough, please provide an 
alternative proposal.

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

Good question. Well, if they have a certificate, then they can still use 
ESSCertID. Maybe your next question will be: "... and if they don't ?"

I let you make a proposal.

Denis