Subject: SCVP 16 comments deadline

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

The deadline communicated at the DC meeting for making comments on SCVP
16 was Nov 30th which has now passed. I have had only three people send
me comments to date. SCVP 17 will be closing very shortly so this is the
last reminder.

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 06 Dec 2004 11:24:50 +0100

Trevor,

> me comments to date. SCVP 17 will be closing very shortly so this is the 

Thank for the remainder. I missed the initial announcement.
My comments are below.

1. Typo. There are two IPR statements related to RFC 3668 on the first
page. Delete one.

“ By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668”.

2. Page 11. Typos. First paragraph on top of the page.
Replace “signers” by “signer’s”.

3. Page 11. Typo. First paragraph on top of the page. Last sentence.
Replace “certificate” by “certificates”.

4. Page 13. Typo. Section 3.1.2 “checks”
The two following lines are in fact one line:

Change:

     - Build a validated certification path to a trust anchor; and

     - Do revocation status checks on the certification path.

into:

     - Build a validated certification path to a trust anchor and
       do revocation status checks on the certification path.

5. Page 15. Typo. Section 3.1.4 validationPolicy

This is the error left intentionally by the editor to know who read the
document. The following sentence is duplicated: “ The validationPolicy
item, defines the validation policy”. Please delete one sentence.

6. Page 24. Typo. Section 3.1.5.9 keyUsages

Change “keyUasge” into “keyUsage”.

7. Page 27. Typo. Section 3.1.8 valididationTime
Last line of the first paragraph. Change “servers” into “server’s”

8. Page 32. Typo. Section 3.5 dhPublicKey
Change: Diffie-Hellamn into Diffie-Hellman.

9. Page 32. Typo. Section 3.5 dhPublicKey
Fifth line. Change “an does” into “and does”

10. Page 32. Typo. Section 3.5 dhPublicKey
Delete: (see section Error! Reference source not found.)

11. Page 33. Typo. Section 4. Validation Response

After the eight items. The following sentence has a grammar problem:
  “Successful responses are be made when the server has fully complied
   with the request”.

12. Page 52. Typo. Section 6 Validation Policy Response

The second sentence is incorrect. It is:
The valPolResponse MAY not unique to any valPolRequest, …”

Change into:
“The valPolResponse MAY not be unique to any valPolRequest, …”

13. The abstract does not reflect accurately the content of the
document.
“certificate handling” is too vague.

Proposed abstract:

   SCVP allows a client to delegate certificate path construction and
   certificate path validation to a server. The path construction or
   validation (i.e. making sure that none of the certificates of the
   path is revoked) is made according to a validation policy which
   contains one or more trust anchors. It allows to simplify client
   implementations and to use a set of predefined validation policies.

14. Section 1.3

The text on validation policy is new. There is no concept of “mutually
agreed” validation policy between the client on the server. The server
supports a set of validation policies which may or may not fit the need
of the client.

Change the second sentence of section 1.3 which is:

“ In SCVP, a validation policy can be either mutually
   agreed between client and server, and subsequently referenced in
   request, or explicitly expressed in the request by passing all of
   the necessary parameters.”

into:

“ In SCVP, the validation policy to be used by the server can be either
fully referenced in the request by the client (and thus no additional
parameter is necessary), referenced in the request by the client with
additional parameters or supported by default by the server if the
client does not reference it.”

15. Section 1.3. The second paragraph needs to be reworded. Currently,
it is the following:

“ Policy definitions can be quite long and complex, and some policies
   may allow for the setting of a few parameters such as a set of
   trust anchors.  The request can therefore be simplified if these
   previously agreed policy dependent parameters are referenced in the
   request by a mutually agreed OBJECT IDENTIFIER (OID) or URL value.
   The referenced value indicates either a partial or full set of
   parameters. The client can therefore omit these agreed parameters
   from the request, only passing any parameters which are not
   specified by the previously agreed policy.  Therefore in the
   simplest form, with validation polices which define every parameter
   necessary, a SCVP request need only contain the certificate to be
   validated, the validation policy and any run-time parameters for
   the request”.

