Subject: Re: Comments to SCVP ID 17

From: "David A. Cooper" <[email-masked]>
Date: Thu, 03 Mar 2005 18:34:53 -0500

Wen-Cheng Wang wrote:

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

I am hesitant to change the name of the algorithm, since this would seem 
to require making changes to the ASN.1.  However, we can certainly 
re-word the first sentence of section 3.2.4.2.3 to remove the word 
"refinement".

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

OK.  I believe that it is very important that we get this document 
finished.  The -00 draft of SCVP was announced on June 28, 1999 and I 
know several people who are anxious to see this document completed.  We 
could argue forever about the best way to format the request, but the 
changes that you propose would have no effect on the information that 
the client could send to the server or that the server could return to 
the client.  It would just shuffle the bits.

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

I would not agree to changing the name from "default validation policy" 
to "basic validation policy" since SCVP does not define the policy.  
This is not the same as the "basic validation algorithm", since the 
"basic validation algorithm" is an actual algorithm.  That is, it is 
fully defined in SCVP.  SCVP has assigned an OID for the "default 
validation policy" but leaves it to each organization to define the 
validation policy that corresponds to that OID.  The only aspect of the 
"default validation policy" that SCVP defines is the "default validation 
algorithm".

I would have no objection to removing the requirement that the "default 
validation policy" MUST use the "basic validation algorithm" as its 
default algorithm, but I'd need some evidence that this change would 
satisfy working group consensus.  I also think there would still need to 
be some restrictions imposed.  For example, it would make no sense to 
use the "name validation algorithm" as a default validation algorithm 
since the "name validation algorithm" requires a query-specific 
parameter.  Since the client would need to include the validation 
algorithm in its request in order to specify the algorithm parameter 
(the subject name(s) to look for), the "name validation algorithm" would 
not make an appropriate default.  A default validation algorithm for a 
validation policy should either be one that does not have any parameters 
or only has parameters for which reasonable default values can be 
defined.  The "basic validation algorithm" satisfies this.  I would 
guess that a "proxy certificate validation algorithm" might satisfy this 
requirement as well, but it seems very unlikely that one would want to 
use that as part of an organizational default 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.

Yes.  As written, the client would need to include the validationPolicy 
item with validationPolRef specifying the default validation policy OID 
and with all other fields of the validationPolicy absent.  While this 
does add a few bits to the request over making this validation policy 
the default in an ASN.1 encoding sense, it doesn't actually make things 
more difficult for the organization since these are just implementation 
details that would be hidden from the organization.

I also asked one of the other editors about this and was told that this 
issue was debated and that a decision was made to require the request to 
explicitly specify the validation policy it wanted the server to use.  
So, I don't think this is something that I could change without evidence 
that there is a working group consensus in favor of the change.  Without 
that, I have to assume that the consensus is in favor of the current ASN.1.

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

I do not understand the objection.  A validation policy MUST specify a 
default validation algorithm.  So, if there is a one-to-one relationship 
between policies and algorithms, the client would NEVER have to specify 
the validation algorithm.

As the document is currently written, an SCVP server could mandate a 
one-to-one relationship between policies and algorithms.  If the server 
supported multiple algorithms, it could define multiple policies with 
each specifying a different default validation algorithm.  The server 
could also reject any requests that specified a non-default validation 
algorithm.  Removing validationAlg from the validationPolicy item would 
simply force this one-to-one relationship on all SCVP servers.  Since 
the inclusion of validationAlg as an optional parameter of the 
validationPolicy does not preclude SCVP servers from having a one-to-one 
relationship between policies and algorithms, I don't see any benefit to 
preventing others from implementing a one-to-many relationship if they 
choose to do so.

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

I would be against trying to add such a feature for two reasons.  First, 
there have been conflicting ideas about how certificate suspension 
should be interpreted.  In my opinion, if a certificate is suspended but 
then removed from suspension, then once it has been removed from 
suspension it can be treated as if it had always been good.  That is, 
one suspends a certificate if there is a question about the status of 
the certificate and then removes the certificate from suspension only if 
it turns out that there was no problem.  Since the conclusion was that 
there was no problem, there is no reason to suspect that the private key 
was misused.

I understand that some view suspension differently.  In their view, even 
if a certificate is removed from suspension any use of the private key 
while the certificate was suspended should be considered invalid.

Second, even if there was universal agreement that any use of the 
private key corresponding to a certificate while the certificate is 
suspended (on hold) is not legitimate, I don't believe that 
functionality you want could be implemented.  If the client provided the 
SCVP server with a certificate and a time interval, how could the server 
ensure that the certificate was never on hold during that time period?  
Remember that if a certificate is on hold (suspended) then the CA 
includes it on the CRL, but once the certificate is removed from hold it 
is simply no longer included on any subsequently issued CRLs.  Since no 
CRL issued after (or before) the certificate was removed from suspension 
would indicate that the certificate had ever been suspended, the SCVP 
server would only know that the certificate had been suspended if it 
looked at a CRL that was issued during the time that the certificate was 
on hold.

