Subject: Re: SCVP Draft 17: Summary of changes

From: Peter Sylvester <[email-masked]>
Date: Tue, 15 Feb 2005 17:40:41 +0100 (MET)

Here some comments to the new draft. 

1 - on page 12: 

   "The list of certificate references in the query item"

 replace this by

   "The list of certificate references in the queriedCerts item"

 It might be usefule to consider to add quotes to enhance some
 readability `queriedCerts'  in particular whether the syntax elements
 could be confused. 

2 - 

I vaguely remember that concerning comment C there was my suggestion 
to use tagging that is an explicit version of what would happen with 
AUTOMATIC tagging, unless I'm wrong this would give something like

     CertReferences ::= CHOICE { 
       pkcRefs           SEQUENCE SIZE (1..MAX) OF PKCReference, 
       acRefs            [0] SEQUENCE SIZE (1..MAX) OF ACReference } 
    
     PKCReference ::= CHOICE { 
       cert              Certificate, 
       pkcRef            [0] ESSCertID } 
    
     ACReference ::= CHOICE { 
       attrCert          AttributeCertificate, 
       acRef             [0] ESSCertID } 

see also point 14.

3 -

         "The checks item MUST contain a sequence of object identifiers
   (OIDs)."  

This sentence seems superflous to me, since the syntax already says that.        

4 - The usage of anyKeyUsage in the keyUsages is not explicitely defined.
   (It can be guessed to a certain degree..)

   in other words, the requiredKeyUsages is defined, but not the anyKeyUsage

   What is the difference of having a NULL option and not having coded
   the optional field?

   Note that if the requiredKeyUsages is used, non existance of the 
   key usage in a cert extension is a match. 

5- 3.2.4.9  

   "If the client wishes to confirm 
   the extended key usage, then it can communicate the usage it wants to
   validate by the same extension using the same semantics as defined in
   [PKIX-1]."

   shouldn't 

      SEQUENCE SIZE (1..MAX) OF KeyPurposeId

   then be replaced by 

      ExtKeyUsageSyntax

   otherwise "same extension" is not well defined. (and even then)
   
6-

  suggestion to replace: 

   "Therefore if the client obtained the certificate in the 
   context of a TLS server," 

   "E.g., if the client obtained the certificate in the 
   context of a TLS server," 

7 -

   "When using the default validation policy, the client can override any
   of the default parameter values by supplying a specific value in the
   request.  The SCVP server MUST make use of the provided parameter 
   values or return an error response."

   How are default values specified?  

8 - 3.2. 4     

   "A validation policy MUST define default values for all parameters 
   necessary for processing an SCVP request.  For each parameter, a 
   validation policy may either allow the client to specify a non-
   default value or forbid the use of a non-default value."

  - How are default values specified?  if there is a MUST, then
    why are all of them OPTIONAL?

  - How is 'forbid the use of a non-default value' indicated in the
    policy, and how, in this case the policy contains a the fixed
    non-default value? 

9 - 3.5  requestorName 
       
   "The optional requestorName item is used by the client to include an 
   identifier in the request.  The client MAY include this information 
   for the DPV server to copy into the response. 
    
   SCVP servers MUST be able to process requests that include this
   field."

   Please add:

   A server MAY require this to match with some authenticated identity
   depending on a server defined rule.   

10 - 4.8  

   "Alternatively, the SCVP server MAY omit this item."

   I don't think that this is not a alternative if the client has set a
   requestorName, if if my reading of 3.5  "to copy into the response"
   mean that the server MUST copy.

   Mildly speaking, after total silence since my last remark concerning
   these fields, I was not sure whether anything at all was accepted
   by the authors, or not, anyway, the tendancy has continued to 
   partially respond, and not say anything to concrete proposal, which
   is simply to have a requesterName in both requests and responses
   as a GeneralNames (note the s), so taht a relay can add an id etc. 

11 -

   "In the case of non-cached responses to signed requests, the SCVP 
   server SHOULD return a requestor name."

   For what reason a SHOULD? What is the reason for returning anything
   for a "signed" requst if the client doesn't need this? And, why
   'signed' and not protected?  

12 - 7:
       "SCVP 
   servers that support relay SHOULD populate this item with the DNS 
   name of the server or the distinguished name in the server's 
   certificate.  SCVP servers MAY choose other procedures for generating
   identifiers that are unique within their community." 

   I don't think the SHOULD is appropriate. DNS or distingushed name may 
   not exist, and there is no indication who an octet string can be populated.
   
13 - 7:

   It is quite nice to have loop detection for relaying,

   but nothing is said how a relay constructs a request from 
   a received on, and how a response is created from the 
   received response.
  
   (E.g. what to do with requesterName in the request? )

   The SCVP still does not contain a means to include the respons 
   of another SCVP server in a response. 

14 - Since it seems that it has been agreed somehow that a id cannot
   necessarily be derived from a security envelope, or, at least for
   symmetric reason, a response should have an value identifying
   the responder.

   Ah well, the previous responder item whihc had context 4 had been
   silently dropped (instead of being replaced by a generalnames.)

     CVResponse ::= SEQUENCE { 
       cvResponseVersion         INTEGER, 
       policyID                  INTEGER, 
       producedAt                GeneralizedTime, 
       responseStatus            ResponseStatus, 
       respValidationPolicy  [0] RespValidationPolicy OPTIONAL, 
       requestRef            [1] RequestReference OPTIONAL, 
       requestorRef          [2] SEQUENCE SIZE (1..MAX) OF OCTET  
                                   STRING OPTIONAL, 
       requestorName         [3] GeneralNames OPTIONAL, 
           replyObjects          [5] ReplyObjects OPTIONAL, 
       respNonce             [6] OCTET STRING OPTIONAL, 
       serverContextInfo     [7] OCTET STRING OPTIONAL, 
       cvResponseExtensions  [8] Extensions OPTIONAL } 

   please "align" the syntax. 

15 - ReplyWantBack

   I have never any explication why the

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

   is an encapsulating octet string. Since the client
   makes a particular wantback, one could assume that
   it knows the syntax? 
   
     ReplyWantBack::= SEQUENCE { 
       wb                         OBJECT IDENTIFIER, 
       value                      ANY DEFINED BY wb } 

   seems better to me. 

17 - 9

   I think all staements of what a client or server MUST do with
   certain field should go to the section defining the protocol
   element. 

   example the first statement in

   "Clients MUST check the requestRef item in the response and ensure 
   that it matches their original request.  Requests contain a lot of 
   information that affects the response and clients need to ensure that
   the server response corresponds to the request."

18 - 9

   "Therefore in these situations use 
            of a URI many be more attractive."

   Is there a comma missing behind the first word? if so, there are other places, too.

19 - 9
   
   "... ensure that the response cannot be a replay
   of a cached response obtained by another client."

   Are you sure? replay of cached responses are a feature
   of a server. A client may well accept a response that
   has no client identifiers etc IF the response is
   timely etc.

20 - 9

   The last paragraph in 9 seems to me to belong elsewhere. 

   And, in fact, nothing has been said anywhere that setting
   a validationTime has something to do with history.
 
   It can simply mean that the client has the best idea of what
   is 'NOW', and gives that time. (Although I would imagine that
   a server probably knows better). 

   The definition of validationTime does not say what a client can
   set into ythat field. 

21 - 9 

   "A certificate may
   have been revoked after the time specified in validationTime, but an 
   invalidity date that precedes the validationTime."
  
   I cannot parse that sequence of words. 

22 - B.1

    "The body of the message is the binary value of the DER encoding 
       of the CVRequest"

   what is the reason for the "DER" here. If no wrapping occurs, then ...
   and also the resulting CMS is not necessarily DER. 

23 - Paul Hoffman used to be one of the authors. Even when nothing of what
   was written by Paul has remained, the contributions section could
   still name him, unless ... 

   "The lively debate"  may you consider to replace it by 'the lively or almost deadly debate' 

Peter

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 15 Feb 2005 17:08:03 -0500

> readability `queriedCerts'  in particular whether the syntax elements
OK.

