Subject: RE: SCVP 16 comments deadline

From: "Trevor Freeman" <[email-masked]>
Date: Mon, 6 Dec 2004 10:09:39 -0800

Hi Peter,
The announcement was made and documented in the SCVP 16 slides. If you
have any comments on the distribution of the minutes and slides, I
suggest you take that up with the chairs.
If you have comments on SCVP 16 can you please submit them ASAP as Denis
did.
Thanks
Trevor

* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Monday, December 06, 2004 3:39 AM
* To: Trevor Freeman; [email-masked]
* Cc: [email-masked]
* Subject: Re: SCVP 16 comments deadline
* 
* Denis and Trevor, >
* > 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.
* What announcement?
* what I can read here is:
* 
* The minutes say (17 nov)
* 
* > SCVP (version 16) - Trevor Freeman (Microsoft)
* 	Lots of changes have been made from v15; many were editorial
* > but also many substantive changes and some new features. Another rev
* > of the document will be needed. We need to ensure that the ASN.1 is
* > correct, once we agree on the functionality, and so we will compile
* > it to verify. Presentation reviewed changes and new features
* > (relative to v15). See slides for additional details.
* 
* The minutes had not been challenged by Trevor.
* 
* I cannot see any announcement on the list about that date. There
* are "no presentation files and no minutes' available in the IETF
* server.
* 
* According to my understanding of how IETF working groups
* function, an announement during a meeting is non-existant
* if not reflected in the mailing list message.
* 
* (It may be that someone filters the content of the imc server for me).
* 
* Peter

---

From: "Trevor Freeman" <[email-masked]>
Date: Mon, 6 Dec 2004 10:06:12 -0800

