[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: SCVP 16 comments deadline
Here is 23-45
Trevor
* -----Original Message-----
* From: Trevor Freeman
* Sent: Wednesday, December 15, 2004 4:02 PM
* To: 'Denis Pinkas'
* Cc: 'ietf-pkix@xxxxxxx'
* Subject: 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
[TF] This has been moved to response flags and the default is
non-cached.
* * *
* * *
* * * 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.
[TF] Why is this only possible with 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".
[TF] OK
* * *
* * *
* * * 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".
[TF] Thats is not true. The client can omit whatever parameters match
the server default value.
* * *
* * * 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.
[TF] The only way to include other parameters is because the algorithm
needs them. You cannot introduce new parameters without at the same time
defining there use. Therefore mandating additional parameters be passed
which the corresponding identifier for their is the right thing to do.
* * *
* * * 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.
[TF] The argument over the stability of URIs is discussed in the
security section - which is the appropriate place. The reality is in
many organizations are stable enough and much more manageable. The issue
over dereferencing and hashing is bogus. Both OID and URI are both
opaque stings for this purpose and rely on you trusting the management
doing the right thing.
* * *
* * * 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".
[TF] The use of userPolicySet aligns with 3280. I don't think the name
to the existing structure is ambiguous or misleading.
* * *
* * * 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.
[TF] Already done
* * *
* * *
* * * 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.
[TF] the basic validation algorithm references the 3280 section 6.
* * *
* * *
* * * 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.
* * *
[TF] See answer to 31
* * *
* * * 33. Page 17. Section 3.1.5.2 validationAlg (same title as 3.1.5 !)
* * * should be as well deleted.
[TF] The duplicate has been 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.
[TF] See answer 27
* * *
* * *
* * * 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.
[TF] Its simple reuses and existing practice.
* * *
* * * 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.
[TF] userPolicySet aligs with 3280 sectuin 6.
* * *
* * *
* * * 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.
[TF] Since all validation polices contain userPolicySet, it can be in
any policy.
* * *
* * *
* * * 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".
[TF] This conflicts with 3280 section 6.
* * *
* * *
* * * 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.
[TF] A server cannot include a hash of the request in a cached 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.
[TF] There is one, it is responseValidationPolByRef. The reponce flags
now has a FullRequestInResponse in place of the requestRefHash
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."
[TF] I have not chages the name, but the section now reads
The responseValidationPolByRef controls whether the response includes
just a reference to the policy or the reference to the policy plus all
the parameters by value of the policy used to process the request.
the response MUST contain references to the validation policy. If the
client wants the validation policy parameters to be also included by
value, then the responseValidationPolByRef is set to FALSE. 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.
[TF] Fixed
* * *
* * * 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.
[TF] Fixed
* * *
* * *
* * * 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".
[TF] draft now read " integrity protect the request and the subsequent
response." The use of DH does not necessarily authenticate the request.
* * *
* * * 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".
* * *
[TF] Fixed
* * *
* * * 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
* * *
* * *