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: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Tim
Polk
Sent: Tuesday, March 01, 2005 6:28 PM
To: Denis Pinkas
Cc: ietf-pkix@xxxxxxx
Subject: 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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature