Subject: SCVP 16 comments 17-45

From: Denis Pinkas <[email-masked]>
Date: Tue, 15 Feb 2005 16:17:32 +0100

Tim,

You said: "I am looking forward to your comments on our disposition of your 
comments".

You already got these ones below which were not responded.

Denis

==========================================================================
Denis,

The editors have been working feverishly to meet the deadlines.  In some 
cases, the disposition of comments are currently chicken scratch on paper. 
They will be submitted to the list as soon as we can document things.

However, you should understand that some comments may not be resolved to 
your satisfaction.  We are looking for *rough consensus* here.  That means 
the WG as a group needs to be satisfied on each issue, but some individuals 
will inevitably be unhappy with the resolution of some particular issues. 
That is just life.

IMHO, issues related to consistency with RFC 3379 are show stoppers - SCVP 
must be responsive to our requirements document!  Issuers related to 
elegance and personal preference are not show stoppers, and should not be 
allowed to prevent this document from moving forward.

Anyway, we will get the disposition of your comments (and others) documented 
and onto the list today or tomorrow.  I'm looking forward to your comments 
on our disposition of your comments.

Thanks,

Tim

-------- Original Message --------
Subject: Re: SCVP 16 comments deadline
Date: Wed, 05 Jan 2005 13:46:18 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Trevor Freeman <[email-masked]>
CC: [email-masked]
References: 
<[email-masked]>

Trevor,

Here are my responses on 17-45. There are still many major points on which
we do not agree. The MAJOR one has still to do with the deletion of the
validation ALGORITHM so that all validation POLICY dependant parameters can
be placed under the validation policy reference.

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 ?

[DP] I do not believe that raising this question is a good way to solve my
concern. The “S” from SCVP was supposed to mean “Simple”. The current
description is the description of CCVP ”Complex Certificate Validation
Protocol”. Now, since you asked, CCVP is unable to support the validation
algorithm described in section 6.2 of RFC 3280 (with many trust points, each
one with its set of parameters). Adding more complexity to
solve it would not be the right answer.

A major simplification is obtained if there is an OID to define the
validation policy while there may be or not be additional parameters.

We sould 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
not be possible in the general case, since the current text from RFC 3280
is too vague/ambiguous 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
[DP] See my response above.

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.

[DP] Would you be more explicit ?

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.

[DP] This does not make sense. If the response is a live response (not
cached) then including the hash of the request in the response is fine and
the request does not need to be signed. If the response is a cached
response, then the cached response must include “sufficient” information
to make sure for the client that it is not a replay from a too old
response. The only way is to copy all the parameters of the original
request. In either case, signing the request does not help.

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.

[DP] I disagree. A server SHALL do what the client asks, no more no less.
Please, delete the sentence.

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.

[DP] RFC 3281 is “An Internet Attribute Certificate Profile for
Authorization ». I do not believe that it is the correct reference. The
basic problem is that there exists no RFC that explains how to check the
"revocation status for each certificate in the AC issuer certification
path". So leaving details to the validation policy is the only solution.

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.
[DP] Fine, finally one point on which we agree.

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?
[DP] Because DPV returns only the fist valid path (i.e. a single path)

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.

[DP] This would mean that the default validation policy always have a full
set of parameters. In that case the quoted sentence is still incorrect
since it states “ a partial set of parameters”. That sentence still needs
to be corrected. What about:” The client supplies a reference to the
policy plus whatever parameters which are allowed to change the default
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.

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

[DP] I disagree. I could say: the only way to include other parameters is
to place them as parameters of the validation policy because the
validation policy needs them. Your response is placed too early and does
not consider the proposal made just after. See the proposal hereafter and
please reconsider your position. This is one of the major issues.

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.

[DP] Anyway a reference to the security consideration section is missing.
If you believe that a URI is opaque, it should be said, because
dereferencing is very often announced by some people as being an
advantage. You can place that information in the security considerations
section if you wish and then let the IESG decide.

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.

