RE: Comments to SCVP ID 17

["Michael Myers" <mmyers@xxxxxxxxx>]

Denis,

Reasonable minds may differ on these shades of meaning without
resolution.  The IETF empowers WG chairs as it does in order to resolve
such impasses.  This document has been tied up in WG far too long
debating ethereal issues that have little if any bits-on-the-wire
technical substance.  Time to move it on I think and let "running code"
determine what defects, if any, exist.

Mike




-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]On Behalf Of Denis Pinkas
Sent: Monday, February 28, 2005 2:24 AM
To: ietf-pkix@xxxxxxx
Cc: wpolk@xxxxxxxx; kent@xxxxxxx
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”.


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.


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.


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.

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


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.


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.


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.


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.


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.


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.


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.


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.


Denis