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
|