Subject: Re: Comments to SCVP ID 17

From: Tim Polk <[email-masked]>
Date: Tue, 01 Mar 2005 18:28:01 -0500

At 10:23 AM 2/28/2005 +0100, you wrote:

Here are some revised comments,
based on the previous e-mail.

1. A new wording introduced in the document which is: “PKI policies”.
This

term is defined nowhere in RFC 3280, nor in this document. When it
is

used, it seems to mean “validation policy”. Please delete everywhere
“PKI

policy” and replace it with “validation policy”.

Both occurrences of "PKI policies" have been changed to
"validation policies" to align with 3379.  (There were no
occurrences of "PKI policy".)

2. On page 7 the new term “basic
certification path processing algorithm”

is introduced whereas RFC 3280 uses a different wording :

- “certification path validation” (that is the title of section 6)
and

- “basic path validation” (that is the title of section
6.1).

Please do not introduce a new term.

The sentence will be revised as
follows:

SCVP defines a basic validation algorithm which implements the basic path
validation algorithm as defined in [PKIX-1], and permits the client to
request additional information about the certificate to be
validated.

3. The text refers to
section 6.1.1 and it is said that one the input in

section 6.1.1 is a “Set of Trust Anchors”. This is not consistent
with

section 6.1.1 from RFC3280 which deals with a *single* trust
anchor,

while section 6.2 from RFC 3280 deals with multiple trust
anchors.

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

anchors”. The protocol should allow, with a single request-response,
to

check if a certificate is valid against a validation policy which
has

more than one trust anchor. These checks should be done in
accordance

with section 6.2 from RFC 3280. The current ASN.1 is not conformant
with

section 6.1 from RFC 3280.

The trust anchor text will be removed from the list associated with 6.1.1
and relegated to the following paragraph.  The following paragraph
will state the options and use cases.

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;

The initial policy set;

Initial inhibit policy mapping setting;

Initial inhibit anyPolicy setting; and

Initial require explicit policy setting.

The basic certification path
processing algorithm also supports specification of one or

more Trust Anchors (by value or
reference) as an input.  Where the client demands a

certification originating with a
specific CA, a single Trust Anchor is specified.  Where

the client is willing to accept
paths beginning with any of several CAs, a set of Trust

anchors is specified.

4. Section 1.4 is about a
validation algorithm. Different rules may apply

to every trust anchor and to the CA certificates from the
certification

path under every trust anchor. The ASN.1 description of
ValidationPolicy

starting on page 17 does not allow the client to define CA related

different parameters for every trust anchor.

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 this would be conformant with the algorithm from section
6.1 of

RFC 3280, but validation policies with multiple trust anchors and
their

own parameters could not be used.

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
to

support section 6.2 from FRC 3280.

Using your ASN.1, the client would need to repeat the request for each
Trust Anchor.

Using the current ASN.1, the client could use a single request for each
set of Trust Anchors that shared the set of parameters.  If the
client wishes to specify different parameters, then the client must use
multiple requests.

In my opinion, the current ASN.1 provides a reasonable compromise between
complexity and functionality.

A validation policy could
OPTIONALLY include several “target certificate

specific parameters” as Wen-Cheng proposed, since they usually do
not

change from one trust anchor to another.

This would also solve the problem that Wen-Cheng noticed about the
“name

validation algorithm”.

Note that, as Wen-Cheng proposed, “target certificate” seems to be
a

better term rather than “end certificate”

It is obvious that for each certification path, the algorithm from

section 6.1 of RFC 3280 is being used. The validationAlg parameter is
not

needed.

We have already given the counter example (proxy certs) where this
parameter *is* 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

}

additionalTests could be used for example to test QCStatements
extensions

presence and values, which would be very useful for Qualified

Certificates.

Other tests are currently supported in conjunction with the validation
algorithm.

5.Section 1.5 states: “However,
revocation checking is an optional

feature in [PKIX-1], ... ” 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. For DPV, revocation checking MUST be done to
validate

a certification path, but this may be done using different means.
This

means may be specified in the validation policy.

First, I am not sure what change(s) you are advocating here.  Is the
problem this sentence or are you advocating additional restrictions on
DPV services?

Second, I also do not agree with your interpretation of 3280.

In RFC 3280, CAs are required to either issue CRLs or have another
mechanism to distribute that information.  (No restrictions are
specified on that mechanism so I presume publishing it in the New York
Times would be okay.)  RFC 3280 does not explicitly impose these
requireemnts on relying parties.  In fact, there are indications in
both 3280 and 3647 that revocation checking need not be performed by
relying parties.

From the security considerations section in RFC 3280:

