[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: SCVP 16 comments deadline
Here is 17-22
Trevor
* -----Original Message-----
* From: Trevor Freeman
* Sent: Tuesday, December 07, 2004 12:47 PM
* To: 'Denis Pinkas'
* Cc: ietf-pkix@xxxxxxx
* Subject: 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.
[TF] Is there a specific issue with the current draft such as a scenario
which is not addressed?
* *
* * 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"
[TF] See comment to 17
* *
* * 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.
[TF] There is plenty of precedence for this to be in a separate
document. CMS itself just defines the syntax.
* *
* *
* * 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".
[TF] Since by definition the anonymous client has to sign the request as
well this does not make sense. A server can also return a cached
response in which case there is no hash of the request in the response.
How about
An anonymous client signs the request to provide integrity over
the request. A identifiable signs the request to authenticate itself 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."
[TF] I think it reinforces that with some checks, don't require
revocation status checking but a server may still elect to do so.
* *
* *
* * 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".
[TF] OK, I will add a reference to 3281 section 5.
* *
* *
* * 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
* *
* *