Subject: RE: SCVP 16 comments deadline

From: "Trevor Freeman" <[email-masked]>
Date: Tue, 15 Feb 2005 14:56:02 -0800

Here are 46 onwards

Trevor

* -----Original Message-----
* From: Trevor Freeman
* Sent: Thursday, December 16, 2004 12:49 PM
* To: Denis Pinkas
* Cc: [email-masked]
* Subject: 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: [email-masked]'
* * 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: [email-masked]
* * * 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:[email-masked]]
* * * * Sent: Monday, December 06, 2004 2:25 AM
* * * * To: Trevor Freeman
* * * * Cc: [email-masked]
* * * * Subject: Re: SCVP 16 comments deadline
* * * *
* * * * Trevor,
* * * *
* * * * > The deadline communicated at the DC meeting for making
comments on
* * * SCVP
* * * * > 16 was Nov 30th which has now passed. I have had only three
people
* * * send
* * * * > me comments to date. SCVP 17 will be closing very shortly so
this
* is
* * * the
* * * * > last reminder.
* * * *
* * * * Thank for the remainder. I missed the initial announcement.
* * * * My comments are below.
* * * *
* * * *
* * * * 1. Typo. There are two IPR statements related to RFC 3668 on the
* first
* * * * page. Delete one.
* * * *
* * * * " By submitting this Internet-Draft, I certify that any
applicable
* * * *    patent or other IPR claims of which I am aware have been
* disclosed,
* * * *    or will be disclosed, and any of which I become aware will be
* * * *    disclosed, in accordance with RFC 3668".
* * * [TF] Fixed
* * * *
* * * *
* * * * 2. Page 11. Typos. First paragraph on top of the page.
* * * * Replace "signers" by "signer's".
* * * [TF] Fixed
* * * *
* * * *
* * * * 3. Page 11. Typo. First paragraph on top of the page. Last
sentence.
* * * * Replace "certificate" by "certificates".
* * * [TF] Fixed
* * * *
* * * *
* * * * 4. Page 13. Typo. Section 3.1.2 "checks"
* * * * The two following lines are in fact one line:
* * * *
* * * * Change:
* * * *
* * * *      - Build a validated certification path to a trust anchor;
and
* * * *
* * * *      - Do revocation status checks on the certification path.
* * * *
* * * * into:
* * * *
* * * *      - Build a validated certification path to a trust anchor
and
* * * *        do revocation status checks on the certification path.
* * * *
* * * [TF] Since this paragraph is listing the possible checks and
building
* a
* * * path is a separate check to revocation checking, I think the
current
* * text
* * * is more accurate.
* * * *
* * * * 5. Page 15. Typo. Section 3.1.4 validationPolicy
* * * *
* * * * This is the error left intentionally by the editor to know who
read
* * the
* * * * document. The following sentence is duplicated: " The
* * validationPolicy
* * * * item, defines the validation policy". Please delete one
sentence.
* * * [TF] Just checking <g> Fixed
* * * *
* * * *
* * * * 6. Page 24. Typo. Section 3.1.5.9 keyUsages
* * * *
* * * * Change "keyUasge" into "keyUsage".
* * * [TF] Fixed
* * * *
* * * *
* * * * 7. Page 27. Typo. Section 3.1.8 valididationTime
* * * * Last line of the first paragraph. Change "servers" into
"server's"
* * * [TF] Fixed
* * * *
* * * *
* * * * 8. Page 32. Typo. Section 3.5 dhPublicKey
* * * * Change: Diffie-Hellamn into Diffie-Hellman.
* * * [TF] Fixed
* * * *
* * * *
* * * * 9. Page 32. Typo. Section 3.5 dhPublicKey
* * * * Fifth line. Change "an does" into "and does"
* * * [TF] Fixed
* * * *
* * * *
* * * * 10. Page 32. Typo. Section 3.5 dhPublicKey
* * * * Delete: (see section Error! Reference source not found.)
* * * *
* * * *
* * * * 11. Page 33. Typo. Section 4. Validation Response
* * * *
* * * * After the eight items. The following sentence has a grammar
problem:
* * * *   "Successful responses are be made when the server has fully
* * complied
* * * *    with the request".
* * * [TF] Deleted the "be"
* * * *
* * * *
* * * * 12. Page 52. Typo. Section 6 Validation Policy Response
* * * *
* * * * The second sentence is incorrect. It is:
* * * * The valPolResponse MAY not unique to any valPolRequest, ..."
* * * *
* * * * Change into:
* * * * "The valPolResponse MAY not be unique to any valPolRequest, ..."
* * * [TF] Fixed
* * * *
* * * *
* * * * 13. The abstract does not reflect accurately the content of the
* * * * document.
* * * * "certificate handling" is too vague.
* * * *
* * * * Proposed abstract:
* * * *
* * * *    SCVP allows a client to delegate certificate path
construction
* and
* * * *    certificate path validation to a server. The path
construction or
* * * *    validation (i.e. making sure that none of the certificates of
the
* * * *    path is revoked) is made according to a validation policy
which
* * * *    contains one or more trust anchors. It allows to simplify
client
* * * *    implementations and to use a set of predefined validation
* policies.
* * * [TF] Suggested text substituted
* * * *
* * * *
* * * * 14. Section 1.3
* * * *
* * * * The text on validation policy is new. There is no concept of
* * "mutually
* * * * agreed" validation policy between the client on the server. The
* * server
* * * * supports a set of validation policies which may or may not fit
the
* * need
* * * * of the client.
* * * *
* * * * Change the second sentence of section 1.3 which is:
* * * *
* * * * " In SCVP, a validation policy can be either mutually
* * * *    agreed between client and server, and subsequently referenced
in
* * * *    request, or explicitly expressed in the request by passing
all of
* * * *    the necessary parameters."
* * * *
* * * * into:
* * * *
* * * * " In SCVP, the validation policy to be used by the server can be
* * either
* * * * fully referenced in the request by the client (and thus no
* additional
* * * * parameter is necessary), referenced in the request by the client
* with
* * * * additional parameters or supported by default by the server if
the
* * * * client does not reference it."
* * * [TF] Suggested text substituted
* * * *
* * * *
* * * * 15. Section 1.3. The second paragraph needs to be reworded.
* Currently,
* * * * it is the following:
* * * *
* * * * " Policy definitions can be quite long and complex, and some
* policies
* * * *    may allow for the setting of a few parameters such as a set
of
* * * *    trust anchors.  The request can therefore be simplified if
these
* * * *    previously agreed policy dependent parameters are referenced
in
* the
* * * *    request by a mutually agreed OBJECT IDENTIFIER (OID) or URL
* value.
* * * *    The referenced value indicates either a partial or full set
of
* * * *    parameters. The client can therefore omit these agreed
parameters
* * * *    from the request, only passing any parameters which are not
* * * *    specified by the previously agreed policy.  Therefore in the
* * * *    simplest form, with validation polices which define every
* parameter
* * * *    necessary, a SCVP request need only contain the certificate
to be
* * * *    validated, the validation policy and any run-time parameters
for
* * * *    the request".
* * * *
* * * * Proposed rewording:
* * * *
* * * * " Policy definitions can be quite long and complex, and some
* policies
* * * *    may allow for the setting of a few parameters.  The request
can
* * * *    therefore be very simple if OBJECT IDENTIFIERS (OIDs) are
used to
* * * *    specify both the algorithm to be used and all the associated
* * * *    parameters of the validation policy. The request can be more
* * complex
* * * *    if the validation policy fixes many of the parameters but
allows
* * the
* * * *    client to specify some of them. When the validation policy
* defines
* * * *    every parameter necessary, a SCVP request needs only to
contain
* the
* * * *    certificate to be validated, the referenced validation policy
and
* * any
* * * *    run-time parameters for the request. In its simplest form, a
SCVP
* * * *    request contains the certificate to be validated and any
run-time
* * * *    parameters for the request. In that case the server uses a
* default
* * * *    validation policy".
* * * [TF] Suggested text substituted
* * * *
* * * *
* * * * 16. Section 1.3. Paragraph 3.
* * * *
* * * * The text is missing the fact that at least one validation policy
* must
* * * * be supported by the server. This is the default policy which is
used
* * * * when the client omits to specify it.
* * * *
* * * * The current text is the following:
* * * *
* * * *   "SCVP server also publishes its default validation policy
* settings.
* * * *    The default policy can be requested for validation and the
client
* * * *    can override any default value in the request if required.
The
* * * *    default values are also used when processing requests which
* * * *    reference a validation policy other than the default one that
* does
* * * *    not contain the full set of parameters necessary for
validation
* and
* * * *    the client has also omitted the missing values in the
request.
* * * *
* * * *    Therefore a client can also simplify the request by omitting
a
* * * *    parameter from a request if the default value published by
the
* * * *    server is acceptable".
* * * *
* * * * Replace it with:
* * * *
* * * * " A SCVP server must support a default validation policy which
will
* * * *    be used if the client does not specify any in its request. A
* server
* * * *    publishes the references of the validation policies it
supports.
* * * *    When these policies have parameters that may be overridden,
the
* * * *    default value for these parameters are communicated by the
server
* * as
* * * *    well. The client can simplify the request by omitting a
parameter
* * * *    from a request if the default value published by the server
for a
* * * *    given validation policy reference is acceptable. However if
there
* * is
* * * *    a desire to demonstrate to someone else that a specific
* validation
* * * *    policy with all its parameters has been used, it will need to
ask
* * the
* * * *    server for the inclusion of the full validation policy with
all
* the
* * * *    parameters in the response".
* * * [TF] Suggested text substituted
* * * *
* * * *
* * * * 17. On top of page 7, the relationship between the validation
policy
* * * * and the basic certification path algorithm is not explained.
Then in
* * * * section 1.4 The concept of validation algorithm is introduced
but
* its
* * * * relationship with the validation policy is not explained. This
is
* * * * confusing.
* * * *
* * * * Later on when observing the ASN.1 syntax it may be discovered
that
* two
* * * * OIDs are being used:
* * * *
* * * *   - one for the validation policy (ValidationPolRef) and
* * * *   - one for the validation algorithm (ValidationAlg).
* * * *
* * * * This is overcomplicated and unnecessary.
* * [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.
[TF] This allows the client to track if any of the data previous
published has changed without polling the server. Forcing client to poll
is very inefficient.
* * * *
* * * *
* * * * 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.
* * * *
[TF] This must be optional since cached responses cannot include this
value.
* * * *
* * * * 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
* * * *
[TF] This has been simplified along the line you describe. Validation
policies must also not define defaults for all values which also helps
in the simplification.
* * * *
* * * *
* * * * 49. Page 41. Section 4.6 requestRef
* * * *
* * * * As stated earlier, requestRef should be mandatory and always be
a
* hash
* * * * of the request.
[TF] See previous answer.
* * * *
* * * * In addition a fullRequest OPTIONAL parameter should be added as
an
* * * * optional item for CVResponse.
[TF] I don't see any value in retuning both the hash of the request and
the full request itself. If you have the full request it trivial to
calculate the hash.
* * * *
* * * * The full description of the validation policy shall be given
back in
* * * * any case, if the fullRequestInResponse Boolean in ResponseFlags
is
* * set.
[TF] SCVP 16 already does this.
* * * *
* * * * 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".
[TF] Denis, the original text is accurate, and your suggested
modification does not address the issue you raised. It is also not clear
this is a significant issue. At best it's a fairly minor denial of
service.
* * * *
* * * *
* * * * 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".
[TF] I agree the sentence needs refining and this was missed from SCVP17
but it does not protect against a replay.
* * * *
* * * *
* * * * 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.
[TF] The client can match the response to the request by comparison of
ether the hash of the request or the full request.
* * * *
* * * *
* * * * 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}
[TF] I don't see this addresses any problems or issues.
* * * *
* * * *
* * * * 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.
[TF] If the SCVP server is experiencing network problems then an client
could try another server immediately. Also anyone auditing events would
hopefully understand that if some SCVP server were experiencing network
difficulties then not all clients would have the same status whereas
when the revocation information is offline all clients will have the
same status.
* * * *
* * * * 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.
[TF] Do you mean certificateHold? In which case retrying does not seem
in the spirit of hold instructions where you either reject or call the
CA issuer.
* * * *
* * * * 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.
[TF] Same reply
* * * *
* * * *
* * * * 56. Page 48. Section 4.10.6 validationAlg
* * * * For reasons given before, delete validationAlg.
[TF] Same reply
* * * *
* * * *
* * * * 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
[TF] Since the text specify refers to the status of the certificate so
the smallest next update from a CRL would be one criteria. It is useful
in that a client could determine how long to cache a successful
validation response.

