Subject: Comments to SCVP ID 17

From: "Wen-Cheng Wang" <[email-masked]>
Date: Fri, 18 Feb 2005 00:37:41 +0800

Dear list,

The following are my comments to SCVP 17.

Wen-Cheng Wang

1. Typo in the last sentence of the last second
   paragraph of page 67:

     "Therefore in these situations use of a URI
      many be more attractive."
   ->
     "Therefore, in these situations use of a URI
      may be more attractive."

   ("many be" -> "may be")

2. I suggest to let the version filed of request and
   response messages default to v1(1).
   That is:

      cvRequestVersion        INTEGER,
   ->
      cvRequestVersion        INTEGER DEFAULT v1(1),

      cvRsponseVersion        INTEGER
   ->
      cvRsponseVersion        INTEGER DEFAULT v1(1),

      vpRequestVersion        INTEGER,
   ->
      vpRequestVersion        INTEGER DEFAULT v1(1),

      vpRsponseVersion        INTEGER
   ->
      vpRsponseVersion        INTEGER DEFAULT v1(1),

   By doing this, the DER code of every request and
   response message will save 3 bytes. I believe that
   the SCVP version will stay at v1 for a long time,
   asigning default value will allow clients and
   servers do not bother to send the version number
   in their requests and responses.

   Note that when a field become a field with DEFAULT
   value, it might need change to a tagged field.

3. The tagging rule for ASN.1 syntax is odd. I list
   the following as oddness:

      (1) In the "ValidationPolicy" data type, the tag
          numbers skip from [4] to [6]. (There is no
          tag [5].)
      (2) In the "CVResponse" data type, the tag numbers
          skip from [3] to [5]. (There is no tag [4].)

   I know that the editors of SCVP ID do not like to
   discuss ASN.1 stylistic change, but the fix is simple.

4. I notice that SCVP 17 newly invented the term
   "end certificate". Personally, I understand what
   you mean by "end certificate" because I have been
   tracking this ID for a long time. However, I am
   worrying that using the term "end certificate"
   might cause confusion because it might have
   different interpretation for different direction
   of path construction (forward or reverse). As a
   technical spec, SCVP should be more precise in
   adopting technical term. Therefore, I suggest to
   use the term "target certificate" instead, not only
   for eliminating possible confucion but also for
   keeping alignment with RFC 3379.

   In addition, to make a more strong connection between
   the term "target certificate" and the field of the
   query message, I further suggest to change the field
   name "queriedCerts" in the "Query" data type into
   "targetCerts". Of course, related statements that
   explain or refer to that field shoul also be modified
   in response to the changing of the filed name.

