Subject: Comments on draft-ietf-pkix-scvp-15.txt

From: Denis Pinkas <[email-masked]>
Date: Wed, 28 Jul 2004 19:09:47 +0200

Comments on draft-ietf-pkix-scvp-15.txt
Simple Certificate Validation Protocol (SCVP) alias
Complex Certificate Validation Protocol (CCVP).

1. The abstract is still omitting to use the term "validation policy". A
certificate can only be valid according to a validation policy. A 
certification
path can only be constructed according to a validation policy.

The current abstract is:

  SCVP allows a client to offload certificate handling to a server.  
  The server can provide the client with a variety of valuable
  information about the certificate, such as whether the certificate
  is valid, a certification path to a trust anchor, and revocation
  status.  SCVP has many purposes, including simplifying client
  implementations and allowing companies to centralize trust and
  policy management.

Change the abstract into:

  SCVP allows a client to offload certificate handling to a server.  
  The server can provide the client with a variety of valuable
  information about the certificate, such as whether the certificate
  is valid according to a validation policy, a certification path to
  one of the trust anchors from a validation policy, and revocation
  status of every element from a certification path. SCVP has many
  purposes, including simplifying client implementations and allowing
  companies to centralize trust and policy management.

2. Section 1. Introduction

Some text in this section is incorrect.

"  The first class of application wants just two things. First, they
  want confirmation that the public key belongs to the identity named
  in the certificate.  Second, they want to know if the public key
  can be used for the intended purpose.  The client completely
  delegates certification path construction and validation to the
  SCVP server".

The rational of the first sentence has noting to do with the second 
sentence.
Simply looking at the content of the certificate allows to answer the two
questions. There is no need to use a server to get that information.

3. In section 1.3 Validation Policies the text states:

" In SCVP, a validation policy can be explicitly expressed by passing
  all the parameters in the request where the request comprises of a
  validation algorithm for certificate path processing and the input
  parameters to the algorithm. Alternatively a validation policy can
  be indirectly referenced by a mutually agreed value such as an OID
  or URL where the value indicates either are a partial or full set
  of parameters necessary to complete the validation."

The two alternatives should be at the same level, or emphasis should 
even be
placed on the second alternative.

In order to support thing clients, it is necessary to be able to simply 
use an
OID (forget about instable / temporary URLs) which either tells 
everything to
the server, or if no OID is being used by the client, an OID supplied by 
the
server which tells every to the client.

Note: URNs could be used, but not URLs.

There is a major difference between a validation policy and a validation
algorithm. A validation policy is a set of rules which includes many 
algorithms
and their associated parameters.

ValidationAlg is currently defined as:

    ValidationAlg ::= SEQUENCE {
      valAlgId              OBJECT IDENTIFIER,
      parameters            ANY DEFINED BY valAlgId OPTIONAL }

A parameter, called validationPol should be introduced in the query to 
allow the
use of a simple OID to reference a full policy or to define a validation 
policy,
i.e. first a validation algorithm compliant with [PKIX-1] section 6.1 
coming
with its associated parameters and additional algorithms coming with their
associated parameters.

ValidationPol should be defined as :

  ValidationPol ::= CHOICE {
      valPolRef             OBJECT IDENTIFIER,
      valPolDef             ValPolRef }

  ValPolDef ::= SEQUENCE {
      valPolId              OBJECT IDENTIFIER,
      parameters            ANY DEFINED BY valPolId OPTIONAL }

When using valPolRef, all algorithms and parameters are fixed.
When using valPolDef, some parameters may be dynamic.

The current structure of ValPolicy defined in section 4.11 on page 38, 
would be
used for the parameters of a specific validation policy defined in this
document, i.e. id-svp-defaultValAlg OBJECT IDENTIFIER ::= { id-svp 1 }

The text should thus not state:

"When the id-svp-defaultValAlg appears as an valAlgId, the
parameters MUST be absent."

The parameters for the default validation policy shall be the parameters of
ValPolDef. The overall structure of the request would be greatly 
simplified.

Note also that the ValidationAlg parameter has been omitted to be 
described at
the right place, i.e. in sequence after section 3.2.4, but is described in
section 3.2.12 as:

3.2.12 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 }

Path processing is only one of the many checks that can be done, since many
additional checks about the content of the certificate can be done in 
addition
to the certificate path processing algorithm defined by [PKIX-1] in section
6.1.1.

It is thus inappropriate to limit in general the parameters to those of 
section
6.1.1., thus why all parameters associated with a given validation 
algorithm
shall always be included in the parameters of ValPolDef.

The text also states:

"The SCVP server can assign validation algorithm object identifiers
  which indicate that some predefined settings are used in addition
  to values provided in the SCVP request."

Why this ? If the client specifies a validation policy either the server
supports it or returns an error. If the client does not specify a 
validation
policy in its request, then the server has to return the default validation
policy which it has been used (and which may have nothing to do with the so-
called default validation policy defined in section 3.2.12.1.)

The following text extracted from the document, highlights the confusion 
between
a validation policy and a validation algorithm.

" For a certification path to be considered valid under a particular
  validation policy, it MUST be a valid certification path as defined
  in [PKIX-1] and all validation policy constraints that apply to the
  certification path MUST be verified.  Applications MAY place
  additional requirements on the validation algorithm."

4. In section 3 Validation Request, the text states:

" All SCVP clients MUST support SignedData for signed requests and
  responses."

For certification path discovery signed responses are not necessary, nor 
are
signed requests necessary. For certificate validation according to a 
validation
policy signed responses are necessary, but signed requests are not 
necessary. So
this requirement should be modified.

5. Similar considerations apply for authenticatedData for signed 
requests and
responses.

6. The current query, which is far too complicated, is currently 
composed of 21
items as follows:

    Query ::= SEQUENCE {
     queriedCerts             SEQUENCE SIZE (1..MAX) OF CertReference,
     checks                   CertChecks,
     wantBack                 WantBack,  
     validationAlg            ValidationAlg,
     requestRefHash           BOOLEAN DEFAULT TRUE,
     fullPolResponse      [0] BOOLEAN DEFAULT FALSE,
     inhibitPolMap        [1] BOOLEAN DEFAULT FALSE,
     requireExplicitPol   [2] BOOLEAN DEFAULT FALSE,
     ignoreAnyPol         [3] BOOLEAN DEFAULT FALSE,
     IsCA                 [4] BOOLEAN DEFAULT FALSE,
     SignResponse         [5] BOOLEAN DEFAULT TRUE,
     serverContextInfo    [6] OCTET STRING OPTIONAL,
     validityTime         [7] GeneralizedTime OPTIONAL,
     trustAnchors         [8] TrustAnchors OPTIONAL,
     intermediateCerts    [9] CertBundle OPTIONAL,
     revInfos            [10] RevocationInfos OPTIONAL,
     keyUsage            [11] KeyUsage OPTIONAL,
     extendedKeyUsage    [12] ExtKeyUsageSyntax OPTIONAL,
     queryExtensions     [13] Extensions OPTIONAL  
     producedAt          [14] GeneralizedTime OPTIONAL
     validationPolRef    [15] ValidationPolRef OPTIONAL}

Taking into consideration the move of the so-called parameters of the 
default
validation algorithm :

     validationPol            ValidationPol,
     inhibitPolMap        [1] BOOLEAN DEFAULT FALSE,
     requireExplicitPol   [2] BOOLEAN DEFAULT FALSE,
     ignoreAnyPol         [3] BOOLEAN DEFAULT FALSE,
     IsCA                 [4] BOOLEAN DEFAULT FALSE,
     trustAnchors         [8] TrustAnchors OPTIONAL,
     keyUsage            [11] KeyUsage OPTIONAL,
     extendedKeyUsage    [12] ExtKeyUsageSyntax OPTIONAL,

In fact as set of parameters is defined on page 38 as:

  ValPolicy ::=SEQUENCE  {
     validationAlg            ValidationAlg,
     inhibitPolMap        [1] BOOLEAN DEFAULT FALSE,
     requireExplicitPol   [2] BOOLEAN DEFAULT FALSE,
     ignoreAnyPol         [3] BOOLEAN DEFAULT FALSE,
     isCA                 [4] BOOLEAN DEFAULT FALSE,
     trustAnchors         [5] TrustAnchors,
     keyUsage             [6] KeyUsage OPTIONAL,
     extendedKeyUsage     [7] ExtKeyUsageSyntax OPTIONAL}

