Subject: Comments on SCVP Draft 15

From: "Wen-Cheng Wang" <[email-masked]>
Date: Sat, 14 Aug 2004 00:45:58 +0800

Here is my comments on SCVP Draft 15:

1. Should it be called "certificate path" or "certification path"?
In SCVP Draft 15, sometimes it is called "certificate path",
otherwhile it is called "certification path"? Please be consistent.
I believe that "certification path" is the mainstream use.

2. Do we really need to keep the validationAlg item in the SCVP Query?
It is very confusing to have both the references of a validation policy
and a validation algorithm in the SCVP Query. There is a large
overlap between the concepts of a validation policy and a validation
algorithm. My understanding is that the validation algorithm is part
of the validation policy. That is, if one specifies a validation policy,
then it already implies a validation algorithm. Therefore, there is
no need to have a validationAlg item in the SCVP Query. If we
remove a validationAlg item from the SCVP Query, we can still
regard inputs such as trust anchors, user-initial-policy-set,
initial-policy-mapping-inhibit, initial-explicit-policy, or
initial-any-policy-inhibit as parameters to the validation policy.
(Be sure to make all these parameters optional, because the
validation might already implies all of them.)

3. Please consider to reorganize the SCVP Query data structure.
Especially, please consider to group parameters such as trust anchors,
user-initial-policy-set, initial-policy-mapping-inhibit,
initial-explicit-policy,
or initial-any-policy-inhibit into a sub-structure. (If I remember
correctly,
Denis had similar opinion.)

In my opinion, the current syntax for the SCVP Query data structure is
not only ugly but also very likely causes ambiguity. For example, it is
not clear if one can specify any parameters without specifing a
validation policy (or a validation algorithm). I believe that design
good data structures is an important part of designing a protocol.
A good protocol should have well-designed data structures. That
is the principle of data structures we learnt in the college computer
science
course, isn't it?

4. Parameters such as inhibitPolMap, requireExplicitPol, ignoreAnyPol,
IsCA should be OPTIONAL fields instead of being fields with a DEFAULT
value. In many cases, the client would like to OMIT these parameters. (For
example in the cases where the validation policy implies all the
parameters.)
If we let these parameters be  fields with a DEFAULT value, then there
is no way to distinct whether the client want to omit them or want to
use the default value. Besides, there is no consensus on the default value
for these parameters in this WG. Especially, I do not agree why the default
value for requireExplicitPol is FALSE, because I believe most serious
verifiers would require a explict certificate policy be set in all
certificates
in the path.

5. Please consider change the name of the parameters to align with
the names used in RFC 3280. Especially, I think 'ignoreAnyPol' is
a bad name. Please note that it is called 'initial-any-policy-inhibit'
in RFC 3280, and 'inhibit' and 'ignore' have quite different meaning.
Besides, since all these parameters are all 'initial' parameters, I
think it is better to keep the 'initial' in their names. Therefore, how
about change their name into 'initPolMapInhibit', 'initExplicitPol',
'initAnyPolInhibit', and 'initCertPolSet'.

6. Section 3.2.4
What if the client requests the server to include the full request in
the response but the server does not support that? Should the
server return a error to the client? If not, should the client reject the
response that only includes a hash of the request?

7. Section 3.2.5
What if the client requests the server to include the fullPolResponse
in the CVResponse but the server does not support that? Should
the server return a error to the client? If not, should the client reject
the response that does not include the fullPolResponse in the
CVResponse?

8. Section 3.2.10
What if the client requests the server to sign the response but the
server does not support that? Should the server return a error to
the client? If not, should the client reject the unsigned response?