5. After reading SCVP 17, I finally understand the
   purpose of name validation algorithm. Before SCVP 17,
   I always thought it is used to specify the name
   matching rule (binary matching or X.500 name matching)
   during certificate chaining. Now I understand that it
   is use to specify the request for checking subject
   name of the "target certificate". If it is so, I think
   it is unreasonalbe to say:

     "The name validation is a refinement of the basic
      validation algorithm"

   The basic validation algorithm is an algorithm
   specifying conditions and rules for validating
   the whole certification path. In terms of RFC 3379,
   the basic validation algorithm specifies
   "certification path requirements". On th contrary,
   the name validation algorithm only specifies the
   request for checking subject name of the "target
   certificate". In terms of RFC 3379, the so-called
   name validation algorithm is simply one of the
   "end-entity certificate specific requirements".
   (Now I prefer to call them "target certificate
    specific requirements".)
   It is much like "keyUsages" and "extendedKeyUsages"
   checks, which are also "target certificate
   specific requirements". To make the protocol
   more resonable and aligned with RFC 3379, I
   suggest to take "name validation algorithm" out
   of section 3.2.4.2 and group it with "keyUsages"
   and "extendedKeyUsages", because they all belong
   to the category of "target certificate specific
   requirements".

6. The current text of SCVP 17 tries to define a
   "global" default validation policy and tries to
   enforce all implementation to support that default
   validation policy. This notion of "default validation
   policy" does not align with the general understanding
   of "default validation policy".
   
   The default validation policy defined in SCVP 17 is
   actually simply a "basic" validation policy which
   adopts the basic path validation algorithm defined
   in RFC 3280, it is odd to specify it as the "global"
   default validation policy. The general understanding
   of "default validation policy" is the default one
   among the organizational validation policies.
    
   I suggest to change term "default validation policy"
   to "basic validation policy" to avoid confussion.
   With this distinction of the notion of "default
   validation policy" and the notion of the predefined
   "basic validation policy, we can clearly say that

     The SCVP server can define multiple vlidation
     policies and nominate one as its default
     policy. If the client does not select a
     validation policy in its request, the server
     will use the default validation policy.

     The SCVP server MAY list the "basic validation
     policy" defined in this specification as one
     of its supported validation policies. The SCVP
     server MAY select the "basic validation
     policy" as its default policy.

   Please note that I also suggest that the
   "validationPolicy" field in the "Query" data type
   should be changed to be an optional field. This
   allow the client to ommit the selection of
   the validation policy in its request and simply
   let the server use its default policy.

7. The title of section 1.3 is "validation Policies", but
   in the middle of that section it mentions:

     "The inputs to the basic certification path processing
      algorithm used by SCVP are defined by [PKIX-1] in
      section 6.1.1 and comprise: 
     
        Certificate to be validated (by value or by reference); 
     
        Validation time; 
     
        Set of Trust Anchors (by value or by reference); 
     
        The initial policy set; 
     
        Initial inhibit policy mapping setting; 
     
        Initial inhibit anyPolicy setting; and 
     
        Initial require explicit policy setting."

   Isn't it be odd to define inputs to "validation
   algorithm" in a section titled "validation
   policies"?

   It reveals that even the authors of SCVP have no
   good distinction between the notion of "validation
   policy" and the notion of "validation algorithm",
   no to say an implementator who try to implement SCVP.

   Even several reviewers (for example Denis and I)
   clearly express that the notion of "validation algorithm"
   is redundant to the notion of "validation policy"
   and can be removed, how strange it is that the
   authors always to reject the suggestions.

   Now, even with SCVP 17 which authors says "the text
   for validation policies, validation algoriothms and
   name validation algorithms has all been revised for
   clarity, the distinction still vague.

   I sugest to remove the notion of "validation
   algorithm" from SCVP, and change the text to:

     "The certification path specific parameters to the
      basic validation policy defined by this specification
      are defined by [PKIX-1] in its section 6.1.1 and
      comprise: 
     
        Certificate to be validated (by value or by reference); 
     
        Validation time; 
     
        Set of Trust Anchors (by value or by reference); 
     
        The initial policy set; 
     
        Initial inhibit policy mapping setting; 
     
        Initial inhibit anyPolicy setting; and 
     
        Initial require explicit policy setting."

8. In th end of section 1.3, it says:

   "The basic certification path processing algorithm
    also supports the following parameters, which are
    defined in [PKIX-1] section 4: 
    
     The usage of the key contained in the certificate
     (e.g., key encipherment, key agreement, signature); and 
      
     Other application-specific purposes for which the
     certified public key may be used."

   Since "the basic certification path processing algorithm"
   is the algorithm defined in section 6 of RFC 3280, it is
   not proper to say that "the certification path processing
   algorithm" supports parameters related to checking
   key usages and extended key usage. Wee all know that
   the lgorithm defined in section 6 of RFC 3280 does not
   support these two kinds of parameters.

   I think the text will be more proper if it is changed to:

   "The basic validation policy defined by this specification
    also supports target certificate specific parameters
    for specifying the following checks: 
    
     The key usages specified in the target certificate
     (e.g., key encipherment, key agreement, signature)
     are acceptable; 
      
     The extended key usages specified in the target
     certificate are acceptable; and

     The subject name or the subject alternative name
     specified in the certificate meet the
     application-specific requirement."

   (Note that I move the name validation requirement here.)

   Again, this is a sign that the distinction between
   the notion of "validation policy" and the notion of
   "validation algorithm" in SCVP 17 is still vague.

9. I give the following comment before but get no response,
   so here I raise it again.

   There are situations where the certificate-using
   applications need to check whether a certificate
   was valid during a period of time, not only validate
   it with respect to a specific moment. For example,
   an application verifying an archived long-term
   signature might need to check whether a certificate
   was valid during a period of time in which the
   signature was generated. Therefore, I suggest to
   extend the structure of the "validationTime" field
   of the "Query" data type to support this. A CHOICE
   between a moment and a period of time is sufficient.

To summarize the above comments, the "Query" needs to
be changed to the following:

(Of course, the related text in the ID should also be
changed. However, at this moment, I simply use the
following syntax to demonstrate my idea to editors
and the list. If my proposal is accepted, then I
will be happy to help revising the related text.)

Query ::= SEQUENCE { 
     targetCerts              CertReferences,
     checks                   CertChecks, 
     wantBack                 WantBack, 
     validationPolicy     [2] ValidationPolicy OPTIONAL, 
     responseFlags        [3] ResponseFlags OPTIONAL, 
     serverContextInfo    [4] OCTET STRING OPTIONAL, 
     validationTime           ValidationTime OPTIONAL, 
     intermediateCerts    [7] CertBundle OPTIONAL, 
     revInfos             [8] RevocationInfos OPTIONAL, 
     producedAt           [9] GeneralizedTime OPTIONAL, 
     queryExtensions      [10] Extensions OPTIONAL }

ValidationTime ::= CHOICE {
     moment               [5] GeneralizedTime,
     period               [6] ValidationPeriod}

ValidationPeriod ::= SEQUENCE {
     start                GeneralizedTime,
     end                  GeneralizedTime}

ValidationPolicy ::= SEQUENCE { 
     validationPolRef               ValidationPolRef,
     pathSpecificParams         [1] PathSpecificParams OPTIONAL,
     targetCertSpecificParams   [2] TargetCertSpecificParams OPTIONAL}

PathSpecificParams ::= SEQUENCE {
     userPolicySet          [1] SEQUENCE SIZE (1..MAX) OF OBJECT 
                                  IDENTIFIER OPTIONAL, 
     inhibitPolicyMapping   [2] BOOLEAN OPTIONAL, 
     requireExplicitPolicy  [3] BOOLEAN OPTIONAL, 
     inhibitAnyPolicy       [4] BOOLEAN OPTIONAL, 
     trustAnchors           [6] TrustAnchors OPTIONAL}

targetCertSpecificParams ::= SEQUENCE {
     keyUsages              [1] KeyUsages OPTIONAL, 
     extendedKeyUsages      [2] SEQUENCE OF KeyPurposeId OPTIONAL,
     nameValidation         [3] NameValidationAlgParms OPTIONAL}

NameValidationAlgParams ::= SEQUENCE { 
     nameCompAlgId          OBJECT IDENTIFIER, 
     validationNames        GeneralNames }

-- SCVP Validation Policy and Algorithm Identifiers 
    
id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 
          dod(6) internet(1) security(5) mechanisms(5) pkix(7) 19 } 