Similarly, implementations of the certification path
validation mechanism described in

section 6 that omit revocation checking provide less
assurance than those that support it.

RFC 3647, section 4.4.9 bullet 6 implies that revocation checking is
optional:

* The mechanisms, if any, that a relying party may use or
must use in order to

check the status of certificates on which they wish to rely;

This text corresponds to the heading "4.9.6 Revocation checking
requirement for relying parties" in the suggested outline.

6. It should be remembered that RFC
3379 makes the separation between DPV

and DPD, while this document defines a single protocol for both of
them.

At the minimum the document should be profiled so that implementers
may

choose to support only DPV and not be forced to support also
DPD.

We will change section 3.2.2 so that DPV servers need not support the
id-stc-build-pkc-path check.

Conforming SCVP server implementations that support delegated path
discovery (DPD) as

defined in [RQMTS] MUST support the id-stc-build-pkc-path
check.

We will change section 3.2.3 to clearly delineate the wantBacks that must
be supported by DPD and DPV server implementations.

All conforming SCVP server implementations MUST support the
id-swb-pkc-cert and

id-swb-pkc-public-key-info wantBacks.  Conforming SCVP
server implementations that

support delegated path discovery (DPD) as defined in [RQMTS]
MUST support the

id-swb-pkc-best-cert-path and id-swb-pkc-revocation-info
wantBacks.  Conforming SCVP

server implementations that support delegated path
validation (DPV) as defined in [RQMTS]

MUST support the id-swb-pkc-cert-status wantBack.

7. “SCVP” is a not a good name when
the request is to only build 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. If
someone

says : “I support SCVP”, how could it make clear that it only
supports

the DPV variant of it ?

Better names would be:

- DPVP: Delegated Path Validation Protocol, and

- DPDP: Delegated Path Discovery Protocol.

Regardless of the mode (DPD vs. DPV) the goal is to simplify certificate
validation.  In one case we offload path discovery and perform
validation locally.  In the second case, both processes are
offloaded to the server.

It is not so hard to clarify which services are supported.  They
could say "Our DPV server (client) implements SCVP as specified in
RFC WXYZ".   This is not new or too difficult.  When
ever there are optional features in a standard, the simple statement
("I support RFC 3280/2560/whatever") is insufficient.

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
protection

(i.e. integrity) to the communication link (i.e. using TLS) and not

supporting other parameters (with the exception of the above
optional

“target certificate specific parameters” as Wen-Cheng proposed). It
is

currently not straightforward to derive from the current document a

profile for this.

It is suggested to revise the document so that this goal can be
achieved

and that conformance clauses are added to be able to say that a
given

implementation is conformant to this aspect only.

Additional comments (up to page 8 only) follow.

Are you suggesting that userPolicySet and trustAnchors fields of the
request should be optional to support?

It is certainly possible to draft a useful profile of SCVP that does not
make use of all the mandatory to support features.  (For example,
David Cooper has drafted a profile for the FPKI that does not require the
use of several of the mandatory to implement features, including these
two fields.)  However, in many environments it may be preferable to
have the client specify these values rather than attempting to define a
separate validation policy for every possible combination that may be
needed for every relying party for every application.

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

Your text implies that validating the certificate is the ultimate
goal.  The current text indicates that validating the certificate is
a necessary step towards achieving the goal - to use the key in a
certificate for an intended purpose.  Your text is simpler, but I
don't think it gets to the heart of the matter.

10. 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 they lack a reliable or efficient method
of

constructing a valid certification path and the
associated

revocation status information.

Clients may wish to retrieve status information directly to ensure
freshness.  It is simple to retrieve status information if the certs
contain CDPs or AIAs that point to OCSP servers.

Given that this is introductory information, I believe the current text
is acceptable.

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

First, central management of policies is a goal noted in 3379, so I
wouldn't want to delete it.

How about:

The primary goals of SCVP are to make it easier to deploy
PKI-enabled

applications by delegating path discovery and/or validation
processing to

a server, and to allow central administration of validation
policies

within an organization.

12. 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 path construction and
validation.

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 information for them.

This is just a repeat of the introductory text in Section 1 above.
We have already introduced the concepts, and there is no reason to assume
that all servers fit into a single category.  A DPV server might
handle DPD requests as well.

Since the current text is accurate let's leave it as is.

Denis

Tim

---

From: "Seth Hitchings" <[email-masked]>
Date: Fri, 4 Mar 2005 10:07:24 -0500

As it appears that there will be another revision to the draft, I have one more request.
 
