Subject: Re: FW: scvp

From: Peter Sylvester <[email-masked]>
Date: Wed, 21 Apr 2004 19:47:09 +0200 (MEST)

> 
> Reposting at Peters request
Thanks

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

There are least one server and all its clients involved which must
agree  on the identifications. Furthermore, the identifications
are also used by other relying parties. this means that all 
participating entities need to have a comon understanding
of an identification. What is the big plus of having an untyped opaque
identifier without any possibility for structuring, this
seems to me that the requirement 

       Mechanisms for matching this identifier with the
  >    authenticated identity depends on local DPV server conditions and/or
  >    the validation policy.

seems unnecessarily difficult in this case. What is the real benefit
over GeneralName. I wonder how one can implement a general solution
in a product without specific code or an " identifier to authenticated identity
mapping function" specifiable dynamically. On the other hand, using
generalName allows to have a simple local definition (identifier must be one
of the identifiers in the authenticated indentity); 
furthermore identifiers are not just for loop control, but supposed to
be displayed or otherwise shown to some user. of course,
one can always show a hexadecimal representation of the identifier
but again, the same difficulty to map this identification of the 
'requester' (not the request) to any of the authenticated entity
remains.   

Well, on can always recomment to encode a generalname in the
octet string ... oops, that doesn't work, either.

                                   If the request or repnoce is signed
> then you get a name in the certifcate.

You can have more than one identification in a certificate using
subject alternatename extension. 

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

Does this refer to 4.8.5?

The question is why is it necessary to use all different
known techniques in this text in a arbitrary choice, at some places
it is any defined by at others it is an octet string encapsulating
a structure, and to invent at least one new opaque.
(ValidationAalg, replywantback, 'identifiers' in requestor, responder, etc)

The argument of encapsulation of some structure in an octet string 
comes from the fact that some encoders/decoders cannot treat correctly
'any defined by' with unknown oids. If one wants to support them then 
there should be no any defined by at all. Or, if the number of types
syntaxes is small and stable, then an additional encapsulation is not
necessary. Another potential reason is that the encapsulated
type cannot easly be encode with DER, well, saying 'The octet string
contains a boolean type' is not ok, I may have overlooked if it is
excluded to have a XER encoding of an ASN.1 type.   

There is a confusion between "ValidationAlg" and  "ValidationAlgorithm"

I have no asnwer to the last question.
As far as I remember there is nowhere a place to have a contentinfo,
i.e. an SCVP response as part of the response. 

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