[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: SCVP 16 comments deadline
Hi Denis,
Below are responses to 1-16. Others will follow later.
Trevor
* -----Original Message-----
* From: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
* Sent: Monday, December 06, 2004 2:25 AM
* To: Trevor Freeman
* Cc: ietf-pkix@xxxxxxx
* 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
*
*