and it would make sense to use that structure which groups them and use 
it as
the parameters to be associated with id-svp 1.

The query could then be simplified as follows:

    Query ::= SEQUENCE {
     queriedCerts             SEQUENCE SIZE (1..MAX) OF CertReference,
     checks                   CertChecks,
     wantBack                 WantBack,  
     requestRefHash           BOOLEAN DEFAULT TRUE,
     fullPolResponse      [0] BOOLEAN DEFAULT FALSE,
     signResponse         [1] BOOLEAN DEFAULT TRUE,
     serverContextInfo        OCTET STRING OPTIONAL,
     validationPol            ValidationPol OPTIONAL,
     -- if missing in the query, then MUST be present in the response
     validityTime             GeneralizedTime OPTIONAL,
     intermediateCerts        CertBundle OPTIONAL,
     revInfos                 RevocationInfos OPTIONAL,
     queryExtensions      [2] Extensions OPTIONAL,
     producedAt           [3] GeneralizedTime OPTIONAL
}

Below the new definition of ValidationPol is copied again.

  ValidationPol ::= CHOICE {
      valPolRef             OBJECT IDENTIFIER,
      valPolDef             ValPolDef }

    ValPolDef ::= SEQUENCE {
      valPolId              OBJECT IDENTIFIER,
      parameters            ANY DEFINED BY valPolId OPTIONAL }

7. The SCVP response is currently defined on page 27 as follows:

    CVResponse ::= SEQUENCE {
      scvpVersion           INTEGER,
      policyID              INTEGER,
      producedAt            GeneralizedTime,
      responseStatus        ResponseStatus,
      requestRef            RequestReference,
      requestor         [1] OCTET STRING OPTIONAL,
      responder         [2] OCTET STRING OPTIONAL,
      replyObjects      [3] ReplyObjects OPTIONAL,
      requestNonce      [4] OCTET STRING OPTIONAL,
      serverContextInfo [5] OCTET STRING OPTIONAL,
      valPolResponse    [6] ValPolicy OPTIONAL,
      validationPolRef  [7] ValidationPolicyRef OPTIONAL  
      respExtensions    [8] Extensions OPTIONAL }

policyID is mandatory and does not make sense when a validation policy 
reference
is being used. It should be deleted.

responder is for SCVP server relay only and the text omits to mention it.

requestor is primarily for SCVP server relay and that this parameter 
should not
have to be supported by a client.

Defining these two parameters as respExtensions would only thin clients 
and non
relaying servers to simply forget about them.

It is thus proposed to simplify the structure as follows:

    CVResponse ::= SEQUENCE {
      scvpVersion           INTEGER,
      requestNonce          OCTET STRING OPTIONAL,
      producedAt            GeneralizedTime,
      requestRef            RequestReference,
      validationPol         ValidationPol OPTIONAL,
      -- if missing in the query, then MUST be present
      responseStatus        ResponseStatus,
      replyObjects      [1] ReplyObjects OPTIONAL,
      serverContextInfo [2] OCTET STRING OPTIONAL,
      respExtensions    [3] Extensions OPTIONAL }

8. The Server Policies Request is currently defined on page 40 as follows:

    PolRequest ::= SEQUENCE {
      scvpVersion                INTEGER }

The current idea is to use a mechanisms similar to the CRL mechanism to 
detect
if the response is current or is a replay. It should be able to support 
a nonce.

The structure should thus be changed to:

    PolRequest ::= SEQUENCE {
      scvpVersion                INTEGER,
      requestNonce               OCTET STRING OPTIONAL }

9. The Server Policies Response is currently defined on page 40 as follows:

    PoliciesResponse ::= SEQUENCE {
      scvpVersion                INTEGER,
      DefaultPolicyID            INTEGER,
      thisUpdate                 GeneralizedTime,
      nextUpdate                 GeneralizedTime,
      trustAnchors               TrustAnchors,
      validationPolices          SEQUENCE OF ValidationPolRef,
      validationAlgs             SEQUENCE OF OBJECT IDENTIFIER,
      authPolicies               SEQUENCE OF AuthPolicy,
      responseTypes              ResponseTypes,   
      defaultValPol              ValPolicy,            
      clockSkew                  INTEGER OPTIONAL,
      authDataCert               Certificate OPTIONAL }