>       attrCert          AttributeCertificate, 
This seems to be a proposal to change the ASN.1 to make it more 
"elegant".  Making this change would in no way improve the protocol.  
Tim wants this document to be completed and has declared that changes to 
the protocol for "stylistic" reasons only are out of scope.

>This sentence seems superflous to me, since the syntax already says that.
The text is consistent, and reinforces the information that an ASN.1 
mechanic would glean from the syntax.  There isn't any harm in leaving 
it, is there?

>   (It can be guessed to a certain degree..)
The text currently says:

  The keyUsages item may indicate either the particular key usages that
  are required by the client or that the client does not require any
  particular key usage.

The anyKeyUsage is implicitly described by the "or that the client does 
not require any particular key usage".  This can be made more explicit 
if necessary.

>   What is the difference of having a NULL option and not having coded
If the client includes the keyUsages item in the validationPolicy in the 
request and specifies the anyKeyUsage choice (encoded as NULL), the 
client is indicating that it does not want validation to fail as a 
result of the contents of the keyUsage extension in the end certificate 
(or the absence of the keyUsage extension from the certificate).

>   key usage in a cert extension is a match.
If the client omits the keyUsages item from the the validationPolicy in 
the request, the client is indicating that validation should be 
performed using the default value for the validation policy specified in 
the validationPolRef item.