-- SCVP Basic Validation Policy Identifier
    
id-svp-basicValPolicy OBJECT IDENTIFIER ::= { id-svp 1 } 
 
-- SCVP Basic Validation Policy Errors 
    
id-bvpe OBJECT IDENTIFIER ::= id-svp-basicValPolicy
    
id-bvpe-expired              OBJECT IDENTIFIER ::= { id-bvae 1 } 
id-bvpe-not-yet-valid        OBJECT IDENTIFIER ::= { id-bvae 2 } 
id-bvpe-wrong-anchor         OBJECT IDENTIFIER ::= { id-bvae 3 } 
id-bvpe-invalid-key-usage    OBJECT IDENTIFIER ::= { id-bvae 10 } 
id-bvpe-invalid-purpose      OBJECT IDENTIFIER ::= { id-bvae 11 } 
id-bvpe-revoked              OBJECT IDENTIFIER ::= { id-bvae 16 } 
    
-- SCVP Name Validation Algorithm Identifier

-- SCVP Name Validation Algorithm DN comparison algorithm 
    
id-nva-dnCompAlg   OBJECT IDENTIFIER ::= { id-svp 4 } 
    
-- SCVP Name Validation Algorithm Errors 
    
id-nvae OBJECT IDENTIFIER ::= id-svp-nameValAlg 
    
id-nvae-name-mismatch          OBJECT IDENTIFIER ::= { id-nvae 1 } 
id-nvae-no-name                OBJECT IDENTIFIER ::= { id-nvae 2 } 
id-nvae-unknown-alg            OBJECT IDENTIFIER ::= { id-nvae 3 } 
id-nvae-bad-name               OBJECT IDENTIFIER ::= { id-nvae 4 } 
id-nvae-bad-name-type          OBJECT IDENTIFIER ::= { id-nvae 5 } 
id-nvae-mixed-names            OBJECT IDENTIFIER ::= { id-nvae 6 }

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 18 Feb 2005 17:08:48 -0500

>      "Therefore, in these situations use of a URI

Done.

>    value, it might need change to a tagged field.

We set a DEFAULT value wherever we could do so without adding any more 
explicit tagging.  So, DEFAULT version numbers were set in CVRequest and 
ValPolRequest, but not CVResponse or ValPolResponse.

>    discuss ASN.1 stylistic change, but the fix is simple.

Fixed.

>    in response to the changing of the filed name.

The term "end certificate" is used in X.509 to refer to the final 
certificate in a certification path (which is usually, but not always, 
an end entity certificate).  However, it appears that the term was never 
used in RFC 3280.  On the other hand, I could only find one use of the 
term "target certificate" in RFC 3379, and it is never defined.  So it 
is not clear that "target" would be any better than "end".  But, I added 
a definition of "end certificate" after its first use.

>    to the category of "target certificate specific

I believe that there is still a misunderstanding.  The name validation 
algorithm does not *only* specify checking the subject name in the end 
(or target) certificate.  When the name validation algorithm is 
specified, the server MUST perform all of the checks required by the 
Basic Validation Algorithm *in addition to* checking the subject name in 
the end (target) certificate.  That is why the name validation algorithm 
is referred to as a refinement of the basic validation algorithm.  As is 
stated in section 3.2.4.2.1 (Basic Validation Algorithm): "That is, none 
of the validation requirements in the basic algorithm may be omitted 
from any newly defined validation algorithms."

While name validation could have been implemented in a similar manner to 
the verification of keyUsage and extendedKeyUsage, specifying name 
validation as a different validation algorithm works just as well.  
Changing the ASN.1 to group name checking with keyUsages and 
extendedKeyUsages would simply be a styistic change that would have no 
real effect on the protocol.  While Tim and I made changes to the ASN.1 
to clean up the tagging since so many people insisted that they wanted 
the change, we really need to get this document finished, and so I think 
we should try to avoid making changes to the protocol that are unnecessary.

>    let the server use its default policy.

The "default validation policy" really is the default validation policy 
for the organiztion; it is not a "global" validation policy.