9. Section 3.2.13
In additional to supporting validating a certificate relative to a
specific validatyTime or current time, it is also important to allow
the client to ask the server whether the target certificate
is valid during a "time period" (i.e., from time t1 to time t2).
In the cases where a client want to verify a long-term digital
signature which might be signed between time t1 and time t2,
the client needs make sure whether the signer's certificate
is valid from time t1 to time t2. Please take a look at RFC 3126
and the paper titled "General principles of digital signature"
(http://www.timestamp.cyber.ee/principles_en.pdf), then you will
see why it is important to determine whether the target certificate
is valid during a "time period".

10. Section 3.2.14
I do not see why user-initial-policy-set needs to be associated
with the trust anchor. This is not align with RFC 3280. Please
consider moving this parameter to the same level as other
parameters such as initial-policy-mapping-inhibit,
initial-explicit-policy, and initial-any-policy-inhibit.

=====
Wen-Cheng Wang

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Sat, 14 Aug 2004 00:59:12 +0800

Sorry! I forgot one comment in my last post.

11. Section 3.2.12.2
It is strange to have "Name Validation Algorithm" as a sub section of
of "3.2.12 validationAlg". Does it means a "Name Validation Algorithm"
itself can be regarded as a certificate validation algorithm?
My understanding is a Name Validation Algorithm is only a part of the
whole validation algorithm (or is an additional conditions to the validation
algorithm, it can not be used to replace the whole validation algorithm.
However, with the current syntax, if one specifies a Name Validation
Algorithm, then it can not specify the validation algorithm anymore. That
is unreasonable.

=====
Wen-Cheng Wang

---

From: "Trevor Freeman" <[email-masked]>
Date: Mon, 16 Aug 2004 11:26:11 -0700

* -----Original Message-----
* From: Wen-Cheng Wang [mailto:[email-masked]]
* Sent: Friday, August 13, 2004 9:46 AM
* To: [email-masked]; [email-masked]; Trevor Freeman
* Subject: Comments on SCVP Draft 15
* 
* Here is my comments on SCVP Draft 15:
* 
* 1. Should it be called "certificate path" or "certification path"?[TF]
Fixed]
* In SCVP Draft 15, sometimes it is called "certificate path",
* otherwhile it is called "certification path"? Please be consistent.
* I believe that "certification path" is the mainstream use.
* 
* 2. Do we really need to keep the validationAlg item in the SCVP
Query?[TF]  Already fixed and is now optional
* It is very confusing to have both the references of a validation
policy
* and a validation algorithm in the SCVP Query. There is a large
* overlap between the concepts of a validation policy and a validation
* algorithm. My understanding is that the validation algorithm is part
* of the validation policy. That is, if one specifies a validation
policy,
* then it already implies a validation algorithm. Therefore, there is
* no need to have a validationAlg item in the SCVP Query. If we
* remove a validationAlg item from the SCVP Query, we can still
* regard inputs such as trust anchors, user-initial-policy-set,
* initial-policy-mapping-inhibit, initial-explicit-policy, or
* initial-any-policy-inhibit as parameters to the validation policy.
* (Be sure to make all these parameters optional, because the
* validation might already implies all of them.)
* 
* 3. Please consider to reorganize the SCVP Query data structure. 
[TF] Data structures and ambiguity of syntax are two orthogonal issues.
The intent is to not artificially restrict the combinations of
arguments.
* Especially, please consider to group parameters such as trust anchors,
* user-initial-policy-set, initial-policy-mapping-inhibit,
* initial-explicit-policy,
* or initial-any-policy-inhibit into a sub-structure. (If I remember
* correctly,
* Denis had similar opinion.)
* 
* In my opinion, the current syntax for the SCVP Query data structure is
* not only ugly but also very likely causes ambiguity. For example, it
is
* not clear if one can specify any parameters without specifing a
* validation policy (or a validation algorithm). I believe that design
* good data structures is an important part of designing a protocol.
* A good protocol should have well-designed data structures. That
* is the principle of data structures we learnt in the college computer
* science
* course, isn't it?
* 
* 4. Parameters such as inhibitPolMap, requireExplicitPol, ignoreAnyPol,
* IsCA should be OPTIONAL
[TF] Fixed
 fields instead of being fields with a DEFAULT
* value. In many cases, the client would like to OMIT these parameters.
(For
* example in the cases where the validation policy implies all the
* parameters.)
* If we let these parameters be  fields with a DEFAULT value, then there
* is no way to distinct whether the client want to omit them or want to
* use the default value. Besides, there is no consensus on the default
value
* for these parameters in this WG. Especially, I do not agree why the
* default
* value for requireExplicitPol is FALSE, because I believe most serious
* verifiers would require a explict certificate policy be set in all
* certificates
* in the path.
* 
* 5. Please consider change the name of the parameters to align with
* the names used in RFC 3280. 
[TF] Fixed
Especially, I think 'ignoreAnyPol' is
* a bad name. Please note that it is called 'initial-any-policy-inhibit'
* in RFC 3280, and 'inhibit' and 'ignore' have quite different meaning.
* Besides, since all these parameters are all 'initial' parameters, I
* think it is better to keep the 'initial' in their names. Therefore,
how
* about change their name into 'initPolMapInhibit', 'initExplicitPol',
* 'initAnyPolInhibit', and 'initCertPolSet'.
* 
* 6. Section 3.2.4
* What if the client requests the server to include the full request in
* the response but the server does not support that? Should the
* server return a error to the client? 
[TF] The server should return an error. I have added text to clarify
that success is returned when the server fully complies with the
request.
If not, should the client reject the
* response that only includes a hash of the request?
* 
* 7. Section 3.2.5
* What if the client requests the server to include the fullPolResponse
* in the CVResponse but the server does not support that? Should
* the server return a error to the client? If not, should the client
reject
* the response that does not include the fullPolResponse in the
* CVResponse?[TF]  fixed (see above)
* 
* 8. Section 3.2.10
* What if the client requests the server to sign the response but the
* server does not support that? Should the server return a error to
* the client? If not, should the client reject the unsigned response?
[TF] fixed (see above)
* 
* 9. Section 3.2.13
* In additional to supporting validating a certificate relative to a
* specific validatyTime or current time, it is also important to allow
* the client to ask the server whether the target certificate
* is valid during a "time period" (i.e., from time t1 to time t2).
* In the cases where a client want to verify a long-term digital
* signature which might be signed between time t1 and time t2,
* the client needs make sure whether the signer's certificate
* is valid from time t1 to time t2. Please take a look at RFC 3126
* and the paper titled "General principles of digital signature"
* (http://www.timestamp.cyber.ee/principles_en.pdf), then you will
* see why it is important to determine whether the target certificate
* is valid during a "time period".
[TF] That can be supported by a validation algorithm.
* 
* 10. Section 3.2.14
* I do not see why user-initial-policy-set needs to be associated
* with the trust anchor. This is not align with RFC 3280. Please
* consider moving this parameter to the same level as other
* parameters such as initial-policy-mapping-inhibit,
* initial-explicit-policy, and initial-any-policy-inhibit.
[TF] Fixed
* 
* =====
* Wen-Cheng Wang

---

From: "Trevor Freeman" <[email-masked]>
Date: Mon, 16 Aug 2004 14:45:05 -0700

* -----Original Message-----
* From: Wen-Cheng Wang [mailto:[email-masked]]
* Sent: Friday, August 13, 2004 9:59 AM
* To: [email-masked]; [email-masked]; Trevor Freeman
* Subject: Re: Comments on SCVP Draft 15
* 
* Sorry! I forgot one comment in my last post.
* 
* 11. Section 3.2.12.2
* It is strange to have "Name Validation Algorithm" as a sub section of
* of "3.2.12 validationAlg". Does it means a "Name Validation Algorithm"
* itself can be regarded as a certificate validation algorithm?
* My understanding is a Name Validation Algorithm is only a part of the
* whole validation algorithm (or is an additional conditions to the
* validation
* algorithm, it can not be used to replace the whole validation
algorithm.
* However, with the current syntax, if one specifies a Name Validation
* Algorithm, then it can not specify the validation algorithm anymore.
That
* is unreasonable.
[TF] I have added text to clarity that all validation algorithm is be a
superset of the basic(was default but that name is causing
confusion)algorithm functionality.
* 
* =====
* Wen-Cheng Wang
* 
* ----- Original Message -----
* From: "Wen-Cheng Wang" <[email-masked]>
* To: <[email-masked]>; <[email-masked]>;
* <[email-masked]>
* Sent: Saturday, August 14, 2004 12:45 AM
* Subject: Comments on SCVP Draft 15
* 
* 
* > Here is my comments on SCVP Draft 15:
* >
* > 1. Should it be called "certificate path" or "certification path"?
* > In SCVP Draft 15, sometimes it is called "certificate path",
* > otherwhile it is called "certification path"? Please be consistent.
* > I believe that "certification path" is the mainstream use.
* >
* > 2. Do we really need to keep the validationAlg item in the SCVP
Query?
* > It is very confusing to have both the references of a validation
policy
* > and a validation algorithm in the SCVP Query. There is a large
* > overlap between the concepts of a validation policy and a validation
* > algorithm. My understanding is that the validation algorithm is part
* > of the validation policy. That is, if one specifies a validation
policy,
* > then it already implies a validation algorithm. Therefore, there is
* > no need to have a validationAlg item in the SCVP Query. If we
* > remove a validationAlg item from the SCVP Query, we can still
* > regard inputs such as trust anchors, user-initial-policy-set,
* > initial-policy-mapping-inhibit, initial-explicit-policy, or
* > initial-any-policy-inhibit as parameters to the validation policy.
* > (Be sure to make all these parameters optional, because the
* > validation might already implies all of them.)
* >
* > 3. Please consider to reorganize the SCVP Query data structure.
* > Especially, please consider to group parameters such as trust
anchors,
* > user-initial-policy-set, initial-policy-mapping-inhibit,
* > initial-explicit-policy,
* > or initial-any-policy-inhibit into a sub-structure. (If I remember
* > correctly,
* > Denis had similar opinion.)
* >
* > In my opinion, the current syntax for the SCVP Query data structure
is
* > not only ugly but also very likely causes ambiguity. For example, it
is
* > not clear if one can specify any parameters without specifing a
* > validation policy (or a validation algorithm). I believe that design
* > good data structures is an important part of designing a protocol.
* > A good protocol should have well-designed data structures. That
* > is the principle of data structures we learnt in the college
computer
* > science
* > course, isn't it?
* >
* > 4. Parameters such as inhibitPolMap, requireExplicitPol,
ignoreAnyPol,
* > IsCA should be OPTIONAL fields instead of being fields with a
DEFAULT
* > value. In many cases, the client would like to OMIT these
parameters.
* (For
* > example in the cases where the validation policy implies all the
* > parameters.)
* > If we let these parameters be  fields with a DEFAULT value, then
there
* > is no way to distinct whether the client want to omit them or want
to
* > use the default value. Besides, there is no consensus on the default
* value
* > for these parameters in this WG. Especially, I do not agree why the
* default
* > value for requireExplicitPol is FALSE, because I believe most
serious
* > verifiers would require a explict certificate policy be set in all
* > certificates
* > in the path.
* >
* > 5. Please consider change the name of the parameters to align with
* > the names used in RFC 3280. Especially, I think 'ignoreAnyPol' is
* > a bad name. Please note that it is called
'initial-any-policy-inhibit'
* > in RFC 3280, and 'inhibit' and 'ignore' have quite different
meaning.
* > Besides, since all these parameters are all 'initial' parameters, I
* > think it is better to keep the 'initial' in their names. Therefore,
how
* > about change their name into 'initPolMapInhibit', 'initExplicitPol',
* > 'initAnyPolInhibit', and 'initCertPolSet'.
* >
* > 6. Section 3.2.4
* > What if the client requests the server to include the full request
in
* > the response but the server does not support that? Should the
* > server return a error to the client? If not, should the client
reject
* the
* > response that only includes a hash of the request?
* >
* > 7. Section 3.2.5
* > What if the client requests the server to include the
fullPolResponse
* > in the CVResponse but the server does not support that? Should
* > the server return a error to the client? If not, should the client
* reject
* > the response that does not include the fullPolResponse in the
* > CVResponse?
* >
* > 8. Section 3.2.10
* > What if the client requests the server to sign the response but the
* > server does not support that? Should the server return a error to
* > the client? If not, should the client reject the unsigned response?
* >
* > 9. Section 3.2.13
* > In additional to supporting validating a certificate relative to a
* > specific validatyTime or current time, it is also important to allow
* > the client to ask the server whether the target certificate
* > is valid during a "time period" (i.e., from time t1 to time t2).
* > In the cases where a client want to verify a long-term digital
* > signature which might be signed between time t1 and time t2,
* > the client needs make sure whether the signer's certificate
* > is valid from time t1 to time t2. Please take a look at RFC 3126
* > and the paper titled "General principles of digital signature"
* > (http://www.timestamp.cyber.ee/principles_en.pdf), then you will
* > see why it is important to determine whether the target certificate
* > is valid during a "time period".
* >
* > 10. Section 3.2.14
* > I do not see why user-initial-policy-set needs to be associated
* > with the trust anchor. This is not align with RFC 3280. Please
* > consider moving this parameter to the same level as other
* > parameters such as initial-policy-mapping-inhibit,
* > initial-explicit-policy, and initial-any-policy-inhibit.
* >
* > =====
* > Wen-Cheng Wang
* >