[DP] Your response arguments about the note but omits to respond to the
main argument of this comment. So I consider that a response to this
comment is still awaited. BTW, userPolicySet is not a term used in RFC
3280, so you cant’t say it aligns with RFC 3280.

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

[DP] Let us see what the next text will look like to know whether this
comment is solved or not. I fear it is not.

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.

[DP] What you call the basic validation algorithm is one of the many
elements of the rfc-3280 basic validation policy. It is buried within the
validation policy and does not need to be identified independently of the
validation policy. The default Validation Algorithm still needs to be
deleted. This relates to comment 17.

32. Page 17. Section 3.1.5.1. Some text of this section might be re-used
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
[DP] See my response above.

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.
[DP] See my response: your response does not consider the proposal made in
comment 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.
[DP] I do not understand the argument about “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 aligns with 3280 section 6.
[DP] userPolicySet is not a term used in RFC 3280, so you cant’t say it
aligns with RFC 3280 section 6. You are probably reading a different
document.

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.

[DP] I disagree. There may be some validation policies where no parameter
at all can be changed by the client. I would expect that most clients will
use OIDs for validation policies with no parameter at all. A client is not
necessarily allowed to change any parameter of a validation policy. In
some cases clients will be allowed to specify only some parameters (but
not all).

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.
[DP] It does not. Section 6 does not mandate policy mapping.
The default is simplicity: no policy mapping.

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.

[DP] A response is missing.

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.

[DP] See my new response to comment 20. If the response is a live response
(not cached) then including the hash of the request in the response is
fine. If the response is a cached response, then the cached response must
include “sufficient” information to make sure for the client that it is
not a replay from a too old response. The only way is to copy all the
parameters of the original request.

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 response flags
now has a FullRequestInResponse in place of the requestRefHash.

[DP] Let us see what the full new proposal is. If you agree with my
response to comment 20, maybe we are converging.

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

[DP] This new proposed text is still incorrect: “just a reference to the
validation policy” does not help, (unless the validation policy has no
variable parameter). We need to have a mechanism for replay protection
and/or for making sure that the response relates to the right request:
“just a reference to the validation policy” does not provide this
property. However, my proposal provides that property. Please reconsider
my text.

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

END OF COMMENTS

Denis

---

From: Tim Polk <[email-masked]>
Date: Tue, 15 Feb 2005 11:14:04 -0500

Denis,

The editors' resolution of the outstanding comments from your 17-45 are 
inserted in line below.

Thanks,

Tim

 >
 >Trevor,
 >
 >Here are my responses on 17-45. There are still many major points on 
which we do not
 >agree.  The MAJOR one has still to do with the deletion of the validation 
ALGORITHM
 >so that all validation POLICY dependent parameters can be placed under 
the validation
 >policy reference.
 >
 >>> 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.
 >
We have done a lot to elaborate on the difference!

 >>> Later on when observing the ASN.1 syntax it may be discovered that two 
OIDs are
 >>> being used:
 >> [TF] Is there a specific issue with the current draft such as a 
scenario which is not
 >> addressed ?
 >
 >I do not believe that raising this question is a good way to solve my 
concern.  The "S"
 >from SCVP was supposed to mean "Simple".  The current description is the 
description
 >of CCVP "Complex Certificate Validation Protocol".  Now, since you asked, 
CCVP is
 >unable to support the validation algorithm described in section 6.2 of 
RFC 3280 (with
 >many trustpoints, each one with its set of parameters).  Adding more 
complexity to solve
 >it would not be the right answer.
 >

We agree that such scenarios are out of scope for SCVP!  Adding such 
complexity would
be a mistake.

 >>> A major simplification is obtained if there is an OID to define the 
validation policy
 >>> while there may be or not be additional parameters.
 >>>
 >>> We should then have:
 >>>
 >>> Specifying a path processing compliant with section 6.1 of RFC 3280 
would not be
 >>> possible in the general case, since the current text from RFC 3280 is too
 >>> vague/ambiguous 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.
 >>>