Proposed rewording:

“ Policy definitions can be quite long and complex, and some policies
   may allow for the setting of a few parameters.  The request can
   therefore be very simple if OBJECT IDENTIFIERS (OIDs) are used to
   specify both the algorithm to be used and all the associated
   parameters of the validation policy. The request can be more complex
   if the validation policy fixes many of the parameters but allows the
   client to specify some of them. When the validation policy defines
   every parameter necessary, a SCVP request needs only to contain the
   certificate to be validated, the referenced validation policy and any
   run-time parameters for the request. In its simplest form, a SCVP
   request contains the certificate to be validated and any run-time
   parameters for the request. In that case the server uses a default
   validation policy”.

16. Section 1.3. Paragraph 3.

The text is missing the fact that at least one validation policy must
be supported by the server. This is the default policy which is used
when the client omits to specify it.

The current text is the following:

  “SCVP server also publishes its default validation policy settings.
   The default policy can be requested for validation and the client
   can override any default value in the request if required.  The
   default values are also used when processing requests which
   reference a validation policy other than the default one that does
   not contain the full set of parameters necessary for validation and
   the client has also omitted the missing values in the request.

   Therefore a client can also simplify the request by omitting a
   parameter from a request if the default value published by the
   server is acceptable”.

Replace it with:

“ A SCVP server must support a default validation policy which will
   be used if the client does not specify any in its request. A server
   publishes the references of the validation policies it supports.
   When these policies have parameters that may be overridden, the
   default value for these parameters are communicated by the server as
   well. The client can simplify the request by omitting a parameter
   from a request if the default value published by the server for a
   given validation policy reference is acceptable. However if there is
   a desire to demonstrate to someone else that a specific validation
   policy with all its parameters has been used, it will need to ask the
   server for the inclusion of the full validation policy with all the
   parameters in the response”.

17. On top of page 7, the relationship between the validation policy
and the basic certification path algorithm is not explained. Then in
section 1.4 The concept of validation algorithm is introduced but its
relationship with the validation policy is not explained. This is
confusing.

Later on when observing the ASN.1 syntax it may be discovered that two
OIDs are being used:

  - one for the validation policy (ValidationPolRef) and
  - one for the validation algorithm (ValidationAlg).

This is overcomplicated and unnecessary.

An important simplification is obtained if, as the previous text
states, there is an OID to defined the validation policy and there may
be or may not be additional parameters.

We could then have:

valPolByOID::= SEQUENCE {
       valPolId              OBJECT IDENTIFIER,
       parameters            ANY DEFINED BY ValPolId OPTIONAL }

Specifying a path processing compliant with section 6.1 of RFC 3280
would be possible (notice however that the text from RFC 3280 is too
vague to support the case where a CRL is not signed by the CA).

It would be desirable to be able to communicate easily and in a
standard way the parameters that may be set in section 6.1 from RFC
3280. In addition, key usage should be added to that list.

The document should then define a bundle of all these previous useful
parameters and allow for the addition of other parameters.

It is thus proposed to define an OID for a validation policy compliant
with section 6.1 of RFC 3280 (some differences with section 6 from
3280bis, i.e. adding precision, may be expected)

It is thus proposed to modify the text starting from :

“ The inputs to the basic certification path processing algorithm
   used by SCVP are defined by [PKIX-1] in section 6.1.1 and comprise”
   up to the end of section 1.3 with the following:

“For clients able to specify the parameters of a validation policy, it
may be useful to define a standard data structure (using a bundle) able
to support the parameters of the basic certification path processing
algorithm defined by in section 6.1.1 from [PKIX-1] :

  - a set of Trust Anchors (by value or by reference),
  - the initial Certificate Policy set,
  - initial Certificate Policy mapping setting,
  - initial any-Policy setting,
  - initial explicit Certificate Policy setting.

as well as :

   - the usage of the key contained in the certificate (e.g., key
     encipherment, key agreement, signature)

This will be done using a bundle which encapsulates all these
parameters.

Other application-specific purposes parameters may be added”.

