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

Re: DPD & DPV requirements

Denis,

Steve,

First of all, many thanks for posting this long document.

I will not respond using directly your text, since my arguments
are fairly different. I will however re-use some of your arguments.

Let us use the concept of "validation policy", that you introduce, which is
all the set of rules to be followed when validating a certificate. It will
usually not simply be the rules mentioned in RFC 2459, but these rules with
additional conditions. Note that in the context of electronic signatures, a
"signature policy" is a specific example of a "validation policy".

We need to be explicit about what are the parameters that control path validation. The 2459 validation algorithm has a well-defined set, but if there are others, we need to have them specified and agreed upon. One conversation that took place in San Diego noted that one could imagine a lot of parameters that a user might want to express re path validation, but which have not been standardized, and for which we do not have general agreement. A very rich list of this sort, and the associated complexity that would accompany an enhanced validation algorithm that used thise parameters, was thought to be out of scope for now, more an R&D topic vs. a topic for standardization. So we have to be careful here.

DPV
===

Let us start with DPV first. A DPV client will not necessarily be either
PKI-aware, nor ASN.1 aware. I thus see two flavors for a DPV protocol:

1) one not using ASN.1 (e.g. using XML),
2) one using ASN.1.

In both cases the client only supplies an unambiguous reference of the
certificate (CA name, serial number and a hash of the certificate) or the
certificate itself and specifies the rules to be followed to validate the
certificate: an identification of a pre-defined "validation policy" (e.g. an
OID and/or a URL to find the policy and a hash of that validation policy).

Given the problems we have had in OCSP (v1) re referring to a target cert, I am not comfortable specifying a target cert other than by providing a copy of that cert to the server.

As a result, the client expects a signed response which reproduces the
requested parameters and includes a status. The status is not simply:
"passed validation", "failed validation", or "don't' know" but can also be
"incomplete validation", meaning that some revocation status information is
not yet available at the time of processing and a later attempt might
succeed.

Incomplete validation is a reasonable response. maybe we should include the set of parameters used for the validation, including ones not supplied by the client, e.g., defaults, or overrides imposed by the server, or the values bound to a policy that was specified.

The response must include the time at which the validation has been
performed. Allowing to test a certificate "in the past", would place some
requirements that cannot always be accomplished by a standard PKI: currently
we do not mandate CAs to maintain revocation information beyond the end of
the validity period of a certificate. We should not change that rule. So I
am very reluctant to autorise validation in the past, e.g. 10 years later.

Good points; we should include the time of the response. I added the "in the past" requirement based on its inclusion in SCVP, but there clearly limits to one's ability to support that feature. However, if the server is uable to verify a cert relative to a prior time, based on unavailability of some revocation data, it can always state that in a response. One might add a requirement to allow the server to be configured to reject requests for validation that cite a time/date prior to some confugured value.

If a client is interested in a later proof, then it should obtain that
information from the server at the time the information is still available.
This means that a client should have the possibility to ask the server to
optionally return an opaque blob that contains all what has been used to
validate the certificate (i.e. a certification path and all the CRLs or
OCSPs needed for each certificate from the path).

We have this requirement already, with a time stamp option.

A question arises from the requirements 1.5 and 1.6 that you listed: should
that opaque blob be time-stamped ? If there is a fear that some of the
issuing keys used in the certification path might later on be compromised,
then this can be useful. This case should be very seldom and hence this
service would not always be required. In addition, why should that service
be embedded in this protocol ? This could be obtained using directly the
TSP, leaving more possibilities: free choice of the TSAs, time stamp of the
full blob, time stamp of the certification chain only, time stamp on both
the certification chain and the revocation information. Thus I do not favor
to piggy-back the two services.

Yes, one could keep the services separate. I am not hard over on this, and can be persuaded to remove the requirement, or to make server support for it optional.

In order to simplify the protocol and allow for PKI-ignorant clients, the
client should NOT be allowed to provide any other element than the
certificate, that might help to construct the path or the revocation
information.

I don't see the rationale for this. We already have application protocols where a client that is not PKI-aware might acquire cert paths and/or revocation data that it could pass on to a DPV server. So, I don't think you have made a good argument here for not allowing such data to be transmitted. Also, I don't think we have agreement yet that we are supporting clients that are not PKI-aware. I merely noted that IF we choose to support such clients, then there are implications for the syntax used for the protocol, and for the semantics of what is transmitted. I don't think we have made the next step to agree to support such clients.

This means that, not only I do not agree with a common list of requirements
for both DPV and DPD, but also that I do not agree with many of the
requirements that you listed:

For a DPV client:

1.1. Only a single certificate should be allowed.
1.2. No revocation items should be allowed.
1.3. No request in the past should be allowed.
1.4. Imposing constraints for CRLs or OCSP responses should be hidden
under the "validation policy" that is selected.
1.5. and 1.6. Time stamped responses, if needed, should not be part of the
service.
1.7. Validation policies are not necessarily "configured at the server",
but can simply be pre-defined, outside the server. I any case, the
rules that has been followed - i.e. "validation policy" - must be
indicated in the response.
1.8. For DPV, responses must be signed.
1.9. The policy ID format can/will be specified in the protocol.

For a DPV server:

2.1. A DPV server, will have to do more than RFC 2459, hence why the use
of a validation policy is needed.
2.2. An opaque blob MAY be returned.
2.3. Time stamping is not needed.
2.4. The concept of policy overriding is too complex: a reference to
a validation policy is sufficient.
2.5. No comment.
2.6. A server must support LDAP for certificate fetching, and EITHER CRL
fetching OR OSCP (OCSP should not be mandatory).
2.7. No comment.


Given that we no longer agree on the underlying assumptions, it probably is not worthwhile discussing each of your proposed changes above.


DPD
===

Let us continue with DPD. I agree in general with many of the requirements
that you listed in that case. In particular, since a DPD client must be both
PKI-aware and ASN.1 aware, the protocol should only be described in ASN.1.

The major difference with the previous protocol is that no evaluation of the
returned chain needs to be done, since the client is supposed to be able to
perform all the checks himself. Therefor no validation status is returned by
the server.

I don't think I agree with both of the statements above. No explicit validation status is returned, but I do think the server is performing validation so that only valid chains are returned.

The service is more a single place for shopping all (?) the needed
certificates and revocation status information.

In the request, the client could either specify a validation policy or the
trusted points with, for each level of the chain, the indication whether
CRLs or OCSP responses are requested.

One or more chains, corresponding to the request may be obtained.

The response does not need to be signed, but only protected by a combined
integrity and data origin authentication service.


CONCLUSION
==========

We could support three protocols:

1° DPV in XML,
2° DPV in ASN.1,
3° DPD in ASN.1.

The operative term here is "could." Also, DPV in XML and DPV in ASN.1 need not be the same protocol, because of different assumptions about the clients. So I think of it three protocols where 2 & 3 may be very similar, but 1 is quite different.

ADDITIONAL QUESTION
===================

For the two protocols in ASN.1, should these two protocols be piggy-back on
OCSP ?

That's one of the proposals, but the answer should be the result of analysis of a revised proposal consistent with the requirements that we adopt.

Before going at the technical details, it is important to raise the
following question: which combination(s) of the three basic requests (OCSP,
DPV and DPD) could make sense ?

If a client requests DPV, then it does not care about OCSP and neither on
DPD (multiple certification chains to be tested).

For a PKI-aware client, only OCSP + DPD makes sense.

This means that :

1) DPV does not need to be supported by OCSP.
2) The only protocol to be piggy-backed to OCSP would be DPD.

I don't understand these comments. You need to provide more substantiation.

Steve