parameters and
 >>> allow for the addition of other parameters.
 >>>
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]:
 >>>           - 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
 >
 >See my response above.
 >

First, it is entirely appropriate for SCVP to focus exclusively on 3280 
path validation.
This is a PKIX spec, and 3280 defines the PKIX path validation algorithm.

Secondly, the proposed ASN.1 requires a great deal more complexity in SCVP 
client
implementations.  The client will need to process the validation policy 
definition to
identify parameters that can be modified and determine their structure.  In 
theory, every
validation policy could have its own policy syntax and that would require a 
lot more
coding in the client.

So, we believe the current ASN.1 should be retained.

 >
 >>> Some of the text present in the current section 1.4 has been used to 
build the new text
 >>> that is proposed below:
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".
 >>>
 >

The algorithm defined in 6.1 of 3280 always begins with a single  trust 
anchor.  Section 6.2, "Using the Path Validation Algorithm", states "the 
path validation algorithm presented in section 6.1 defines the minimum 
conditions for a path to be considered valid."  This algorithm could be 
extended to support multiple trust anchors or refined to require an 
alternative name form, but the path itself would still satisfy 6.1.

Specification of multiple trust anchors, even with different initialization 
parameters, could be supported through pre-established validation 
policies.  I suspect this meets 99% of all real world use cases.  It has 
the added virtue that it does not add any complexity at the client.

 >>> 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.
 >
 >Would you be more explicit ?
 >

Like most of the PKIX protocols, SCVP does not mandate a particular 
transport.  HTTP is highlighted in the appendices as the most common 
transport.  If the details for HTTP are insufficient for interoperable 
implementations, this should be corrected.

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

If the response is a live response (not cached) then including the hash of 
the request in the response is fine and the request does not need to be 
signed.  If the response is a cached response, then the cached response 
must include "sufficient" information to make sure for the client that it 
is not a replay from a too old response.  The only way is to copy all the 
parameters of the original request.  In either case, signing the request 
does not help.

The phrase signed in SCVP indicates an electronic signature.  Both a 
digital signature and an HMAC are supported.  The digital signature 
authenticates the client to the server.  The HMAC "signature" can provide 
anonymous client integrity.  This has been clarified in the new draft.

 >>>    "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.
 >
 >I disagree.  A server SHALL do what the client asks, no more no 
less.  Please, delete the
 > sentence.

So a server should return an affirmative response with a path including 
certificates it knows to be revoked?  That places the server in an 
untenable position.

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".
 >RFC 3281 is "An Internet Attribute Certificate Profile for 
Authorization".  I do not
 >believe that it is the correct reference.  The basic problem is that 
there exists no RFC
 >that explains how to check the "revocation status for each certificate in 
the AC issuer
 >certification path". So leaving details to the validation policy is the 
only solution.

An AC issuer certification is a 3280-compliant certification path where the 
end certificate contains the key used to issue the attribute 
certificate.  Where is the ambiguity?

 >>>    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
 >>
 >Fine, finally one point on which we agree.
 >
 >Because DPV returns only the fist valid path (i.e. a single path)
 >

A DPV server might sensibly be designed to return the first valid path it 
encountered, but that isn't the only solution.  It is certainly possible 
for multiple valid paths to exist, and be known to a server.  In such a 
case, the server could certainly return multiple paths.  I checked 3379, 
and did not see any contradiction.

 >>> 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
 >>
 >>>     "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.
 >>>     "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.
 >
 >This would mean that the default validation policy always have a full set 
of parameters.
 >In that case the quoted sentence is still incorrect since it states "a 
partial set of
 >parameters".  That sentence still needs to be corrected.  What about "The 
client supplies
 >a reference to the policy plus whatever parameters which are allowed to 
change the
 >default parameters".

New text: "A validation policy MUST define default values for all 
parameters necessary for processing an SCVP request."

 >>> 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.
 >>
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.
 >
 >I disagree.  I could say: the only way to include other parameters is to 