18. Section 1.4 is about a “Validation Algorithm”. Given what was said
before, the header of this section should be changed. If we make a
subsection 1.3.1 called “1.3.1. General” for encapsulating the previous
text, then we can introduce a new section 1.3.2 called:

“1.3.2. Validation policy according to section 6.1 of RFC 3280”

Some of the text present in the current section 1.4 has been used to
build the new text that is proposed below:

“1.3.2. Validation policy according to section 6.1 of RFC 3280

   SCVP defines a specific validation policy which implements the
   certification path validation algorithm as defined in section 6.1 of
   [PKIX-1]. This specific validation policy, called “rfc-3280 basic
   validation policy” uses the parameters defined in the bundle
   mentioned above.

   Note that this algorithm does not support in its full generality the
   algorithm described in section 6.2 of [PKIX-1] since, when more than
   one trust anchor is being defined, all the conditions that are
   specified apply to all trust anchors, whereas section 6.2 allows to
   have different conditions for every trust anchor.

   The rfc-3280 basic validation policy may be the default validation
   policy supported by the server, but does not need to”.

19. Section 2 “Protocol Overview”

In order to allow for interoperability and testing a common protocol
needs to be supported. It should be defined.

20. Section 3 “Validation Request”

The unsigned request form is not explained and there is a confusion for
the signed request which indeed authenticates the client and is thus
not anonymous. The current text is :

   “A signed
   request is used to authenticate the client to the server or to
   provide an anonymous client integrity over the request-response
   pair.”

It should be rephrased as:

   “An unsigned request provides an anonymous client integrity over
    the request since the hash of the request or the full request is
    incorporated in the response. A signed request is used to
    authenticate the client to the server”.

21. Page 13. Section 3.1.2 “checks”

The following sentence adds nothing and should be removed:

   “A server may still choose to
   perform revocation status checks when performing path construction,
   although this information cannot be returned to the client.”

22. Page 15. Section 3.1.3 “wantBack”

The text states:

     - Proof of revocation status for each certificate in the AC
        issuer certification path;

It would be important to refer the section of the RFC which explains
how to
check the “revocation status for each certificate in the AC issuer
certification path”.

23. Page 15. Section 3.1.3 “wantBack”

The text states:

   The client can also request a non-cached response to the request by
   including wantback id-swb-non-cached-resp in the request.

The default behavior should be the reverse: fresh information is
provided, unless the client accept cached information. The item should
be changed into:
id-swb-cached-resp

24. Page 15. Section 3.1.3 “wantBack”

The text states:

id-swb-pkc-all-valid-cert-paths OBJECT IDENTIFIER ::= { id-swb 13}

It should be mentioned that this item is only possible for DPD.

25. Page 16. Section 3.1.4 validationPolicy

The following sentence is talking of an agreement whereas such
agreement does not exist. Delete the sentence:

  “The client and server can optionally agree on a set of parameters
   which may fully or partially define a validation policy”.

26. Page 16. Section 3.1.4 validationPolicy
The text states:

   "If a partial set of parameters has been agreed upon,
   then the client supplies a reference to the policy plus whatever
   parameters are necessary to complete the request in this item.

This should be replaced with:

   “If the validation policy does not define all parameters necessary
   for processing an SCVP request, then the client need to supply these
   parameters”.

27. Page 16. Section 3.1.4 validationPolicy

   The syntax of the validationPolicy item is defined as:

   ValidationPolicy ::= SEQUENCE {
     validationPolRef          ValidationPolRef,
     validationAlg         [0] ValidationAlg OPTIONAL,
     userPolicySet         [1] SEQUENCE SIZE (1..MAX) OF OBJECT
                                 IDENTIFIER OPTIONAL,
     inhibitPolicyMapping  [2] BOOLEAN OPTIONAL,
     requireExplicitPolicy [3] BOOLEAN OPTIONAL,
     inhibitAnyPolicy      [4] BOOLEAN OPTIONAL,
     isCA                  [5] BOOLEAN OPTIONAL,
     trustAnchors          [6] TrustAnchors OPTIONAL,
     keyUsages             [7] SEQUENCE SIZE (1..MAX) OF KeyUsage
                                  OPTIONAL,
     extendedKeyUsages     [8] ExtKeyUsageSyntax OPTIONAL}