So, would the SCVP server be required to check every CRL issued in the 
interval [t2 ... t1] to verify that the certificate was not listed one 
any CRL during the interval?  If so, how could the SCVP server be sure 
that it really checked every CRL issued during that interval?  If not, 
how could the SCVP server be sure that the certificate had not been 
suspended at any point in the interval?

Dave

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Thu, 10 Mar 2005 11:56:07 +0800

(I do not know why the ML server won't accept my email in HTML
format. Therefore, I change the format to plaintext. This is my second
try to send this email. I am sorry if you receieve this email more than
once.)

David,

When I re-read section 3.2.4.2.1, I incidentally found
the term "identity certificates" undefined. I suggest
change it to "public key certificates".

Please also read my comments to your answers below.

>David A. Cooper wrote:
>>Wen-Cheng Wang wrote:
>>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".
>I am hesitant to change the name of the algorithm, since
>this would seem to require making changes to the ASN.1.  However,
>we can certainly re-word the first sentence of section 3.2.4.2.3
>to remove the word "refinement".

I am not sure whether the word "refinement" should be removed.
What I concern is that the name "name validation algorithm" is
misleading. At the first glance, I was under the impression that
it is an algorithm defining the string matching rules for
certificate name chaining, but finally I realized that it is
actually the basic validation algorithm supplemented with
checking the subject name of the target certificate.

>>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".
>finished.  The -00 draft of SCVP was announced on June 28, 1999 and
>I know several people who are anxious to see this document completed.
>We could argue forever about the best way to format the request, but
>the changes that you propose would have no effect on the information
>that the client could send to the server or that the server could
>return to the client.  It would just shuffle the bits.

As a matter of fact, the changes I propose is not just a shuffle
of the bits. The difference is that my proposal makes "subject name
checking" orthogonal to the "path validation algorithm". It is analogy
to that the "key usage checking" is orthogonal to the "path validation
algorithm". The current SCVP draft forces that "subject name checking"
can only be appended to the "basic validation algorithm", it is
impossible to adopt a more restricted validation algorithm and perform
"subject name checking" at the same time. For example, a validation
policy might want to adopt a path validation algorithm that additionally
checks criticality flags of several certificate extensions, while the
policy might also want to perform "subject name checking". With current
SCVP draft, it is impossible to do that. Obviously, keeping them
orthogonal will provide more flexibility.

This is another advantage of my proposal, in addition to the logicalness
of the protocol design I mentioned. Therefore, please think about this
advantage before you say "no" to the changes I proposed.

Well, I have done my best to try to convince you to improve the protocol
design. If the answer is still "no", then as I said I can livewith "the
basic validation algorithm with name validation" but of course it is a
pity we have no time to improve the protocol design further.

>>>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).
>>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".
>
>I would not agree to changing the name from "default validation
>policy" to "basic validation policy" since SCVP does not
>define the policy.  This is not the same as the "basic validation
>algorithm", since the "basic validation algorithm" is an actual
>algorithm.  That is, it is fully defined in SCVP.  SCVP has
>assigned an OID for the "default validation policy" but leaves
>it to each organization to define the validation policy that
>corresponds to that OID.  The only aspect of the "default validation
>policy" that SCVP defines is the "default validation algorithm".

Good clarification. How about adding this clarification to the
text? The clarification would be something like the following text:

A SCVP server MUST designate a validation policy as its default
validation policy. For alowing all SCVP clients to specify the
default validation policy of any SCVP server in an universal way,
SCVP defines the OID value id-svp-defaultValPolicy. If a SCVP
client specify the OID value id-svp-defaultValPolicy in its query,
it means that the client agrees the server to adopt its
default validation policy. Conforming implementations of SCVP
servers MUST recognize the OID value id-svp-defaultValPolicy. In
some cases, a SCVP server might assign a OID value other than
id-svp-defaultValPolicy as the reference to its default validation
policy. In other cases, a SCVP server might not assign any OID
value as the reference to its default validation policy. In any
case, once the SCVP client specify the OID value id-svp-defaultValPolicy
in its query, the SCVP server MUST perform it actions according
to its default validation policy.

Note that SCVP does not define the default validation policy
of any SCVP server. SCVP only assigns the OID value id-svp-defaultValPolicy
but leaves it to each SCVP server to define its default validation policy.

>I would have no objection to removing the requirement that the
>"default validation policy" MUST use the "basic validation algorithm" 
>as its default algorithm, but I'd need some evidence that this
>change would satisfy working group consensus.  I also think there
>would still need to be some restrictions imposed.  For example, it would
>make no sense to use the "name validation algorithm" as a default
>validation algorithm since the "name validation algorithm" requires
>a query-specific parameter.  Since the client would need to include
>the validation algorithm in its request in order to specify the
>algorithm parameter (the subject name(s) to look for), the "name
>validation algorithm" would not make an appropriate default.  A
>default validation algorithm for a validation policy should either be
>one that does not have any parameters or only has parameters for which
>reasonable default values can be defined.  The "basic validation
>algorithm" satisfies this.  I would guess that a "proxy certificate
>validation algorithm" might satisfy this requirement as well, but it
>seems very unlikely that one would want to use that as part of an

I do not think it is necessary to impose the restrictions you
mentioned on the candidate of a default validation algorithm. For
example, it is quite natural for a SCVP server that only serves
IPsecVPN devices to use "the basic validation algorithm with
name validation" as the default validation algorithm of its
default validation policy, because it is important to check
whether the target certificate contains proper DNS name, IP Address,
or Email Address. In such environment, there is nothing wrong to use
"the basic validation algorithm with name validation" as the default
validation algorithm and require the SCVP client (the VPN device) to
specify query-specific target name checking parameter in each query.
This example also show that SCVP should remove the requirement that the
default validation policy" MUST use the "basic validation algorithm"
as its default algorithm.

>>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.
>does add a few bits to the request over making this validation policy the
>default in an ASN.1 encoding sense, it doesn't actually make things more
>difficult for the organization since these are just implementation details
>that would be hidden from the organization.
>

I am not aware the consensus you mentioned. As far as I remenber, the
decision only requires that SCVP must allow the client to explicitly
specify a validation policy other than the default validation policy.
(Of course, the specified validation policy still need to be one that
supported by the SCVP server.) I do not think the decision require that
the client can not omit the validation policy reference in the query to
let the server adopt its default validation policy. The editors seemed
to over-interpret the decision.

Comparing to forcing the client to specify the OID value
id-svp-defaultValPolicy in each query, I am in favor of let the client
omit the validation policy reference in that query to express the intention
of agreeing the server to adopt its default validation policy, because
that is more economic.

However, if the clarification text for the default validation policy
OID is incorprated into the draft, I can live with the current ASN.1
syntax that defines validationPolicy as a non-optional item.

>>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,
>>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
>>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
>I do not understand the objection.  A validation policy MUST specify
>a default validation algorithm.  So, if there is a one-to-one relationship
>simply force this one-to-one relationship on all SCVP servers. Since the
>inclusion of validationAlg as an optional parameter of the validationPolicy
>does not preclude SCVP servers from having a one-to-one relationship between
>policies and algorithms, I don't see any benefit to preventing others
>from implementing a one-to-many relationship if they choose to do so.

Good clarification. I think it is important to clarify the relationship
between policies and algorithms. How about adding some text to clarify
that relationship between policies and algorithms can be one-to-one as
well as one-to-many?

In addition, since the one-to-many relationship has never been discussed
in the working group, I think it is better that other members of the
working group could express their opinions about whether it proper to
alow a one-to-many relationship between policies and algorithms. If the
working group consnesus say "yes", then I have no objection on having both
notions of "validation policy" and "validation algorithm" exist in SCVP.

>>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".
>there have been conflicting ideas about how certificate suspension should be
>interpreted.  In my opinion, if a certificate is suspended but then removed
>from suspension, then once it has been removed from suspension it can be
>treated as if it had always been good.  That is, one suspends a certificate if
>there is a question about the status of the certificate and then removes the
>certificate from suspension only if it turns out that there was no problem.  
>Since the conclusion was that there was no problem, there is no reason to
>suspect that the private key was misused.
>
>I understand that some view suspension differently.  In their view, even if
>a certificate is removed from suspension any use of the private key while
>the certificate was suspended should be considered invalid.

Exactly, this is my view of the validity of the use of the signing
private key while the certificate was suspended. In some countries, the
public-key certificate is issued with the citizen ID card. The law may
stipulate that if a citizen temporarily loses its civil rights
(e.g., due to crimial), then validity of the citizen ID card as well as
its certificate will be suspended until it regain its civil rights. In such
situation, any digital signature signed by the private key corresponding
to the suspended certificate should be considered invalid.

>Second, even if there was universal agreement that any use of the private
>key corresponding to a certificate while the certificate is suspended (on hold)
>is not legitimate, I don't believe that functionality you want could be
>implemented.  If the client provided the SCVP server with a certificate
>and a time interval, how could the server ensure that the certificate was
>never on hold during that time period?  Remember that if a certificate is
>on hold (suspended) then the CA includes it on the CRL, but once the
>certificate is removed from hold it is simply no longer included on any
>subsequently issued CRLs.  Since no CRL issued after (or before) the
>certificate was removed from suspension would indicate that the certificate
>had ever been suspended, the SCVP server would only know that the certificate
>had been suspended if it looked at a CRL that was issued during the time
>that the certificate was on hold.
>
>interval [t2 ... t1] to verify that the certificate was not listed one any
>CRL during the interval?  If so, how could the SCVP server be sure that it
>really checked every CRL issued during that interval?  If not, how could
>the SCVP server be sure that the certificate had not been suspended at any
>point in the interval?

Yes, in that situation the SCVP server might need to check several CRLs to
verify that the validity of certificate was not suspended during the interval
[t2...t1]. By checking the thisUpdate and nextUpdate items of CRLs and
knowing the CA's policy of issuing CRLs, the SCVP server can determine
whether it has checked all CRLs that need to be checked. It might be
hard but it is possible to implement this feature.

Wen-Cheng Wang