Hi Denis,
Thanks for these comments. I will replay in detail shortly.
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".
* 
* 
* 2. Page 11. Typos. First paragraph on top of the page.
* Replace "signers" by "signer's".
* 
* 
* 3. Page 11. Typo. First paragraph on top of the page. Last sentence.
* Replace "certificate" by "certificates".
* 
* 
* 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.
* 
* 
* 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.
* 
* 
* 6. Page 24. Typo. Section 3.1.5.9 keyUsages
* 
* Change "keyUasge" into "keyUsage".
* 
* 
* 7. Page 27. Typo. Section 3.1.8 valididationTime
* Last line of the first paragraph. Change "servers" into "server's"
* 
* 
* 8. Page 32. Typo. Section 3.5 dhPublicKey
* Change: Diffie-Hellamn into Diffie-Hellman.
* 
* 
* 9. Page 32. Typo. Section 3.5 dhPublicKey
* Fifth line. Change "an does" into "and does"
* 
* 
* 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".
* 
* 
* 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, ..."
* 
* 
* 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.
* 
* 
* 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."
* 
* 
* 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".
* 
* 
* 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".
* 
* 
* 17. On top of page 7, the relationship between the validation policy
* and the basic certification path algorithm is not explained. Then in
* section 1.4 The concept of validation algorithm is introduced but its
* relationship with the validation policy is not explained. This is
* confusing.
* 
* Later on when observing the ASN.1 syntax it may be discovered that two
* OIDs are being used:
* 
*   - one for the validation policy (ValidationPolRef) and
*   - one for the validation algorithm (ValidationAlg).
* 
* This is overcomplicated and unnecessary.
* 
* An important simplification is obtained if, as the previous text
* states, there is an OID to defined the validation policy and there may
* be or may not be additional parameters.
* 
* We could then have:
* 
* valPolByOID::= SEQUENCE {
*        valPolId              OBJECT IDENTIFIER,
*        parameters            ANY DEFINED BY ValPolId OPTIONAL }
* 
* Specifying a path processing compliant with section 6.1 of RFC 3280
* would be possible (notice however that the text from RFC 3280 is too
* vague to support the case where a CRL is not signed by the CA).
* 
* It would be desirable to be able to communicate easily and in a
* standard way the parameters that may be set in section 6.1 from RFC
* 3280. In addition, key usage should be added to that list.
* 
* The document should then define a bundle of all these previous useful
* parameters and allow for the addition of other parameters.
* 
* It is thus proposed to define an OID for a validation policy compliant
* with section 6.1 of RFC 3280 (some differences with section 6 from
* 3280bis, i.e. adding precision, may be expected)
* 
* It is thus proposed to modify the text starting from :
* 
* " The inputs to the basic certification path processing algorithm
*    used by SCVP are defined by [PKIX-1] in section 6.1.1 and comprise"
*    up to the end of section 1.3 with the following:
* 
* "For clients able to specify the parameters of a validation policy, it
* may be useful to define a standard data structure (using a bundle)
able
* to support the parameters of the basic certification path processing
* algorithm defined by in section 6.1.1 from [PKIX-1] :
* 
*   - a set of Trust Anchors (by value or by reference),
*   - the initial Certificate Policy set,
*   - initial Certificate Policy mapping setting,
*   - initial any-Policy setting,
*   - initial explicit Certificate Policy setting.
* 
* as well as :
* 
*    - the usage of the key contained in the certificate (e.g., key
*      encipherment, key agreement, signature)
* 
* This will be done using a bundle which encapsulates all these
* parameters.
* 
* Other application-specific purposes parameters may be added".
* 
* 
* 18. Section 1.4 is about a "Validation Algorithm". Given what was said
* before, the header of this section should be changed. If we make a
* subsection 1.3.1 called "1.3.1. General" for encapsulating the
previous
* text, then we can introduce a new section 1.3.2 called:
* 
* "1.3.2. Validation policy according to section 6.1 of RFC 3280"
* 
* Some of the text present in the current section 1.4 has been used to
* build the new text that is proposed below:
* 
* "1.3.2. Validation policy according to section 6.1 of RFC 3280
* 
*    SCVP defines a specific validation policy which implements the
*    certification path validation algorithm as defined in section 6.1
of
*    [PKIX-1]. This specific validation policy, called "rfc-3280 basic
*    validation policy" uses the parameters defined in the bundle
*    mentioned above.
* 
*    Note that this algorithm does not support in its full generality
the
*    algorithm described in section 6.2 of [PKIX-1] since, when more
than
*    one trust anchor is being defined, all the conditions that are
*    specified apply to all trust anchors, whereas section 6.2 allows to
*    have different conditions for every trust anchor.
* 
*    The rfc-3280 basic validation policy may be the default validation
*    policy supported by the server, but does not need to".
* 
* 
* 19. Section 2 "Protocol Overview"
* 
* In order to allow for interoperability and testing a common protocol
* needs to be supported. It should be defined.
* 
* 
* 20. Section 3 "Validation Request"
* 
* The unsigned request form is not explained and there is a confusion
for
* the signed request which indeed authenticates the client and is thus
* not anonymous. The current text is :
* 
*    "A signed
*    request is used to authenticate the client to the server or to
*    provide an anonymous client integrity over the request-response
*    pair."
* 
* It should be rephrased as:
* 
*    "An unsigned request provides an anonymous client integrity over
*     the request since the hash of the request or the full request is
*     incorporated in the response. A signed request is used to
*     authenticate the client to the server".
* 
* 
* 21. Page 13. Section 3.1.2 "checks"
* 
* The following sentence adds nothing and should be removed:
* 
*    "A server may still choose to
*    perform revocation status checks when performing path construction,
*    although this information cannot be returned to the client."
* 
* 
* 22. Page 15. Section 3.1.3 "wantBack"
* 
* The text states:
* 
*      - Proof of revocation status for each certificate in the AC
*         issuer certification path;
* 
* It would be important to refer the section of the RFC which explains
* how to
* check the "revocation status for each certificate in the AC issuer
* certification path".
* 
* 
* 23. Page 15. Section 3.1.3 "wantBack"
* 
* The text states:
* 
*    The client can also request a non-cached response to the request by
*    including wantback id-swb-non-cached-resp in the request.
* 
* The default behavior should be the reverse: fresh information is
* provided, unless the client accept cached information. The item should
* be changed into:
* id-swb-cached-resp
* 
* 
* 24. Page 15. Section 3.1.3 "wantBack"
* 
* The text states:
* 
* id-swb-pkc-all-valid-cert-paths OBJECT IDENTIFIER ::= { id-swb 13}
* 
* It should be mentioned that this item is only possible for DPD.
* 
* 
* 25. Page 16. Section 3.1.4 validationPolicy
* 
* The following sentence is talking of an agreement whereas such
* agreement does not exist. Delete the sentence:
* 
*   "The client and server can optionally agree on a set of parameters
*    which may fully or partially define a validation policy".
* 
* 
* 26. Page 16. Section 3.1.4 validationPolicy
* The text states:
* 
*    "If a partial set of parameters has been agreed upon,
*    then the client supplies a reference to the policy plus whatever
*    parameters are necessary to complete the request in this item.
* 
* This should be replaced with:
* 
*    "If the validation policy does not define all parameters necessary
*    for processing an SCVP request, then the client need to supply
these
*    parameters".
* 
* 27. Page 16. Section 3.1.4 validationPolicy
* 
*    The syntax of the validationPolicy item is defined as:
* 
*    ValidationPolicy ::= SEQUENCE {
*      validationPolRef          ValidationPolRef,
*      validationAlg         [0] ValidationAlg OPTIONAL,
*      userPolicySet         [1] SEQUENCE SIZE (1..MAX) OF OBJECT
*                                  IDENTIFIER OPTIONAL,
*      inhibitPolicyMapping  [2] BOOLEAN OPTIONAL,
*      requireExplicitPolicy [3] BOOLEAN OPTIONAL,
*      inhibitAnyPolicy      [4] BOOLEAN OPTIONAL,
*      isCA                  [5] BOOLEAN OPTIONAL,
*      trustAnchors          [6] TrustAnchors OPTIONAL,
*      keyUsages             [7] SEQUENCE SIZE (1..MAX) OF KeyUsage
*                                   OPTIONAL,
*      extendedKeyUsages     [8] ExtKeyUsageSyntax OPTIONAL}
* 
* 
* This structure is quite odd, because it only allows to pass additional
* parameters as parameters of the validationAlg. Suppressing the
* validationAlg item add adding validationParamExtensions would be a
* simpler and cleaner way.
* 
* Each validation policies uses its own parameters.
* We should have something like :
* 
* ValPolByOID  ::= SEQUENCE {
*        valPolgId             OBJECT IDENTIFIER,
*        parameters            ANY DEFINED BY valPolId OPTIONAL }
* 
* More details follow.
* 
* 
* 28. It is highly debatable if URIs should be supported or not to
* reference a validation policy. URIs are not stable over time and thus
* unless there are dereferenced and a hash value is computed over them,
* it is insecure to use them. There is a discussion in the security
* consideration section, but no warning and no pointer here. If we keep
* them, we should warn the user.
* 
* If the WG should decides that they should be supported (and if the
IESG
* agrees) on page 17, the ASN.1 description should then be:
* 
* ValidationPolicy ::= CHOICE {
*      valPolByOID         [0] ValPolByOID,
*      valPolByURI         [1] ValPolByURI }
* 
* ValPolByOID  ::= SEQUENCE {
*        valPolgId             OBJECT IDENTIFIER,
*        parameters            ANY DEFINED BY valPolId OPTIONAL }
* 
* ValPolByURI ::= SEQUENCE {
*      uri            IA5String,
*      hashAlgo       OBJECT IDENTIFIER,
*      hashValue      OCTET STRING}
* 
* 
* 29. It is proposed to define the following bundle:
* 
* ValidationParamBundle ::= SEQUENCE {
*      certificatePolicySet      [0] SEQUENCE SIZE (1..MAX) OF OBJECT
*                                    IDENTIFIER OPTIONAL,
*      inhibitPolicyMapping      [1] BOOLEAN OPTIONAL,
*      requireExplicitPolicy     [2] BOOLEAN OPTIONAL,
*      inhibitAnyPolicy          [3] BOOLEAN OPTIONAL,
*      isCA                      [4] BOOLEAN OPTIONAL,
*      trustAnchors              [5] TrustAnchors OPTIONAL,
*      keyUsages                 [6] SEQUENCE SIZE (1..MAX) OF KeyUsage
*                                    OPTIONAL,
*      extendedKeyUsages         [7] ExtKeyUsageSyntax OPTIONAL
*      extensions                [8] EXPLICIT Extensions OPTIONAL }
* 
* Note that userPolicySet" is unclear and has been changed into
* "certificatePolicySet".
* 
* The text would need to be aligned with the new structure and, of
course
* the parameters of the rfc-3280 basic validation policy will simply
* include the bundle above as its parameters.
* 
* It should also be mentioned somewhere in the document that the support
* of the rfc-3280 basic validation policy is not mandatory for
* conformance but, if supported then the bundle needs to be supported.
* 
* 
* 30. Page 17. Section 3.1.5 validationAlg should be deleted.
* 
* 
* 31. Page 17. Section 3.1.5.1 Default Validation Algorithm should be
* deleted and replaced by a section later on the "rfc-3280 basic
* validation policy", which should have its OID defined under the scvp
* tree for OIDs.
* 
* 
* 32. Page 17. Section 3.1.5.1. Some text of this section might be re-
* sued to build a new section on the rfc-3280 basic validation policy.
* Note that the last sentence at the bottom of page 17, should be
* removed. This sentence is: "The default validation policy MUST use the
* basic validation algorithm". Any default validation policy can be
used.
* 
* 
* 33. Page 17. Section 3.1.5.2 validationAlg (same title as 3.1.5 !)
* should be as well deleted.
* 
* 
* 34. Page 20. Section 3.1.5.2.3 Name Validation Algorithm
* 
* This goal of this section seems to introduce an additional test to the
* basic "rfc-3280 basic validation policy". It would come naturally as
an
* extension of ValidationParamBundle, rather than as a parameter of the
* validationAlgo which has been proposed to be removed. The text should
* be modified accordingly.
* 
* 
* 35. Page 21. Section 3.1.5.2.3 Name Validation Algorithm
* 
*      NameValidationAlgParms ::= SEQUENCE {
*        keyPurposeId      KeyPurposeId,
*        validationNames   GeneralNames }
* 
* This construct is artificial since KeyPurposeId is about the Extended
* Key Usage and has nothing to do with name validation.
* 
* It could indeed be interesting to test the Extended Key Usage
extension
* of a certificate, but this should be supported as an extension of
* ValidationParamBundle. The text should be modified accordingly.
* 
* 
* 36. Page 22. Section 3.1.5.3 userPolicySet
* 
* userPolicySet should be changed everywhere into certificatePolicySet.
* 
* 
* 37. Page 22. Section 3.1.5.3 userPolicySet
* 
* The text has many sentences like:
* 
*    SCVP clients SHOULD support userPolicySet item in requests, and
*    SCVP servers MUST support userPolicySet item in requests.
* 
* These requirements only apply for the rfc-3280 basic validation
policy,
* and this should be clearly mentioned.
* 
* 
* 38. Page 22. Section 3.1.5.4 inhibitPolicyMapping
* 
* The text states:
* 
*    By default the server allows policy mapping as
*    part of certification path validation.
* 
* For simplicity, this should be the reverse. Replace with:
* 
*   "By default the server does not perform policy mapping as
*    part of certification path validation. If the client wants the
*    server to support policy mapping, allowPolicyMapping must be set
*    to TRUE in the request".
* 
* 
* 39. Page 24. Section 3.1.5.8 trustAnchors
* 
* The text states:
* 
*   "A certificate reference can be used to identify the
*    trust anchor by certificate hash and optionally a distinguished
*    name with serial number".
* 
* This is not consistent with the ASN.1 definition of PKCReference which
* is:
* 
*    PKCReference ::= CHOICE {
*      cert                   [0] Certificate,
*      pkcRef                 [1] ESSCertID }
* 
* Please correct.
* 
* 
* 40. Page 25. Section 3.1.6 responseRefHash
* 
* The text states:
* 
*    "By default, the server includes a hash
*    of the request in the response.  If the client wants the server to
*    include the full request in the response, responseRefHash is set to
*    FALSE."
* 
* The server shall always include a hash of the request in the response.
* This is an easy way to allow to test the integrity of the request.
* Since the full description of the validation policy may be much longer
* a flag should be used to say that the full validation policy is not
* returned unless requested. It is thus proposed to have instead the
* following:
* 
* "3.1.6.1 fullRequestInResponse
* 
*    The fullRequestInResponse controls if the client wants the server
*    to include the full request in the response. By default,
*    fullRequestInResponse is set to FALSE. If the client wants back
*    the full request then it must set this parameter to TRUE. The main
*    reason a client would request the server to include the full
request
*    in the response is to archive the request-response exchange in a
*    single object.  That is, the client wants to archive a single
object
*    which includes both request and response".
* 
* 
* 41. Page 26. Section 3.1.6.2 responseValidationPolByRef
* 
* This item should be renamed: fullValPolInResponse
* 
* The text should be changed into:
* 
* "The fullValPolInResponse controls whether the response includes the
* identifier of the validation policy with all the parameters that have
* been used by the server, i.e. all the variable parameters independent
* from the fact that there were specified by the client or defaulted if
* not specified. By default, fullValPolInResponse is set to FALSE. If
the
* client wants the full validation policy to be included, then
* fullValPolInResponse is set to TRUE. The main reason a client would
* request the server to include validation policy to be included by
value
* is to archive the request-response exchange in a single object. That
* is, the client wants to archive the CVResponse and have it include
* every aspect of the validation policy."
* 
* The ResponseFlags should be changed as follows:
* 
*    ResponseFlags ::= SEQUENCE {
*      fullRequestInResponse      BOOLEAN DEFAULT FALSE,
*      fullValPolInResponse       BOOLEAN DEFAULT FALSE,
*      signResponse               BOOLEAN DEFAULT TRUE }
* 
* 
* 42. Page 28. Section 3.1.9 intermediateCerts. Minor.
* 
* Change:
* 
*    The optional intermediateCerts item helps the SCVP server create
*    valid certification paths.
* 
* into:
* 
*    The optional intermediateCerts item may help the SCVP server to
* create
*    valid certification paths.
* 
* 43. Page 29. Section 3.1.11. producedAt
* 
* Last sentence. Change:
* 
*    SCVP server SHOULD support the producedAt values in the request.
* 
* into:
* 
*    SCVP server MAY support the producedAt values in the request.
* 
* Reason: cached responses should not need to be implemented in order to
* be compliant with the specification.
* 
* 
* 44. Page 32. Section 3.5 dhPublicKey
* 
* The text states:
* 
*   "For the server to compute the shared
*    secret, it must lean the public values the client generates,
*    therefore the client MUST include this in the request if it uses
*    this mechanism to integrity protect the request-response pair."
* 
* Replace:
* 
* "to integrity protect the request-response pair"
* 
* with :
* 
* "to authenticate and integrity protect the first response and
* authenticate and integrity protect subsequent request-response pairs".
* 
* 45. Page 32. Section 3.6 SCVP Request Authentication
* 
* The text states:
* 
*   "It is a matter of local policy what validation policy is used by
*    the server when validating requests".
* 
* This sentence could be misinterpreted because the word "validating" is
* being used. Change into:
* 
*    It is a matter of local policy what validation policy is used by
*    the server when authentication requests".
* 
* 
* 46. Page 35. Section 4. Validation Response
* 
*    The CVResponse is defined as follows:
* 
*      CVResponse ::= SEQUENCE {
*        cvResponseVersion         cvResponseVersion        INTEGER,
*        policyID                  INTEGER,
*        producedAt                GeneralizedTime,
*        ....
* 
* On the next page the test states:
* 
*   "The policy ID used by the SCVP server when it processed the
request.
*    See section 6.4 for details."
* 
* In section 6.4 the text states:
* 
* "6.4 defaultPolicyID
* 
*    An integer that uniquely represents the version of the default
*    validation policy as represented by the trustAnchors, ..."
* 
* This is not understandable, over-engineering and very complicated.
* Please delete this item.
* 
* 
* 47. Page 35. Section 4. Validation Response
* 
*    The CVResponse contains:
* 
*        requestRef            [1] RequestReference OPTIONAL,
* 
* Remove "OPTIONAL" since it is very beneficial to mandate this item
* since it allows to make sure that the request has not be modified if
* the response is integrity protected. The computation is fast and easy
* and the hash value does not overload the response.
* 
* 
* 48. Page 38. Section 4.5 respValidationPolicy
* 
* The definition of this item is overcomplicated and not tailored to
* support any kind of validation policy.
* 
* If the client does not specify the validation policy or if the client
* specifies a validation policy which has default parameters, then the
* full description of the validation policy shall be given back.
* 
* If the client specifies a validation policy which has no default
* parameters, then the reference and parameters, if any, of the
* validation policy are in the request.
* 
* The full description of the validation policy shall be given back in
* any case, if the fullValPolInResponse Boolean in ResponseFlags is set.
* 
* respValidationPolicy :: = ValidationPolicy
* 
* 
* 
* 49. Page 41. Section 4.6 requestRef
* 
* As stated earlier, requestRef should be mandatory and always be a hash
* of the request.
* 
* In addition a fullRequest OPTIONAL parameter should be added as an
* optional item for CVResponse.
* 
* The full description of the validation policy shall be given back in
* any case, if the fullRequestInResponse Boolean in ResponseFlags is
set.
* 
* Change the text and the syntax accordingly.
* 
* 
* 50. Page 41. Section 4.6 requestRef
* 
* The text states:
* 
*    "The requestRef item allows the client to associate a response with
*    a request"
* 
* This is wrong. This does not protect against a replay.
* 
* Change with:
* 
* "When the response is authenticated, the requestRef item allows the
* client to make sure that the request was not modified in transit".
* 
* 
* 51. Page 41. Section 4.6 requestRef
* 
* The text states:
* 
* " The requestNonce provides an alternative mechanism for
*    matching requests and responses if the client has selected to
*    include a full response."
* 
* This is wrong. This is not an alternative for matching requests and
* responses.
* 
* Replace with:
* 
*   "The requestNonce allows to protect against replay, even if time
* synchronization is not good between the client and the server".
* 
* 
* 52. Page 42. Section 4.6.1 requestHash
* 
* The text states:
* 
* " The requestNonce provides an alternative mechanism for matching
* requests and responses".
* 
* This is wrong. See above. Delete.
* 
* 
* 53. Page 45. Section 4.10.4 replyChecks
* 
* ReplyCheck is defined as:
* 
*      ReplyCheck ::= SEQUENCE {
*        check                      OBJECT IDENTIFIER,
*        status                     INTEGER }
* 
* It should be defined as:
* 
*      ReplyCheck ::= SEQUENCE {
*        check                      OBJECT IDENTIFIER,
*        status                     INTEGER DEFAULT 0}
* 
* 
* 54. Page 46. Section 4.10.4 replyChecks
* 
* The text states
* 
*    "The status value for public key certification path building to a
*    trusted root along with complete status checking, { id-stc 3 }, can
*    be one of the following:
* 
*        0: Good
*        1: Revoked
*        2: Revocation Offline
*        3: Revocation Unavailable
* 
* It is unclear to understand the benefits that a client can have from
* the difference between "Revocation Offline" and "Revocation
* Unavailable". In addition, these wordings do not match the
explanations
* of what there are.
* 
* A much more important response is missing: suspended. Suspended is a
* variation of revoked, but the client then knows it may attempt another
* try later on.
* 
* It is thus suggested to change it into:
* 
*        0: Good
*        1: Revoked
*        2: Suspended
*        3: Revocation info unavailable"
* 
* 
* 55. Page 46. Section 4.10.4 replyChecks
* 
* 
* The same comment applies for the status value for AC issuer
* certification path.
* 
* 
* 56. Page 48. Section 4.10.6 validationAlg
* For reasons given before, delete validationAlg.
* 
* 
* 57. Page 48. Section 4.10.8 nextUpdate
* 
* If CRLs are used, should this field contain the value of the next
* update field for the smallest value of all the CRLs ? What is the real
* benefit of supporting this element besides added complexity ? It is
* suggested to delete that item.
* 
* 
* 58. Page 49. Section 4.11 responseNonce
* 
* The text states:
* 
* "The responseNonce item contains an identifier to binds the request
* to the response."
* 
* This is incorrect. The nonce is to detect replay.
* 
* Change into:
* 
* "The responseNonce item contains a unique number which allows to
detect
* replay".
* 
* 
* 59. Page 51. Section 5 Server Policy Request
* 
* The text states:
* 
*   "A SCVP client uses the valPolRequest item to request the list of
*    validation policies supported by the SCVP server."
* 
* This is not a correct description of what this request is doing. When
* looking at the ASN.1 it is doing much more. So the question is whether
* two requests should be provided or one. In the later case, it is
* important to advertise correctly what the request is doing.
* 
* 
* 60. Page 52. Section 6 Validation Policy Response
* 
* The ASN.1 of the VPResponse is over-complicated.
* 
* The first three items are overengineering:
* 
*        vpResponseVersion          INTEGER,
*        maxCVResponseVersion       INTEGER,
*        maxVPResponseVersion       INTEGER,
* 
* Further more they are mandatory. Please delete.
* 
* 
* 61. Page 52. Section 6 Validation Policy Response
* 
* The ASN.1 of the VPResponse is over-complicated.
* 
*         defaultPolicyID            INTEGER,
* 
* This item does not make sense. When an OID references a validation
* policy, there is no concept of versioning. Another version will simply
* get another OID (hopefully in the same branch). Please delete.
* 
* 
* 62. Page 52. Section 6 Validation Policy Response
* 
* The ASN.1 of the VPResponse is over-complicated.
* 
*        validationPolices          SEQUENCE OF ValidationPolRef,
*        validationAlgs             SEQUENCE OF OBJECT IDENTIFIER,
* 
* validationAlgs is unnecessary. Please delete.
* 
* validationPolicies (not validationPolices) is the main component. See
* below for a full proposal for restructuring VPResponse.
* 
* 
* 63. Page 52. Section 6 Validation Policy Response
* 
*        authPolicies               SEQUENCE OF AuthPolicy,
*        responseTypes              ResponseTypes,
*        dhPublicKeyInfo            SEQUENCE OF DHPublicKeyInfo,
* 
* are elements which have nothing to do with the list of validation
* policies, and they are mandatory ! Either group them in one OPTIONAL
* item or define another command to get them.
* 
* 
* 64. Page 52. Section 6 Validation Policy Response
* 
*       defaultPolicyValues        ValidationPolValues,
* 
* This is simply the set of parameters which are related to the rfc-3280
* basic validation policy. This set could be used by other validation
* policies. Please delete.
* 
* 
* 65. Page 52. Section 6 Validation Policy Response
* 
* What follows is a sketch for a proposal for VPResponse.
* 
*     VPResponse ::= SEQUENCE {
*        requestNonce               OCTET STRING      OPTIONAL
*        thisUpdate                 GeneralizedTime,
*        nextUpdate                 GeneralizedTime   OPTIONAL,
*        validationPolicies         SEQUENCE OF ValidationPolicy,
*        serverParams               ServerParams      OPTIONAL }
* 
* 
*     ServerParams ::= SEQUENCE {
*        responseTypes              ResponseTypes,
*        authPolicies           [0] SEQUENCE OF AuthPolicy
OPTIONAL,
*        dhPublicKeyInfo        [1] SEQUENCE OF DHPublicKeyInfo
OPTIONAL,
*        clockSkew              [2] INTEGER OPTIONAL }
* 
* Note: it is re-called that ValidationPolicy should be redefined as:
* 
* ValidationPolicy ::= CHOICE {
*      valPolByOID         [0] ValPolByOID,
*      valPolByURI         [1] ValPolByURI }
* 
* ValPolByOID  ::= SEQUENCE {
*        valPolgId             OBJECT IDENTIFIER,
*        parameters            ANY DEFINED BY valPolId OPTIONAL }
* 
* ValPolByURI ::= SEQUENCE {
*      uri            IA5String,
*      hashAlgo       OBJECT IDENTIFIER,
*      hashValue      OCTET STRING}
* 
* 
* 
* 66. Page 56. Section 7 SCVP Server Relay
* 
* This section is incomplete and lacking explanations. Please explain
how
* relaying is achieved.
* 
* 
* 67. Page 65. Section 9 Security Considerations
* 
* In the second paragraph, there is a discussion about the use of URIs
to
* reference validation policies.
* 
* Firstly, if URIs are going to stay, a pointer to the security
* consideration section should be present in the main body of the
* document.
* 
* Secondly, the text should mention the need for the ability to
* dereference the URI and the need to compute a hash, while the main
body
* of the document should explain the computation of a hash on the
content
* of the URI.
* 
* 
* 68. Page 65. Section 9 Security Considerations
* 
* The text states:
* 
*   "It can also do this by using the Diffie-hellman keys to sign the
* request".
* 
* Replace "sign" by "authenticate".
* 
* END OF COMMENTS
* 
*

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 6 Dec 2004 19:09:13 +0100 (MET)

I am quite pleased that about the addition
of requestorName in the responsea and that 
the convention of  consecutive null terminated
strings in a requestorRef have been replaced,

But: 

The syntax is GeneralNames. how many ids is the server intended
to extract from a certificate? The subject + all alternate ids?

Why not having this id declared by the client, and the authentication
methods matches against it. ==> Add a corresponding field in the request.
Which is required: 

   When the DPV request is authenticated, the client SHOULD be able to
   include a client identifier in the request for the DPV server to copy
   into the response.  Mechanisms for matching this identifier with the
   authenticated identity depends on local DPV server conditions and/or
   the validation policy.  The DPV server MAY choose to blindly copy the
   identifier, omit the identifier, or return an error response.

It is an identifer identifying the client and not the request. 

The new text replacing "requestor" in chapter 7 by "requestorRef".

> however, 
>  all of the octets MUST have values other than zero. 
Why? I would find it quite useful to add a 
hash of something local, if at all, the hash of its IP address for example
(for which I can use the Nonce as well).  

  The requestRef item allows the client to associate a response with 
  a request.  The requestNonce provides an alternative mechanism ..

  and you have also the requestorRef. 

The concept of trying to make loop control with values which are explicitely 
defined as not globally unique sounds strange to me.

 "The requestorRef item is also needed 
  to prevent looping in some configurations" 

 "No provisions are 
  made to ensure uniqueness of the requestorRef octet string"

The usefulness of "requestorRef" as an identifier for the request
is pretty weak, since you can have a nonce if it is for each
request. use GeneralName(s) in a requestorName sequence as for the
response. 

page 34:

  The requestorRef and the responder items MUST be included if the request included a 
  requestor item. 

what does this mean? what is the relationship between a requesterRef and responder?  

If I'd be interested in anything identifying the response, then it is
a sequence of identifiers of the servers that have partipated, and some
local ids or "serial number' like thing if I want to go to that server and
asks 'did you really tell this to my friend'.  

Chapter 7: Denis is right that the spec does not describe how relaying is
performed, i.e. how a response is created from a response received from another
server by a 'proxy'.

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 6 Dec 2004 19:27:18 +0100 (MET)

> suggest you take that up with the chairs.

No, there are no slides available. (see below XX) 

> * The minutes had not been challenged by Trevor.

You have made a statement about what you might or might not have
presented in the meeting, and you are discriminating people that
were present in the meeting from those who only read the mailing list.

I request you to present your excuses for ignoring mailing list participants
not having the microsoft travel budget possibilities. 

It is not up to other mailing list participants to guess, and you
were certainly able to detect whether the slides were made available
since, and furthermore, if you would really believe that this is
important, you could have announced the date by yourself (unless
you don't want to interfere with the chairmen's work, which you did
by announcing the end of the deadline.

XX: Besides that, I agree with you that not distributing the slides and
refering to them in minutes is not exactly professional work.

I have started some comments. 

Peter

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 7 Dec 2004 13:14:38 +0100 (MET)

We have

  Query ::= SEQUENCE { 
   queriedCerts               SEQUENCE SIZE (1..MAX) OF CertReference, 

   ...
   validationPolicy           ValidationPolicy, 

with 
  ValidationPolicy ::= SEQUENCE { 
    ...
    validationAlg         [0] ValidationAlg OPTIONAL, 

3.1.5 validationAlg 
   
  The validationAlg item, defines the validation algorithm to be used 
  by the SCVP server during certificate validation.  The value of 
  this item can be determined by agreement between the client and the 
  server, and is represented as an object identifier.  The server 
  might want to assign additional object identifiers that indicate 
  that some settings are used in addition to others given in the 
  request.  In this way, the validation algorithm object identifier 
  can be a shorthand for some SCVP options, but not others. 
   
  The validationAlg item uses the ValidationAlg type, which has the 
  following syntax: 
   
    ValidationAlg ::= SEQUENCE { 
      valAlgId              OBJECT IDENTIFIER, 
      parameters            ANY DEFINED BY valAlgId OPTIONAL } 

and also

3.1.5.2 validationAlg 
   
  The optional validationAlg item defines the validation algorithm to 
  be used by the SCVP server during certificate validation.  The 
  value of this item can be determined by agreement between the 
  client and the server, and the validation algorithm is represented 
  by an object identifier. 
   
   The syntax of the validationAlg is: 
   
    ValidationAlg ::= SEQUENCE { 
      valAlgId              OBJECT IDENTIFIER, 
      parameters            ANY DEFINED BY valAlgId OPTIONAL } 
   
  The following section specifies the basic validation algorithm and 
  the name validation algorithm.  SCVP clients and servers MUST 
  support both validation algorithms defined in this section.  Other 
  validation algorithms can be specified in other documents for use 
  with specific applications.  SCVP clients and servers MAY support 
  any such validation algorithms.  

---------------

3.1.5.2.3 Name Validation Algorithm 
   
  The name validation algorithm allows the client to supply an 
  application identifier and a name to the server.  The application 
  identifier defines the name matching rules to use in comparing the 
  name supplied in the request with the names in the certificate. 

There may be more than one certificate in the request. 

    NameValidationAlgParms ::= SEQUENCE { 
      keyPurposeId      KeyPurposeId, 
      validationNames   GeneralNames } 

What is the relation between the KeyPurposeId and the extendeddkeyusage
3.1.5.10 extendedKeyUsages 

  If the keyPurposeID supplied in the request is id-kp-mailProtection 
  [PKIX-1], then GeneralNames supplied in the request MUST be a 
  rfc822Name, and the matching rules are defined in [SMIME-CERT]. 

'an rfc822Name".

what is the meaning of this if I have more than one email certificate,
i.e. I want to validate all encryption certs before using them. 

Does this means that the validate Algorithm is cert specific and not
request specific?

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 7 Dec 2004 13:14:46 +0100 (MET)

To have an independant issue:

4.8 requestorName 
   
  The optional requestorName item is used by the server with signed 
  requests to return the identity of the client in the response.  
  Mechanisms for matching this identifier with the authenticated 
  identity are a matter of local server policy. 
   
  In the case of non-cached responses to signed requests, the SCVP 
  server MUST return a requestor name.  A server SHOULD copy the 
  selected identifier from a certificate or other credential used to 
  authenticate the request.  A SCVP server MAY use a client 
  identifier from an out-of-band mechanism or omit the identifier 
  from the response. 
   
  In the case of cached responses to signed requests, the 
  RequestorName MAY be present in the response. 
   
  SCVP server that supports signed requests MUST support this item.

This chapter is new and pretty uncomprehensible:

"matching" is IMO an action where you have two inputs, I don't see
where the identifier comes from, or when it is extracted from
some authenticated information, why there is a "matching" at all. 
"The identity" of the client is not defined anywhere in the document.

The 3379 text says:

   the validation policy.  

The client has no way to declare its identity in the protocol, 
and there no provision of what this could be from what it would
be derived from (IP address, DNS name of the host, ...), ...

Why is this restricted to signed requests, and not to 'authenticated'?

As already said in another may, this text could make sense if there
would be a corresponding requestorName in the request.

---

From: "Trevor Freeman" <[email-masked]>
Date: Tue, 7 Dec 2004 17:10:41 -0800

Hi Peter,
See below for answers
Trevor
* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Monday, December 06, 2004 10:09 AM
* To: Trevor Freeman
* Cc: [email-masked]
* Subject: Re: SCVP 16 comments deadline
* 
* 
* I am quite pleased that about the addition
* of requestorName in the responsea and that
* the convention of  consecutive null terminated
* strings in a requestorRef have been replaced,
* 
* But:
* 
* The syntax is GeneralNames. how many ids is the server intended
* to extract from a certificate? The subject + all alternate ids?
* 
* Why not having this id declared by the client, and the authentication
* methods matches against it. ==> Add a corresponding field in the
request.
* Which is required:
* 
*    When the DPV request is authenticated, the client SHOULD be able to
*    include a client identifier in the request for the DPV server to
copy
*    into the response.  Mechanisms for matching this identifier with
the
*    authenticated identity depends on local DPV server conditions
and/or
*    the validation policy.  The DPV server MAY choose to blindly copy
the
*    identifier, omit the identifier, or return an error response.
* 
* It is an identifer identifying the client and not the request.
[TF] If the client sends a signed request with certificate it has
included a client identifier in the request. Its matter of local server
policy which name it chooses to return.
* 
* The new text replacing "requestor" in chapter 7 by "requestorRef".
* 
* > however,
* >  all of the octets MUST have values other than zero.
* Why? I would find it quite useful to add a
* hash of something local, if at all, the hash of its IP address for
example
* (for which I can use the Nonce as well).
[TF] If you want me to remove the clause about values being other than
zero - I am happy to do so. Since this is of local significance only, if
an implementation puts garbage in here it does not effect
interoperability.
* 
*   The requestRef item allows the client to associate a response with
*   a request.  The requestNonce provides an alternative mechanism ..
* 
*   and you have also the requestorRef.
* 
* The concept of trying to make loop control with values which are
* explicitely
* defined as not globally unique sounds strange to me.
[TF] I have a big problem which the concept of global uniqueness. I
class it the same bucket as non-repudiation. 
* 
*  "The requestorRef item is also needed
*   to prevent looping in some configurations"
* 
*  "No provisions are
*   made to ensure uniqueness of the requestorRef octet string"
* 
* The usefulness of "requestorRef" as an identifier for the request
* is pretty weak, since you can have a nonce if it is for each
* request. use GeneralName(s) in a requestorName sequence as for the
* response.
* 
* page 34:
* 
*   The requestorRef and the responder items MUST be included if the
request
* included a
*   requestor item.
* 
* what does this mean? what is the relationship between a requesterRef
and
* responder?
[TF] If requestorRef is populated, it means it's a relayed request in
which case the responder is of significance.
* 
* If I'd be interested in anything identifying the response, then it is
* a sequence of identifiers of the servers that have partipated, and
some
* local ids or "serial number' like thing if I want to go to that server
and
* asks 'did you really tell this to my friend'.
* 
* 
* Chapter 7: Denis is right that the spec does not describe how relaying
is
* performed, i.e. how a response is created from a response received
from
* another
* server by a 'proxy'.
[TF] What specifically are you looking for?
* 
* 
* 
* 
*

---

From: "Trevor Freeman" <[email-masked]>
Date: Tue, 7 Dec 2004 17:20:01 -0800

Hi Peter,
All parameter assonated with policy mapping are names the same. If you
want guidance on their use in combination with the policy reference see
section 1.3.
SCVP only supports one policy per request therefore if you want to
process different polices for different certificates - send different
requests.
Trevor

* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Tuesday, December 07, 2004 4:15 AM
* To: Trevor Freeman
* Cc: [email-masked]
* Subject: Re: SCVP 16 comments deadline
* 
* There are several boolean values like
* 
*   ValidationPolicy ::= SEQUENCE {
*     ...
*     inhibitPolicyMapping  [2] BOOLEAN OPTIONAL,
* 
* and a policy definition.
* 
*   ValidationPolValues ::=SEQUENCE  {
*     ...
*     inhibitPolMap            BOOLEAN,
* 
* 
* - It would be nice to use the same field names.
* 
* - I suggest BOOLEAN DEFAULT FALSE for the inhibitPolMap together
*   with some apppropriate tagging, it doesn't make much sense to
*   me to code useless values.
* 
* Would it be possible to add some statement about the intended
* meaning of the 6 possible combination:
* 
* 
* inhibitPolMap = FALSE
* 
* inhibitPolicyMapping absent  1
*                      FALSE   2
*                      TRUE    3
* 
* inhibitPolMap = TRUE
* 
* inhibitPolicyMapping absent  4
*                      FALSE   5
*                      TRUE    6
* 
* 
* Does it mean that when the client value takes preceedence over the
* server value?
* 
* 1 = FALSE
* 2 = FALSE
* 3 = TRUE
* 4 = TRUE
* 5 = FALSE
* 6 = TRUE
* 
* 
* It had been said some time ago (as far as I remember) that these
* inputs are not global ones but in principle for each of the
* certs to be asked for. what was the conclusion why they stay global
* for all certs?

---

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

Hi Peter,
See below for details.
Trevor
* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Tuesday, December 07, 2004 4:15 AM
* To: Trevor Freeman
* Cc: [email-masked]
* Subject: Re: SCVP 16 comments deadline
* 
* We have
* 
*   Query ::= SEQUENCE {
*    queriedCerts               SEQUENCE SIZE (1..MAX) OF CertReference,
* 
*    ...
*    validationPolicy           ValidationPolicy,
* 
* with
*   ValidationPolicy ::= SEQUENCE {
*     ...
*     validationAlg         [0] ValidationAlg OPTIONAL,
* 
* 
* 3.1.5 validationAlg
[TF] The duplicate Validation alg section has been removed.
* 
*   The validationAlg item, defines the validation algorithm to be used
*   by the SCVP server during certificate validation.  The value of
*   this item can be determined by agreement between the client and the
*   server, and is represented as an object identifier.  The server
*   might want to assign additional object identifiers that indicate
*   that some settings are used in addition to others given in the
*   request.  In this way, the validation algorithm object identifier
*   can be a shorthand for some SCVP options, but not others.
* 
*   The validationAlg item uses the ValidationAlg type, which has the
*   following syntax:
* 
*     ValidationAlg ::= SEQUENCE {
*       valAlgId              OBJECT IDENTIFIER,
*       parameters            ANY DEFINED BY valAlgId OPTIONAL }
* 
* 
* and also
* 
* 
* 3.1.5.2 validationAlg
* 
*   The optional validationAlg item defines the validation algorithm to
*   be used by the SCVP server during certificate validation.  The
*   value of this item can be determined by agreement between the
*   client and the server, and the validation algorithm is represented
*   by an object identifier.
* 
*    The syntax of the validationAlg is:
* 
*     ValidationAlg ::= SEQUENCE {
*       valAlgId              OBJECT IDENTIFIER,
*       parameters            ANY DEFINED BY valAlgId OPTIONAL }
* 
*   The following section specifies the basic validation algorithm and
*   the name validation algorithm.  SCVP clients and servers MUST
*   support both validation algorithms defined in this section.  Other
*   validation algorithms can be specified in other documents for use
*   with specific applications.  SCVP clients and servers MAY support
*   any such validation algorithms.
* 
* ---------------
* 
* 3.1.5.2.3 Name Validation Algorithm
* 
*   The name validation algorithm allows the client to supply an
*   application identifier and a name to the server.  The application
*   identifier defines the name matching rules to use in comparing the
*   name supplied in the request with the names in the certificate.
* 
* There may be more than one certificate in the request.
[TF] The policy is global to the request.
* 
* 
*     NameValidationAlgParms ::= SEQUENCE {
*       keyPurposeId      KeyPurposeId,
*       validationNames   GeneralNames }
* 
* What is the relation between the KeyPurposeId and the
extendeddkeyusage
* 3.1.5.10 extendedKeyUsages
[TF] The OID with name validation defines the matching rules. In theory
there could be multiple matching rules for an 822 name.
* 
*   If the keyPurposeID supplied in the request is id-kp-mailProtection
*   [PKIX-1], then GeneralNames supplied in the request MUST be a
*   rfc822Name, and the matching rules are defined in [SMIME-CERT].
* 
* 'an rfc822Name".
* 
* what is the meaning of this if I have more than one email certificate,
* i.e. I want to validate all encryption certs before using them.
[TF] If they are different names they have to be different requests.
* 
* 
* Does this means that the validate Algorithm is cert specific and not
* request specific?
[TF] The validation policy for the request is global to the request.

---

From: "Trevor Freeman" <[email-masked]>
Date: Wed, 8 Dec 2004 10:42:02 -0800

Denis,
I know of several systems who's policy is never to revoke the identity
certificate because they have other mechanisms to address the issue.
They are using authorization bound to the identity and they either rely
on  short lived authorization assertions or revoke the authorization
privilege assonated with the identity. Therefore in those cases not
checking the revocation status of the certificate makes perfect sense.
Trevor

* -----Original Message-----
* From: [email-masked]
[mailto:[email-masked]]
* On Behalf Of Denis Pinkas
* Sent: Wednesday, December 08, 2004 8:01 AM
* To: Trevor Freeman
* Cc: [email-masked]
* Subject: Re: SCVP 16 comments deadline
* 
* 
* Trevor,
* 
* > Hi Denis,
* > Below are responses to 1-16. Others will follow later.
* 
* I am pleased that you accepted comments 13, 14, 15 and 16.
* Among this list, I have a further remark on comment 4.
* 
* > * 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.
* 
* I agree that "building a path is a separate check to revocation
checking",
* but revocation checking without building a validated path does not
make
* sense.
* 
* The full text currently is:
* 
*      - Build a certification path to a trust anchor;
* 
*      - Build a validated certification path to a trust anchor; and
* 
*      - Do revocation status checks on the certification path.
* 
* The full text should be:
* 
*      - Build a certification path to a trust anchor;
* 
*      - Build a validated certification path to a trust anchor; and
*        do revocation status checks on the certification path.
* 
* Denis

---

From: "Seth Hitchings" <[email-masked]>
Date: Wed, 8 Dec 2004 14:33:57 -0500

Trevor,

For clarification, I assume that doing revocation status checks on a path implies building
a validated path?

If I am correct, in what case would a client ever send more than one check?

Seth

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Trevor Freeman
Sent: Wednesday, December 08, 2004 1:42 PM
To: Denis Pinkas
Cc: [email-masked]
Subject: RE: SCVP 16 comments deadline

Denis,
I know of several systems who's policy is never to revoke the identity certificate because
they have other mechanisms to address the issue.
They are using authorization bound to the identity and they either rely on  short lived
authorization assertions or revoke the authorization privilege assonated with the
identity. Therefore in those cases not checking the revocation status of the certificate
makes perfect sense.
Trevor

* > [TF] Since this paragraph is listing the possible checks and building a
* I agree that "building a path is a separate check to revocation checking",
* but revocation checking without building a validated path does not make

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 9 Dec 2004 12:46:38 +0100 (MET)

> policy which name it chooses to return.

Are you saying that this client identifier is the "issuerSerial"?
What field *IS* the "client identifier"? The certificate is not
a client identifier? In a certificate, you may have several identifiers
concerning the entity. 

The client has no way to set an "identifier for itself" in the request, so that 

   "the DPV server MAY choose to blindly copy the identifier".

The server that you propose ALWAYS MUST create some generalnames
structure for which no guideline is given on how it could be
derived from the requestorRef which is an item that has no relation
at all to the returned requesterName. 

Since two years or so I am asking that you just make two elements

requestor GeneralNames
responder GeneralNames

in both the request and the response. (and to get rid of the octet string stuff)

I may have not understod your intention of "responder", if this is a pure
local reference of the RESPONSE vs the repspoinder, then I think a 
sequence number would be more appropriate. 

> an implementation puts garbage in here it does not effect
How do relate 'local significance only' and the usage of such fields
for 'loop control'. The significance not just local. 
If relays just put "relay" as a local reference you will have problems. 

LOOONG time ago, I told you that an encoding of identifiers in an octet string
sounds strange, given that we have lots of ways and that you don't provide
any guideline on how identifiers can be encoded.

Although you violantly rejected all proprosals to change this, you
silently starting doing this in this version:

- replacing an octet string by a sequence  (good, but omitted the only reason
  for not allowing zeros).
- adding a requesterName item with is a generalnames

> class it the same bucket as non-repudiation. 

You are operating in a PKI where ID's of
entities are unique within the PKI. If you don't trust the
naming rule in your PKI, i.e. in some associated SCVP network
which is much smaller, i.e. in the magnitude of the size of
the CA name space.

Well, domain names work as far as I know. And telephone numbers also.
I don't say that non-repudiation doesn't work. I don't say that
I agree or disagree with your comparision since I do not see why this
is relevant here. 

You are not even answering the question: You make loop control, and
you explicitely says that the identifiers that are used do only have
local significance. You could have said: An example for identifiers
that could be used for loop control are uuids generated on each server
startup using the server address and a time value. 

> which case the responder is of significance.

No. any client can set a requestorRef, independant of whether the request
will be relayed. What is the significance of responder? In your spec
it is only of local signifance for the responding server? waht can this
be good for? 

> [TF] What specifically are you looking for?

A working specification that includes:

- how a request received is transformed into a new request by a relay,
  which fields are copied, or not, or may.
- how the response is transformed into a response to the original request
  there are SEVERAL options, in particulat the one that addresses
  the requirement of allowing a response as part of another one.

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 9 Dec 2004 12:48:49 +0100 (MET)

> [TF] The duplicate Validation alg section has been removed.

good. But which one? 

no comment. 

> [TF] The validation policy for the request is global to the request.

It is quite normal that the parameters assocaited to the single algorithm
may not be different for each cert, in particular for email.

It seems possible to allow a list of emails and require that for each
email, there must be at least one certificate in the certificate list.

Or you move the parameters to some information associated to the certificate,
or one says that the sequence of names must correspond to the sequence
of certs, ...

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 9 Dec 2004 12:48:38 +0100 (MET)

Either I was unclear in my question or you have totally misunderstood it,
or I don't understand what your are responding.

> want guidance on their use in combination with the policy reference see
It is obviously not difficult to guess which names corresponds, that
is not the problem. 

> process different polices for different certificates - send different
Where do I talk about different policies and different certificates,
are you confusing this with another message? 

I am just asking how parameters from the client and the server are
combined in a request for one signed cert with one policy. And, to
be sure, I can also assume that a client sets all the input flags
or none, if you want. 

The current syntax allows all kind of combinations of settings and
by the client and the server, it is not specified:

- how they are combined
- whether there this only a subset of useful meanings.

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 9 Dec 2004 13:58:10 +0100 (MET)

I find the possibilities for the Name Validation Algorithm
rather unsafisfying. 

It should be possible IMO to have a matching simply by
presenting whatever form of Generalname and this should
be compared with the corresponding value in the cert.

In fact, the id-svp-dnValAlg sounds rather restrictive to
me, it seems to imply that only the subject field is
compared (or does this also compare with the Dirname in
a subjectAltname).

This restriction about a DN doesn't seem necssary to me,
Any generalName can be compared with any in the subjectAltname.

E.g. an IP address. 

'id-nvae-unknown-pupose'   ==> 'id-nvae-unknown-purpose'

  id-nvae-name-mismatch vs   The id-nvae-nameMismatch value

please align the spellings of all the errors types.

  The id-nvae-badName value means the client supplied either and 
  empty or malformed name in the request. 

what is a bad or malformed name? How can this happen without raising
a general asn1 decoding error

since it comes right next? 

--- 
cleanup the following text, please 

  The userPolicySet item specifies a list of policy identifiers that 
  the SCVP server MUST use when forming and validating a certificate 
  If certPolicies is not specified, then any-policy MUST be used. 
   
3.1.5.3 userPolicySet 
   
  The userPolicySet item specifies a list of certificate policy 
  identifiers that the SCVP server MUST use when constructing and 
  validating a certification path.  If userPolicySet is not specified, 
  then any-policy MUST be used.

---

From: "Trevor Freeman" <[email-masked]>
Date: Thu, 9 Dec 2004 10:10:05 -0800

Hi Peter,
* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Tuesday, December 07, 2004 4:15 AM
* To: Trevor Freeman
* Cc: [email-masked]
* Subject: Re: SCVP 16 comments deadline
* 
* To have an independant issue:
* 
* 
* 4.8 requestorName
* 
*   The optional requestorName item is used by the server with signed
*   requests to return the identity of the client in the response.
*   Mechanisms for matching this identifier with the authenticated
*   identity are a matter of local server policy.
* 
*   In the case of non-cached responses to signed requests, the SCVP
*   server MUST return a requestor name.  A server SHOULD copy the
*   selected identifier from a certificate or other credential used to
*   authenticate the request.  A SCVP server MAY use a client
*   identifier from an out-of-band mechanism or omit the identifier
*   from the response.
* 
*   In the case of cached responses to signed requests, the
*   RequestorName MAY be present in the response.
* 
*   SCVP server that supports signed requests MUST support this item.
* 
* This chapter is new and pretty uncomprehensible:
* 
* "matching" is IMO an action where you have two inputs, I don't see
* where the identifier comes from, or when it is extracted from
* some authenticated information, why there is a "matching" at all.
* "The identity" of the client is not defined anywhere in the document.
[TF] How the server identifies the client is a mater of local server
policy.
* 
* The 3379 text says:
* 
*    When the DPV request is authenticated, the client SHOULD be able to
*    include a client identifier in the request for the DPV server to
copy
*    into the response.  Mechanisms for matching this identifier with
the
*    authenticated identity depends on local DPV server conditions
and/or
*    the validation policy.
* 
* The client has no way to declare its identity in the protocol,
* and there no provision of what this could be from what it would
* be derived from (IP address, DNS name of the host, ...), ...
[TF] The client can declare its identity in the request in a number of
ways.
 	1. by including its signing certificate in the request
	2. by including its DH certificate used to compute the hmac
	3. By HMACing the request using a shared secret or password

What identity the server knows or uses for the client based on this data
is a matter of local server policy
 
* 
* Why is this restricted to signed requests, and not to 'authenticated'?
[TF] Its not. Section 3 defies signed requests as being either
signedData or authenticatedData.
* 
* As already said in another may, this text could make sense if there
* would be a corresponding requestorName in the request.
* 
* 
* 

Trevor

---

From: "Trevor Freeman" <[email-masked]>
Date: Thu, 9 Dec 2004 10:13:24 -0800

Hi Peter

* On Behalf Of Peter Sylvester
[TF] The request specifies a policy, which in tern references an
algorithm. The policy applies globally to the request. There is no
relationship between the certificate and the algorithm.
Trevor

Trevor

---

From: "Trevor Freeman" <[email-masked]>
Date: Thu, 9 Dec 2004 10:27:54 -0800

H Peter,

* -----Original Message-----
* From: [email-masked]
[mailto:[email-masked]]
* On Behalf Of Peter Sylvester
* Sent: Tuesday, December 07, 2004 4:15 AM
* To: Trevor Freeman
* Cc: [email-masked]
* Subject: Re: SCVP 16 comments deadline
* 
* 
* There are several boolean values like
* 
*   ValidationPolicy ::= SEQUENCE {
*     ...
*     inhibitPolicyMapping  [2] BOOLEAN OPTIONAL,
* 
* and a policy definition.
* 
*   ValidationPolValues ::=SEQUENCE  {
*     ...
*     inhibitPolMap            BOOLEAN,
* 
* 
* - It would be nice to use the same field names.
[TF] Fixed
* 
* - I suggest BOOLEAN DEFAULT FALSE for the inhibitPolMap together
*   with some apppropriate tagging, it doesn't make much sense to
*   me to code useless values.
* 
* Would it be possible to add some statement about the intended
* meaning of the 6 possible combination:
* 
* 
* inhibitPolMap = FALSE
* 
* inhibitPolicyMapping absent  1
*                      FALSE   2
*                      TRUE    3
* 
* inhibitPolMap = TRUE
* 
* inhibitPolicyMapping absent  4
*                      FALSE   5
*                      TRUE    6
* 
[TF] There is only one Boolean value for inhibitPolicyMapping. It can be
defined in the policy, supplied in the request or defined in the servers
default policy. Section 1.3 defines the precedence for each. Further
3.1.5.1 also requests the server to reject a request which summits a
request which attempts to override the precedence.
* 
* Does it mean that when the client value takes preceedence over the
* server value?
* 
* 1 = FALSE
* 2 = FALSE
* 3 = TRUE
* 4 = TRUE
* 5 = FALSE
* 6 = TRUE
* 
* 
* It had been said some time ago (as far as I remember) that these
* inputs are not global ones but in principle for each of the
* certs to be asked for. what was the conclusion why they stay global
* for all certs?
[TF] There is one validation policy per request therefore the same
policy applies to all certs in the request.

Trevor

---

From: "Trevor Freeman" <[email-masked]>
Date: Thu, 9 Dec 2004 10:56:32 -0800

Hi Peter

* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Thursday, December 09, 2004 3:47 AM
* To: [email-masked]; Trevor Freeman
* Cc: [email-masked]
* Subject: RE: SCVP 16 comments deadline
* 
* > *
* > * But:
* > *
* > * The syntax is GeneralNames. how many ids is the server intended
* > * to extract from a certificate? The subject + all alternate ids?
* > *
* > * Why not having this id declared by the client, and the
authentication
* > * methods matches against it. ==> Add a corresponding field in the
* > request.
* > * Which is required:
* > *
* > *    When the DPV request is authenticated, the client SHOULD be
able to
* > *    include a client identifier in the request for the DPV server
to
* > copy
* > *    into the response.  Mechanisms for matching this identifier
with
* > the
* > *    authenticated identity depends on local DPV server conditions
* > and/or
* > *    the validation policy.  The DPV server MAY choose to blindly
copy
* > the
* > *    identifier, omit the identifier, or return an error response.
* > *
* > * It is an identifer identifying the client and not the request.
* > [TF] If the client sends a signed request with certificate it has
* > included a client identifier in the request. Its matter of local
server
* > policy which name it chooses to return.
* 
* Are you saying that this client identifier is the "issuerSerial"?
[TF] I am saying how the server identifies the client for the supplied
information is a matter of local policy to the server.
* What field *IS* the "client identifier"? The certificate is not
* a client identifier? In a certificate, you may have several
identifiers
* concerning the entity.
[TF] I am saying how the server identifies the client for the supplied
information is a matter of local policy to the server.
* 
* The client has no way to set an "identifier for itself" in the
request, so
* that
* 
*    "the DPV server MAY choose to blindly copy the identifier".
* 
* The server that you propose ALWAYS MUST create some generalnames
* structure for which no guideline is given on how it could be
* derived from the requestorRef which is an item that has no relation
* at all to the returned requesterName.
[TF] I am saying how the server identifies the client for the supplied
information is a matter of local policy to the server.
* 
* Since two years or so I am asking that you just make two elements
* 
* requestor GeneralNames
* responder GeneralNames
* 
* in both the request and the response. (and to get rid of the octet
string
* stuff)
* 
* I may have not understod your intention of "responder", if this is a
pure
* local reference of the RESPONSE vs the repspoinder, then I think a
* sequence number would be more appropriate.
* 
* > *
* > * The new text replacing "requestor" in chapter 7 by "requestorRef".
* > *
* > * > however,
* > * >  all of the octets MUST have values other than zero.
* > * Why? I would find it quite useful to add a
* > * hash of something local, if at all, the hash of its IP address for
* > example
* > * (for which I can use the Nonce as well).
* > [TF] If you want me to remove the clause about values being other
than
* > zero - I am happy to do so. Since this is of local significance
only, if
* > an implementation puts garbage in here it does not effect
* > interoperability.
* How do relate 'local significance only' and the usage of such fields
* for 'loop control'. The significance not just local.
* If relays just put "relay" as a local reference you will have
problems.
* 
* LOOONG time ago, I told you that an encoding of identifiers in an
octet
* string
* sounds strange, given that we have lots of ways and that you don't
provide
* any guideline on how identifiers can be encoded.
* 
* Although you violantly rejected all proprosals to change this, you
* silently starting doing this in this version:
* 
* - replacing an octet string by a sequence  (good, but omitted the only
* reason
*   for not allowing zeros).
* - adding a requesterName item with is a generalnames
* 
* 
* > *
* > *   The requestRef item allows the client to associate a response
with
* > *   a request.  The requestNonce provides an alternative mechanism
..
* > *
* > *   and you have also the requestorRef.
* > *
* > * The concept of trying to make loop control with values which are
* > * explicitely
* > * defined as not globally unique sounds strange to me.
* > [TF] I have a big problem which the concept of global uniqueness. I
* > class it the same bucket as non-repudiation.
* 
* You are operating in a PKI where ID's of
* entities are unique within the PKI. If you don't trust the
* naming rule in your PKI, i.e. in some associated SCVP network
* which is much smaller, i.e. in the magnitude of the size of
* the CA name space.
[TF] Names give by an instance of a PKI are by definition not global.
* 
* Well, domain names work as far as I know. And telephone numbers also.
* I don't say that non-repudiation doesn't work. I don't say that
* I agree or disagree with your comparision since I do not see why this
* is relevant here.
* 
* You are not even answering the question: You make loop control, and
* you explicitely says that the identifiers that are used do only have
* local significance. You could have said: An example for identifiers
* that could be used for loop control are uuids generated on each server
* startup using the server address and a time value.
[TF] Are you asking a question or suggesting text for the draft? If you
want an example of how one might generate a identifier of local
significance I can do that.
* 
* 
* > *
* > *  "The requestorRef item is also needed
* > *   to prevent looping in some configurations"
* > *
* > *  "No provisions are
* > *   made to ensure uniqueness of the requestorRef octet string"
* > *
* > * The usefulness of "requestorRef" as an identifier for the request
* > * is pretty weak, since you can have a nonce if it is for each
* > * request. use GeneralName(s) in a requestorName sequence as for the
* > * response.
* > *
* > * page 34:
* > *
* > *   The requestorRef and the responder items MUST be included if the
* > request
* > * included a
* > *   requestor item.
* > *
* > * what does this mean? what is the relationship between a
requesterRef
* > and
* > * responder?
* > [TF] If requestorRef is populated, it means it's a relayed request
in
* > which case the responder is of significance.
* 
* No. any client can set a requestorRef, independant of whether the
request
* will be relayed. What is the significance of responder? In your spec
* it is only of local signifance for the responding server? waht can
this
* be good for?
[TF] It good for detecting loops. The server adds an identifier which it
recognizes to the response. It is the only one rrequired to recognize
the value so it can put whatever it wants in the field. There is no need
to standardize the behavior of the SCVP server in this regard.
* 
* > *
* > * If I'd be interested in anything identifying the response, then it
is
* > * a sequence of identifiers of the servers that have partipated, and
* > some
* > * local ids or "serial number' like thing if I want to go to that
server
* > and
* > * asks 'did you really tell this to my friend'.
* > *
* > *
* > * Chapter 7: Denis is right that the spec does not describe how
relaying
* > is
* > * performed, i.e. how a response is created from a response received
* > from
* > * another
* > * server by a 'proxy'.
* > [TF] What specifically are you looking for?
* 
* A working specification that includes:
* 
* - how a request received is transformed into a new request by a relay,
*   which fields are copied, or not, or may.
* - how the response is transformed into a response to the original
request
*   there are SEVERAL options, in particulat the one that addresses
*   the requirement of allowing a response as part of another one.
[TF] OK. I will add that.

Trevor
*

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 10 Dec 2004 14:01:58 +0100 (MET)

> relationship between the certificate and the algorithm.

I agree that it seems sufficient for one request to have the same
*algorithm(s)* performed for all the certs, but the only examples defined
contain a *parameter* which is specific to each cert, i.e. an identity/name
that has to be matched with the content of a cert, thus currently the
usage of this 'extension' features limits the requests to one cert only.

For requests concerning SSL servers, IPsec auths, *one signature*, one
cert will be present in the request, a case for multiple requests *may* 
be certs for encryption. It may be sufficient to allow multiple names
for e-mail protection certs in the existing parameter, and a rule saying
that names must be present.

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 10 Dec 2004 14:00:47 +0100 (MET)

> information is a matter of local policy to the server.

Repeating this three time doesn't make the statement true. It is
totally contrary to what is described in the requirements document.

If you don't agree about the meaning of 'client identifier' in the
following excerpt, then we will not be able to get anywhere further.

If the intention of the excerpt above would be that the client does not
explicitely do provide an identifier, then the text would be like:

   When the DPV requets is authenticated, then server MAY return to the
   client an identifier derived from the authentication.

if you want to derive *one* identifier from the authentication, what will
you set for a certificate with one or more instances of subjectAltname.
The best you can do is to return all identities. 

The client has to have a means to explicitely present his identity.

This is an identifier where the client declares its identity, furthermore 
this identifier being an octet string without any structure is not
something that is common in PKI environments, in particular you already
return a GeneralNames structure in the requesterName. 

I simply repeat my request to add requesterName and a responderName structure
in both the request and the response. 

here a text proposal:

x.x.x Entity identification.

Since an SCVP response MAY be used by a client to demonstrate to another
relying party that certificate validation has been duly performed, the
protocol allows to add identities of requesting clients and responding
server to the response.

An identity is encoded as GeneralName. (cf. syntax)

Servers may have more than one identity, for example, a URI 
to access to the service, or a DN related or not to CAs.
In particular, an SCVP server may have the same identity as a CA
for which the server can provide answers in a similar way as an
OCSP server. 

The protocol is as follows:

x.x.x.1 requesterName

This field in the request indicates one or more identities participating
in the creation of the request. A client MAY add this field to a request.
If the request is authenticated, one of the presented identities SHOULD 
match with at least one identity that can be derived from authentication. 
A server MAY accept a request even if the presented identities do not 
correspond to one derived from authentication. If the request cannot be
authenticated, a server SHOULD reject the request if it contains this field.

On relaying, a relay MAY choose not to copy the presented identity to
the relayed request, e.g., to anonymize the requester.

This field SHOULD be returned as is in the response. A server MAY choose
to add additional identities. This may be done when a relay is involved, 
when an authenticated identity is different.  

(merge some stuff from the existing requesterName if necessary).

x.x.x.1 responderName

This field in the request indicated identities of one or more servers that
are intending to participate in the construction of the response. This
may be used for example to indicate to a relaying proxy the identity of
another scvp server. 

This field in the response indicate the identities of the servers that
have participated in creating the response. There is no particular
relationship with the field with the same name in the input. 

------

Now we can treat the usefulness of the requester/responder for,loop
control independantly. 
 
> * sequence number would be more appropriate.

what is the current definition of responder good for? You menton something
below, see later. 

> * - adding a requesterName item with is a generalnames

I probably expected some [TF] here, but well, you seem to agree.  

> [TF] Names give by an instance of a PKI are by definition not global.

Can you point me to the definition?
You may have a problem of ensuring uniqueness of name inside the PKI
this but that's a similar proble as for the domain name system, 
it is organisational and not technical.
Names inside a PKI are non-ambiguously associated to the
entities as far as I remember.

I really don't see what you are arguing about?

> significance I can do that.

An identifier of 'local' significance is simple: 'I'

It seems that we don't agree about the meaning of 'local significance'.

You need that each potentially participating entity has at least one
identifier which are distincet among the servers, but may or not
have any global 'significance'. 

If you want to keep the requester item for this, why not. it may be
useful not to overload an 'identification', a nonce, a loop control tickmark
in the same field. 

> to standardize the behavior of the SCVP server in this regard.

To be sure: The question was: "What is the significance of responder?" 
How does this value occur in the loop control algo? So far, the server
just adds this, and noone is doing somthing with it, at least not in
the current spec?

> [TF] OK. I will add that.
good.

Would it be possible to send a draft to the list before it get graved into 
electronic marble.

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 10 Dec 2004 13:59:43 +0100 (MET)

> * - It would be nice to use the same field names.

ok.
> request which attempts to override the precedence.

Ok. 

> policy applies to all certs in the request.

Ok.

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 10 Dec 2004 14:01:45 +0100 (MET)

> [TF] How the server identifies the client is a mater of local server
See my other message and a text proposal. 

> 	3. By HMACing the request using a shared secret or password

None of these is a "declaration" of an identity. It is a means to authenticate
the request at least in my opinion. 

Note the remark about 'may respond with an error' in
the requirements. This is intended to mean that a server may reject
a request when the declared entity is not one that can be authenticated.
(I don't think that it was meant that an error can be 'not authorized')

Ok. 

> * would be a corresponding requestorName in the request.

you seem to agree?

---

From: "Trevor Freeman" <[email-masked]>
Date: Fri, 10 Dec 2004 10:31:15 -0800

Hi Peter,
You are assuming that there is only one possible matching algorithm for
a name type - which seems a fragile assertion. The be more  robust then
you supply a name and a matching rule identifier - which is what the
name validation algorithm does.
I have seen examples of cases where a name has been inserted into an asn
structure which does not cause an ASN decode error but the name is still
bad because the name semantics are wrong - so I don't subscribe to the
notion that all bad names cause asn decode errors.

* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Thursday, December 09, 2004 4:58 AM
* To: [email-masked]; Trevor Freeman
* Cc: [email-masked]
* Subject: RE: SCVP 16 comments deadline
* 
* 3.1.5.2.3 Name Validation Algorithm
* 
* I find the possibilities for the Name Validation Algorithm
* rather unsafisfying.
* 
* It should be possible IMO to have a matching simply by
* presenting whatever form of Generalname and this should
* be compared with the corresponding value in the cert.
* 
* In fact, the id-svp-dnValAlg sounds rather restrictive to
* me, it seems to imply that only the subject field is
* compared (or does this also compare with the Dirname in
* a subjectAltname).
* 
* This restriction about a DN doesn't seem necssary to me,
* Any generalName can be compared with any in the subjectAltname.
* 
* E.g. an IP address.
* 
* 'id-nvae-unknown-pupose'   ==> 'id-nvae-unknown-purpose'
* 
*   id-nvae-name-mismatch vs   The id-nvae-nameMismatch value
[TF] Fixed
* 
* please align the spellings of all the errors types.
* 
*   The id-nvae-badName value means the client supplied either and
*   empty or malformed name in the request.
* 
* what is a bad or malformed name? How can this happen without raising
* a general asn1 decoding error
* 
* since it comes right next?
* 
* ---
* cleanup the following text, please
* 
*   The userPolicySet item specifies a list of policy identifiers that
*   the SCVP server MUST use when forming and validating a certificate
*   If certPolicies is not specified, then any-policy MUST be used.
* 
* 3.1.5.3 userPolicySet
* 
*   The userPolicySet item specifies a list of certificate policy
*   identifiers that the SCVP server MUST use when constructing and
*   validating a certification path.  If userPolicySet is not specified,
*   then any-policy MUST be used.
* 
* 
[TF] I will change the userPolicy set to the following
The userPolicySet item specifies a list of certificate policy
identifiers that the SCVP server MUST use when constructing and
validating a certification path.

The requirement for use of the userPolicySet falling back to any-policy
is being dropped because the referenced policy or the default policy
will cover this.
* 
 
Trevor

---

From: "Trevor Freeman" <[email-masked]>
Date: Fri, 10 Dec 2004 11:05:03 -0800

Peter

* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Friday, December 10, 2004 5:01 AM
* To: [email-masked]; Trevor Freeman
* Cc: [email-masked]
* Subject: RE: SCVP 16 comments deadline
* 
* > [TF] I am saying how the server identifies the client for the
supplied
* > information is a matter of local policy to the server.
* 
* Repeating this three time doesn't make the statement true. It is
* totally contrary to what is described in the requirements document.
* 
*    When the DPV request is authenticated, the client SHOULD be able to
*    include a client identifier in the request for the DPV server to
copy
*    into the response.  Mechanisms for matching this identifier with
the
*    authenticated identity depends on local DPV server conditions
and/or
*    the validation policy.  The DPV server MAY choose to blindly copy
the
*    identifier, omit the identifier, or return an error response.
[TF] 
Reputedly copying the same section from 3379 has the same effect. I
believe the current draft of SCVP complies with the text. The name must
be in the certificate. I don't see value in repeating the value twice in
the request.

* 
* If you don't agree about the meaning of 'client identifier' in the
* following excerpt, then we will not be able to get anywhere further.
* 
* If the intention of the excerpt above would be that the client does
not
* explicitely do provide an identifier, then the text would be like:
* 
*    When the DPV requets is authenticated, then server MAY return to
the
*    client an identifier derived from the authentication.
* 
* if you want to derive *one* identifier from the authentication, what
will
* you set for a certificate with one or more instances of
subjectAltname.
* The best you can do is to return all identities.
* 
* The client has to have a means to explicitely present his identity.
* 
* This is an identifier where the client declares its identity,
furthermore
* this identifier being an octet string without any structure is not
* something that is common in PKI environments, in particular you
already
* return a GeneralNames structure in the requesterName.
* 
* I simply repeat my request to add requesterName and a responderName
* structure
* in both the request and the response.
* 
* here a text proposal:
* 
* x.x.x Entity identification.
* 
* Since an SCVP response MAY be used by a client to demonstrate to
another
* relying party that certificate validation has been duly performed, the
* protocol allows to add identities of requesting clients and responding
* server to the response.
* 
* An identity is encoded as GeneralName. (cf. syntax)
* 
* Servers may have more than one identity, for example, a URI
* to access to the service, or a DN related or not to CAs.
* In particular, an SCVP server may have the same identity as a CA
* for which the server can provide answers in a similar way as an
* OCSP server.
* 
* The protocol is as follows:
* 
* x.x.x.1 requesterName
* 
* This field in the request indicates one or more identities
participating
* in the creation of the request. A client MAY add this field to a
request.
* If the request is authenticated, one of the presented identities
SHOULD
* match with at least one identity that can be derived from
authentication.
* A server MAY accept a request even if the presented identities do not
* correspond to one derived from authentication. If the request cannot
be
* authenticated, a server SHOULD reject the request if it contains this
* field.
* 
* On relaying, a relay MAY choose not to copy the presented identity to
* the relayed request, e.g., to anonymize the requester.
* 
* This field SHOULD be returned as is in the response. A server MAY
choose
* to add additional identities. This may be done when a relay is
involved,
* when an authenticated identity is different.
* 
* (merge some stuff from the existing requesterName if necessary).
* 
* x.x.x.1 responderName
* 
* This field in the request indicated identities of one or more servers
that
* are intending to participate in the construction of the response. This
* may be used for example to indicate to a relaying proxy the identity
of
* another scvp server.
* 
* This field in the response indicate the identities of the servers that
* have participated in creating the response. There is no particular
* relationship with the field with the same name in the input.
* 
* ------
* 
* Now we can treat the usefulness of the requester/responder for,loop
* control independantly.
* 
* > *
* > * Since two years or so I am asking that you just make two elements
* > *
* > * requestor GeneralNames
* > * responder GeneralNames
* > *
* > * in both the request and the response. (and to get rid of the octet
* > string
* > * stuff)
* > *
* > * I may have not understod your intention of "responder", if this is
a
* > pure
* > * local reference of the RESPONSE vs the repspoinder, then I think a
* > * sequence number would be more appropriate.
* > *
* 
* what is the current definition of responder good for? You menton
something
* below, see later.
* 
* 
* > * > *
* > * > * The new text replacing "requestor" in chapter 7 by
"requestorRef".
* > * > *
* > * > * > however,
* > * > * >  all of the octets MUST have values other than zero.
* > * > * Why? I would find it quite useful to add a
* > * > * hash of something local, if at all, the hash of its IP address
for
* > * > example
* > * > * (for which I can use the Nonce as well).
* > * > [TF] If you want me to remove the clause about values being
other
* > than
* > * > zero - I am happy to do so. Since this is of local significance
* > only, if
* > * > an implementation puts garbage in here it does not effect
* > * > interoperability.
* > * How do relate 'local significance only' and the usage of such
fields
* > * for 'loop control'. The significance not just local.
* > * If relays just put "relay" as a local reference you will have
* > problems.
* > *
* > * LOOONG time ago, I told you that an encoding of identifiers in an
* > octet
* > * string
* > * sounds strange, given that we have lots of ways and that you don't
* > provide
* > * any guideline on how identifiers can be encoded.
* > *
* > * Although you violantly rejected all proprosals to change this, you
* > * silently starting doing this in this version:
* > *
* > * - replacing an octet string by a sequence  (good, but omitted the
only
* > * reason
* > *   for not allowing zeros).
* > * - adding a requesterName item with is a generalnames
* > *
* > *
* 
* I probably expected some [TF] here, but well, you seem to agree.
* 
* > * > *
* > * > *   The requestRef item allows the client to associate a
response
* > with
* > * > *   a request.  The requestNonce provides an alternative
mechanism
* > ..
* > * > *
* > * > *   and you have also the requestorRef.
* > * > *
* > * > * The concept of trying to make loop control with values which
are
* > * > * explicitely
* > * > * defined as not globally unique sounds strange to me.
* > * > [TF] I have a big problem which the concept of global
uniqueness. I
* > * > class it the same bucket as non-repudiation.
* > *
* > * You are operating in a PKI where ID's of
* > * entities are unique within the PKI. If you don't trust the
* > * naming rule in your PKI, i.e. in some associated SCVP network
* > * which is much smaller, i.e. in the magnitude of the size of
* > * the CA name space.
* > [TF] Names give by an instance of a PKI are by definition not
global.
* 
* Can you point me to the definition?
* You may have a problem of ensuring uniqueness of name inside the PKI
* this but that's a similar proble as for the domain name system,
* it is organisational and not technical.
* Names inside a PKI are non-ambiguously associated to the
* entities as far as I remember.
* 
* I really don't see what you are arguing about?
* 
* > *
* > * Well, domain names work as far as I know. And telephone numbers
also.
* > * I don't say that non-repudiation doesn't work. I don't say that
* > * I agree or disagree with your comparision since I do not see why
this
* > * is relevant here.
* > *
* > * You are not even answering the question: You make loop control,
and
* > * you explicitely says that the identifiers that are used do only
have
* > * local significance. You could have said: An example for
identifiers
* > * that could be used for loop control are uuids generated on each
server
* > * startup using the server address and a time value.
* > [TF] Are you asking a question or suggesting text for the draft? If
you
* > want an example of how one might generate a identifier of local
* > significance I can do that.
* 
* An identifier of 'local' significance is simple: 'I'
* 
* It seems that we don't agree about the meaning of 'local
significance'.
* 
* You need that each potentially participating entity has at least one
* identifier which are distincet among the servers, but may or not
* have any global 'significance'.
* 
* If you want to keep the requester item for this, why not. it may be
* useful not to overload an 'identification', a nonce, a loop control
* tickmark
* in the same field.
* 
* > * > *  "The requestorRef item is also needed
* > * > *   to prevent looping in some configurations"
* > * > *
* > * > *  "No provisions are
* > * > *   made to ensure uniqueness of the requestorRef octet string"
* > * > *
* > * > * The usefulness of "requestorRef" as an identifier for the
request
* > * > * is pretty weak, since you can have a nonce if it is for each
* > * > * request. use GeneralName(s) in a requestorName sequence as for
the
* > * > * response.
* > * > *
* > * > * page 34:
* > * > *
* > * > *   The requestorRef and the responder items MUST be included if
the
* > * > request
* > * > * included a
* > * > *   requestor item.
* > * > *
* > * > * what does this mean? what is the relationship between a
* > requesterRef
* > * > and
* > * > * responder?
* > * > [TF] If requestorRef is populated, it means it's a relayed
request
* > in
* > * > which case the responder is of significance.
* > *
* > * No. any client can set a requestorRef, independant of whether the
* > request
* > * will be relayed. What is the significance of responder? In your
spec
* > * it is only of local signifance for the responding server? waht can
* > this
* > * be good for?
* 
* > [TF] It good for detecting loops. The server adds an identifier
which it
* > recognizes to the response. It is the only one rrequired to
recognize
* > the value so it can put whatever it wants in the field. There is no
need
* > to standardize the behavior of the SCVP server in this regard.
* 
* To be sure: The question was: "What is the significance of responder?"
* How does this value occur in the loop control algo? So far, the server
* just adds this, and noone is doing somthing with it, at least not in
* the current spec?
* 
* > *
* > * > *
* > * > * If I'd be interested in anything identifying the response,
then it
* > is
* > * > * a sequence of identifiers of the servers that have partipated,
and
* > * > some
* > * > * local ids or "serial number' like thing if I want to go to
that
* > server
* > * > and
* > * > * asks 'did you really tell this to my friend'.
* > * > *
* > * > *
* > * > * Chapter 7: Denis is right that the spec does not describe how
* > relaying
* > * > is
* > * > * performed, i.e. how a response is created from a response
received
* > * > from
* > * > * another
* > * > * server by a 'proxy'.
* > * > [TF] What specifically are you looking for?
* > *
* > * A working specification that includes:
* > *
* > * - how a request received is transformed into a new request by a
relay,
* > *   which fields are copied, or not, or may.
* > * - how the response is transformed into a response to the original
* > request
* > *   there are SEVERAL options, in particulat the one that addresses
* > *   the requirement of allowing a response as part of another one.
* > [TF] OK. I will add that.
* good.
* 
* Would it be possible to send a draft to the list before it get graved
into
* electronic marble.

---

From: "Trevor Freeman" <[email-masked]>
Date: Fri, 10 Dec 2004 13:02:16 -0800

* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Friday, December 10, 2004 5:02 AM
* To: [email-masked]; Trevor Freeman
* Cc: [email-masked]
* Subject: RE: SCVP 16 comments deadline
* 
* > [TF] How the server identifies the client is a mater of local server
* > policy.
* See my other message and a text proposal.
* 
* > *
* > * The 3379 text says:
* > *
* > *    When the DPV request is authenticated, the client SHOULD be
able to
* > *    include a client identifier in the request for the DPV server
to
* > copy
* > *    into the response.  Mechanisms for matching this identifier
with
* > the
* > *    authenticated identity depends on local DPV server conditions
* > and/or
* > *    the validation policy.
* > *
* > * The client has no way to declare its identity in the protocol,
* > * and there no provision of what this could be from what it would
* > * be derived from (IP address, DNS name of the host, ...), ...
* > [TF] The client can declare its identity in the request in a number
of
* > ways.
* >  	1. by including its signing certificate in the request
* > 	2. by including its DH certificate used to compute the hmac
* > 	3. By HMACing the request using a shared secret or password
* 
* None of these is a "declaration" of an identity. It is a means to
* authenticate
* the request at least in my opinion.
[TF] When I sign email, I don't include an additional attribute, I just
include my certificate. How is that not a declaration of identity.
* 
* Note the remark about 'may respond with an error' in
* the requirements. This is intended to mean that a server may reject
* a request when the declared entity is not one that can be
authenticated.
* (I don't think that it was meant that an error can be 'not
authorized')
* 
* >
* > What identity the server knows or uses for the client based on this
data
* > is a matter of local server policy
* >
* > *
* > * Why is this restricted to signed requests, and not to
'authenticated'?
* > [TF] Its not. Section 3 defies signed requests as being either
* > signedData or authenticatedData.
* 
* Ok.
* 
* > *
* > * As already said in another may, this text could make sense if
there
* > * would be a corresponding requestorName in the request.
* 
* you seem to agree?

---

From: "Trevor Freeman" <[email-masked]>
Date: Fri, 10 Dec 2004 13:09:43 -0800

* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Friday, December 10, 2004 5:02 AM
* To: [email-masked]; Trevor Freeman
* Cc: [email-masked]
* Subject: RE: SCVP 16 comments deadline
* 
* > *
* > *
* > * Does this means that the validate Algorithm is cert specific and
not
* > * request specific?
* > [TF] The request specifies a policy, which in tern references an
* > algorithm. The policy applies globally to the request. There is no
* > relationship between the certificate and the algorithm.
* > Trevor
* >
* 
* I agree that it seems sufficient for one request to have the same
* *algorithm(s)* performed for all the certs, but the only examples
defined
* contain a *parameter* which is specific to each cert, i.e. an
* identity/name
* that has to be matched with the content of a cert, thus currently the
* usage of this 'extension' features limits the requests to one cert
only.
* 
* For requests concerning SSL servers, IPsec auths, *one signature*, one
* cert will be present in the request, a case for multiple requests
*may*
* be certs for encryption. It may be sufficient to allow multiple names
* for e-mail protection certs in the existing parameter, and a rule
saying
* that names must be present.
[TF] If you just want to check all the certs to be email protection, you
can do that via the basic policy. If you want ot check specific certs
with specific names, yes you have to submit multiple requests.

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 13 Dec 2004 16:14:35 +0100 (MET)

> name validation algorithm does.
I am not assuming a single possible matching algorithm. 
I'd am saying that there should be at least
one matching algorithm that can compare any name (probably at least
binary comparison). 

> notion that all bad names cause asn decode errors.

Do you mean 'additional syntactical constraints' or really 'semantics'?

Syntactical errors include dection like 'an rfc822 has an @ sign etc'.
Semantical sounds to me like you want validate whether the email exists, whether
domain exists, etc.?

Syntactical errors can provokde asn1 decoding errors, it depends also
to a certain degree on what version of ASN1 you use in order to
directly specify constraints... ooups, I think is currently
forbidden to talk at all about ASN1 version in PKIX. So I break the
rule. make a ASN1 syntax which is valid under a CURRENT version, please.  

Anyway, having a special error code doesn't hurt too much.

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 13 Dec 2004 16:52:54 +0100 (MET)

For the statement

     If the extended key usage extension is present, it MUST contain 
     either the client authentication OID, the SCVP client OID, or 
     some other OID by agreement with the SCVP server.

where are the two OID defined?

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 13 Dec 2004 16:52:59 +0100 (MET)

> be in the certificate. I don't see value in repeating the value twice in

And I don't "believe" this.in fact,I don't have to believe anything here,
since I know why I had asked for the text in 3379.

If one gets married, I don't necessarily want to change the identity 
indicated in a drivers licence just because of this. I want to be able 
to pretend to have a certain identity, i.e. a statement to be made for
it, and then, in whatever way, provide the means to authenticate this
identity, and not the other way around, to derive a potentially unwanted
identity.

If a certificate would be sufficient, then I don't see what can be
the meaning of the sentence  

"Mechanisms for matching this identifier with the
   authenticated identity depends on local DPV server conditions and/or
   the validation policy."

a sentence which is grammatically incorrect, but anyway: There are
clearly TWO identifiers, one is the authenticated identity, and one
is another. 

If all declarations are done via a certificate that is also used
for authentication, what would be "mechanism for matching" of TWO
things can occur?  

But well, maybe the authors of 3379 may comment.  

Peter

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 13 Dec 2004 16:05:24 +0100 (MET)

> include my certificate. How is that not a declaration of identity.

You have a From: field in your e-mail, which is how a signer claims
his identity in general.

---

From: "Trevor Freeman" <[email-masked]>
Date: Wed, 15 Dec 2004 15:36:57 -0800

Hi David,

First off I think that the current draft has an omission with respect
the fact that there is no explicit do revocation check. Therefore if you
want path construction with revocation, that is two checks to request.
If the client then subsequently passes in the revocation check on is
own, does that mandate a path build on the client certificate - no. A
server may elect to do that voluntarily, but I don't want to require the
server to do any more than is absolutely necessary. If a client had
previously requested the certificate validity form the server, it may
just be interested in refreshing the revocation status. It can simply do
that by passing in the set of certificates from the previous validation
and request revocation checking. You have the name CAs name and CDP or
AIA - so you have everything you need. I would expect the server to
check the status of signer of the revocation information but otherwise
where is the problem. I would agree that a client should not request
this without having first checked the status of the certificate, but
then there are 1000 ways the client can screw this up and the server is
powerless.

Trevor

________________________________

From: David A. Cooper [mailto:[email-masked]] 
Sent: Tuesday, December 14, 2004 8:37 AM
To: Trevor Freeman
Cc: Denis Pinkas; [email-masked]
Subject: Re: SCVP 16 comments deadline

Trevor,

There seems to be a misunderstanding here.  The check in question is:

Do revocation status checks on the certification path

In your response to Denis below, you say:

If the client has asked for revocation information, I don't see a full
path build for the client certificate is required. You may build a path
for the CA certificate which signed the CRL, but that is different.

There is a disconnect between these two statements.  The check requires
the server to perform status checks on the path.  In your response, you
refer to the CRL.  If the check only required to server to perform a
status check on the end certificate (i.e., the certificate presented in
the request), then your comment would make sense.  However, the check
requires the server to perform status checks on the path.  Since SCVP
does not allow the client to present a path to the server, the server
MUST build a certification path in order to perform the
id-stc-build-status-checked-pkc-path check, otherwise the server would
not have a certification path for which to perform status checks.

You suggest that the id-stc-build-status-checked-pkc-path check might be
used by itself in a case in which a DPD client has already been able to
build a path.  But this does not work, since the server may not provide
status checks on the same certification path as the one constructed by
the client (or the one that the client had previously obtained from the
SCVP server).  The client could increase the chances that the server
would use the path that it was interested in by providing the
certificates in the path through the intermediateCerts field, but this
would not guarantee that the server would provide status checks for this
path.

As I said in my previous message, if the client wants to server to
provide status checks for the certificates in a particular certification
path, then the client should use OCSP.  OCSP allows the client to ask
for status information for a specific set of certificates, SCVP does
not.  With SCVP, the client can only specify the trust anchor and the
end certificate; the server MUST build the remainder of the
certification path.  So, even if the client only includes the
id-stc-build-status-checked-pkc-path check, there is an implicit
requirement for the server to build a certification path.  I believe
that it makes no sense for the server to perform the
id-stc-build-status-checked-pkc-path check on an unvalidated
certification path.  That is, I believe that the only sensible use of
this feature is for the server to build a validated certification path
and then perform status checks on that path; there is no benefit to
performing status checks on an unvalidated certification path.  Given
this, it makes sense to explicitly indicate that the
id-stc-build-status-checked-pkc-path check requires the server to build
a validated certification path and do revocation status checks on that
certification path.

Dave

Trevor Freeman wrote:

* -----Original Message-----
* From: Denis Pinkas [mailto:[email-masked]]
* Sent: Monday, December 13, 2004 12:35 AM
* To: Trevor Freeman
* Cc: David A. Cooper; [email-masked]
* Subject: Re: SCVP 16 comments deadline
* 
* Trevor,
* 
* > David,
* > No wanting to rathole on this sine time is short, the section of the
* > document in question which Denis referred to is dealing with the set
of
* > request that the client can make to the server. We agree that the
client
* > can ask for path construction without revocation checking.
* 
* Up to here we agree.
[TF] Good
* 
* > I think it
* > legitimate a DPD client could ask for revocation checking because it
has
* > already be able to build a path. Conceivably a DPV client could do
the
* > same because it pervious asked for the path to be constructed and
just
* > wants the revocation data refreshed.
* 
* Here we do not agree. If a client has already been able to build a
path,
* then he provides that path as "useful certificates" and the DPV server
will
* necessarily build the path (using or not using these "useful
certificates")
* and verify it.
* 
* So if revocation checking is asked for by the client, this necessarily
* mandates path construction.
[TF] what there server does to process the request is orthogonal to the
section in question.  If the client has asked for revocation
information, I don't see a full path build for the client certificate is
required. You may build a path for the CA certificate which signed the
CRL, but that is different.
* 
* Denis
* 
* 
* > However to get to the bottom line, is there a specific problem with
the
* > text in section 3.1.2
* > Trevor
* >
* > * -----Original Message-----
* > * From: David A. Cooper [mailto:[email-masked]]
* > * Sent: Thursday, December 09, 2004 2:22 PM
* > * To: Trevor Freeman
* > * Cc: [email-masked]
* > * Subject: Re: SCVP 16 comments deadline
* > *
* > * Trevor,
* > *
* > * I must say that I agree with Seth and Denis.  I was under the
impression
* > * that "Do revocation status checking on the certification path"
really
* > * meant "build and validated certification path to a trust anchor
and do
* > * revocation status checking on the certification path".  While I
can see
* > * that there may be circumstances in which one would request a
validated
* > * certification path without requiring revocation status checking, I
can't
* > * see requesting revocation status checking without requesting that
the
* > * path be validated.
* > *
* > * It is certainly the case that one can not "do revocation status
checking
* > * on the certification path" without also building a certification
path.
* > * Since the client can not provide a certification path, revocation
status
* > * checking must be performed on a path that is built by the server.
I
* > * suppose you could argue that this simply means that a well formed
query
* > * can not include the id-stc-build-status-checked-pkc-path without
also
* > * including either the id-stc-build-pkc-path or
* > * id-stc-build-valid-pkc-path check.  But, I see see the need for
this.
* > *
* > * A DPD client would include the id-stc-build-pkc-path along with
the
* > * id-swb-pkc-best-cert-path and/or id-swb-pkc-revocation-info
wantBacks.
* > * If the DPD client included the id-swb-pkc-revocation-info
wantBack, it
* > * wouldn't need to also include the
id-stc-build-status-checked-pkc-path
* > * check.  If the DPD client did not include the
id-swb-pkc-revocation-info
* > * wantBack, then would not include the
id-stc-build-status-checked-pkc-path check.
* > *
* > * So, I would argue that the id-swb-pkc-revocation-info wantBack
would
* > * only be used in the case that the client was requesting a
validated
* > * certification path.  The way that I had interpreted the currently
* > * defined checks items, an SCVP query would only include one check
since
* > * each successive check included the requirements of the previous
one:
* > * id-stc-build-valid-pkc-path included the requirement to build a
path
* > * (id-stc-build-pkc-path) and id-stc-build-status-checked-pkc-path
* > * included the requirement to build a validated path
* > * (id-stc-build-valid-pkc-path).
* > *
* > * Under what circumstances can you envision a client wanting the
server to
* > * do revocation status checking on a certification path (that is
* > * constructed by the server) without also including a requirement
that the
* > * certification path be validated?   If there are no reasonable
* > * circumstances in which a client would make such a query, why is it
* > * necessary for clients to be able to construct such a query?
* > *
* > * Dave
* > *
* > * Trevor Freeman wrote:
* > *
* > * >Hi Seth,
* > * >A server can always go beyond what the client asked for. I don't
see
* > * >that as strictly necessary in all cases such as if the client
just asks
* > * >for revocation. Untimely is a matter of local server policy. What
the
* > * >server cannot do is return status or errors relating to the other
* > * >activities which  were beyond the request scope.
* > * >Trevor
* > * >
* > * While it might make sense for a client to only ask for revocation
* > * checking if the client could specify the certification path, it
does not
* > * seem to make sense given that the server chooses the certification
path
* > * for which revocation status checking will be performed.  If the
client
* > * wants to specify a set of certificates for which it only wants to
know
* > * the revocation status, that is what OCSP is for.
* > *
* > * >
* > * >* -----Original Message-----
* > * >* From: Seth Hitchings [mailto:[email-masked]]
* > * >* Sent: Wednesday, December 08, 2004 11:34 AM
* > * >* To: Trevor Freeman
* > * >* Cc: [email-masked]
* > * >* Subject: RE: SCVP 16 comments deadline
* > * >*
* > * >* Trevor,
* > * >*
* > * >* For clarification, I assume that doing revocation status checks
on a path
* > * >* implies building a validated path?
* > * >*
* > * >* If I am correct, in what case would a client ever send more
than one check?
* > * >*
* > * >* Seth
* > * >*
* > * >* -----Original Message-----
* > * >* From: [email-masked]
* > * >[mailto:[email-masked]]
* > * >* On Behalf Of
* > * >* Trevor Freeman
* > * >* Sent: Wednesday, December 08, 2004 1:42 PM
* > * >* To: Denis Pinkas
* > * >* Cc: [email-masked]
* > * >* Subject: RE: SCVP 16 comments deadline
* > * >*
* > * >*
* > * >* Denis,
* > * >* I know of several systems who's policy is never to revoke the
identity certificate because
* > * >* they have other mechanisms to address the issue.
* > * >* They are using authorization bound to the identity and they
either rely on short lived
* > * >* authorization assertions or revoke the authorization privilege
assonated with the
* > * >* identity. Therefore in those cases not checking the revocation
status of the certificate
* > * >* makes perfect sense.
* > * >* Trevor
* > * >*
* > * >* * -----Original Message-----
* > * >* * From: [email-masked]
* > * >* [mailto:[email-masked]]
* > * >* * On Behalf Of Denis Pinkas
* > * >* * Sent: Wednesday, December 08, 2004 8:01 AM
* > * >* * To: Trevor Freeman
* > * >* * Cc: [email-masked]
* > * >* * Subject: Re: SCVP 16 comments deadline
* > * >* *
* > * >* *
* > * >* * Trevor,
* > * >* *
* > * >* * > Hi Denis,
* > * >* * > Below are responses to 1-16. Others will follow later.
* > * >* *
* > * >* * I am pleased that you accepted comments 13, 14, 15 and 16.
* > * >* * Among this list, I have a further remark on comment 4.
* > * >* *
* > * >* * > * 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.
* > * >* *
* > * >* * I agree that "building a path is a separate check to
revocation checking",
* > * >* * but revocation checking without building a validated path
does not make sense.
* > * >* *
* > * >* * The full text currently is:
* > * >* *
* > * >* *      - Build a certification path to a trust anchor;
* > * >* *
* > * >* *      - Build a validated certification path to a trust
anchor; and
* > * >* *
* > * >* *      - Do revocation status checks on the certification path.
* > * >* *
* > * >* * The full text should be:
* > * >* *
* > * >* *      - Build a certification path to a trust anchor;
* > * >* *
* > * >* *      - Build a validated certification path to a trust
anchor; and
* > * >* *        do revocation status checks on the certification path.
* > * >* *
* > * >* * Denis

---

From: "Trevor Freeman" <[email-masked]>
Date: Wed, 15 Dec 2004 16:02:02 -0800

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
* *
* *
* * 24. Page 15. Section 3.1.3 "wantBack"
* *
* * The text states:
* *
* * id-swb-pkc-all-valid-cert-paths OBJECT IDENTIFIER ::= { id-swb 13}
* *
* * It should be mentioned that this item is only possible for DPD.
* *
* *
* * 25. Page 16. Section 3.1.4 validationPolicy
* *
* * The following sentence is talking of an agreement whereas such
* * agreement does not exist. Delete the sentence:
* *
* *   "The client and server can optionally agree on a set of parameters
* *    which may fully or partially define a validation policy".
* *
* *
* * 26. Page 16. Section 3.1.4 validationPolicy
* * The text states:
* *
* *    "If a partial set of parameters has been agreed upon,
* *    then the client supplies a reference to the policy plus whatever
* *    parameters are necessary to complete the request in this item.
* *
* * This should be replaced with:
* *
* *    "If the validation policy does not define all parameters
necessary
* *    for processing an SCVP request, then the client need to supply
these
* *    parameters".
* *
* * 27. Page 16. Section 3.1.4 validationPolicy
* *
* *    The syntax of the validationPolicy item is defined as:
* *
* *    ValidationPolicy ::= SEQUENCE {
* *      validationPolRef          ValidationPolRef,
* *      validationAlg         [0] ValidationAlg OPTIONAL,
* *      userPolicySet         [1] SEQUENCE SIZE (1..MAX) OF OBJECT
* *                                  IDENTIFIER OPTIONAL,
* *      inhibitPolicyMapping  [2] BOOLEAN OPTIONAL,
* *      requireExplicitPolicy [3] BOOLEAN OPTIONAL,
* *      inhibitAnyPolicy      [4] BOOLEAN OPTIONAL,
* *      isCA                  [5] BOOLEAN OPTIONAL,
* *      trustAnchors          [6] TrustAnchors OPTIONAL,
* *      keyUsages             [7] SEQUENCE SIZE (1..MAX) OF KeyUsage
* *                                   OPTIONAL,
* *      extendedKeyUsages     [8] ExtKeyUsageSyntax OPTIONAL}
* *
* *
* * This structure is quite odd, because it only allows to pass
additional
* * parameters as parameters of the validationAlg. Suppressing the
* * validationAlg item add adding validationParamExtensions would be a
* * simpler and cleaner way.
* *
* * Each validation policies uses its own parameters.
* * We should have something like :
* *
* * ValPolByOID  ::= SEQUENCE {
* *        valPolgId             OBJECT IDENTIFIER,
* *        parameters            ANY DEFINED BY valPolId OPTIONAL }
* *
* * More details follow.
* *
* *
* * 28. It is highly debatable if URIs should be supported or not to
* * reference a validation policy. URIs are not stable over time and
thus
* * unless there are dereferenced and a hash value is computed over
them,
* * it is insecure to use them. There is a discussion in the security
* * consideration section, but no warning and no pointer here. If we
keep
* * them, we should warn the user.
* *
* * If the WG should decides that they should be supported (and if the
IESG
* * agrees) on page 17, the ASN.1 description should then be:
* *
* * ValidationPolicy ::= CHOICE {
* *      valPolByOID         [0] ValPolByOID,
* *      valPolByURI         [1] ValPolByURI }
* *
* * ValPolByOID  ::= SEQUENCE {
* *        valPolgId             OBJECT IDENTIFIER,
* *        parameters            ANY DEFINED BY valPolId OPTIONAL }
* *
* * ValPolByURI ::= SEQUENCE {
* *      uri            IA5String,
* *      hashAlgo       OBJECT IDENTIFIER,
* *      hashValue      OCTET STRING}
* *
* *
* * 29. It is proposed to define the following bundle:
* *
* * ValidationParamBundle ::= SEQUENCE {
* *      certificatePolicySet      [0] SEQUENCE SIZE (1..MAX) OF OBJECT
* *                                    IDENTIFIER OPTIONAL,
* *      inhibitPolicyMapping      [1] BOOLEAN OPTIONAL,
* *      requireExplicitPolicy     [2] BOOLEAN OPTIONAL,
* *      inhibitAnyPolicy          [3] BOOLEAN OPTIONAL,
* *      isCA                      [4] BOOLEAN OPTIONAL,
* *      trustAnchors              [5] TrustAnchors OPTIONAL,
* *      keyUsages                 [6] SEQUENCE SIZE (1..MAX) OF
KeyUsage
* *                                    OPTIONAL,
* *      extendedKeyUsages         [7] ExtKeyUsageSyntax OPTIONAL
* *      extensions                [8] EXPLICIT Extensions OPTIONAL }
* *
* * Note that userPolicySet" is unclear and has been changed into
* * "certificatePolicySet".
* *
* * The text would need to be aligned with the new structure and, of
course
* * the parameters of the rfc-3280 basic validation policy will simply
* * include the bundle above as its parameters.
* *
* * It should also be mentioned somewhere in the document that the
support
* * of the rfc-3280 basic validation policy is not mandatory for
* * conformance but, if supported then the bundle needs to be supported.
* *
* *
* * 30. Page 17. Section 3.1.5 validationAlg should be deleted.
* *
* *
* * 31. Page 17. Section 3.1.5.1 Default Validation Algorithm should be
* * deleted and replaced by a section later on the "rfc-3280 basic
* * validation policy", which should have its OID defined under the scvp
* * tree for OIDs.
* *
* *
* * 32. Page 17. Section 3.1.5.1. Some text of this section might be re-
* * sued to build a new section on the rfc-3280 basic validation policy.
* * Note that the last sentence at the bottom of page 17, should be
* * removed. This sentence is: "The default validation policy MUST use
the
* * basic validation algorithm". Any default validation policy can be
used.
* *
* *
* * 33. Page 17. Section 3.1.5.2 validationAlg (same title as 3.1.5 !)
* * should be as well deleted.
* *
* *
* * 34. Page 20. Section 3.1.5.2.3 Name Validation Algorithm
* *
* * This goal of this section seems to introduce an additional test to
the
* * basic "rfc-3280 basic validation policy". It would come naturally as
* an
* * extension of ValidationParamBundle, rather than as a parameter of
the
* * validationAlgo which has been proposed to be removed. The text
should
* * be modified accordingly.
* *
* *
* * 35. Page 21. Section 3.1.5.2.3 Name Validation Algorithm
* *
* *      NameValidationAlgParms ::= SEQUENCE {
* *        keyPurposeId      KeyPurposeId,
* *        validationNames   GeneralNames }
* *
* * This construct is artificial since KeyPurposeId is about the
Extended
* * Key Usage and has nothing to do with name validation.
* *
* * It could indeed be interesting to test the Extended Key Usage
extension
* * of a certificate, but this should be supported as an extension of
* * ValidationParamBundle. The text should be modified accordingly.
* *
* *
* * 36. Page 22. Section 3.1.5.3 userPolicySet
* *
* * userPolicySet should be changed everywhere into
certificatePolicySet.
* *
* *
* * 37. Page 22. Section 3.1.5.3 userPolicySet
* *
* * The text has many sentences like:
* *
* *    SCVP clients SHOULD support userPolicySet item in requests, and
* *    SCVP servers MUST support userPolicySet item in requests.
* *
* * These requirements only apply for the rfc-3280 basic validation
policy,
* * and this should be clearly mentioned.
* *
* *
* * 38. Page 22. Section 3.1.5.4 inhibitPolicyMapping
* *
* * The text states:
* *
* *    By default the server allows policy mapping as
* *    part of certification path validation.
* *
* * For simplicity, this should be the reverse. Replace with:
* *
* *   "By default the server does not perform policy mapping as
* *    part of certification path validation. If the client wants the
* *    server to support policy mapping, allowPolicyMapping must be set
* *    to TRUE in the request".
* *
* *
* * 39. Page 24. Section 3.1.5.8 trustAnchors
* *
* * The text states:
* *
* *   "A certificate reference can be used to identify the
* *    trust anchor by certificate hash and optionally a distinguished
* *    name with serial number".
* *
* * This is not consistent with the ASN.1 definition of PKCReference
which
* * is:
* *
* *    PKCReference ::= CHOICE {
* *      cert                   [0] Certificate,
* *      pkcRef                 [1] ESSCertID }
* *
* * Please correct.
* *
* *
* * 40. Page 25. Section 3.1.6 responseRefHash
* *
* * The text states:
* *
* *    "By default, the server includes a hash
* *    of the request in the response.  If the client wants the server
to
* *    include the full request in the response, responseRefHash is set
to
* *    FALSE."
* *
* * The server shall always include a hash of the request in the
response.
* * This is an easy way to allow to test the integrity of the request.
* * Since the full description of the validation policy may be much
longer
* * a flag should be used to say that the full validation policy is not
* * returned unless requested. It is thus proposed to have instead the
* * following:
* *
* * "3.1.6.1 fullRequestInResponse
* *
* *    The fullRequestInResponse controls if the client wants the server
* *    to include the full request in the response. By default,
* *    fullRequestInResponse is set to FALSE. If the client wants back
* *    the full request then it must set this parameter to TRUE. The
main
* *    reason a client would request the server to include the full
request
* *    in the response is to archive the request-response exchange in a
* *    single object.  That is, the client wants to archive a single
object
* *    which includes both request and response".
* *
* *
* * 41. Page 26. Section 3.1.6.2 responseValidationPolByRef
* *
* * This item should be renamed: fullValPolInResponse
* *
* * The text should be changed into:
* *
* * "The fullValPolInResponse controls whether the response includes the
* * identifier of the validation policy with all the parameters that
have
* * been used by the server, i.e. all the variable parameters
independent
* * from the fact that there were specified by the client or defaulted
if
* * not specified. By default, fullValPolInResponse is set to FALSE. If
the
* * client wants the full validation policy to be included, then
* * fullValPolInResponse is set to TRUE. The main reason a client would
* * request the server to include validation policy to be included by
value
* * is to archive the request-response exchange in a single object. That
* * is, the client wants to archive the CVResponse and have it include
* * every aspect of the validation policy."
* *
* * The ResponseFlags should be changed as follows:
* *
* *    ResponseFlags ::= SEQUENCE {
* *      fullRequestInResponse      BOOLEAN DEFAULT FALSE,
* *      fullValPolInResponse       BOOLEAN DEFAULT FALSE,
* *      signResponse               BOOLEAN DEFAULT TRUE }
* *
* *
* * 42. Page 28. Section 3.1.9 intermediateCerts. Minor.
* *
* * Change:
* *
* *    The optional intermediateCerts item helps the SCVP server create
* *    valid certification paths.
* *
* * into:
* *
* *    The optional intermediateCerts item may help the SCVP server to
* * create
* *    valid certification paths.
* *
* * 43. Page 29. Section 3.1.11. producedAt
* *
* * Last sentence. Change:
* *
* *    SCVP server SHOULD support the producedAt values in the request.
* *
* * into:
* *
* *    SCVP server MAY support the producedAt values in the request.
* *
* * Reason: cached responses should not need to be implemented in order
to
* * be compliant with the specification.
* *
* *
* * 44. Page 32. Section 3.5 dhPublicKey
* *
* * The text states:
* *
* *   "For the server to compute the shared
* *    secret, it must lean the public values the client generates,
* *    therefore the client MUST include this in the request if it uses
* *    this mechanism to integrity protect the request-response pair."
* *
* * Replace:
* *
* * "to integrity protect the request-response pair"
* *
* * with :
* *
* * "to authenticate and integrity protect the first response and
* * authenticate and integrity protect subsequent request-response
pairs".
* *
* * 45. Page 32. Section 3.6 SCVP Request Authentication
* *
* * The text states:
* *
* *   "It is a matter of local policy what validation policy is used by
* *    the server when validating requests".
* *
* * This sentence could be misinterpreted because the word "validating"
is
* * being used. Change into:
* *
* *    It is a matter of local policy what validation policy is used by
* *    the server when authentication requests".
* *
* *
* * 46. Page 35. Section 4. Validation Response
* *
* *    The CVResponse is defined as follows:
* *
* *      CVResponse ::= SEQUENCE {
* *        cvResponseVersion         cvResponseVersion        INTEGER,
* *        policyID                  INTEGER,
* *        producedAt                GeneralizedTime,
* *        ....
* *
* * On the next page the test states:
* *
* *   "The policy ID used by the SCVP server when it processed the
request.
* *    See section 6.4 for details."
* *
* * In section 6.4 the text states:
* *
* * "6.4 defaultPolicyID
* *
* *    An integer that uniquely represents the version of the default
* *    validation policy as represented by the trustAnchors, ..."
* *
* * This is not understandable, over-engineering and very complicated.
* * Please delete this item.
* *
* *
* * 47. Page 35. Section 4. Validation Response
* *
* *    The CVResponse contains:
* *
* *        requestRef            [1] RequestReference OPTIONAL,
* *
* * Remove "OPTIONAL" since it is very beneficial to mandate this item
* * since it allows to make sure that the request has not be modified if
* * the response is integrity protected. The computation is fast and
easy
* * and the hash value does not overload the response.
* *
* *
* * 48. Page 38. Section 4.5 respValidationPolicy
* *
* * The definition of this item is overcomplicated and not tailored to
* * support any kind of validation policy.
* *
* * If the client does not specify the validation policy or if the
client
* * specifies a validation policy which has default parameters, then the
* * full description of the validation policy shall be given back.
* *
* * If the client specifies a validation policy which has no default
* * parameters, then the reference and parameters, if any, of the
* * validation policy are in the request.
* *
* * The full description of the validation policy shall be given back in
* * any case, if the fullValPolInResponse Boolean in ResponseFlags is
set.
* *
* * respValidationPolicy :: = ValidationPolicy
* *
* *
* *
* * 49. Page 41. Section 4.6 requestRef
* *
* * As stated earlier, requestRef should be mandatory and always be a
hash
* * of the request.
* *
* * In addition a fullRequest OPTIONAL parameter should be added as an
* * optional item for CVResponse.
* *
* * The full description of the validation policy shall be given back in
* * any case, if the fullRequestInResponse Boolean in ResponseFlags is
set.
* *
* * Change the text and the syntax accordingly.
* *
* *
* * 50. Page 41. Section 4.6 requestRef
* *
* * The text states:
* *
* *    "The requestRef item allows the client to associate a response
with
* *    a request"
* *
* * This is wrong. This does not protect against a replay.
* *
* * Change with:
* *
* * "When the response is authenticated, the requestRef item allows the
* * client to make sure that the request was not modified in transit".
* *
* *
* * 51. Page 41. Section 4.6 requestRef
* *
* * The text states:
* *
* * " The requestNonce provides an alternative mechanism for
* *    matching requests and responses if the client has selected to
* *    include a full response."
* *
* * This is wrong. This is not an alternative for matching requests and
* * responses.
* *
* * Replace with:
* *
* *   "The requestNonce allows to protect against replay, even if time
* * synchronization is not good between the client and the server".
* *
* *
* * 52. Page 42. Section 4.6.1 requestHash
* *
* * The text states:
* *
* * " The requestNonce provides an alternative mechanism for matching
* * requests and responses".
* *
* * This is wrong. See above. Delete.
* *
* *
* * 53. Page 45. Section 4.10.4 replyChecks
* *
* * ReplyCheck is defined as:
* *
* *      ReplyCheck ::= SEQUENCE {
* *        check                      OBJECT IDENTIFIER,
* *        status                     INTEGER }
* *
* * It should be defined as:
* *
* *      ReplyCheck ::= SEQUENCE {
* *        check                      OBJECT IDENTIFIER,
* *        status                     INTEGER DEFAULT 0}
* *
* *
* * 54. Page 46. Section 4.10.4 replyChecks
* *
* * The text states
* *
* *    "The status value for public key certification path building to a
* *    trusted root along with complete status checking, { id-stc 3 },
can
* *    be one of the following:
* *
* *        0: Good
* *        1: Revoked
* *        2: Revocation Offline
* *        3: Revocation Unavailable
* *
* * It is unclear to understand the benefits that a client can have from
* * the difference between "Revocation Offline" and "Revocation
* * Unavailable". In addition, these wordings do not match the
explanations
* * of what there are.
* *
* * A much more important response is missing: suspended. Suspended is a
* * variation of revoked, but the client then knows it may attempt
another
* * try later on.
* *
* * It is thus suggested to change it into:
* *
* *        0: Good
* *        1: Revoked
* *        2: Suspended
* *        3: Revocation info unavailable"
* *
* *
* * 55. Page 46. Section 4.10.4 replyChecks
* *
* *
* * The same comment applies for the status value for AC issuer
* * certification path.
* *
* *
* * 56. Page 48. Section 4.10.6 validationAlg
* * For reasons given before, delete validationAlg.
* *
* *
* * 57. Page 48. Section 4.10.8 nextUpdate
* *
* * If CRLs are used, should this field contain the value of the next
* * update field for the smallest value of all the CRLs ? What is the
real
* * benefit of supporting this element besides added complexity ? It is
* * suggested to delete that item.
* *
* *
* * 58. Page 49. Section 4.11 responseNonce
* *
* * The text states:
* *
* * "The responseNonce item contains an identifier to binds the request
* * to the response."
* *
* * This is incorrect. The nonce is to detect replay.
* *
* * Change into:
* *
* * "The responseNonce item contains a unique number which allows to
detect
* * replay".
* *
* *
* * 59. Page 51. Section 5 Server Policy Request
* *
* * The text states:
* *
* *   "A SCVP client uses the valPolRequest item to request the list of
* *    validation policies supported by the SCVP server."
* *
* * This is not a correct description of what this request is doing.
When
* * looking at the ASN.1 it is doing much more. So the question is
whether
* * two requests should be provided or one. In the later case, it is
* * important to advertise correctly what the request is doing.
* *
* *
* * 60. Page 52. Section 6 Validation Policy Response
* *
* * The ASN.1 of the VPResponse is over-complicated.
* *
* * The first three items are overengineering:
* *
* *        vpResponseVersion          INTEGER,
* *        maxCVResponseVersion       INTEGER,
* *        maxVPResponseVersion       INTEGER,
* *
* * Further more they are mandatory. Please delete.
* *
* *
* * 61. Page 52. Section 6 Validation Policy Response
* *
* * The ASN.1 of the VPResponse is over-complicated.
* *
* *         defaultPolicyID            INTEGER,
* *
* * This item does not make sense. When an OID references a validation
* * policy, there is no concept of versioning. Another version will
simply
* * get another OID (hopefully in the same branch). Please delete.
* *
* *
* * 62. Page 52. Section 6 Validation Policy Response
* *
* * The ASN.1 of the VPResponse is over-complicated.
* *
* *        validationPolices          SEQUENCE OF ValidationPolRef,
* *        validationAlgs             SEQUENCE OF OBJECT IDENTIFIER,
* *
* * validationAlgs is unnecessary. Please delete.
* *
* * validationPolicies (not validationPolices) is the main component.
See
* * below for a full proposal for restructuring VPResponse.
* *
* *
* * 63. Page 52. Section 6 Validation Policy Response
* *
* *        authPolicies               SEQUENCE OF AuthPolicy,
* *        responseTypes              ResponseTypes,
* *        dhPublicKeyInfo            SEQUENCE OF DHPublicKeyInfo,
* *
* * are elements which have nothing to do with the list of validation
* * policies, and they are mandatory ! Either group them in one OPTIONAL
* * item or define another command to get them.
* *
* *
* * 64. Page 52. Section 6 Validation Policy Response
* *
* *       defaultPolicyValues        ValidationPolValues,
* *
* * This is simply the set of parameters which are related to the
rfc-3280
* * basic validation policy. This set could be used by other validation
* * policies. Please delete.
* *
* *
* * 65. Page 52. Section 6 Validation Policy Response
* *
* * What follows is a sketch for a proposal for VPResponse.
* *
* *     VPResponse ::= SEQUENCE {
* *        requestNonce               OCTET STRING      OPTIONAL
* *        thisUpdate                 GeneralizedTime,
* *        nextUpdate                 GeneralizedTime   OPTIONAL,
* *        validationPolicies         SEQUENCE OF ValidationPolicy,
* *        serverParams               ServerParams      OPTIONAL }
* *
* *
* *     ServerParams ::= SEQUENCE {
* *        responseTypes              ResponseTypes,
* *        authPolicies           [0] SEQUENCE OF AuthPolicy
OPTIONAL,
* *        dhPublicKeyInfo        [1] SEQUENCE OF DHPublicKeyInfo
OPTIONAL,
* *        clockSkew              [2] INTEGER OPTIONAL }
* *
* * Note: it is re-called that ValidationPolicy should be redefined as:
* *
* * ValidationPolicy ::= CHOICE {
* *      valPolByOID         [0] ValPolByOID,
* *      valPolByURI         [1] ValPolByURI }
* *
* * ValPolByOID  ::= SEQUENCE {
* *        valPolgId             OBJECT IDENTIFIER,
* *        parameters            ANY DEFINED BY valPolId OPTIONAL }
* *
* * ValPolByURI ::= SEQUENCE {
* *      uri            IA5String,
* *      hashAlgo       OBJECT IDENTIFIER,
* *      hashValue      OCTET STRING}
* *
* *
* *
* * 66. Page 56. Section 7 SCVP Server Relay
* *
* * This section is incomplete and lacking explanations. Please explain
how
* * relaying is achieved.
* *
* *
* * 67. Page 65. Section 9 Security Considerations
* *
* * In the second paragraph, there is a discussion about the use of URIs
to
* * reference validation policies.
* *
* * Firstly, if URIs are going to stay, a pointer to the security
* * consideration section should be present in the main body of the
* * document.
* *
* * Secondly, the text should mention the need for the ability to
* * dereference the URI and the need to compute a hash, while the main
body
* * of the document should explain the computation of a hash on the
content
* * of the URI.
* *
* *
* * 68. Page 65. Section 9 Security Considerations
* *
* * The text states:
* *
* *   "It can also do this by using the Diffie-hellman keys to sign the
* * request".
* *
* * Replace "sign" by "authenticate".
* *
* * END OF COMMENTS
* *
* *

---

From: "Trevor Freeman" <[email-masked]>
Date: Thu, 16 Dec 2004 12:48:35 -0800

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.
* * *
* * *
* * * 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
* * *
* * *