This structure is quite odd, because it only allows to pass additional
parameters as parameters of the validationAlg. Suppressing the
validationAlg item add adding validationParamExtensions would be a
simpler and cleaner way.

Each validation policies uses its own parameters.
We should have something like :

ValPolByOID  ::= SEQUENCE {
       valPolgId             OBJECT IDENTIFIER,
       parameters            ANY DEFINED BY valPolId OPTIONAL }

More details follow.

28. It is highly debatable if URIs should be supported or not to
reference a validation policy. URIs are not stable over time and thus
unless there are dereferenced and a hash value is computed over them,
it is insecure to use them. There is a discussion in the security
consideration section, but no warning and no pointer here. If we keep
them, we should warn the user.

If the WG should decides that they should be supported (and if the IESG
agrees) on page 17, the ASN.1 description should then be:

ValidationPolicy ::= CHOICE {
     valPolByOID         [0] ValPolByOID,
     valPolByURI         [1] ValPolByURI }

ValPolByOID  ::= SEQUENCE {
       valPolgId             OBJECT IDENTIFIER,
       parameters            ANY DEFINED BY valPolId OPTIONAL }

ValPolByURI ::= SEQUENCE {
     uri            IA5String,
     hashAlgo       OBJECT IDENTIFIER,
     hashValue      OCTET STRING}

29. It is proposed to define the following bundle:

ValidationParamBundle ::= SEQUENCE {
     certificatePolicySet      [0] SEQUENCE SIZE (1..MAX) OF OBJECT
                                   IDENTIFIER OPTIONAL,
     inhibitPolicyMapping      [1] BOOLEAN OPTIONAL,
     requireExplicitPolicy     [2] BOOLEAN OPTIONAL,
     inhibitAnyPolicy          [3] BOOLEAN OPTIONAL,
     isCA                      [4] BOOLEAN OPTIONAL,
     trustAnchors              [5] TrustAnchors OPTIONAL,
     keyUsages                 [6] SEQUENCE SIZE (1..MAX) OF KeyUsage
                                   OPTIONAL,
     extendedKeyUsages         [7] ExtKeyUsageSyntax OPTIONAL
     extensions                [8] EXPLICIT Extensions OPTIONAL }

Note that userPolicySet” is unclear and has been changed into
“certificatePolicySet”.

The text would need to be aligned with the new structure and, of course
the parameters of the rfc-3280 basic validation policy will simply
include the bundle above as its parameters.

It should also be mentioned somewhere in the document that the support
of the rfc-3280 basic validation policy is not mandatory for
conformance but, if supported then the bundle needs to be supported.

30. Page 17. Section 3.1.5 validationAlg should be deleted.

31. Page 17. Section 3.1.5.1 Default Validation Algorithm should be
deleted and replaced by a section later on the “rfc-3280 basic
validation policy”, which should have its OID defined under the scvp
tree for OIDs.

32. Page 17. Section 3.1.5.1. Some text of this section might be re-
sued to build a new section on the rfc-3280 basic validation policy.
Note that the last sentence at the bottom of page 17, should be
removed. This sentence is: “The default validation policy MUST use the
basic validation algorithm”. Any default validation policy can be used.

33. Page 17. Section 3.1.5.2 validationAlg (same title as 3.1.5 !)
should be as well deleted.

34. Page 20. Section 3.1.5.2.3 Name Validation Algorithm

This goal of this section seems to introduce an additional test to the
basic “rfc-3280 basic validation policy”. It would come naturally as an
extension of ValidationParamBundle, rather than as a parameter of the
validationAlgo which has been proposed to be removed. The text should
be modified accordingly.

35. Page 21. Section 3.1.5.2.3 Name Validation Algorithm

     NameValidationAlgParms ::= SEQUENCE {
       keyPurposeId      KeyPurposeId,
       validationNames   GeneralNames }