DefaultPolicyID and defaultValPol do not need to be present, since the 
default
policy may simply be the first policy of the SEQUENCE of validation 
policies
that is returned.

nextUpdate should be OPTIONAL since a server may choose to always send a 
fresh
response.

trustAnchors is a parameter of one specify validation policy and thus 
should not
be present at that level.

validationPolices should be used to define a sequence of validation policy
references and/or a sequence of validation policy definitions. See below.

validationAlgs may be inner component of validation policy definition.

authPolicies is unclear, since all responses MUST be signed. Deleted for
simplification.

defaultValPol is not needed, if the default policy is simply the first 
policy of
the SEQUENCE of validation policies that is returned.

The name of authDataCert should be changed into serverCert.

The structure should thus be changed to:

    PoliciesResponse ::= SEQUENCE {
      scvpVersion                INTEGER,
      responseNonce              OCTET STRING OPTIONAL,
      thisUpdate                 GeneralizedTime,
      nextUpdate                 GeneralizedTime OPTIONAL,
      validationPolicies         SEQUENCE OF ValidationPol,
      -- the default validation policy is the first of the sequence
      responseTypes              ResponseTypes,
      clockSkew                  INTEGER OPTIONAL,
      serverCert                 Certificate OPTIONAL }

Denis

---

From: "Trevor Freeman" <[email-masked]>
Date: Sat, 31 Jul 2004 01:14:39 -0700

Hi Denis,
Sorry for the delayed response but I am on vacation. Comments below.
Trevor

* -----Original Message-----
* From: [email-masked]
[mailto:[email-masked]]
* On Behalf Of Denis Pinkas
* Sent: Wednesday, July 28, 2004 10:10 AM
* To: pkix
* Subject: Comments on draft-ietf-pkix-scvp-15.txt
* 
* 
* Comments on draft-ietf-pkix-scvp-15.txt
* Simple Certificate Validation Protocol (SCVP) alias
* Complex Certificate Validation Protocol (CCVP).
* 
* 1. The abstract is still omitting to use the term "validation policy".
A
* certificate can only be valid according to a validation policy. A
* certification
* path can only be constructed according to a validation policy.
* 
* The current abstract is:
* 
*   SCVP allows a client to offload certificate handling to a server.
*   The server can provide the client with a variety of valuable
*   information about the certificate, such as whether the certificate
*   is valid, a certification path to a trust anchor, and revocation
*   status.  SCVP has many purposes, including simplifying client
*   implementations and allowing companies to centralize trust and
*   policy management.
* 
* Change the abstract into:
* 
*   SCVP allows a client to offload certificate handling to a server.
*   The server can provide the client with a variety of valuable
*   information about the certificate, such as whether the certificate
*   is valid according to a validation policy, a certification path to
*   one of the trust anchors from a validation policy, and revocation
*   status of every element from a certification path. SCVP has many
*   purposes, including simplifying client implementations and allowing
*   companies to centralize trust and policy management.

[TF] How about

SCVP allows a client to offload certificate handling to a server. The
server can provide the client with a variety of valuable information
about the certificate, such as whether the certificate is valid
according to a validation policy i.e. a certification path to one of the
policies trust anchors, and revocation status of every element from a
certification path conforms to the policy requirements. SCVP has many
purposes, including simplifying client implementations and allowing
companies to centralize trust and policy management.

* 
* 2. Section 1. Introduction
* 
* Some text in this section is incorrect.
* 
* "  The first class of application wants just two things. First, they
*   want confirmation that the public key belongs to the identity named
*   in the certificate.  Second, they want to know if the public key
*   can be used for the intended purpose.  The client completely
*   delegates certification path construction and validation to the
*   SCVP server".
* 
* The rational of the first sentence has noting to do with the second
* sentence.
* Simply looking at the content of the certificate allows to answer the
two
* questions. There is no need to use a server to get that information.