For example, a validation policy may, by default, require that the end 
certificate either not include a keyUsage extension or include a 
keyUsage extension with the digitalSignature bit set.  If the client 
specifies the use of this validation policy and omits the keyUsages item 
from the the validationPolicy in the request, then any end certificate 
that included a keyUsage extension without the digitalSignature bit set 
would be rejected.  If the client specifies the use of this validation 
policy but includes the keyUsages item with the anyKeyUsage choice, then 
the client is indicating that end certificates should be considered 
valid if they include keyUsage extensions with digitalSignature set to 0.

Acutally, in the validationPolicy structure, extendedKeyUsages is now 
defined as:

         extendedKeyUsages     [8] SEQUENCE OF KeyPurposeId OPTIONAL

Unlike in a certificate, there needed to be the option to include 
extendedKeyUsages in an SCVP request with an empty sequence.  The effect 
of including extendedKeyUsages in a request with an empty sequence is 
similar to the effect of including keyUsages with anyKeyUsage.  That is, 
the client is explcitly stating that it has no requirements with respect 
to extended key usages.

We will re-word the above sentence to more clearly convey this.

>   context of a TLS server," 
We will replace "Therefore" with "For example".

>   How are default values specified?
For the default validation policy, the server provides the default 
paramers in its validation policy response message.

In section 3.2.4, the client is specifying the validation policy under 
which it wants certificates to be validated.  The fields are OPTIONAL 
since the client only needs to specify values that are different from 
the default values for the validation policy specified in 
validationPolRef.  Since the client could opt to use the server's 
default values for all parameters, the parameter values are OPTIONAL in 
the request.

In the server's response message,  if the server is including the full 
validation policy in the response, then all of these fields MUST be 
populated.

>    policy, and how, in this case the policy contains a the fixed
In the validation policy response, the server indicates the default 
values it uses for the default validation policy.  The validation policy 
response also allows the server to list which validation policies it 
supports, but without providing any information about them.  In the 
certificate validation response, the server may indicate the parameter 
values that it used when processing a particular request (if the client 
set responseValidationPolByRef to FALSE in the request).

So, it seems to me that any other information about validation policies, 
including which default parameter values can be overridden and which can 
not must be provided through out of band means.  Either that or the 
client figures it out through trial and error :)

>   depending on a server defined rule.
Why do we need to say this explicitly?  It seems out of scope to me.  
The server may choose to support clients on whatever basis it wishes, 
including the contents of the requestorName field in the request and 
some authneticated identity.  We do not need to specify the variety of 
mechanisms that might be considered...

>   mean that the server MUST copy.
RFC 3379 states:

  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 last sentence in this paragraph is very clear that the server may 
omit the identifier in the response even when the client sends an 
authenticated request with and asserts an identity in the request.

>   as a GeneralNames (note the s), so taht a relay can add an id etc.
For relay, one uses requestorRef.  requestorRef allows for a sequence of 
identities, there is text in section 7 stating that the sequence needs 
to list all of the servers involved in processing the request, and there 
is a requirement that the response MUST copy the value of requestorRef 
from the request.

>   'signed' and not protected?
I agree that signed should be replaced with "authenticated".  The change 
from "signed" to "protected" was made at the last minute and this was 
overlooked.  The term "protected" would be inappropriate here since 
"protected" includes unauthenticated requests in which the client used 
an ephemeral Diffie-Hellman key.

>   not exist, and there is no indication who an octet string can be populated.
The entire paragraph reads:

  To prevent false loop detection, servers should use identifiers that
  are unique within their network of cooperating SCVP servers.  SCVP
  servers that support relay SHOULD populate this item with the DNS
  name of the server or the distinguished name in the server's
  certificate.  SCVP servers MAY choose other procedures for generating
  identifiers that are unique within their community.

As you state, a DNS name or DN may not be appropriate in all 
circumstances, which is why the document says "SHOULD" instead of 
"MUST".  The most important part is that identifiers be chosen "that are 
unique within their network of cooperating SCVP servers".  DNS names and 
DNs are just two types of identifiers that are likely to provide this 
property.

Since the only requirement is that the identifiers be "unique within 
their network of cooperating SCVP servers", there is no need to mandate 
how the identifiers are encoded within the OCTET STRING.