Section 3.2.4.1.1 states that the default validation policy MUST use the 
basic validation algorithm as its default validation algorithm, but each 
individual SCVP server is free to set the default values for all other 
parameters (e.g., trust anchors) of the validation policy as it wishes.  
The server specifies the default parameter values that it uses in its 
default validation policy in its validation policy response (in the 
defaultPolicyValues item).

So, if a client wants to use the organizational default validation 
policy, it simply specifies the OID for the default validation policy.  
Rather than make the validationPolicy field OPTIONAL, the editors chose 
to define an OID for the default validation policy.  The effect is the 
same, it is just a slightly different encoding.  This was done before I 
became involved with SCVP, but it may have been done in order to make it 
possible for the server to reject requests that specify the default 
policy OID (the server can simply not list that OID in the 
validationPolices item of its validation policy response.

>         Initial require explicit policy setting."

I still believe that it is useful to have both a validation policy and a 
validation algorithm.  You suggest that it is odd for the validation 
policy to specify the inputs to the validation algorithm, but I 
disagree.  The basic validation algorithm, for example, is simply an 
algorithm.  It specifies the rules for creating a set of outputs from a 
set of inputs.  The validation algorithm does not, however, specify the 
*values* for the inputs.  The validation policy specifies not only what 
algorithm should be used to determine whether the certificate is valid, 
but also the *values* for the inputs to the algorithm (e.g., trust 
anchors, user initial policy set, etc.).

If the validation algorithm were removed as a parameter then it would 
not be possible to specify the use of an algorithm other than the basic 
validation algorithm for determining whether a certificate were valid 
given the other inputs specified by the policy.

At the moment, there are only two validation algorithms defined for use 
with SCVP and as you stated, subject name checking could have been 
implemented with defining a new validation algorithm.  However, 
including the validation algorithm as a parameter of the validation 
policy allows for other validation algorithms to be specified in the 
future.  For example, someone could define a validation algorithm that 
verifies whether a certificate is a valid proxy certificate according to 
RFC 3820.  This proxy certificate algorithm could either be used as the 
default validation algorithm for a validation policy or it use could be 
specified by the client in the request.  So, a client could, for 
example, specify the use of the default validation policy, but with the 
proxy certificate validation algorithm.  The result would be that the 
organizational default values would be used for the inputs (trusts 
anchors, user intial policy set, etc.), but the certificate(s) would be 
validated as a proxy certificate (RFC 3820) rather than being validated 
using the normal validation algorithm (RFC 3280).

>    "validation algorithm" in SCVP 17 is still vague.

As noted above, it would not be correct to say that "the basic 
validation policy ... also supports...."  An algorithm supports certain 
parameters, since the algorithm specifies how the outputs are derived 
from the inputs.   So, the algorithm supports the parameters and the 
policy specifies values for the parameters.

Hopefully the discussion above along with the example of a possible 
alternative validation algorithm helps to explain the distinction 
between the validation algorithm and validaiton policy.

>    between a moment and a period of time is sufficient.

I have not been involved with SCVP for very long, but I have not heard 
this one before and it is not clear why it is needed.  If you specify a 
validationTime equal to "end" (as defined in your ASN.1 below) and the 
response is that the certificate is not valid, then it was not valid.  
If the certificate was valid at time "end", then there must be a valid 
certification path in which all of the certificates were valid at time 
"end".  If the certificates were valid at time "end", then they could 
not have been revoked before time "end".  So, the only way the 
certification path could have been invalid at any point between "start" 
and "end" is if "start" preceded the notBefore time in any of the 
certificates in the certification path.  If this is a concern, you could 
send a second query with a validationTime of "start".  If the server 
reports that the certificate is valid at both "start" and "end", then it 
seems that one can safely conclude that the certificate was valid during 
the entire interval.

Under what circumstances would you expect the server to indicate that 
the certificate was valid at "start" and "end", but invalid for the 
period "[start ... end]"?  If there were any such circumstances, why 
would the client need to know this?

Even if the feature is needed, is there any reason that it could not be 
added through the extensions mechanism after the base standard has been 
completed?

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 22 Feb 2005 17:02:32 -0700

Colleagues,

Please consider the following contribution from Hannes Tschoefenig and myself.

http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-ocsp-02.txt

We propose two IKEv2 CERT payload extensions which taken together enable in-band use of OCSP in IKEv2.  This -02 draft incorporates comments to date.

Mike

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 22 Feb 2005 17:35:12 -0700

All,

Apologies for the typo.  The correct URL is

http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-oscp-02.txt

The document title should refer to OCSP, not OSCP.
                                    ^^        ^^
This will be corrected.

Mike

-----Original Message-----
From: Michael Myers [mailto:[email-masked]]
Sent: Tuesday, February 22, 2005 5:03 PM
To: [email-masked]; [email-masked]
Subject: OCSP in IKEv2, draft -02

Colleagues,

Mike

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Thu, 24 Feb 2005 09:40:10 +0800

Dear List,

I am sorry if you received this mail more than once. The
PKIX ML server seemed to have problem to accept my
email. This is my fifth trial to send this email to PKIX ML.
 
Please see my comments in-line.
  
David A. Cooper wrote:
>Sent: Saturday, February 19, 2005 6:08 AM
>Subject: Re: Comments to SCVP ID 17
>
>
>Wen-Cheng Wang wrote: 
>We set a DEFAULT value wherever we could do so without adding any
>more explicit tagging.  So, DEFAULT version numbers were set in
>CVRequest and ValPolRequest, but not CVResponse or ValPolResponse.

I can live with that, although I prefer to all the version numbers
omittable in both requests and responses.

>The term "end certificate" is used in X.509 to refer to the
>final certificate in a certification path (which is usually, but
>not always, an end entity certificate).  However, it appears that
>the term was never used in RFC 3280.  On the other hand, I could only
>find one use of the term "target certificate" in RFC 3379, and it is
>never defined.  So it is not clear that "target" would be any better
>than "end".  But, I added a definition of "end certificate" after
>its first use.

Again, I can live with that, although I prefer the term "target certificate".
Please also not that the "Certification Path Building" ID also use the term
"target certificate".

>I believe that there is still a misunderstanding.  The
>name validation algorithm does not *only* specify checking
>the subject name in the end (or target) certificate.  When
>the name validation algorithm is specified, the server MUST
>perform all of the checks required by the Basic Validation
>Algorithm *in addition to* checking the subject name in the
>end (target) certificate.  That is why the name validation
>algorithm is referred to as a refinement of the basic
>validation algorithm.  As is stated in section 3.2.4.2.1
>(Basic Validation Algorithm): "That is, none of the validation
>requirements in the basic algorithm may be omitted from any
>newly defined validation algorithms."

Believe me, I understand the refinement relationship. I simply feel that
it is odd to say a "name validation algorithm" is a refinement of a path
validation algorithm. I believe that most people will not associate
path validation with the term "name validation". Maybe you should name
it "the basic validation algorithm with name checking".

>While name validation could have been implemented in a similar
>manner to the verification of keyUsage and extendedKeyUsage,
>specifying name validation as a different validation algorithm
>works just as well.  Changing the ASN.1 to group name checking
>with keyUsages and extendedKeyUsages would simply be a styistic
>change that would have no real effect on the protocol.  While Tim
>and I made changes to the ASN.1 to clean up the tagging since so
>many people insisted that they wanted the change, we really need
>to get this document finished, and so I think we should try to avoid
>making changes to the protocol that are unnecessary.

I still believe that it is better to group "name checking", "key usage checking"
and "extended key usage checking" into the category of "end/target certificate
requirements". This is not a simply a stylistic change. It is a matter of logicalness
of the protocol design. However, if we are really running out of time, I can live
with "the basic validation algorithm with name validation".

>The "default validation policy" really is the default validation
>policy for the organiztion; it is not a "global" validation policy.
>
>Section 3.2.4.1.1 states that the default validation policy MUST
>use the basic validation algorithm as its default validation
>algorithm, but each individual SCVP server is free to set the
>default values for all other parameters (e.g., trust anchors) of
>the validation policy as it wishes.  The server specifies the default
>parameter values that it uses in its default validation policy in its
>validation policy response (in the defaultPolicyValues item).
>Basically, I agree that the validation algorithm adopt by the server MUST be based
>on the basic path validation algorithm defined by RFC 3280 or its descendant, but
>it is not necessary to force every organization to accept that "basic path validation
>algorithm" as the alogorithm of their organizational default validation policy. What
>if the organization want to adopt an extended/refined version of  path validation
>algorithm in their organizational default validation policy? To allow organizations
>to define their own organizational default validation policy, I still think it is better to
>name the validation policy defined by the SCVP spec as "basic validation policy".
>It is analogy to that RFC 3280 named its path validation algorithm as "basic path
>validation algorithm" (not "default validation algorithm").
 
The point is that SCVP should give freedom to organizations to define their own
organizational default validation policy. Nevertheless, SCVP could ask organization
to adopt PKIX-compliant validation algorithm no mater if they define their own
organizational default validation policy.
 
I understand that it is good if SCVP defines a validat policy and its OID for the
convenience of organization unwilling/unable to define their own validat policy/OID.
However, it should not be "the default validation policy". It should simply be "a basic
validation policy".

>So, if a client wants to use the organizational default validation policy, it
>simply specifies the OID for the default validation policy.  Rather than
>make the validationPolicy field OPTIONAL, the editors chose to define an
>OID for the default validation policy.  The effect is the same, it is just a
>slightly different encoding.  This was done before I became involved with SCVP,
>but it may have been done in order to make it possible for the server to reject
>requests that specify the default policy OID (the server can simply not list that
>OID in the validationPolices item of its validation policy response.

I know that this is the way SCVP letting organizations overwrite the globally
defined "default validation policy". However, in the situation where an organization
only supports one validation policy and naturally uses that validation policy as its
default organizational validation policy, isn't it superfluous to request all its clients
to specify the organizational validation policy OID? In such situation, clients usually
want to omit the validation polict item in their request and let the server use its
default policy. With current syntax, it is impossible to do that.

>I still believe that it is useful to have both a validation
>policy and a validation algorithm.  You suggest that it is
>odd for the validation policy to specify the inputs to the
>validation algorithm, but I disagree.  The basic validation
>algorithm, for example, is simply an algorithm.  It specifies
>the rules for creating a set of outputs from a set of inputs.
>The validation algorithm does not, however, specify the *values*
>for the inputs.  The validation policy specifies not only what
>algorithm should be used to determine whether the certificate
>is valid, but also the *values* for the inputs to the algorithm
>(e.g., trust anchors, user initial policy set, etc.).
>
>If the validation algorithm were removed as a parameter then
>it would not be possible to specify the use of an algorithm
>other than the basic validation algorithm for determining
>whether a certificate were valid given the other inputs
>specified by the policy.
>
>At the moment, there are only two validation algorithms defined
>for use with SCVP and as you stated, subject name checking could
>have been implemented with defining a new validation algorithm.
>However, including the validation algorithm as a parameter of the
>validation policy allows for other validation algorithms to be
>specified in the future.  For example, someone could define a
>validation algorithm that verifies whether a certificate is a
>valid proxy certificate according to RFC 3820.  This proxy
>certificate algorithm could either be used as the default validation
>algorithm for a validation policy or it use could be specified by
>the client in the request.  So, a client could, for example, specify
>the use of the default validation policy, but with the proxy
>certificate validation algorithm.  The result would be that the
>anchors, user intial policy set, etc.), but the certificate(s)
>would be validated as a proxy certificate (RFC 3820) rather than
>being validated using the normal validation algorithm (RFC 3280).

The question is what is the relationship between "validation policy" and
"validation algorithm"? Will it be normally one-to-one relationship or
one-to-many relationship? By one-to-one relationship, I mean one validation
policy can only support one validation algorithm. By one-to-many relationship,
I mean one validation policy can support multiple validation algorithms.
In one-to-many relationship, a client might need to select one of the multiple
validation algorithms supported by the validation policy it specifies in the request.
In one-to-one relationship, since the validation policy implies the validation
algorithm, it is superfluous to ask the client to specify both of them.
 
I believe that it is easier to adopt one-to-one relationship model, let one
validation policy imply a validation algorithm, and remove the validation
algorithm item from the syntax. With one-to-one relationship model, if
an organization want to support multiple validation algorithm, they can
define multiple validation policies and let each imply one validation algorithm
respectively.
 
The point is a validation policy can imply a validation algorithm, and therefore
the notion of validation algorithm can be removed from SCVP.
 
>As noted above, it would not be correct to say that "the
>basic validation policy ... also supports...."  An algorithm
>supports certain parameters, since the algorithm specifies
>how the outputs are derived from the inputs.   So, the algorithm
>supports the parameters and the policy specifies values for the
>parameters.
>
>Hopefully the discussion above along with the example of a
>possible alternative validation algorithm helps to explain
>the distinction between the validation algorithm and validaiton policy.

As commented above.

>I have not been involved with SCVP for very long, but I have
>not heard this one before and it is not clear why it is needed.  If
>you specify a validationTime equal to "end" (as defined in your ASN.1
>below) and the response is that the certificate is not valid, then it
>was not valid.  If the certificate was valid at time "end", then there
>must be a valid certification path in which all of the certificates were
>valid at time "end".  If the certificates were valid at time "end", then
>they could not have been revoked before time "end".  So, the only way the

The current SCVP syntax and semantics only support validating certificates against
a retrospective moment. Please not that it is not the same to say "a certificate is
valid at time t1" as to say "a certificate is valid before time t1", because the validity of
the certificate could be suspended and then resumed before time t1. It is certainly
different with "a certificate is valid from time t2 to time t1".

>Under what circumstances would you expect the server to indicate that the
>certificate was valid at "start" and "end", but invalid for the period
>"[start ... end]"?  If there were any such circumstances, why would the
>client need to know this?
In some situations, it is not possible to determine the time (the moment) when
the private key was used to sign a signature. For example, to verify an archived
long-term signature, it might not be possible to determine the retrospective time
when the sigature is signed. Fortunately, the archived long-term signature might
be associated with content time-stamp and signature time-stamp for helping
in validating its validity. Suppose its content time-stamp was generated at time t2 and
its signature time-stamp was generated at time t1, then the verifier can conclude that
the signature must be signed between time t2 and time t1. To validate the archived
long-term signature, the verifier must make sure that the signer's certificate is valid
from time t2 to time t1.
 
You might be interested to read the paper at http://www.timestamp.cyber.ee/principles_en.pdf
to get the idea why the signer's certificate needed to be valid during the time period in which
the archived long-term signature was signed.

>Even if the feature is needed, is there any reason that it could
>not be added through the extensions mechanism after the base
>standard has been completed?
 
Yes, the feature certainly could be added through the extensions mechanism.
I simply think it is important for SCVP to support validating certificates
against a time period (not just a a retrospective moment), therefore I
suggest to add it now.
 
Wen-Cheng Wang

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 24 Feb 2005 15:44:04 +0100

To the co-editors,

1. I basically agree with the comments from Wen-Cheng sent to the list on
February 18 : the authors have still not correctly understand the
difference between “validation policy” and “validation algorithm”.

Sections 1.3 and 1.4 which are the foundations of the document are still
wrong. It is very painful, time consuming and time wasting to repeat
again and again the same comments which are not considered by the
editors.

The authors, who are more and more numerous (since Tim Polk and David
Cooper have now joined round 17) have not read in detail RFC 3280 and are
making confusion between terms and are inventing new wordings which add
to the confusion (see more details below).

2. The first new wording introduced is: “PKI policies” which is a term
which is defined nowhere in RFC 3280 nor in this document. When it is
used, it means “validation policy”. Please delete everywhere “PKI policy”
and replace it with “validation policy”.

The author have not read in details RFC 3280 section 6.1.

On page 7 they introduce a new term “basic certification path processing
algorithm” whereas RFC 3280 uses:
  - “certification path validation” (that is the title of section 6) and
  - “basic path validation” (that is the title of section 6.1).

The major mistake is to refer to section 6.1.1 and then say that the
inputs in section 6.1.1 have a “Set of Trust Anchors”. This is wrong.
Section 6.1.1 deals with a *single* trust anchor, whereas section 6.2
from RFC 3280 deals with multiple trust anchors.

This demonstrates that section 1.3 is wrong.

3. Section 1.4 is about a “validation algorithm”. Does this notion, as
explained, makes sense ? Is this notion supported in RFC 3379 ? The
answer is no.

 From the introduction, “a validation policy contains one or more trust
anchors »

 From section 1.3, “a validation policy specifies the rules and parameters
to be used by the SCVP server when validating a certificate”.

Different rules may apply to every trust anchor and to the CA
certificates from a certification path under every trust anchor. The
ASN.1 description of ValidationPolicy starting on page 17 does not allow
to define different rules for different trust anchors. This comes from
the previous mistakes.

We currently have:

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,
        trustAnchors          [6] TrustAnchors OPTIONAL,
        keyUsages             [7] KeyUsages OPTIONAL,
        extendedKeyUsages     [8] SEQUENCE OF KeyPurposeId OPTIONAL}

