[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments to SCVP ID 17

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