This construct is artificial since KeyPurposeId is about the Extended
Key Usage and has nothing to do with name validation.

It could indeed be interesting to test the Extended Key Usage extension
of a certificate, but this should be supported as an extension of
ValidationParamBundle. The text should be modified accordingly.

36. Page 22. Section 3.1.5.3 userPolicySet

userPolicySet should be changed everywhere into certificatePolicySet.

37. Page 22. Section 3.1.5.3 userPolicySet

The text has many sentences like:

   SCVP clients SHOULD support userPolicySet item in requests, and
   SCVP servers MUST support userPolicySet item in requests.

These requirements only apply for the rfc-3280 basic validation policy,
and this should be clearly mentioned.

38. Page 22. Section 3.1.5.4 inhibitPolicyMapping

The text states:

   By default the server allows policy mapping as
   part of certification path validation.

For simplicity, this should be the reverse. Replace with:

  “By default the server does not perform policy mapping as
   part of certification path validation. If the client wants the
   server to support policy mapping, allowPolicyMapping must be set
   to TRUE in the request”.

39. Page 24. Section 3.1.5.8 trustAnchors

The text states:

  “A certificate reference can be used to identify the
   trust anchor by certificate hash and optionally a distinguished
   name with serial number”.

This is not consistent with the ASN.1 definition of PKCReference which
is:

   PKCReference ::= CHOICE {
     cert                   [0] Certificate,
     pkcRef                 [1] ESSCertID }

Please correct.

40. Page 25. Section 3.1.6 responseRefHash

The text states:

   “By default, the server includes a hash
   of the request in the response.  If the client wants the server to
   include the full request in the response, responseRefHash is set to
   FALSE.”

The server shall always include a hash of the request in the response.
This is an easy way to allow to test the integrity of the request.
Since the full description of the validation policy may be much longer
a flag should be used to say that the full validation policy is not
returned unless requested. It is thus proposed to have instead the
following:

“3.1.6.1 fullRequestInResponse

   The fullRequestInResponse controls if the client wants the server
   to include the full request in the response. By default,
   fullRequestInResponse is set to FALSE. If the client wants back
   the full request then it must set this parameter to TRUE. The main
   reason a client would request the server to include the full request
   in the response is to archive the request-response exchange in a
   single object.  That is, the client wants to archive a single object
   which includes both request and response”.

41. Page 26. Section 3.1.6.2 responseValidationPolByRef

This item should be renamed: fullValPolInResponse

The text should be changed into:

“The fullValPolInResponse controls whether the response includes the
identifier of the validation policy with all the parameters that have
been used by the server, i.e. all the variable parameters independent
from the fact that there were specified by the client or defaulted if
not specified. By default, fullValPolInResponse is set to FALSE. If the
client wants the full validation policy to be included, then
fullValPolInResponse is set to TRUE. The main reason a client would
request the server to include validation policy to be included by value
is to archive the request-response exchange in a single object. That
is, the client wants to archive the CVResponse and have it include
every aspect of the validation policy.”

The ResponseFlags should be changed as follows:

   ResponseFlags ::= SEQUENCE {
     fullRequestInResponse      BOOLEAN DEFAULT FALSE,
     fullValPolInResponse       BOOLEAN DEFAULT FALSE,
     signResponse               BOOLEAN DEFAULT TRUE }

42. Page 28. Section 3.1.9 intermediateCerts. Minor.

Change:

   The optional intermediateCerts item helps the SCVP server create
   valid certification paths.

into:

   The optional intermediateCerts item may help the SCVP server to
create
   valid certification paths.

43. Page 29. Section 3.1.11. producedAt

Last sentence. Change:

   SCVP server SHOULD support the producedAt values in the request.

into:

   SCVP server MAY support the producedAt values in the request.

Reason: cached responses should not need to be implemented in order to
be compliant with the specification.

44. Page 32. Section 3.5 dhPublicKey

The text states:

  “For the server to compute the shared
   secret, it must lean the public values the client generates,
   therefore the client MUST include this in the request if it uses
   this mechanism to integrity protect the request-response pair.”