and

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

If:
        trustAnchors          [6] TrustAnchors OPTIONAL,

is changed into:

        trustAnchor          [6] TrustAnchor OPTIONAL,

then only the algorithm from section 6.1 of RFC 3280 can be used, and it
would be a pity to make three calls if a validation policy included three
trust anchors.

PLEASE co-editors, read carefully, and think about it before answering
too quickly.

The conditions that apply to CA certificates may be very complicated and
vary from one trust anchor to another. The goal if this document is NOT
to be able to specific *remotely* every single parameter of section 6.1
from RFC 3280.

The goal if this document is to support as a whole section 6.2 from RFC
3280. Once again, from the introduction, “a validation policy contains
one or more trust anchors ».

The validation policy could OPTIONALLY include several “target
certificate specific parameters” as Wen-Cheng proposed, since these
parameters do not change from one trust anchor to another. I fully agree
with Wen-Cheng that “target certificate” is more appropriate than “end
certificate”.

This would also solve the confusion that Wen-Cheng noticed about the
“name validation algorithm” which would become one of the “target
certificate specific parameters”. Checking the target certificate DN is
far more important than checking the CA DNs. If both checks are really
needed, those checks may be different.

It is obvious that for each certification path the algorithm from section
6.1 of RFC 3280 is being used.