In section 4.9.5, replyWantBacks, please remove the "additional certitifcates used to
validate the revocation information" from the id-swb-pkc-best-cert-path and
id-swb-all-cert-paths want backs. This information will only ever be present if a client
requests id-swb-pkc-revocation-info. It makes the idea of the wantBack unnecessarily
complex to allow the presence or absence one wantBack to control the semantics of another.
It also increases the complexity for the client to parse the certification path out of the
cert path wantBack.

I suggest placing all information related to revocation info in the same wantBack. As
such, the wantBack value for id-swb-pkc-revocation-info could be updated to use the
following ASN.1 structure:

RevInfoWantBack ::= SEQUENCE {
  revocationInfo       RevocationInfos,
  validationCerts      CertBundle OPTIONAL }

Thanks,
Seth

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tim
Polk
Sent: Tuesday, March 01, 2005 6:28 PM
To: Denis Pinkas
Cc: [email-masked]
Subject: Re: Comments to SCVP ID 17

	Here are some revised comments, based on the previous e-mail.
	
	1. A new wording introduced in the document which is: “PKI policies”. This
	term is defined nowhere in RFC 3280, nor in this document. When it is
	used, it seems to mean “validation policy”. Please delete everywhere “PKI
	policy” and replace it with “validation policy”.

Both occurrences of "PKI policies" have been changed to "validation policies" to align
with 3379.  (There were no occurrences of "PKI policy".)

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

The sentence will be revised as follows:

SCVP defines a basic validation algorithm which implements the basic path validation
algorithm as defined in [PKIX-1], and permits the client to request additional information
about the certificate to be validated.  

	3. The text refers to section 6.1.1 and it is said that one the input in
	section 6.1.1 is a “Set of Trust Anchors”. This is not consistent with
	section 6.1.1 from RFC3280 which deals with a *single* trust anchor,
	while section 6.2 from RFC 3280 deals with multiple trust anchors.
	
	From the introduction, “a validation policy contains one or more trust
	anchors”. The protocol should allow, with a single request-response, to
	check if a certificate is valid against a validation policy which has
	more than one trust anchor. These checks should be done in accordance
	with section 6.2 from RFC 3280. The current ASN.1 is not conformant with
	section 6.1 from RFC 3280.

The trust anchor text will be removed from the list associated with 6.1.1 and relegated to
the following paragraph.  The following paragraph will state the options and use cases.  

    The inputs to the basic certification path processing algorithm
    used by SCVP are defined by [PKIX-1] in section 6.1.1 and 
    comprise:

		Validation time;

		The initial policy set;

       The basic certification path processing algorithm also supports specification of
one or 
       more Trust Anchors (by value or reference) as an input.  Where the client demands a
       certification originating with a specific CA, a single Trust Anchor is specified.
Where
       the client is willing to accept paths beginning with any of several CAs, a set of
Trust
       anchors is specified.

	4. Section 1.4 is about a validation algorithm. Different rules may apply
	to every trust anchor and to the CA certificates from the certification
	path under every trust anchor. The ASN.1 description of ValidationPolicy
	starting on page 17 does not allow the client to define CA related
	different parameters for every trust anchor.
	
	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 this would be conformant with the algorithm from section 6.1 of
	RFC 3280, but validation policies with multiple trust anchors and their
	own parameters could not be used.
	
	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 to
	support section 6.2 from FRC 3280.

Using your ASN.1, the client would need to repeat the request for each Trust Anchor.

Using the current ASN.1, the client could use a single request for each set of Trust
Anchors that shared the set of parameters.  If the client wishes to specify different
parameters, then the client must use multiple requests.

In my opinion, the current ASN.1 provides a reasonable compromise between complexity and
functionality.

	A validation policy could OPTIONALLY include several “target certificate
	specific parameters” as Wen-Cheng proposed, since they usually do not
	change from one trust anchor to another.
	
	This would also solve the problem that Wen-Cheng noticed about the “name
	validation algorithm”.
	
	Note that, as Wen-Cheng proposed, “target certificate” seems to be a
	better term rather than “end certificate”
	
	It is obvious that for each certification path, the algorithm from
	section 6.1 of RFC 3280 is being used. The validationAlg parameter is not
	needed. 

We have already given the counter example (proxy certs) where this parameter *is* 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
	   }
	
	additionalTests could be used for example to test QCStatements extensions
	presence and values, which would be very useful for Qualified
	Certificates.

Other tests are currently supported in conjunction with the validation algorithm.

	5.Section 1.5 states: “However, revocation checking is an optional
	feature in [PKIX-1], ... ” 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. For DPV, revocation checking MUST be done to validate
	a certification path, but this may be done using different means. This
	means may be specified in the validation policy.