Replace:

“to integrity protect the request-response pair”

with :

“to authenticate and integrity protect the first response and
authenticate and integrity protect subsequent request-response pairs”.

45. Page 32. Section 3.6 SCVP Request Authentication

The text states:

  “It is a matter of local policy what validation policy is used by
   the server when validating requests”.

This sentence could be misinterpreted because the word “validating” is
being used. Change into:

   It is a matter of local policy what validation policy is used by
   the server when authentication requests”.

46. Page 35. Section 4. Validation Response

   The CVResponse is defined as follows:

     CVResponse ::= SEQUENCE {
       cvResponseVersion         cvResponseVersion        INTEGER,
       policyID                  INTEGER,
       producedAt                GeneralizedTime,
       ....

On the next page the test states:

  “The policy ID used by the SCVP server when it processed the request.
   See section 6.4 for details.”

In section 6.4 the text states:

“6.4 defaultPolicyID

   An integer that uniquely represents the version of the default
   validation policy as represented by the trustAnchors, …”

This is not understandable, over-engineering and very complicated.
Please delete this item.

47. Page 35. Section 4. Validation Response

   The CVResponse contains:

       requestRef            [1] RequestReference OPTIONAL,

Remove “OPTIONAL” since it is very beneficial to mandate this item
since it allows to make sure that the request has not be modified if
the response is integrity protected. The computation is fast and easy
and the hash value does not overload the response.

48. Page 38. Section 4.5 respValidationPolicy

The definition of this item is overcomplicated and not tailored to
support any kind of validation policy.

If the client does not specify the validation policy or if the client
specifies a validation policy which has default parameters, then the
full description of the validation policy shall be given back.

If the client specifies a validation policy which has no default
parameters, then the reference and parameters, if any, of the
validation policy are in the request.

The full description of the validation policy shall be given back in
any case, if the fullValPolInResponse Boolean in ResponseFlags is set.

respValidationPolicy :: = ValidationPolicy

49. Page 41. Section 4.6 requestRef

As stated earlier, requestRef should be mandatory and always be a hash
of the request.

In addition a fullRequest OPTIONAL parameter should be added as an
optional item for CVResponse.

The full description of the validation policy shall be given back in
any case, if the fullRequestInResponse Boolean in ResponseFlags is set.

Change the text and the syntax accordingly.

50. Page 41. Section 4.6 requestRef

The text states:

   “The requestRef item allows the client to associate a response with
   a request”

This is wrong. This does not protect against a replay.

Change with:

“When the response is authenticated, the requestRef item allows the
client to make sure that the request was not modified in transit”.

51. Page 41. Section 4.6 requestRef

The text states:

“ The requestNonce provides an alternative mechanism for
   matching requests and responses if the client has selected to
   include a full response.”

This is wrong. This is not an alternative for matching requests and
responses.

Replace with:

  “The requestNonce allows to protect against replay, even if time
synchronization is not good between the client and the server”.

52. Page 42. Section 4.6.1 requestHash

The text states:

“ The requestNonce provides an alternative mechanism for matching
requests and responses”.

This is wrong. See above. Delete.

53. Page 45. Section 4.10.4 replyChecks

ReplyCheck is defined as:

     ReplyCheck ::= SEQUENCE {
       check                      OBJECT IDENTIFIER,
       status                     INTEGER }

It should be defined as:

     ReplyCheck ::= SEQUENCE {
       check                      OBJECT IDENTIFIER,
       status                     INTEGER DEFAULT 0}

54. Page 46. Section 4.10.4 replyChecks

The text states

   “The status value for public key certification path building to a
   trusted root along with complete status checking, { id-stc 3 }, can
   be one of the following:

       0: Good
       1: Revoked
       2: Revocation Offline
       3: Revocation Unavailable

It is unclear to understand the benefits that a client can have from
the difference between “Revocation Offline” and “Revocation
Unavailable”. In addition, these wordings do not match the explanations
of what there are.

A much more important response is missing: suspended. Suspended is a
variation of revoked, but the client then knows it may attempt another
try later on.

It is thus suggested to change it into:

       0: Good
       1: Revoked
       2: Suspended
       3: Revocation info unavailable”

55. Page 46. Section 4.10.4 replyChecks

The same comment applies for the status value for AC issuer
certification path.

56. Page 48. Section 4.10.6 validationAlg
For reasons given before, delete validationAlg.

57. Page 48. Section 4.10.8 nextUpdate

If CRLs are used, should this field contain the value of the next
update field for the smallest value of all the CRLs ? What is the real
benefit of supporting this element besides added complexity ? It is
suggested to delete that item.

58. Page 49. Section 4.11 responseNonce

The text states:

“The responseNonce item contains an identifier to binds the request
to the response.”

This is incorrect. The nonce is to detect replay.

Change into:

“The responseNonce item contains a unique number which allows to detect
replay”.

59. Page 51. Section 5 Server Policy Request

The text states:

  “A SCVP client uses the valPolRequest item to request the list of
   validation policies supported by the SCVP server.”

This is not a correct description of what this request is doing. When
looking at the ASN.1 it is doing much more. So the question is whether
two requests should be provided or one. In the later case, it is
important to advertise correctly what the request is doing.

60. Page 52. Section 6 Validation Policy Response

The ASN.1 of the VPResponse is over-complicated.

The first three items are overengineering:

       vpResponseVersion          INTEGER,
       maxCVResponseVersion       INTEGER,
       maxVPResponseVersion       INTEGER,

Further more they are mandatory. Please delete.

61. Page 52. Section 6 Validation Policy Response

The ASN.1 of the VPResponse is over-complicated.

        defaultPolicyID            INTEGER,

This item does not make sense. When an OID references a validation
policy, there is no concept of versioning. Another version will simply
get another OID (hopefully in the same branch). Please delete.

62. Page 52. Section 6 Validation Policy Response

The ASN.1 of the VPResponse is over-complicated.

       validationPolices          SEQUENCE OF ValidationPolRef,
       validationAlgs             SEQUENCE OF OBJECT IDENTIFIER,

validationAlgs is unnecessary. Please delete.

validationPolicies (not validationPolices) is the main component. See
below for a full proposal for restructuring VPResponse.

63. Page 52. Section 6 Validation Policy Response

       authPolicies               SEQUENCE OF AuthPolicy,
       responseTypes              ResponseTypes,
       dhPublicKeyInfo            SEQUENCE OF DHPublicKeyInfo,

are elements which have nothing to do with the list of validation
policies, and they are mandatory ! Either group them in one OPTIONAL
item or define another command to get them.

64. Page 52. Section 6 Validation Policy Response

      defaultPolicyValues        ValidationPolValues,

This is simply the set of parameters which are related to the rfc-3280
basic validation policy. This set could be used by other validation
policies. Please delete.

65. Page 52. Section 6 Validation Policy Response

What follows is a sketch for a proposal for VPResponse.

    VPResponse ::= SEQUENCE {
       requestNonce               OCTET STRING      OPTIONAL
       thisUpdate                 GeneralizedTime,
       nextUpdate                 GeneralizedTime   OPTIONAL,
       validationPolicies         SEQUENCE OF ValidationPolicy,
       serverParams               ServerParams      OPTIONAL }

    ServerParams ::= SEQUENCE {
       responseTypes              ResponseTypes,
       authPolicies           [0] SEQUENCE OF AuthPolicy      OPTIONAL,
       dhPublicKeyInfo        [1] SEQUENCE OF DHPublicKeyInfo OPTIONAL,
       clockSkew              [2] INTEGER OPTIONAL }

Note: it is re-called that ValidationPolicy should be redefined as:

ValidationPolicy ::= CHOICE {
     valPolByOID         [0] ValPolByOID,
     valPolByURI         [1] ValPolByURI }

ValPolByOID  ::= SEQUENCE {
       valPolgId             OBJECT IDENTIFIER,
       parameters            ANY DEFINED BY valPolId OPTIONAL }

ValPolByURI ::= SEQUENCE {
     uri            IA5String,
     hashAlgo       OBJECT IDENTIFIER,
     hashValue      OCTET STRING}

66. Page 56. Section 7 SCVP Server Relay

This section is incomplete and lacking explanations. Please explain how
relaying is achieved.

67. Page 65. Section 9 Security Considerations

In the second paragraph, there is a discussion about the use of URIs to
reference validation policies.

Firstly, if URIs are going to stay, a pointer to the security
consideration section should be present in the main body of the
document.

Secondly, the text should mention the need for the ability to
dereference the URI and the need to compute a hash, while the main body
of the document should explain the computation of a hash on the content
of the URI.

68. Page 65. Section 9 Security Considerations

The text states:

  “It can also do this by using the Diffie-hellman keys to sign the
request”.

Replace “sign” by “authenticate”.

END OF COMMENTS

---

From: Dan Proietti <[email-masked]>
Date: Mon, 6 Dec 2004 14:08:04 -0500

Hi, Trevor.  I have a few comments re: default validation policy.

a) Section 1.3 states, "The default policy can be requested for
validation and the client can override any default value in the
request if required.  The default values are also used when processing
requests which reference a validation policy other than the default
one that does not contain the full set of parameters necessary for
validation and the client has also omitted the missing values in the
request." Section 6.14 is also quite clear about this.  However, in
section 3.1.4, the field descriptions for the ValidationPolicy type
imply that a fixed default is used when an OPTIONAL item is not
included.  For instance the description for userPolicySet (section
3.1.5.3) states, "If userPolicySet is not specified, then any-policy
MUST be used."  If section 1.3 still holds, the correct description
should be something like, "If userPolicySet is not specified, then the
value from the default validation policy will be used."  Same goes for
the other ValidationPolicy field descriptions: inhibitPolicyMapping,
requireExplicitPolicy, inhibitAnyPolicy, isCA, keyUsages,
extendedKeyUsages.  If this is indeed the intent.

