Subject: Comments on SCVP

From: Denis Pinkas <[email-masked]>
Date: Mon, 21 Mar 2005 09:48:43 +0100

To
the list (and Tim),

A. I would like to mention upfront that I share the same concerns like

Wen-Cheng on the validation algorithm which should be suppressed.

B. I have the same concern like Sharon, but a solution different

from the one she proposed.

When there is a request to a service, the service MUST attempt to

perform the request AND DO NO MORE.

This golden rule SHALL not be changed. Changing it would face us with
major

complications and would lead us to much complexity, in particular for

clients having to process unwanted responses.

So PLEASE, remove all text involving more processing by the client than

what is requested by the client.

C. I would also like mention that the concept of default validation
policy

is unnecessary. In a request when someone wants to use a default value,

then the value is simply omitted and there is no need to specify an OID
to

say "this OID means the default". As an example, RFC 3161 is based in
that

paradigm. Let us not use the statement "why make it simple, when it can
be

complicated ? " Please suppress the OID of the default validation
policy.

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

Tim: Both occurrences of "PKI policies" have been changed to
"validation

policies" to align with 3379.  (There were no occurrences of "PKI
policy".)

Denis: Fine

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.

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

Denis: This does not work: the inputs to the certification path
validation

algorithm used by SCVP are NOT those defined by [PKIX-1] in section
6.1.1

but those defined by section 6.2 which allow more than one trust anchor.

SCVP MUST allow to perform the certification path validation from
section 6

and 6.2 and not simply the basic path validation from section 6.1. A

validation policy includes more than one trust anchor.

There can be no compromise on this issue: PKIX-compliant certification
path

validation is NOT simply section 6.1 from RFC 3280.

Furthermore there is no need to "permit 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.

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

Denis: This is still incorrect. The basic certification path processing

algorithm DOES NOT support specification of one or more Trust Anchors
(by

value or reference) as an input.

For each Trust Anchor the set of parameters may be different. The
current

ASN.1 structure would not allow for it. see a proposal further down in

these comments.

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.

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

Denis: This is not acceptable. There cannot be such a "reasonable

compromise". It would be unacceptable to ask for one call per Trust
Anchor.

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.

Denis: No. A validation policy may have any set of parameters.
Suppressing

the set of parameters of the validation algorithm would solve the issue.

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.

Tim: Other tests are currently supported in conjunction with the
validation

algorithm.

Denis: Once again the structure above is able to solve the issue: we
have

to make the difference between the set of parameters which is related
to

the CA hierarchy (up to one or more Trust Anchors) and the parameters
which

are related to the target certificate. See an updated proposal further
down

in this e-mail.

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.

Tim: 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 requirements on
relying

parties.  In fact, there are indications in both 3280 and 3647 that

revocation checking need not be performed by relying parties.

Denis: There is no such statements. See below

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.

Denis: The reality is the following: if you want assurance then you
MUST

perform revocation. If you do not want assurance or want less assurance

then you may do whatever tests you want: the less tests, the lower the

assurance.

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;

Denis: A rewriting is anyway necessary. There is a major difference
between

simply saying "OPTIONAL" without any explanations and saying "no
revocation

test means no assurance or little assurance".

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.

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

Denis: this would not be sufficient. If someone is interested in DPV
only,

how will it be possible to easily know what to implement or not ? Are
you

going to provide a table which provide only the necessary options ?

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.

Denis: Would this summarize all the differences ? I guess the answer is
no.

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.

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

Denis: This does not solve the issue cat all. Implementers should be
able

to implement only DPV and be able to say "I am RFC XXX conformant".

Currently this is not possible.

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.

Tim: Are you suggesting that userPolicySet and trustAnchors fields of
the

request should be optional to support?

Denis: I am suggesting something different. In fact, for every
trustAnchor,

the userPolicySet parameter may be different. In the proposal they are
both

"hidden" under the validation policy, so the complexity is not visible
from

the client side.

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

Denis: While for DPD the client may want to specify these values and
work

Trust Anchor by Trust Anchor (as you may easily guess, I am not
interested

in DPD due to its complexity), this is not the case for DPV where the

client simply wants to specify a validation policy and MAY want in
addition

to specify some specific "certificate target parameters", IF they are
not

already specified in the validation policy.

This is simple. Default parameters on the server side that could be
changed

by the client would add complexity.

This would mean that the client would only be allowed to specify in its

request parameters that the server is able to process under the
specified

validation policy.

As already said, there a interest to be able to separate the parameters

which relate to the algorithm described in section 6.2 of RFC 3280 (I
did

say 6.2, not 6.1) from the parameters which relate to the test to be

accomplished on the target certificate.

However they are both parameters from the validation policy.

We could define in this specification (but we do not need to) some
useful

set of parameters that could be used by specific validation policies.

We could also define in this specification (but we do not need to) some

useful validation policies.

Separating the section to define these specific validation policies
would

also add clarity.

ValidationPolicy ::= SEQUENCE {

valPolicyId         OBJECT IDENTIFIER,

parameters          ANY DEFINED BY valPolicyId OPTIONAL }

A nice structure to import for certification path validation would be:

CertificationPathValidationParameters ::=

SEQUENCE OF BasicPathVvalidationParameters

with :

BasicPathVvalidationParameters ::= SEQUENCE {

trustAnchor               TrustAnchor,

userPolicySet         [1] SEQUENCE SIZE (1..MAX) OF

OBJECT IDENTIFIER OPTIONAL,

inhibitPolicyMapping  [2] BOOLEAN OPTIONAL,

requireExplicitPolicy [3] BOOLEAN OPTIONAL,

inhibitAnyPolicy      [4] BOOLEAN OPTIONAL }

A nice structure to import for the target certificate properties would
be:

CertificateTargetParameters ::= SEQUENCE {

keyUsages                [0] KeyUsages OPTIONAL,

extendedKeyUsages        [1] SEQUENCE OF KeyPurposeId OPTIONAL,

nameValidationAlgParms   [2] NameValidationAlgParms OPTIONAL,

otherTests               [3] OtherTests OPTIONAL }

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.

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

Denis: It does, since the validation policy MAY mandate that the key in
the

target certificate is for an intended purpose.

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.

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

Denis: If you keep the sentence as it is, then it means that DPD
clients do

not care for revocation checking. If so, remove all parameters for

revocation checking in the case of DPD.

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.

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

Denis: This is a good compromise.

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: No. A DPV server handles DPV requests while a DP server handles
DPD

requests. The same machine (not the same server) may do both. This
notion

is fundamental so that the two services can be separated.

This notion of separation goes well beyond these sentences ands should
be

reflected within the document. I would like that we use two different
ports

to address the requests: one for DPV and one for DPD. Once again, one
goal

is to be able to only have a DPV compliant server.

Denis