Re: Comments to SCVP ID 17

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

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


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

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

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
>organizational default validation policy.

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

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.

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

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

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

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