Re: Comments to SCVP ID 17

["David A. Cooper" <david.cooper@xxxxxxxx>]

Wen-Cheng Wang wrote:

Dear list,

 

The following are my comments to SCVP 17.

 

Wen-Cheng Wang

 

1. Typo in the last sentence of the last second
   paragraph of page 67:

 

     "Therefore in these situations use of a URI
      many be more attractive."
   ->
     "Therefore, in these situations use of a URI
      may be more attractive."

 

   ("many be" -> "may be")

Done.

2. I suggest to let the version filed of request and
   response messages default to v1(1).
   That is:

 

      cvRequestVersion        INTEGER,
   ->
      cvRequestVersion        INTEGER DEFAULT v1(1),

 

      cvRsponseVersion        INTEGER
   ->
      cvRsponseVersion        INTEGER DEFAULT v1(1),

 

      vpRequestVersion        INTEGER,
   ->
      vpRequestVersion        INTEGER DEFAULT v1(1),

 

      vpRsponseVersion        INTEGER
   ->
      vpRsponseVersion        INTEGER DEFAULT v1(1),

 

   By doing this, the DER code of every request and
   response message will save 3 bytes. I believe that
   the SCVP version will stay at v1 for a long time,
   asigning default value will allow clients and
   servers do not bother to send the version number
   in their requests and responses.

 

   Note that when a field become a field with DEFAULT
   value, it might need change to a tagged field.

We set a DEFAULT value wherever we could do so without adding any more explicit tagging.  So, DEFAULT version numbers were set in CVRequest and ValPolRequest, but not CVResponse or ValPolResponse.

3. The tagging rule for ASN.1 syntax is odd. I list
   the following as oddness:

 

      (1) In the "ValidationPolicy" data type, the tag
          numbers skip from [4] to [6]. (There is no
          tag [5].)
      (2) In the "CVResponse" data type, the tag numbers
          skip from [3] to [5]. (There is no tag [4].)

 

   I know that the editors of SCVP ID do not like to
   discuss ASN.1 stylistic change, but the fix is simple.

Fixed.

4. I notice that SCVP 17 newly invented the term
   "end certificate". Personally, I understand what
   you mean by "end certificate" because I have been
   tracking this ID for a long time. However, I am
   worrying that using the term "end certificate"
   might cause confusion because it might have
   different interpretation for different direction
   of path construction (forward or reverse). As a
   technical spec, SCVP should be more precise in
   adopting technical term. Therefore, I suggest to
   use the term "target certificate" instead, not only
   for eliminating possible confucion but also for
   keeping alignment with RFC 3379.

 

   In addition, to make a more strong connection between
   the term "target certificate" and the field of the
   query message, I further suggest to change the field
   name "queriedCerts" in the "Query" data type into
   "targetCerts". Of course, related statements that
   explain or refer to that field shoul also be modified
   in response to the changing of the filed name.

The term "end certificate" is used in X.509 to refer to the final certificate in a certification path (which is usually, but not always, an end entity certificate).  However, it appears that the term was never used in RFC 3280.  On the other hand, I could only find one use of the term "target certificate" in RFC 3379, and it is never defined.  So it is not clear that "target" would be any better than "end".  But, I added a definition of "end certificate" after its first use.