A validationAlg parameter is not needed. We could then simply have:

ValidationPolicy ::= SEQUENCE {
        validationPolRef          ValidationPolRef,
        keyUsages                [0] KeyUsages OPTIONAL,
        extendedKeyUsages        [1] SEQUENCE OF KeyPurposeId OPTIONAL,
        nameValidationAlgParms   [2] NameValidationAlgParms OPTIONAL,
        otherTests               [3] OtherTests OPTIONAL
}

    otherTests could be used for example to test QCStatements extensions.

4. As Wen-Cheng noted, the “default validation policy” does not make
sense.

5.Section 1.5 states: “However, revocation checking is an optional
feature in [PKIX-1], and revocation information is distributed in
multiple formats.” This is incorrect.

RFC 3280 does not say that revocation checking is optional. Only CRLs
processing is defined in RFC 3280 but we all know that OCSP is an
alternative method. Revocation checking MUST be done to validate a
certificate, but may be done using different means. These means may be
specified in the validation policy.

On page 49 from we have:

    Conforming CAs are not required to issue CRLs if other revocation or
    certificate status mechanisms are provided.

When the client sends a DPV request, revocation checking MUST be done.
When the client send a DPD request, revocation status information MAY be
returned or not.

This illustrates once again the problem when a single document is mixing
the protocols for DPV and DPD.