[TF] I disagree that they are unrelated. It is perfectly legitimate to
ask the serve to check aspects of the certificate since this is a minor
increment to the path validation. 

* 
* 
* 3. In section 1.3 Validation Policies the text states:
* 
* " In SCVP, a validation policy can be explicitly expressed by passing
*   all the parameters in the request where the request comprises of a
*   validation algorithm for certificate path processing and the input
*   parameters to the algorithm. Alternatively a validation policy can
*   be indirectly referenced by a mutually agreed value such as an OID
*   or URL where the value indicates either are a partial or full set
*   of parameters necessary to complete the validation."
* 
* The two alternatives should be at the same level, or emphasis should
* even be
* placed on the second alternative.

[TF] you comments makes no sense to me. Can you rephrase.
* 
* In order to support thing clients, it is necessary to be able to
simply
* use an
* OID 

[TF] I disagree that it is necessary for this clients to use an OID.
Untimely is a deployment and implementation decision.

(forget about instable / temporary URLs) which either tells
* everything to
* the server, or if no OID is being used by the client, an OID supplied
by
* the
* server which tells every to the client.

[TF] OIDs are supported in SCVP15 so I don't understand you point.

* 
* Note: URNs could be used, but not URLs.
[TF] URLs are easier and simpler. 
* 
* There is a major difference between a validation policy and a
validation
* algorithm. A validation policy is a set of rules which includes many
* algorithms
* and their associated parameters.
* 
* ValidationAlg is currently defined as:
* 
*     ValidationAlg ::= SEQUENCE {
*       valAlgId              OBJECT IDENTIFIER,
*       parameters            ANY DEFINED BY valAlgId OPTIONAL }
* 
* A parameter, called validationPol should be introduced in the query to
* allow the
* use of a simple OID to reference a full policy or to define a
validation
* policy,

[TF] ValidationPolRef allows the use of a simple OID as you describe.
THE request support all common parameters required by pkix and is
extensible. Is there a requirement in 3379 that SCVP 15 does not
support?

* i.e. first a validation algorithm compliant with [PKIX-1] section 6.1
* coming
* with its associated parameters and additional algorithms coming with
their
* associated parameters.

[TF] I missed making validationAlg optional. Once that is corrected I
don't see an issue that requires making the other changes to Validation
policy you discuss..

* 
* ValidationPol should be defined as :
* 
*   ValidationPol ::= CHOICE {
*       valPolRef             OBJECT IDENTIFIER,
*       valPolDef             ValPolRef }
* 
*   ValPolDef ::= SEQUENCE {
*       valPolId              OBJECT IDENTIFIER,
*       parameters            ANY DEFINED BY valPolId OPTIONAL }
* 
* When using valPolRef, all algorithms and parameters are fixed.
* When using valPolDef, some parameters may be dynamic.
* 
* The current structure of ValPolicy defined in section 4.11 on page 38,
* would be
* used for the parameters of a specific validation policy defined in
this
* document, i.e. id-svp-defaultValAlg OBJECT IDENTIFIER ::= { id-svp 1 }
* 
* The text should thus not state:
* 
* "When the id-svp-defaultValAlg appears as an valAlgId, the
* parameters MUST be absent."

[TF] Given that all parameters assonated with the default policy can be
expressed elsewhere in the request this is appropriate. As a general
principal since the validation policy is a deployment specific decision,
I don't see how you proposal is workable. Clients cannot be expected to
support any arbitrary set of parameters in order to implement a given
deployment.

* 
* The parameters for the default validation policy shall be the
parameters
* of
* ValPolDef. The overall structure of the request would be greatly
* simplified.
* 
* Note also that the ValidationAlg parameter has been omitted to be
* described at
* the right place, i.e. in sequence after section 3.2.4, but is
described in
* section 3.2.12 as:
* 
* 3.2.12 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 }
* 
* Path processing is only one of the many checks that can be done, since
* many
* additional checks about the content of the certificate can be done in
* addition
* to the certificate path processing algorithm defined by [PKIX-1] in
* section
* 6.1.1.
* 
* It is thus inappropriate to limit in general the parameters to those
of
* section
* 6.1.1., thus why all parameters associated with a given validation
* algorithm

