Subject: FW: scvp

From: "Trevor Freeman" <[email-masked]>
Date: Wed, 21 Apr 2004 09:39:48 -0700

Reposting at Peters request

-----Original Message-----
From: Trevor Freeman 
Sent: Tuesday, April 13, 2004 11:25 AM
To: 'Peter Sylvester'; [email-masked]
Subject: RE: scvp

Hi Peter,
Respnces below.

The change to 3.4 permits a SCVP server to return a cached response in
which case it cannot include any request specific values. A client could
require a non-cached repsoce in which case this value must be present.

There is no requiremnt today that SCVP client must have a name in the
genral name space. They can simply use soemthing generated localy and
use that which seems a big plus. If the request or repnoce is signed
then you get a name in the certifcate.

The octet string vs. oid with any was a arbitary chioce since boht
chiver the same end. 

Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Peter Sylvester
Sent: Tuesday, April 13, 2004 3:56 AM
To: [email-masked]
Subject: scvp

SCVP 14:
 3.4 Requestor 
   
  The OPTIONAL requestor item is a reference local to the requestor. 
  The value is only of local significance to the requestor.  If the 
  SCVP client includes a requestor value in the request, then the 
  SCVP server MUST return the same value in a unique SCVP response. 
  The SCVP server MAY omit the requestor value from cached SCVP 
  responses. 

SCVP 13: 

  The OPTIONAL requestor item is a reference local to the requestor. 
  The value is only of local significance to the requestor.  If the 
  SCVP client includes a requestor value in the request, then the 
  SCVP server MUST return the same value in the response. 

As far as I remember, there was no discussion about this. 

I think that the following sentence of 4.6 does not respect the
requirements. 

 4.6 Requestor 
   
  The OPTIONAL requestor item is used to identify the requestor.  The 
  value is only of local significance to the requestor. 

requirements say:

   When the DPV request is authenticated, the client SHOULD be able to
   include a client identifier in the request for the DPV server to copy
   into the response.  Mechanisms for matching this identifier with the
   authenticated identity depends on local DPV server conditions and/or
   the validation policy.  The DPV server MAY choose to blindly copy the
   identifier, omit the identifier, or return an error response.

IMO this clearly indicates that the identifier has a meaning for the
server.

Unless I have overlooked something, I have not seen any response
to the following.  Maybe the content of my message considered
as pure nonsense.

Date: Tue Oct 28 18:43:58 2003
To: [email-masked], [email-masked], [email-masked]
Subject: RE: SCVP additions

hello,

It would be nice to hear whether all or which comments
about SCVP have been addressed. Unless I have overlooked
something, my remarks about the definitions of requestor
and responder have not received any treatment. 

I simplify the content of my comments:

requestor and responder should be GENERALNAMES which
indicate and identify in global the partipating parties.  

IMO Using arbitrary octets with only LOCAL significance
is not compatible with the procedure to detect loops.

4.6 indicates the there MUST NOt be null characters,
something which is explicitly allowed for a server
acting as a relay.

What is the sense of 4.7? The responder field is
never used anywhere in the actual protocol, what
is the meaning of such an opaque value?

4.8.5 What is the reason of having an additional octet string
encapsulation instead of an any defined by construct? Is it
that some tools may break decodeing when they find an OID
that is not known? If so, whay are there ANY DEFINED BYs at
other places?

can someone indicate me how a relay would return the response
of the next server to a client as part of his response?

regards