Subject: SCVP 16 Comments

From: "Seth Hitchings" <[email-masked]>
Date: Wed, 1 Dec 2004 12:29:14 -0500

Hi all,

My company, CoreStreet Ltd, is currently developing an implementation of SCVP. We've recently updated our software to reflect the
changes made in draft 16 and have found that there are many ambiguities in the specification, both in the ASN.1 module and in the
descriptions of how various elements are meant to be used. 

Given the number of changes that will have to be made to draft 16, I wonder if it won't be necessary to permit another round of
review before submitting the final draft to the RFC editors. I know that there is a lot of pressure for draft 17 to be the final
draft and to get this process completed, but it is in all of our best interest that the final draft be as clear and usable as
possible.

I have sent most of my feedback on draft 16 directly to the editors, but I have a few questions that I'd like the entire list
consider.

1) The 'check' for building a certification path to a trusted root has been removed, implying that an SCVP server can only returns
paths that meet a local validation policy on the server. In a DPD environment, I believe that the client should be able to control
whether the server performs validation. As such, I would like to see id-stc-build-pkc-path and id-stc-build-aa-path restored in
draft 17. 

2) The want back for all paths, id-swb-pkc-all-valid-cert-paths, should be changed to id-swb-pkc-all-cert-paths. The level of
validation that is performed on the path is defined by the requested checks, not the want back. We don't have a separate want back
for status checked certification paths.

3) The new RespValidationPolicy contains the userFinalPolicySet, permittedSubtrees and excludedSubtrees items that result from
validation. Each unique path that is validated may produce different values for these three items but only one value for each item
may be returned because only one RespValidationPolicy is returned with each CVResponse. There are two ways that more than one path
can be returned in a CVResponse: a single CVRequest can contain more than one query certificate, and multiple paths can be returned
for each query certificate using the new 'want back' id-swb-pkc-all-valid-cert-paths. There is no way for the validation algorithm
output can be included as the specification is currently written.

4) Draft 16 requires SCVP servers to maintain a Diffie-Hellman public key for use in authenticated requests. Given that SCVP servers
are not required to support AuthenticatedData requests and that, in general, authentication should be a matter of local server
policy, I believe that the new DH functionality should be optional for SCVP servers.

5) The VPResponse contains a sequence of ValidationPolRef that enumerates the set of validation policies supported by the SCVP
server. However, these validation policies are not defined by value in the VPResponse, they are merely listed by OID or URI. I
believe that there is value in allowing a client to determine the actual policy values that are used in each server policy. As such,
I believe that the type for the validationPolicies item in VPResponse should be 'SEQUENCE OF ValidationPolicy'.

Thanks. I'd be interested to hear thoughts on any of these issues, especially from other folks who are developing SCVP servers.

Seth Hitchings
CoreStreet, Ltd.

---

From: "Trevor Freeman" <[email-masked]>
Date: Thu, 2 Dec 2004 12:55:04 -0800

Hi Seth

* -----Original Message-----
* From: [email-masked]
[mailto:[email-masked]]
* On Behalf Of Seth Hitchings
* Sent: Wednesday, December 01, 2004 9:29 AM
* To: [email-masked]
* Subject: SCVP 16 Comments
* 
* Hi all,
* 
* My company, CoreStreet Ltd, is currently developing an implementation
of
* SCVP. We've recently updated our software to reflect the
* changes made in draft 16 and have found that there are many
ambiguities in
* the specification, both in the ASN.1 module and in the
* descriptions of how various elements are meant to be used.
* 
* Given the number of changes that will have to be made to draft 16, I
* wonder if it won't be necessary to permit another round of
* review before submitting the final draft to the RFC editors. I know
that
* there is a lot of pressure for draft 17 to be the final
* draft and to get this process completed, but it is in all of our best
* interest that the final draft be as clear and usable as
* possible.
* 
* I have sent most of my feedback on draft 16 directly to the editors,
but I
* have a few questions that I'd like the entire list
* consider.
* 
* 1) The 'check' for building a certification path to a trusted root has
* been removed, implying that an SCVP server can only returns
* paths that meet a local validation policy on the server. In a DPD
* environment, I believe that the client should be able to control
* whether the server performs validation. As such, I would like to see
id-
* stc-build-pkc-path and id-stc-build-aa-path restored in
* draft 17.
* 
[TF] Fixed
* 2) The want back for all paths, id-swb-pkc-all-valid-cert-paths,
should be
* changed to id-swb-pkc-all-cert-paths. The level of
* validation that is performed on the path is defined by the requested
* checks, not the want back. We don't have a separate want back
* for status checked certification paths.
[TF] OK
* 
* 3) The new RespValidationPolicy contains the userFinalPolicySet,
* permittedSubtrees and excludedSubtrees items that result from
* validation. Each unique path that is validated may produce different
* values for these three items but only one value for each item
* may be returned because only one RespValidationPolicy is returned with
* each CVResponse. There are two ways that more than one path
* can be returned in a CVResponse: a single CVRequest can contain more
than
* one query certificate, and multiple paths can be returned
* for each query certificate using the new 'want back'
id-swb-pkc-all-valid-
* cert-paths. There is no way for the validation algorithm
* output can be included as the specification is currently written.
[TF] the user final policy set is only for validating CA certificates
and there have been a number of off list comments to back out this
feature from 17 which is want I plan to do.
* 
* 4) Draft 16 requires SCVP servers to maintain a Diffie-Hellman public
key
* for use in authenticated requests. Given that SCVP servers
* are not required to support AuthenticatedData requests and that, in
* general, authentication should be a matter of local server
* policy, I believe that the new DH functionality should be optional for
* SCVP servers.
[TF] The DH key role depends on the client and transport to the server.
The DH key was added to allow anonymous clients to also gain integrity
over the request/response pair where the client is not using a secure
transport. Its use is optional. 
* 
* 5) The VPResponse contains a sequence of ValidationPolRef that
enumerates
* the set of validation policies supported by the SCVP
* server. However, these validation policies are not defined by value in
the
* VPResponse, they are merely listed by OID or URI. I
* believe that there is value in allowing a client to determine the
actual
* policy values that are used in each server policy. As such,
* I believe that the type for the validationPolicies item in VPResponse
* should be 'SEQUENCE OF ValidationPolicy'.
[TF] ]The premise for the use of policy by reference is both client and
server understand the policy by is reference. What is the value in
client learning the value for polices references it otherwise doesn't
know?
* 
* Thanks. I'd be interested to hear thoughts on any of these issues,
* especially from other folks who are developing SCVP servers.
* 
* Seth Hitchings
* CoreStreet, Ltd.