* * * * 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.
       [TF] See previous answer
* * * *
* * * * 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.
        [TF] We will just update the description to broaden the scope
beyond validation policies.
* * * *
* * * *
* * * * 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.
[TF] They are in for forwards compatibility. A client can always query
with VP=1 and find out what other capabilities the server has.
* * * *
* * * *
* * * * 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.
[TF} this is simply used by the server to indicate a configuration
change, therefore a integer is simple to implement. 
* * * *
* * * *
* * * * 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.
[TF] See previous answer.
* * * *
* * * * 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.
[TF] The server public key is now optional.
* * * *
* * * *
* * * * 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.
[TF] Deleted. We now reuse the same structure as the validation
response.
* * * *
* * * *
* * * * 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}
* * * *
[TF] This is a stylistic change so is out of scope.
* * * *
* * * *
* * * * 66. Page 56. Section 7 SCVP Server Relay
* * * *
* * * * This section is incomplete and lacking explanations. Please
explain
* * how
* * * * relaying is achieved.
[TF] Do you have specific question or area which is unclear?
* * * *
* * * *
* * * * 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.
[TF] We will add a reference to the security secion. This was missed for
SCVP17.
* * * *
* * * * 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.
[TF] We don't have this requirement for OIDs so I don't see we need it
for 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".
[TF] We use the term protect the request since the request can also be
anonymous.
* * * *
* * * * END OF COMMENTS
* * * *
* * * *