Subject: RE: SCVP 16 comments deadline

From: "Trevor Freeman" <[email-masked]>
Date: Tue, 7 Dec 2004 12:46:37 -0800

Hi Denis,
Below are responses to 1-16. Others will follow later.
Trevor

* -----Original Message-----
* From: Denis Pinkas [mailto:[email-masked]]
* Sent: Monday, December 06, 2004 2:25 AM
* To: Trevor Freeman
* Cc: [email-masked]
* Subject: Re: SCVP 16 comments deadline
* 
* Trevor,
* 
* > 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.
* 
* 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".
[TF] Fixed
* 
* 
* 2. Page 11. Typos. First paragraph on top of the page.
* Replace "signers" by "signer's".
[TF] Fixed
* 
* 
* 3. Page 11. Typo. First paragraph on top of the page. Last sentence.
* Replace "certificate" by "certificates".
[TF] Fixed
* 
* 
* 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.
* 
[TF] Since this paragraph is listing the possible checks and building a
path is a separate check to revocation checking, I think the current
text is more accurate.
* 
* 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.
[TF] Just checking <g> Fixed
* 
* 
* 6. Page 24. Typo. Section 3.1.5.9 keyUsages
* 
* Change "keyUasge" into "keyUsage".
[TF] Fixed
* 
* 
* 7. Page 27. Typo. Section 3.1.8 valididationTime
* Last line of the first paragraph. Change "servers" into "server's"
[TF] Fixed
* 
* 
* 8. Page 32. Typo. Section 3.5 dhPublicKey
* Change: Diffie-Hellamn into Diffie-Hellman.
[TF] Fixed
* 
* 
* 9. Page 32. Typo. Section 3.5 dhPublicKey
* Fifth line. Change "an does" into "and does"
[TF] Fixed
* 
* 
* 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".
[TF] Deleted the "be"
* 
* 
* 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, ..."
[TF] Fixed
* 
* 
* 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.
[TF] Suggested text substituted
* 
* 
* 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."
[TF] Suggested text substituted
* 
* 
* 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".
[TF] Suggested text substituted
* 
* 
* 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".
[TF] Suggested text substituted
* 
* 
* 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: Denis Pinkas <[email-masked]>
Date: Wed, 08 Dec 2004 17:00:33 +0100

Trevor,

> Below are responses to 1-16. Others will follow later.

I am pleased that you accepted comments 13, 14, 15 and 16.
Among this list, I have a further remark on comment 4.

> path is a separate check to revocation checking, I think the current

I agree that "building a path is a separate check to revocation checking", 
but revocation checking without building a validated path does not make sense.

The full text currently is:

     - Build a certification path to a trust anchor;

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

     - Do revocation status checks on the certification path.

The full text should be:

     - Build a certification path to a trust anchor;

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

Denis