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

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Peter,

Thank you for your interest in CVP.

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

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.

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

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.

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

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'
> mean what? the requesting or the receivin gserver? Well, it may 
> be deduced from the loop detection procedure.

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

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