5. After reading SCVP 17, I finally understand the
   purpose of name validation algorithm. Before SCVP 17,
   I always thought it is used to specify the name
   matching rule (binary matching or X.500 name matching)
   during certificate chaining. Now I understand that it
   is use to specify the request for checking subject
   name of the "target certificate". If it is so, I think
   it is unreasonalbe to say:

 

     "The name validation is a refinement of the basic
      validation algorithm"

 

   The basic validation algorithm is an algorithm
   specifying conditions and rules for validating
   the whole certification path. In terms of RFC 3379,
   the basic validation algorithm specifies
   "certification path requirements". On th contrary,
   the name validation algorithm only specifies the
   request for checking subject name of the "target
   certificate". In terms of RFC 3379, the so-called
   name validation algorithm is simply one of the
   "end-entity certificate specific requirements".
   (Now I prefer to call them "target certificate
    specific requirements".)
   It is much like "keyUsages" and "extendedKeyUsages"
   checks, which are also "target certificate
   specific requirements". To make the protocol
   more resonable and aligned with RFC 3379, I
   suggest to take "name validation algorithm" out
   of section 3.2.4.2 and group it with "keyUsages"
   and "extendedKeyUsages", because they all belong
   to the category of "target certificate specific
   requirements".

I believe that there is still a misunderstanding.  The name validation algorithm does not *only* specify checking the subject name in the end (or target) certificate.  When the name validation algorithm is specified, the server MUST perform all of the checks required by the Basic Validation Algorithm *in addition to* checking the subject name in the end (target) certificate.  That is why the name validation algorithm is referred to as a refinement of the basic validation algorithm.  As is stated in section 3.2.4.2.1 (Basic Validation Algorithm): "That is, none of the validation requirements in the basic algorithm may be omitted from any newly defined validation algorithms."

While name validation could have been implemented in a similar manner to the verification of keyUsage and extendedKeyUsage, specifying name validation as a different validation algorithm works just as well.  Changing the ASN.1 to group name checking with keyUsages and extendedKeyUsages would simply be a styistic change that would have no real effect on the protocol.  While Tim and I made changes to the ASN.1 to clean up the tagging since so many people insisted that they wanted the change, we really need to get this document finished, and so I think we should try to avoid making changes to the protocol that are unnecessary.

6. The current text of SCVP 17 tries to define a
   "global" default validation policy and tries to
   enforce all implementation to support that default
   validation policy. This notion of "default validation
   policy" does not align with the general understanding
   of "default validation policy".
  
   The default validation policy defined in SCVP 17 is
   actually simply a "basic" validation policy which
   adopts the basic path validation algorithm defined
   in RFC 3280, it is odd to specify it as the "global"
   default validation policy. The general understanding
   of "default validation policy" is the default one
   among the organizational validation policies.
   
   I suggest to change term "default validation policy"
   to "basic validation policy" to avoid confussion.
   With this distinction of the notion of "default
   validation policy" and the notion of the predefined
   "basic validation policy, we can clearly say that

 

     The SCVP server can define multiple vlidation
     policies and nominate one as its default
     policy. If the client does not select a
     validation policy in its request, the server
     will use the default validation policy.

 

     The SCVP server MAY list the "basic validation
     policy" defined in this specification as one
     of its supported validation policies. The SCVP
     server MAY select the "basic validation
     policy" as its default policy.

 

   Please note that I also suggest that the
   "validationPolicy" field in the "Query" data type
   should be changed to be an optional field. This
   allow the client to ommit the selection of
   the validation policy in its request and simply
   let the server use its default policy.

The "default validation policy" really is the default validation policy for the organiztion; it is not a "global" validation policy.

Section 3.2.4.1.1 states that the default validation policy MUST use the basic validation algorithm as its default validation algorithm, but each individual SCVP server is free to set the default values for all other parameters (e.g., trust anchors) of the validation policy as it wishes.  The server specifies the default parameter values that it uses in its default validation policy in its validation policy response (in the defaultPolicyValues item).

So, if a client wants to use the organizational default validation policy, it simply specifies the OID for the default validation policy.  Rather than make the validationPolicy field OPTIONAL, the editors chose to define an OID for the default validation policy.  The effect is the same, it is just a slightly different encoding.  This was done before I became involved with SCVP, but it may have been done in order to make it possible for the server to reject requests that specify the default policy OID (the server can simply not list that OID in the validationPolices item of its validation policy response.

7. The title of section 1.3 is "validation Policies", but
   in the middle of that section it mentions:

 

     "The inputs to the basic certification path processing
      algorithm used by SCVP are defined by [PKIX-1] in
      section 6.1.1 and comprise:
    
        Certificate to be validated (by value or by reference);
    
        Validation time;
    
        Set of Trust Anchors (by value or by reference);
    
        The initial policy set;
    
        Initial inhibit policy mapping setting;
    
        Initial inhibit anyPolicy setting; and
    
        Initial require explicit policy setting."

 

   Isn't it be odd to define inputs to "validation
   algorithm" in a section titled "validation
   policies"?

 

   It reveals that even the authors of SCVP have no
   good distinction between the notion of "validation
   policy" and the notion of "validation algorithm",
   no to say an implementator who try to implement SCVP.

 

   Even several reviewers (for example Denis and I)
   clearly express that the notion of "validation algorithm"
   is redundant to the notion of "validation policy"
   and can be removed, how strange it is that the
   authors always to reject the suggestions.

 

   Now, even with SCVP 17 which authors says "the text
   for validation policies, validation algoriothms and
   name validation algorithms has all been revised for
   clarity, the distinction still vague.

 

   I sugest to remove the notion of "validation
   algorithm" from SCVP, and change the text to:

 

     "The certification path specific parameters to the
      basic validation policy defined by this specification
      are defined by [PKIX-1] in its section 6.1.1 and
      comprise:
    
        Certificate to be validated (by value or by reference);
    
        Validation time;
    
        Set of Trust Anchors (by value or by reference);
    
        The initial policy set;
    
        Initial inhibit policy mapping setting;
    
        Initial inhibit anyPolicy setting; and
    
        Initial require explicit policy setting."

I still believe that it is useful to have both a validation policy and a validation algorithm.  You suggest that it is odd for the validation policy to specify the inputs to the validation algorithm, but I disagree.  The basic validation algorithm, for example, is simply an algorithm.  It specifies the rules for creating a set of outputs from a set of inputs.  The validation algorithm does not, however, specify the *values* for the inputs.  The validation policy specifies not only what algorithm should be used to determine whether the certificate is valid, but also the *values* for the inputs to the algorithm (e.g., trust anchors, user initial policy set, etc.).

If the validation algorithm were removed as a parameter then it would not be possible to specify the use of an algorithm other than the basic validation algorithm for determining whether a certificate were valid given the other inputs specified by the policy.

At the moment, there are only two validation algorithms defined for use with SCVP and as you stated, subject name checking could have been implemented with defining a new validation algorithm.  However, including the validation algorithm as a parameter of the validation policy allows for other validation algorithms to be specified in the future.  For example, someone could define a validation algorithm that verifies whether a certificate is a valid proxy certificate according to RFC 3820.  This proxy certificate algorithm could either be used as the default validation algorithm for a validation policy or it use could be specified by the client in the request.  So, a client could, for example, specify the use of the default validation policy, but with the proxy certificate validation algorithm.  The result would be that the organizational default values would be used for the inputs (trusts anchors, user intial policy set, etc.), but the certificate(s) would be validated as a proxy certificate (RFC 3820) rather than being validated using the normal validation algorithm (RFC 3280).

8. In th end of section 1.3, it says:

 

   "The basic certification path processing algorithm
    also supports the following parameters, which are
    defined in [PKIX-1] section 4:
   
     The usage of the key contained in the certificate
     (e.g., key encipherment, key agreement, signature); and
     
     Other application-specific purposes for which the
     certified public key may be used."

 

   Since "the basic certification path processing algorithm"
   is the algorithm defined in section 6 of RFC 3280, it is
   not proper to say that "the certification path processing
   algorithm" supports parameters related to checking
   key usages and extended key usage. Wee all know that
   the lgorithm defined in section 6 of RFC 3280 does not
   support these two kinds of parameters.

 

   I think the text will be more proper if it is changed to:

 

   "The basic validation policy defined by this specification
    also supports target certificate specific parameters
    for specifying the following checks:
   
     The key usages specified in the target certificate
     (e.g., key encipherment, key agreement, signature)
     are acceptable;
     
     The extended key usages specified in the target
     certificate are acceptable; and

 

     The subject name or the subject alternative name
     specified in the certificate meet the
     application-specific requirement."

 

   (Note that I move the name validation requirement here.)

 

   Again, this is a sign that the distinction between
   the notion of "validation policy" and the notion of
   "validation algorithm" in SCVP 17 is still vague.

As noted above, it would not be correct to say that "the basic validation policy ... also supports...."  An algorithm supports certain parameters, since the algorithm specifies how the outputs are derived from the inputs.   So, the algorithm supports the parameters and the policy specifies values for the parameters.

Hopefully the discussion above along with the example of a possible alternative validation algorithm helps to explain the distinction between the validation algorithm and validaiton policy.

9. I give the following comment before but get no response,
   so here I raise it again.

 

   There are situations where the certificate-using
   applications need to check whether a certificate
   was valid during a period of time, not only validate
   it with respect to a specific moment. For example,
   an application verifying an archived long-term
   signature might need to check whether a certificate
   was valid during a period of time in which the
   signature was generated. Therefore, I suggest to
   extend the structure of the "validationTime" field
   of the "Query" data type to support this. A CHOICE
   between a moment and a period of time is sufficient.

I have not been involved with SCVP for very long, but I have not heard this one before and it is not clear why it is needed.  If you specify a validationTime equal to "end" (as defined in your ASN.1 below) and the response is that the certificate is not valid, then it was not valid.  If the certificate was valid at time "end", then there must be a valid certification path in which all of the certificates were valid at time "end".  If the certificates were valid at time "end", then they could not have been revoked before time "end".  So, the only way the certification path could have been invalid at any point between "start" and "end" is if "start" preceded the notBefore time in any of the certificates in the certification path.  If this is a concern, you could send a second query with a validationTime of "start".  If the server reports that the certificate is valid at both "start" and "end", then it seems that one can safely conclude that the certificate was valid during the entire interval.

Under what circumstances would you expect the server to indicate that the certificate was valid at "start" and "end", but invalid for the period "[start ... end]"?  If there were any such circumstances, why would the client need to know this?

Even if the feature is needed, is there any reason that it could not be added through the extensions mechanism after the base standard has been completed?

To summarize the above comments, the "Query" needs to
be changed to the following:

 

(Of course, the related text in the ID should also be
changed. However, at this moment, I simply use the
following syntax to demonstrate my idea to editors
and the list. If my proposal is accepted, then I
will be happy to help revising the related text.)

 

Query ::= SEQUENCE {
     targetCerts              CertReferences,
     checks                   CertChecks,
     wantBack                 WantBack,
     validationPolicy     [2] ValidationPolicy OPTIONAL,
     responseFlags        [3] ResponseFlags OPTIONAL,
     serverContextInfo    [4] OCTET STRING OPTIONAL,
     validationTime           ValidationTime OPTIONAL,
     intermediateCerts    [7] CertBundle OPTIONAL,
     revInfos             [8] RevocationInfos OPTIONAL,
     producedAt           [9] GeneralizedTime OPTIONAL,
     queryExtensions      [10] Extensions OPTIONAL }

 

ValidationTime ::= CHOICE {
     moment               [5] GeneralizedTime,
     period               [6] ValidationPeriod}

 

ValidationPeriod ::= SEQUENCE {
     start                GeneralizedTime,
     end                  GeneralizedTime}

 

ValidationPolicy ::= SEQUENCE {
     validationPolRef               ValidationPolRef,
     pathSpecificParams         [1] PathSpecificParams OPTIONAL,
     targetCertSpecificParams   [2] TargetCertSpecificParams OPTIONAL}

 

PathSpecificParams ::= SEQUENCE {
     userPolicySet          [1] SEQUENCE SIZE (1..MAX) OF OBJECT
                                  IDENTIFIER OPTIONAL,
     inhibitPolicyMapping   [2] BOOLEAN OPTIONAL,
     requireExplicitPolicy  [3] BOOLEAN OPTIONAL,
     inhibitAnyPolicy       [4] BOOLEAN OPTIONAL,
     trustAnchors           [6] TrustAnchors OPTIONAL}

 

targetCertSpecificParams ::= SEQUENCE {
     keyUsages              [1] KeyUsages OPTIONAL,
     extendedKeyUsages      [2] SEQUENCE OF KeyPurposeId OPTIONAL,
     nameValidation         [3] NameValidationAlgParms OPTIONAL}

 

NameValidationAlgParams ::= SEQUENCE {
     nameCompAlgId          OBJECT IDENTIFIER,
     validationNames        GeneralNames }

 

-- SCVP Validation Policy and Algorithm Identifiers
   
id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
          dod(6) internet(1) security(5) mechanisms(5) pkix(7) 19 }

 

-- SCVP Basic Validation Policy Identifier
   
id-svp-basicValPolicy OBJECT IDENTIFIER ::= { id-svp 1 }
 
-- SCVP Basic Validation Policy Errors
   
id-bvpe OBJECT IDENTIFIER ::= id-svp-basicValPolicy
   
id-bvpe-expired              OBJECT IDENTIFIER ::= { id-bvae 1 }
id-bvpe-not-yet-valid        OBJECT IDENTIFIER ::= { id-bvae 2 }
id-bvpe-wrong-anchor         OBJECT IDENTIFIER ::= { id-bvae 3 }
id-bvpe-invalid-key-usage    OBJECT IDENTIFIER ::= { id-bvae 10 }
id-bvpe-invalid-purpose      OBJECT IDENTIFIER ::= { id-bvae 11 }
id-bvpe-revoked              OBJECT IDENTIFIER ::= { id-bvae 16 }
   
-- SCVP Name Validation Algorithm Identifier

 

-- SCVP Name Validation Algorithm DN comparison algorithm
   
id-nva-dnCompAlg   OBJECT IDENTIFIER ::= { id-svp 4 }
   
-- SCVP Name Validation Algorithm Errors
   
id-nvae OBJECT IDENTIFIER ::= id-svp-nameValAlg
   
id-nvae-name-mismatch          OBJECT IDENTIFIER ::= { id-nvae 1 }
id-nvae-no-name                OBJECT IDENTIFIER ::= { id-nvae 2 }
id-nvae-unknown-alg            OBJECT IDENTIFIER ::= { id-nvae 3 }
id-nvae-bad-name               OBJECT IDENTIFIER ::= { id-nvae 4 }
id-nvae-bad-name-type          OBJECT IDENTIFIER ::= { id-nvae 5 }
id-nvae-mixed-names            OBJECT IDENTIFIER ::= { id-nvae 6 }