[TF] SCVP does not limit the parameters to the path processing
parameters. However since those parameters are a common set of
parameters it standardized their  use so they can be reused across
multiple validation policies or validation algorithms use while leaving
room for other to be defined.

* shall always be included in the parameters of ValPolDef.
* 
* The text also states:
* 
* "The SCVP server can assign validation algorithm object identifiers
*   which indicate that some predefined settings are used in addition
*   to values provided in the SCVP request."

[TF] This is true for both the policy and algorithm so this needs to be
expanded to include both in the text.

* 
* Why this ? If the client specifies a validation policy either the
server
* supports it or returns an error. If the client does not specify a
* validation
* policy in its request, then the server has to return the default
* validation
* policy which it has been used (and which may have nothing to do with
the
* so-
* called default validation policy defined in section 3.2.12.1.)
* 
* The following text extracted from the document, highlights the
confusion
* between
* a validation policy and a validation algorithm.
* 
* " For a certification path to be considered valid under a particular
*   validation policy, it MUST be a valid certification path as defined
*   in [PKIX-1] and all validation policy constraints that apply to the
*   certification path MUST be verified.  Applications MAY place
*   additional requirements on the validation algorithm."

[TF] I don't see that as a problem. In the example validation algorithm
given a application such as an email client can be configured to use a
specific validation algorithm because it always wants the name
comparison to be performed. That is totally independent of broader the
validation policy

* 
* 
* 4. In section 3 Validation Request, the text states:
* 
* " All SCVP clients MUST support SignedData for signed requests and
*   responses."
* 
* For certification path discovery signed responses are not necessary,
nor
* are
* signed requests necessary. For certificate validation according to a
* validation
* policy signed responses are necessary, but signed requests are not
* necessary. So
* this requirement should be modified.

[TF] If you read 3.2.10 you will see that a client can request that the
response not be signed. However it is a local policy decision on the
server to sign if this value is set. So a DPD only client has to deal
with signed responses even it is only to decode the response. It is not
required to validate the signature.