b) Section 3.1.5.1 is titled "Default Validation Algorithm" but
discusses the default validation policy.  This is very confusing.  I
presume this should be titled "Default Validation Policy" and be
re-located to a sub-section of the validationPolRef description
(3.1.4.1)?

c) Section 3.1.5.2.1 (Basic Validation Algorithm) defines the "meaning
of the default validation algorithm".  This is extremely confusing as
this is the first time this term is mentioned.  I presume "algorithm"
should be changed to "policy" and the remainder of this sub-section
should be merged into the "Default Validation Policy" section?

d) Related to c) above, the second bullet states, "The acceptable
policy set will come from the userPolicySet item.  If no certificate
policies are specified in the userPolicySet item, then the SCVP server
will use any-policy."  What if the server has defined the default
validation policy with a userPolicySet of {1.2.3.4} and the client
requests the default validation policy and does not specify a
userPolicySet override?  Does the server use {1.2.3.4} or
{any-policy}?  Or is it invalid for a server to define a default
validation policy with a userPolicySet other than {any-policy}?

Personally, I think the specification needs to be more concise re:
constructing the actual validation policy based on a) the referenced
policy, b) the explicit overrides, and c) the default policy fallbacks.  An
example with a hypothetical agreed upon validation policy would do it.

Thanks for your time,
Dan Proietti

On Thu, 2 Dec 2004 12:22:31 -0800, Trevor Freeman
<[email-masked]> wrote:
>
>
>
> The deadline communicated at the DC meeting for making comments on SCVP 16
> was Nov 30th which has now passed. I have had only three people send me
> comments to date. SCVP 17 will be closing very shortly so this is the last
> reminder.

---

From: Dan Proietti <[email-masked]>
Date: Wed, 8 Dec 2004 13:29:51 -0500

Trevor, I have one additional comment.

Section 4.9 responder: This item is not adequately described in this
section, nor is it mentioned anywhere else in the specification.  I
presume the value of this field is the value that the SCVP server
stuffs into the requestorRef to identify itself when relaying
requests.  But if the value is "only of local signifigance to the SCVP
server" then why is it returned to the client in the response?  What
could the client possibly do with information?

Dan