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