* 
* 
* 5. Similar considerations apply for authenticatedData for signed
* requests and
* responses.
* 
* 
* 6. The current query, which is far too complicated, is currently
* composed of 21
* items as follows:
* 
*     Query ::= SEQUENCE {
*      queriedCerts             SEQUENCE SIZE (1..MAX) OF CertReference,
*      checks                   CertChecks,
*      wantBack                 WantBack,
*      validationAlg            ValidationAlg,
*      requestRefHash           BOOLEAN DEFAULT TRUE,
*      fullPolResponse      [0] BOOLEAN DEFAULT FALSE,
*      inhibitPolMap        [1] BOOLEAN DEFAULT FALSE,
*      requireExplicitPol   [2] BOOLEAN DEFAULT FALSE,
*      ignoreAnyPol         [3] BOOLEAN DEFAULT FALSE,
*      IsCA                 [4] BOOLEAN DEFAULT FALSE,
*      SignResponse         [5] BOOLEAN DEFAULT TRUE,
*      serverContextInfo    [6] OCTET STRING OPTIONAL,
*      validityTime         [7] GeneralizedTime OPTIONAL,
*      trustAnchors         [8] TrustAnchors OPTIONAL,
*      intermediateCerts    [9] CertBundle OPTIONAL,
*      revInfos            [10] RevocationInfos OPTIONAL,
*      keyUsage            [11] KeyUsage OPTIONAL,
*      extendedKeyUsage    [12] ExtKeyUsageSyntax OPTIONAL,
*      queryExtensions     [13] Extensions OPTIONAL
*      producedAt          [14] GeneralizedTime OPTIONAL
*      validationPolRef    [15] ValidationPolRef OPTIONAL}
* 
* Taking into consideration the move of the so-called parameters of the
* default
* validation algorithm :
* 
*      validationPol            ValidationPol,
*      inhibitPolMap        [1] BOOLEAN DEFAULT FALSE,
*      requireExplicitPol   [2] BOOLEAN DEFAULT FALSE,
*      ignoreAnyPol         [3] BOOLEAN DEFAULT FALSE,
*      IsCA                 [4] BOOLEAN DEFAULT FALSE,
*      trustAnchors         [8] TrustAnchors OPTIONAL,
*      keyUsage            [11] KeyUsage OPTIONAL,
*      extendedKeyUsage    [12] ExtKeyUsageSyntax OPTIONAL,
* 
* 
* In fact as set of parameters is defined on page 38 as:
* 
*   ValPolicy ::=SEQUENCE  {
*      validationAlg            ValidationAlg,
*      inhibitPolMap        [1] BOOLEAN DEFAULT FALSE,
*      requireExplicitPol   [2] BOOLEAN DEFAULT FALSE,
*      ignoreAnyPol         [3] BOOLEAN DEFAULT FALSE,
*      isCA                 [4] BOOLEAN DEFAULT FALSE,
*      trustAnchors         [5] TrustAnchors,
*      keyUsage             [6] KeyUsage OPTIONAL,
*      extendedKeyUsage     [7] ExtKeyUsageSyntax OPTIONAL}
* 
* and it would make sense to use that structure which groups them and
use
* it as
* the parameters to be associated with id-svp 1.
* 
* The query could then be simplified as follows:
* 
*     Query ::= SEQUENCE {
*      queriedCerts             SEQUENCE SIZE (1..MAX) OF CertReference,
*      checks                   CertChecks,
*      wantBack                 WantBack,
*      requestRefHash           BOOLEAN DEFAULT TRUE,
*      fullPolResponse      [0] BOOLEAN DEFAULT FALSE,
*      signResponse         [1] BOOLEAN DEFAULT TRUE,
*      serverContextInfo        OCTET STRING OPTIONAL,
*      validationPol            ValidationPol OPTIONAL,
*      -- if missing in the query, then MUST be present in the response
*      validityTime             GeneralizedTime OPTIONAL,
*      intermediateCerts        CertBundle OPTIONAL,
*      revInfos                 RevocationInfos OPTIONAL,
*      queryExtensions      [2] Extensions OPTIONAL,
*      producedAt           [3] GeneralizedTime OPTIONAL
* }
* 
* Below the new definition of ValidationPol is copied again.
* 
*   ValidationPol ::= CHOICE {
*       valPolRef             OBJECT IDENTIFIER,
*       valPolDef             ValPolDef }
* 
*     ValPolDef ::= SEQUENCE {
*       valPolId              OBJECT IDENTIFIER,
*       parameters            ANY DEFINED BY valPolId OPTIONAL }
* 

[TF] Given that many of the parameters are either defaulted or optional,
I don't agree that moving them around achieves anything other than
document churn. This is a stylistic rater than a technical issue.

* 
* 7. The SCVP response is currently defined on page 27 as follows:
* 
*     CVResponse ::= SEQUENCE {
*       scvpVersion           INTEGER,
*       policyID              INTEGER,
*       producedAt            GeneralizedTime,
*       responseStatus        ResponseStatus,
*       requestRef            RequestReference,
*       requestor         [1] OCTET STRING OPTIONAL,
*       responder         [2] OCTET STRING OPTIONAL,
*       replyObjects      [3] ReplyObjects OPTIONAL,
*       requestNonce      [4] OCTET STRING OPTIONAL,
*       serverContextInfo [5] OCTET STRING OPTIONAL,
*       valPolResponse    [6] ValPolicy OPTIONAL,
*       validationPolRef  [7] ValidationPolicyRef OPTIONAL
*       respExtensions    [8] Extensions OPTIONAL }
* 
* policyID is mandatory and does not make sense when a validation policy
* reference
* is being used. It should be deleted.

[TF] The relevance of the policyID depends on the validation policy so
rather than have the server figure our that dependency, its simpler to
mandate the policyID be present.

* 
* responder is for SCVP server relay only and the text omits to mention
it.

[TF] I will add text to that effect.
* 
* requestor is primarily for SCVP server relay and that this parameter
* should not
* have to be supported by a client.

[TF] A server who relays a request is by definition also a client. Any
client who is not concerned with these values can ignore them. 