6. It should be remembered that RFC 3379 makes the separation between DPV
and DPD, while this document mixes them. It is therefor very doubtful to
say that this document fills in the goals of RFC 3379.

7. “SCVP” is a very bad name when the request is to build only a
certification path, with or without revocation status (i.e. DPD, leaving
the validation to the client). The certificate is not VALIDATED by the
server, and even if it would, the client would not trust it. It is
apparent that some people would like to keep the “trade name” SCVP, but
this will add confusion; but maybe this is what is deliberately wanted ?

8. The text correctly states on page 6: “An SCVP request needs only to
contain the certificate to be validated, the referenced validation
policy, and any run-time parameters for the request”.

It would be very beneficial to be able to have implementations that only
support the above requirements for DPV, leaving the security of the
communication link (i.e. using TLS) . The problem is that is not
straightforward to derive a profile from this huge “monument” which is
overcomplicated because it mixes DPV and DPD requirements.

It is strong suggested to revise the document so that this goal can be
achieved and that conformance clauses can be added to be able to say that
a given implementation is conformant to the *simple* certificate
validation request mentioned above.

Unless the editors can provide a profile or/and indications on how this
goal would be achieved, it is very doubtful that the full protocol will
be widely implemented and used by applications.

If this is not done, it would then make sense to develop “HSCVP” : Hyper
Simple Certificate Validation Protocol” or rename the current drat as
CCVP, as it has always be !