---

From: "Seth Hitchings" <[email-masked]>
Date: Thu, 2 Dec 2004 18:46:55 -0500

Thanks Trevor,

For item 4, I believe that support for DH should be optional for the server as well as the
client. If a server doesn't wish to support that form of integrity protection, it
shouldn't have to. Currently, the VPResponse requires support for DH.

Seth 

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]] 
Sent: Thursday, December 02, 2004 3:55 PM
To: Seth Hitchings; [email-masked]
Subject: RE: SCVP 16 Comments

Hi Seth

* -----Original Message-----
* From: [email-masked]
[mailto:[email-masked]]
* On Behalf Of Seth Hitchings
* Sent: Wednesday, December 01, 2004 9:29 AM
* To: [email-masked]
* Subject: SCVP 16 Comments
*
* Hi all,
*
* My company, CoreStreet Ltd, is currently developing an implementation of
* SCVP. We've recently updated our software to reflect the
* changes made in draft 16 and have found that there are many ambiguities in
* the specification, both in the ASN.1 module and in the
* descriptions of how various elements are meant to be used.
*
* Given the number of changes that will have to be made to draft 16, I
* wonder if it won't be necessary to permit another round of
* review before submitting the final draft to the RFC editors. I know that
* there is a lot of pressure for draft 17 to be the final
* draft and to get this process completed, but it is in all of our best
* interest that the final draft be as clear and usable as
* possible.
*
* I have sent most of my feedback on draft 16 directly to the editors, but I
* have a few questions that I'd like the entire list
* consider.
*
* 1) The 'check' for building a certification path to a trusted root has
* been removed, implying that an SCVP server can only returns
* paths that meet a local validation policy on the server. In a DPD
* environment, I believe that the client should be able to control
* whether the server performs validation. As such, I would like to see
id-
* stc-build-pkc-path and id-stc-build-aa-path restored in
* draft 17.
*
[TF] Fixed
* 2) The want back for all paths, id-swb-pkc-all-valid-cert-paths, should be
* changed to id-swb-pkc-all-cert-paths. The level of
* validation that is performed on the path is defined by the requested
* checks, not the want back. We don't have a separate want back
* for status checked certification paths.
[TF] OK
*
* 3) The new RespValidationPolicy contains the userFinalPolicySet,
* permittedSubtrees and excludedSubtrees items that result from
* validation. Each unique path that is validated may produce different
* values for these three items but only one value for each item
* may be returned because only one RespValidationPolicy is returned with
* each CVResponse. There are two ways that more than one path
* can be returned in a CVResponse: a single CVRequest can contain more than
* one query certificate, and multiple paths can be returned
* for each query certificate using the new 'want back'
id-swb-pkc-all-valid-
* cert-paths. There is no way for the validation algorithm
* output can be included as the specification is currently written.
[TF] the user final policy set is only for validating CA certificates and there have been
a number of off list comments to back out this feature from 17 which is want I plan to do.
*
* 4) Draft 16 requires SCVP servers to maintain a Diffie-Hellman public key
* for use in authenticated requests. Given that SCVP servers
* are not required to support AuthenticatedData requests and that, in
* general, authentication should be a matter of local server
* policy, I believe that the new DH functionality should be optional for
* SCVP servers.
[TF] The DH key role depends on the client and transport to the server.
The DH key was added to allow anonymous clients to also gain integrity over the
request/response pair where the client is not using a secure transport. Its use is
optional. 
*
* 5) The VPResponse contains a sequence of ValidationPolRef that enumerates
* the set of validation policies supported by the SCVP
* server. However, these validation policies are not defined by value in the
* VPResponse, they are merely listed by OID or URI. I
* believe that there is value in allowing a client to determine the actual
* policy values that are used in each server policy. As such,
* I believe that the type for the validationPolicies item in VPResponse
* should be 'SEQUENCE OF ValidationPolicy'.
[TF] ]The premise for the use of policy by reference is both client and server understand
the policy by is reference. What is the value in client learning the value for polices
references it otherwise doesn't know?
*
* Thanks. I'd be interested to hear thoughts on any of these issues,
* especially from other folks who are developing SCVP servers.
*
* Seth Hitchings
* CoreStreet, Ltd.