First, I am not sure what change(s) you are advocating here.  Is the problem this sentence
or are you advocating additional restrictions on DPV services?

In RFC 3280, CAs are required to either issue CRLs or have another mechanism to distribute
that information.  (No restrictions are specified on that mechanism so I presume
publishing it in the New York Times would be okay.)  RFC 3280 does not explicitly impose
these requireemnts on relying parties.  In fact, there are indications in both 3280 and
3647 that revocation checking need not be performed by relying parties.  

    Similarly, implementations of the certification path validation mechanism described in
    section 6 that omit revocation checking provide less assurance than those that support
it. 

RFC 3647, section 4.4.9 bullet 6 implies that revocation checking is optional:

   * The mechanisms, if any, that a relying party may use or must use in order to
   check the status of certificates on which they wish to rely; 

This text corresponds to the heading "4.9.6 Revocation checking requirement for relying
parties" in the suggested outline.

	6. It should be remembered that RFC 3379 makes the separation between DPV
	and DPD, while this document defines a single protocol for both of them.
	At the minimum the document should be profiled so that implementers may
	choose to support only DPV and not be forced to support also DPD.

  Conforming SCVP server implementations that support delegated path discovery (DPD) as
   defined in [RQMTS] MUST support the id-stc-build-pkc-path check.  

We will change section 3.2.3 to clearly delineate the wantBacks that must be supported by
DPD and DPV server implementations.

   All conforming SCVP server implementations MUST support the id-swb-pkc-cert and
   id-swb-pkc-public-key-info wantBacks.  Conforming SCVP server implementations that
   support delegated path discovery (DPD) as defined in [RQMTS] MUST support the
   id-swb-pkc-best-cert-path and id-swb-pkc-revocation-info wantBacks.  Conforming SCVP
   server implementations that support delegated path validation (DPV) as defined in
[RQMTS]
   MUST support the id-swb-pkc-cert-status wantBack.

	7. “SCVP” is a not a good name when the request is to only build 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. If someone
	says : “I support SCVP”, how could it make clear that it only supports
	the DPV variant of it ?
	
	Better names would be:

Regardless of the mode (DPD vs. DPV) the goal is to simplify certificate validation.  In
one case we offload path discovery and perform validation locally.  In the second case,
both processes are offloaded to the server.

It is not so hard to clarify which services are supported.  They could say "Our DPV server
(client) implements SCVP as specified in RFC WXYZ".   This is not new or too difficult.
When ever there are optional features in a standard, the simple statement ("I support RFC
3280/2560/whatever") is insufficient.  

	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 protection
	(i.e. integrity) to the communication link (i.e. using TLS) and not
	supporting other parameters (with the exception of the above optional
	“target certificate specific parameters” as Wen-Cheng proposed). It is
	currently not straightforward to derive from the current document a
	profile for this.
	
	It is suggested to revise the document so that this goal can be achieved
	and that conformance clauses are added to be able to say that a given
	implementation is conformant to this aspect only.

Are you suggesting that userPolicySet and trustAnchors fields of the request should be
optional to support?

It is certainly possible to draft a useful profile of SCVP that does not make use of all
the mandatory to support features.  (For example, David Cooper has drafted a profile for
the FPKI that does not require the use of several of the mandatory to implement features,
including these two fields.)  However, in many environments it may be preferable to have
the client specify these values rather than attempting to define a separate validation
policy for every possible combination that may be needed for every relying party for every
application.

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

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

Your text implies that validating the certificate is the ultimate goal.  The current text
indicates that validating the certificate is a necessary step towards achieving the goal -
to use the key in a certificate for an intended purpose.  Your text is simpler, but I
don't think it gets to the heart of the matter.

	10. 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 they lack a reliable or efficient method of
	   constructing a valid certification path and the associated
	   revocation status information.

Clients may wish to retrieve status information directly to ensure freshness.  It is
simple to retrieve status information if the certs contain CDPs or AIAs that point to OCSP
servers.

Given that this is introductory information, I believe the current text is acceptable.

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

First, central management of policies is a goal noted in 3379, so I wouldn't want to
delete it.

How about:

   The primary goals of SCVP are to make it easier to deploy PKI-enabled
   applications by delegating path discovery and/or validation processing to
   a server, and to allow central administration of validation policies
   within an organization.

	12. 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 path construction and validation.
	
	   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 information for them.

This is just a repeat of the introductory text in Section 1 above.  We have already
introduced the concepts, and there is no reason to assume that all servers fit into a
single category.  A DPV server might handle DPD requests as well.

	Denis

Tim