Hyper Simple Certificate Validation Protocol is a protocol which contains
the certificate to be validated (i.e. just one), the referenced
validation policy (no other parameter), any useful certificates and
revocation information (as provided by the client), and where the server
tells whether the certificate is valid or not against that referenced
policy (it may also return a “I don’t know” response).

In section 1.5, the text states: “The typical use of SCVP is expected to
be over HTTP [HTTP] ». I would rather say: “HSCVP is expected to be over
HTTPS [HTTPS]”

9. Given the time that it took me to comments on only 8 pages of the
documents (about 7 hours), you can imagine how long it will take me to
comment on the full document. I believe the topic is extremely important,
but the editors are wasting my time.

Being the lead editor of RFC 3379, I believe that I have a little
knowledge on that topic. More consideration should be paid to my comments
and to the comments from Wen-Cheng. As he correctly said: “how strange it
is that the authors always reject the suggestions”.

10. Additional minor comments (up to page 8).

Page 5. Section 1. Second paragraph. The text states:

    The first class of applications wants just two things: confirmation
    that the public key belongs to the identity named in the certificate
    and confirmation that the public key can be used for the intended
    purpose.

This is not the main goal. Rephrase as:

    The first class of applications wants just confirmation
    that the certificate is valid according a given validation policy.

11. Additional minor comment.
Page 5. Section 1. Second paragraph. The text states:

    The second class of applications can perform certification path
    validation, but they lack a reliable or efficient method of
    constructing a valid certification path.

Rephrase as:

    The second class of applications can perform certification path
    validation, but lack a reliable or efficient method of
    constructing a valid certification path and the associated
    revocation status information.

12. Additional minor comment.
Page 5. Section 1.1. Second paragraph.

    The primary goals of SCVP are to make it easier to deploy PKI-enabled
    applications and to allow central administration of PKI policies
    within an organization.

Rephrase as:

    The primary goals of SCVP are to make it easier to deploy PKI-enabled
    applications and to allow a server to support one or more validation
    policies against which certificates can be tested by applications.

13. Additional minor comment.
Page 5. Section 1.1. Second paragraph.

    SCVP can be used by clients that do much of
    the certificate processing themselves but simply want an untrusted
    server to collect information for them.  However, when the client has
    complete trust in the SCVP server, SCVP can be used to delegate the
    work of certification path construction and validation, and SCVP can
    be used to ensure that policies are consistently enforced throughout
    an organization.

Rephrase as:

    SCVP, used for DPV, can be used by clients that have complete trust
    in a trusted DPV server. In such a case, the protocol can be used to
    delegate the work of certification validation against a validation
    policy.

    SCVP, used for DPD, can be used by clients that do much of
    the certificate processing themselves but simply want an untrusted
    DPD server to collect certificates and revocation status information
    for them.

14. Since both one of the security area directors and one of the co-
chairs of PKIX are editors, I request that both the other security area
director and the other PKIX co-chair take a look at the debate: Tim, the
over-ever optimistic, being both editor of the draft and PKIX co-chair
cannot be in a position to say when a rough consensus will be reached.

15. Note also that after having waited for months changes and responses to
comments, it is not acceptable, that - AS USUAL - the document is only
delivered two weeks ahead the PKIX meeting: it is not possible to review
in details two major documents of this WG, i.e. SCVP-17 and RFC3280bis in
only two weeks.

16. Finally, note also that, unless I can finally agree on the document,
I do not want to have my name placed in the acknowledgments section as it
is currently mentioned, since, at this time, I am not *in any way*
supportive of this “monument”.

I certainly participated to the lively debate, but at this time my
contributions have not yet been able to “greatly improve the document”.

Denis

---

From: [email-masked]
Date: Fri, 25 Feb 2005 09:50:32 -0500

Denis,

I was looking forward to reading thoughtful and insightful comments on the new 
draft, and was very disappointed to find that the following message was nothing 
but insults.  To repeatedly suggest that the editors "have not read in detail 
RFC 3280" or its various sections is a bit much.

Consider your message deleted.

Tim Polk