Re: Comments to SCVP ID 17

["Wen-Cheng Wang" <wcwang@xxxxxxxxxx>]

Dear List,

I am sorry if you received this mail more than once. The
PKIX ML server seemed to have problem to accept my
email. This is my fifth trial to send this email to PKIX ML.
 
Please see my comments in-line.
  
David A. Cooper wrote:
>Sent: Saturday, February 19, 2005 6:08 AM
>Subject: Re: Comments to SCVP ID 17
>
>
>Wen-Cheng Wang wrote: 
>>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.

I can live with that, although I prefer to all the version numbers
omittable in both requests and responses.

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

Again, I can live with that, although I prefer the term "target certificate".
Please also not that the "Certification Path Building" ID also use the term
"target certificate".

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

Believe me, I understand the refinement relationship. I simply feel that
it is odd to say a "name validation algorithm" is a refinement of a path
validation algorithm. I believe that most people will not associate
path validation with the term "name validation". Maybe you should name
it "the basic validation algorithm with name checking".

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

I still believe that it is better to group "name checking", "key usage checking"
and "extended key usage checking" into the category of "end/target certificate
requirements". This is not a simply a stylistic change. It is a matter of logicalness
of the protocol design. However, if we are really running out of time, I can live
with "the basic validation algorithm with name validation".

>>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).
>Basically, I agree that the validation algorithm adopt by the server MUST be based
>on the basic path validation algorithm defined by RFC 3280 or its descendant, but
>it is not necessary to force every organization to accept that "basic path validation
>algorithm" as the alogorithm of their organizational default validation policy. What
>if the organization want to adopt an extended/refined version of  path validation
>algorithm in their organizational default validation policy? To allow organizations
>to define their own organizational default validation policy, I still think it is better to
>name the validation policy defined by the SCVP spec as "basic validation policy".
>It is analogy to that RFC 3280 named its path validation algorithm as "basic path
>validation algorithm" (not "default validation algorithm").
 
The point is that SCVP should give freedom to organizations to define their own
organizational default validation policy. Nevertheless, SCVP could ask organization
to adopt PKIX-compliant validation algorithm no mater if they define their own
organizational default validation policy.
 
I understand that it is good if SCVP defines a validat policy and its OID for the
convenience of organization unwilling/unable to define their own validat policy/OID.
However, it should not be "the default validation policy". It should simply be "a basic
validation policy".

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

I know that this is the way SCVP letting organizations overwrite the globally
defined "default validation policy". However, in the situation where an organization
only supports one validation policy and naturally uses that validation policy as its
default organizational validation policy, isn't it superfluous to request all its clients
to specify the organizational validation policy OID? In such situation, clients usually
want to omit the validation polict item in their request and let the server use its
default policy. With current syntax, it is impossible to do that.

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

The question is what is the relationship between "validation policy" and
"validation algorithm"? Will it be normally one-to-one relationship or
one-to-many relationship? By one-to-one relationship, I mean one validation
policy can only support one validation algorithm. By one-to-many relationship,
I mean one validation policy can support multiple validation algorithms.
In one-to-many relationship, a client might need to select one of the multiple
validation algorithms supported by the validation policy it specifies in the request.
In one-to-one relationship, since the validation policy implies the validation
algorithm, it is superfluous to ask the client to specify both of them.
 
I believe that it is easier to adopt one-to-one relationship model, let one
validation policy imply a validation algorithm, and remove the validation
algorithm item from the syntax. With one-to-one relationship model, if
an organization want to support multiple validation algorithm, they can
define multiple validation policies and let each imply one validation algorithm
respectively.
 
The point is a validation policy can imply a validation algorithm, and therefore
the notion of validation algorithm can be removed from SCVP.
 
>>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.

As commented above.

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

The current SCVP syntax and semantics only support validating certificates against
a retrospective moment. Please not that it is not the same to say "a certificate is
valid at time t1" as to say "a certificate is valid before time t1", because the validity of
the certificate could be suspended and then resumed before time t1. It is certainly
different with "a certificate is valid from time t2 to time t1".


>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?
In some situations, it is not possible to determine the time (the moment) when
the private key was used to sign a signature. For example, to verify an archived
long-term signature, it might not be possible to determine the retrospective time
when the sigature is signed. Fortunately, the archived long-term signature might
be associated with content time-stamp and signature time-stamp for helping
in validating its validity. Suppose its content time-stamp was generated at time t2 and
its signature time-stamp was generated at time t1, then the verifier can conclude that
the signature must be signed between time t2 and time t1. To validate the archived
long-term signature, the verifier must make sure that the signer's certificate is valid
from time t2 to time t1.
 
You might be interested to read the paper at http://www.timestamp.cyber.ee/principles_en.pdf
to get the idea why the signer's certificate needed to be valid during the time period in which
the archived long-term signature was signed.

>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?
 
Yes, the feature certainly could be added through the extensions mechanism.
I simply think it is important for SCVP to support validating certificates
against a time period (not just a a retrospective moment), therefore I
suggest to add it now.
 
Wen-Cheng Wang