place them as
 >parameters of the validation policy because the validation policy needs 
them.  Your
 >response is placed too early and does not consider the proposal made just 
after.  See the
 >proposal hereafter and please reconsider your position.  This is one of 
the major issues.

We believe the new draft clarifies the difference between validation 
policies and algorithms.  Given this clarification, we believe the current 
ASN.1 structure provides appropriate mechanisms to specify any required 
parameters.

 >
 >>> Each validation policies uses its own parameters. We should have 
something like :
 >>> 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.
 >
 >Anyway a reference to the security consideration section is missing.  If 
you believe that a
 >URI is opaque, it should be said, because dereferencing is very often 
announced by some
 >people as being an advantage.  You can place that information in the security
 >considerations section if you wish and then let the IESG decide.
 >

The security considerations section includes the following text.  We 
believe this addresses the concern.

    The only validation policy references that are truly persistent are
    OIDs.  If the ownership of the policy could in any way be an issue,
    then OIDs should be the reference type of choice.  However in many
    situations, even though URIs are technically non-persistent, the use
    of a URI is much more readily understood because of its widespread
    use elsewhere, and with many organizations they may be viewed as
    persistent for practical purposes. Therefore in these situations use
    of a URI many be more attractive.

 >>> 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:
 >>>

First, this would preclude the client from supplying parameters to any 
validation policy supplied by reference to a URI.  There is no reason for 
this distinction.

Second, both the OID and the URI simply represent a name for the validation 
policy.  The client is already trusting the server to perform path 
validation on its behalf.  If the client does not trust the server to 
validate against the appropriate policy, it should require specification of 
the policy by value in the response.  This is required whether an OID or 
URI is used to specify the policy!

"certificatePolicySet".
 >>
 >> [TF] The use of userPolicySet aligns with 3280.  I don't think the name 
to the existing
 >> structure is ambiguous or misleading.
 >
 >Your response arguments about the note but omits to respond to the main 
argument of
 >this comment.  So I consider that a response to this comment is still 
awaited.  BTW,
 >userPolicySet is not a term used in RFC 3280, so you can't say it aligns 
with RFC 3280.
 >
 >>> 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.
 >>>
 >

As noted above, using "ANY DEFINED BY" to specify parameters has serious 
implications for complexity of clients.  Again, this is PKIX and support 
for the 3280 validation algorithm is mandatory.

 >Let us see what the next text will look like to know whether this comment 
is solved or
 >not. I fear it is not.
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.
 >>
 >What you call the basic validation algorithm is one of the many elements 
of the rfc-3280
 >basic validation policy.  It is buried within the validation policy and 
does not need to be
 >identified independently of the validation policy.  The default 
Validation Algorithm still
 >needs to be deleted.  This relates to comment 17.
 >
 >Hopefully, this has been resolved by the clarifications between 
validation policy and
 >algorithm.
 >
 >>> 32. Page 17. Section 3.1.5.1. Some text of this section might be 
re-used 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.
 >See my response above.

As specified, this states that the default policy uses the 3280 validation 
algorithm as specified in section 6.1 for identity certificates and as 
supplemented in 3281 for attribute certificates.  It is wholly appropriate 
for the PKIX DPD/DPV protocol default to the PKIX specs!

Note that servers are not forced to accept requests that specify this policy.

 >
 >>> 33. Page 17. Section 3.1.5.2 validationAlg (same title as 3.1.5 !) 
should be as well
 >>> deleted.
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.
 >
 >See my response: your response does not consider the proposal made in 
comment 27.

There are always multiple ways to describe things.  The current structure 
is no worse than any other, so there is no reason to change.

 >>> This construct is artificial since KeyPurposeId is about the Extended 
Key Usage and
 >>> has nothing to do with name validation.
 >>
 >I do not understand the argument about "existing practice".
 >

Renamed keyPurposeId as name comparison algorithm, which more accurately 
describes its function.

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

This feature is provided by the extendedKeyUsages field in the validation 
policy.

 >userPolicySet is not a term used in RFC 3280, so you cant't say it aligns 