>   of another SCVP server in a response.
SCVP should not include a means to include the response of another SCVP 
server in a response.  An SCVP client sends a request to an SCVP server 
and gets a response from that server.  How the server derives the answer 
that it provides in the response is a local matter to the server.  The 
server may call upon the services of other SCVP servers in generating 
the response (i.e., the server may use SCVP relay), but that should be 
transparent to the reponse.  If the SCVP server were allowed to simply 
include the reponse from another SCVP server in its response, then this 
would impose more complexity on the SCVP client, which would need to 
parse responses that differed based on how the SCVP server derived the 
response.

>   please "align" the syntax.

A self asserted identity has a value to the client, as established in 
RFC 3379, when returned in the response.  Since this requirement was 
agreed upon by the WG and included in RFC 3379, we wanted to be sure the 
specification supported it.

Our reading of RFC 3379 does not support inclusion of a self asserted 
server identity.   Where the client cares about the identity, it can 
obtain that information from the security envelope.  Where no security 
envelope is available, the client is performing all security relevant 
processing locally, and does not need the server's identity.  Unlike the 
requestorName, this information is not returned in future messages, so 
it has no value to the server either. 

In short, a self asserted server identity has no security value, and we 
could not come up with other useful semantics  - we tried -  so we 
deleted it.

>       value                      ANY DEFINED BY wb } 
This is an "elegance" issue again, and we can make similar arguments 
about the encoding of Extensions, etc.  Changing from "OCTET STRING" to 
"ANY DEFINED BY wb" would be a stylistic change that would not improve 
the protocol.

>   the server response corresponds to the request."
We missed this one in the security requirements section.  Since 
non-cached responses may omit the requestRef item, this cannot be a 
MUST.  Matching the request message with the contents of requestRef is 
one option, but there are other ways for the client to verify that the 
response properly corresponds to the request.  So, we would propose 
changing the referenced text in the security considerations section. 

   Clients MUST verify that the response matches their orignal 
request.   Clients need to ensure that
   the server has performed the appropriate checks for the correct 
certificates under the requested
   validation policy for the specified validation time, and that the 
response includes the requested want
   backs and meets the client's freshness requirements.

It's a mouthful, but I believe this is the correct statement.  As 
restated, it should stay in the security considerations section.

>   Is there a comma missing behind the first word? if so, there are other places, too.
We'll ask our local tech editor, but I think that the comma is not 
required.  However, we should change the "many" to "may".

>   has no client identifiers etc IF the response is
We will delete "and ensure that the response cannot be a replay of a 
cached response obtained by another client".  This will require 
rewriting the remainder of the paragraph.  How about the following text:

   If an SCVP client is not operating on a network with good physical
   protection, it must ensure that there is integrity over the SCVP
   request-response pair.  The client can ensure integrity by using a
   protected transport such as TLS.  It can ensure integrity by using
   MACs or digital signatures to individually protect the request and
   response messages.

>   The last paragraph in 9 seems to me to belong elsewhere. 
Section 3.2.7 already contains advice on how to use the validationTime 
field.  Section 9 describes the security considerations associated with 
use of a historical validationTime.

>   The definition of validationTime does not say what a client can
Section 3.2.7 states:

  The validationTime provided MUST be a
  retrospective time since the server can only perform a validity check
  using the current time (default) or previous time.  A server can
  ignore the validationTime provided in the request if the time is
  within the clock skew of the server's current time.

So, validationTime is really only intended to be used when the specified 
time is in the past.  While the specified time could be in the recent 
past or distant past, there is nothing in section 3.2.7 or section 9 
that suggests otherwise.

>   I cannot parse that sequence of words.
This does need to be fixed.  It should say:

    A certificate may have been revoked after the time specified in 
validationTime,
    but the revocation notice may specify an invalidity date that 
precedes the
    validationTime.

>   and also the resulting CMS is not necessarily DER.
OK.  We will change DER to BER.  That change will probably need to occur 
in sections B.2, etc., as well.

>   "The lively debate"  may you consider to replace it by 'the lively or almost deadly debate' 
This predates my involvement, but you are correct.  Tim tells me we 
should add Paul to the list of guilty parties.

As to the debate, how much honesty do we really need?

---

From: Steven Legg <[email-masked]>
Date: Wed, 16 Feb 2005 10:52:16 +1100

Peter,

>        acRefs            [0] SEQUENCE SIZE (1..MAX) OF ACReference }

AUTOMATIC tagging would actually give you this:

    CertReferences ::= CHOICE {
      pkcRefs           [0] IMPLICIT SEQUENCE SIZE (1..MAX) OF PKCReference,
      acRefs            [1] IMPLICIT SEQUENCE SIZE (1..MAX) OF ACReference }

Similarly for the other two.

The IMPLICIT keyword is redundant in this case because
the module already uses IMPLICIT TAGS.

Regards,
Steven