Subject: first comments for SCVP 12

From: Peter Sylvester <[email-masked]>
Date: Mon, 4 Aug 2003 18:47:57 +0200 (MEST)

This is a first list of comments regarding SCVP draft 12. This
does not take into account various comments from other people
so some text may be redundant.

Chapter 3:

I am not convinced that it is a good idea to copy definitions from CMS.

There are some comments as annotations which should be explained
in text, e;g; why is there only one signerInfo present? 
I don't see why there couldn't be several signatures or
countersignatures (for example in relaying). 

  " There are two forms of SCVP request: unsigned and signed.  A signed 
   request can be used to authenticate the client to the server. "

This seems to require a modification concerning the addition of
authenticated data. 

3.5 reqExtensions 
 
 " An SCVP server MUST reject the query if it encounters a 
   critical extension it does not recognize;  "

which error code should be used? 22? 

4: 

Same remark as for chapter 3 about copying the syntax.

The response can be eieyther signedData or authenticated? what
if a client implementation only support one option, and a 
server only the other?

it is very unclear why the signedData have all the MUSTs about
ess signing certificate etc. 

  " The SCVP server MUST include its own certificate in the certificates 
   field within SignedData."

Why this?  Well, the requirements doc says:

  "The DPV server's certificate MUST authenticate the DPV server."

How is this supposed to be done in SCVP? T
The current text says that the server MUST return its
certificate, the client matches this against what? It may be difficult
distngusih from any end entity providing SCVP responses. Configuring 
the client requires in this case at least
an identity + some CA cert or a separate tree...
 
It seems useful to me to have a special extendedKeyusage (id-kp) such
as for OCSP, TSA etc.  and also to follow at least the trust models 
of OCSP.

I propose to rewrite the sections along the following lines:

- first, the payload definition

- then sections about security envelopes addressing different
  requirements, in particular:
  - the client is the only RP.
  - the client will use the response to show it another RP
  (Shouldn't this be part of a policy or a wantback? i.e. 'signature required')?

4.3: is it necessary to have status codes which have non consecutive
     numbers. This seems to me a left over from a textual version
     where somehow like in SMTP the code is actaully a combination
     of three codes or else. 

     There are several codes refering to signedData signature
     problems but none about authenticated data?

     40 shouldn't this say: 'The server detected a loop during relaying'?

Why this?

     ReplyWantBack::= SEQUENCE { 
       wb                         OBJECT IDENTIFIER, 
       value                      OCTET STRING } 

and not 
     ReplyWantBack::= SEQUENCE { 
       wb                         OBJECT IDENTIFIER, 
       value                      ANY DEFINED BY wb } 

What is the intention of using [1] and [2] tags? 

     CertReply ::= SEQUENCE { 
       cert                       CertReference, 
       replyStatus                ReplyStatus, 
       replyValTime               GeneralizedTime, 
       replyChecks                ReplyChecks, 
       replyWantBacks             ReplyWantBacks, 
       valPolicy                  ValidationPolicy, 
       nextUpdate             [1] GeneralizedTime OPTIONAL, 
       certReplyExtensions    [2] Extensions OPTIONAL } 

(There are some other places in the syntax. It seems that tags are
 systematically used for optional tags even if not required).

4.4
  " When using connectionless protocols, the requestRef item allows the 
   client to associate a response with a request. "

replace by: 

   The requestRef item allows the client and other relying parties 
   to associate a response with a request.

4.5: 

I think that someone has misunderstood the requirement. well, it
may not be clear in the requirements doc, since after spending
several months of fights ... Anyway:

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

The (at least my) idea was to have a "GeneralNames" since this is
waht is used everywhere else in PKIX for identifiers.    

For relaying the identifiers must be globally unique. creating a new
octet string based type may a new nice way to get of DNs or other
naming contexts, but saying

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

is asking for problems because two servers may choose the same id, or
worse, one chooses a prefix of another followed by a a zero octet.  
 
4.6 

Similar here. 

In fact, the requirement is that both the request and the response
have a requestor and a responder field.  

The requestor in the request indicates who is asking, or, in the
response, to whom the reqponse is provided.

The responder in the request indicates who is th intended id of
the provider, and in the response, who actually provided the
response. 

The impact to chapter 7 are obvious:

- A server MUST add HIS identity in the requestor field.*
- A server MUST perform inbound loop detection, i.e., detect
  if the requestor field already cntains its own identity.
- A server MAY perfom outbound relay checks, in the relayed server 
  identity is known. 

- A relaying server must add his identity in the responder field 
  of the response.

4.7.8

Since the protocol defines so many new types, I wonder why it is
necessary to reuse the Extension type here since the critical bit
needs to be set to false anyway. And: The syntax already defines
some policies using "any defined by" or even SEQUENCE {oid, string)
why not simply using the same. 

4.8

I am not yet sure whether it is really necessary but I propose that 
the Nonce returned must have a prefix that corresponds to the request
nonce.

Relaying: A server that is relaying one half of the request to one
server, and another to another, how does the server include the
responses from the two services, allowing another relying party to
validate them? How are DPV responses from other servers included in
a response?

Well, so far, it is getting too hot here to continue....
Peter

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 7 Aug 2003 16:59:06 +0200 (MEST)

Here some more comments. 

After having read the conversation between trevor and Denis
concerning validation policies, i'd like to see asap the
next textual proposal. 

I believe that the current text of SCVP is difficult to implement
if I remember correctly how to use ASN1.

for data structures that are using some types like

   SEQUENCE {type OID, parm ANY DEFINED BY type} 

the complete list of known ids (like the default or the
name policy) need to be defined in advance and complied into
the code. 

On the other hand the requirements doc and SCVP specify that
the valPolicy identifies a configuration. A configuration
can contain for example trust anchors. one would at least have
to define in the client some cloning mechanism to identify
different settings of trust anchors in a dynamic way 
suited for a particular client context. 

The configuration of the client would be something like:

-  an OID identifying the agreed context/configuration

-  an rule allowing to code one or more "validation policy parameters"
  for the validation policy (ies) which are part of the particular 
  configuration identified by a configuration OID.
  
If we remember a structure like: 

PolicyInformation ::= SEQUENCE {

     policyIdentifier   CertPolicyId,
     policyQualifiers   SEQUENCE SIZE (1..MAX) OF
             PolicyQualifierInfo OPTIONAL }

CertPolicyId ::= OBJECT IDENTIFIER

PolicyQualifierInfo ::= SEQUENCE {
       policyQualifierId  PolicyQualifierId,
       qualifier        ANY DEFINED BY policyQualifierId }

one would define additional values for PolicyQualifierId
for the default policy and the name policy. 

It is getting really hot here.
Peter