with RFC 3280
 >section 6.  You are probably reading a different document.
 >

The userPolicySet is used to specify the user-initial-policy-set.  The 
"initial" is implied in the context, as with all the other variables.  That 
is, the inhibitAnyPolicy field is used to specify the 
initial-any-policy-inhibit state variable in 6.1, etc., etc.

Adding initial to all the names would be tedious and verbose.

 >>>     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.
 >
 >I disagree.  There may be some validation policies where no parameter at 
all can be
 >changed by the client.  I would expect that most clients will use OIDs 
for validation
 >policies with no parameter at all.  A client is not necessarily allowed 
to change any
 >parameter of a validation policy.  In some cases clients will be allowed 
to specify only
 >some parameters (but not all).
 >

We agree that a validation policy may not let you change this 
value.  Essentially, this text mandates that implementations of SCVP 
servers support policies that allow changing this value.  That does not 
mean a specific SCVP server can't be configured to reject requests that 
change this value.

 >>>     By default the server allows policy mapping as part of 
certification path validation.
 >>>     "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".
 >>
 >It does not.  Section 6 does not mandate policy mapping.  The default is 
simplicity: no
 >policy mapping.

If a server (or any other implementation) recognizes an extension, it is 
required to process it.  This is a requirement in both X.509 and RFC 3280.

The behavior you described above is achieved when the validation policy 
inhibit policy mapping or the client asserts inhibitPolicyMapping in the 
request.  Note that the policy mapping extension is still processed if 
recognized, but the results are different..

 >>>      "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:
 >A response is missing.

The quoted text is describing the ESSCertID option.  When this option is 
used the certificate IS identified by a hash and optionally a distinguished 
name with serial number.  Section 3.1.5.8 also includes a sentence that 
indicates that the certificate itself can be included.

 >>>     "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."
 >See my new response to comment 20. If the response is a live response 
(not cached) then
 >including the hash of the request in the response is fine. If the 
response is a cached
 >response, then the cached response must include "sufficient" information 
to make sure
 >for the client that it is not a replay from a too old response. The only 
way is to copy all
 >the parameters of the original request.
 >

If the server includes the entire request in the response, there is no 
reason to include a hash as well.  The "produced at" time should be 
sufficient to check the age of your response (assuming you trust your server!)

 >
 >>> 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 response 
flags now has a
 >> FullRequestInResponse in place of the requestRefHash.
 >
 >Let us see what the full new proposal is. If you agree with my response 
to comment 20, maybe we are converging.
 >>>   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".
 >>>
 >>>
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 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.
 >
 >This new proposed text is still incorrect: "just a reference to the 
validation policy" does
 >not help, (unless the validation policy has no variable parameter).  We 
need to have a
 >mechanism for replay protection and/or for making sure that the response 
relates to the
 >right request: "just a reference to the validation policy" does not 
provide this property.
 >However, my proposal provides that property.  Please reconsider my text.
 >

Please review Section 4.5.1.  Even if responseValidationPolByRef is TRUE, 
the response includes any items for which the value in the request differs 
from the value from the referenced validation policy.

 >>>   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.
 >>>     SCVP server SHOULD support the producedAt values in the request.
 >>>
 >>> into:
 >>>
 >>> Reason: cached responses should not need to be implemented in order to 
be compliant
 >>> with the specification.
 >>>   "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 authenticate and integrity protect the first response and 
authenticate and integrity
 >>>    protect subsequent request-response pairs".
 >>
response." The
 >> use of DH does not necessarily authenticate the request.
 >>
 >>>
 >>>    "It is a matter of local policy what validation policy is used by 
the server when
 >>>    validating requests".
being used.
 >>> Change into:
 >>>
 >>>    It is a matter of local policy what validation policy is used by 
the server when
 >>>    authentication requests".
 >>
 >> [TF] Fixed
 >>
 >>> END OF COMMENTS
 >
 >Denis
 >
 >