* 
* Defining these two parameters as respExtensions would only thin
clients
* and non
* relaying servers to simply forget about them.
* 
* It is thus proposed to simplify the structure as follows:
* 
*     CVResponse ::= SEQUENCE {
*       scvpVersion           INTEGER,
*       requestNonce          OCTET STRING OPTIONAL,
*       producedAt            GeneralizedTime,
*       requestRef            RequestReference,
*       validationPol         ValidationPol OPTIONAL,
*       -- if missing in the query, then MUST be present
*       responseStatus        ResponseStatus,
*       replyObjects      [1] ReplyObjects OPTIONAL,
*       serverContextInfo [2] OCTET STRING OPTIONAL,
*       respExtensions    [3] Extensions OPTIONAL }
* 
* 
* 8. The Server Policies Request is currently defined on page 40 as
follows:
* 
*     PolRequest ::= SEQUENCE {
*       scvpVersion                INTEGER }
* 
* The current idea is to use a mechanisms similar to the CRL mechanism
to
* detect
* if the response is current or is a replay. It should be able to
support
* a nonce.
* 
* The structure should thus be changed to:
* 
*     PolRequest ::= SEQUENCE {
*       scvpVersion                INTEGER,
*       requestNonce               OCTET STRING OPTIONAL }

[TF] Agreed.

* 
* 
* 9. The Server Policies Response is currently defined on page 40 as
* follows:
* 
*     PoliciesResponse ::= SEQUENCE {
*       scvpVersion                INTEGER,
*       DefaultPolicyID            INTEGER,
*       thisUpdate                 GeneralizedTime,
*       nextUpdate                 GeneralizedTime,
*       trustAnchors               TrustAnchors,
*       validationPolices          SEQUENCE OF ValidationPolRef,
*       validationAlgs             SEQUENCE OF OBJECT IDENTIFIER,
*       authPolicies               SEQUENCE OF AuthPolicy,
*       responseTypes              ResponseTypes,
*       defaultValPol              ValPolicy,
*       clockSkew                  INTEGER OPTIONAL,
*       authDataCert               Certificate OPTIONAL }
* 
* 
* DefaultPolicyID and defaultValPol do not need to be present, 

[TF] The PolicyID is the server policy so needs to be present.

* default
* policy may simply be the first policy of the SEQUENCE of validation
* policies
* that is returned.
* 
* nextUpdate should be OPTIONAL since a server may choose to always send
a
* fresh
* response.
[TF] simply omitting the nextUpdate by itself is ambiguous sine the
client cannot tell if the policy is in response to the request or has
infinite lifetime. If the client submits a nonce then the server can
either return a fresh policy or the cached version. If the client omits
the nonce then the server MUST return the cached version with the
nextUpdate.

* 
* trustAnchors is a parameter of one specify validation policy and thus
* should not
* be present at that level.

[TF] Clients are not mandated to use validation policy so this is
appropriate at this level

* 
* validationPolices should be used to define a sequence of validation
policy
* references and/or a sequence of validation policy definitions. See
below.
* 
* validationAlgs may be inner component of validation policy definition.

[TF] Again validation policies are not mandatory in deployments.

* 
* authPolicies is unclear, since all responses MUST be signed. 

[TF] This is for auth to the server.

Deleted for
* simplification.
* 
* defaultValPol is not needed, if the default policy is simply the first
* policy of
* the SEQUENCE of validation policies that is returned.
* 
* The name of authDataCert should be changed into serverCert.

[TF] The authDataCert is the certificate used for the authenticated data
requests/responses. The name differentiates it form the signing cert
returned in the CMS envelope.

* 
* The structure should thus be changed to:
* 
*     PoliciesResponse ::= SEQUENCE {
*       scvpVersion                INTEGER,
*       responseNonce              OCTET STRING OPTIONAL,
*       thisUpdate                 GeneralizedTime,
*       nextUpdate                 GeneralizedTime OPTIONAL,
*       validationPolicies         SEQUENCE OF ValidationPol,
*       -- the default validation policy is the first of the sequence
*       responseTypes              ResponseTypes,
*       clockSkew                  INTEGER OPTIONAL,
*       serverCert                 Certificate OPTIONAL }

[TF] The revised SCVP server policy response is now

* 
* 
* Denis
* 
*