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

Re: DPD & DPV requirements

Denis,

Steve,

See my responses embbeded with your comments.

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


[Steve]

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.


[Denis]

The current validation algorithm described in RFC 2459 is fine but too
restritive. It works fine with a single root key in the case where there are
no naming constraints nor Certification Policy constraints, or in the case
where there are are included in the (root) self-signed certificates. I have
worked with Tim Polk so that in the "son-of-RFC2459" we will have the
description of an enhanced path validation algorithm that will take care of
multiple roots, each one associated with different naming constraints or
Certification Policy constraints - which will not necessarilly be included
in the root self-signed certificates.

Self-signed certs are not the only way to deal with multiple roots, and it often seems to me that they are a poor way, when we want to make use of features like naming constraints. Why not just have cross certs issued to other "roots" by a local CA and embed the naming (and policy?) constraints into those cross certs?

So we would need to support two options, which are not mutually exclusive:

1) define with a great level of accuracy each of the parameters, or
2) provide an OID which is a global reference to all these parameters.



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

[Steve]

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.


[Denis]


In a signed CMS message, you may only have the EESCertID, without the
certificate itself.

ESSCertID ::= SEQUENCE {
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}

Hash ::= OCTET STRING -- SHA1 hash of entire certificate

IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serialNumber CertificateSerialNumber
}

The idea is to be able to use ESSCertID without the need to fetch the
certificate itself.

I see your example, but I also stand by my observation that providing anything other than the target cert per se has potential problems and adds complexity to the server. We'll have to decide whether we want to impose such adde complexity on servers, and whether we can provide clean, algorithmic means of dealing with this complexity.

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

[Steve]

Incomplete validation is a reasonable response.

Yes, it will have to be one of the responses, hopefully with an explanation of what caused the response to be incomplete.

[Denis]

:-)

[Steve]

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.

[Denis]

We are not on the same track here. I am assuming that a DPV client is PKI
ignorant. You are making the assumption that the client MAY simply some
elements of the certification path, where I make the assumption that the
single element that MAY be supplied in a DPV request is the leaf
certificate. For all the other elements of a certification path, the server
is supposed to have access to the various repositories. The response
contains a blob of what has been used, that can be blinding copied and
stored.

A DPV client MAY be not PKI-aware, but that is not the only case we agreed to address. I'll need to see more comments from WG members to persuade me that we wish to restrict DPV interactions to clients that are presumed to be PKI-ignorant, to use your term.

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

[Steve]

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.


[Denis]

Since archiving of recocation information is not mandated to the CAs, such a
function would need to be provided by some other trusted service provider.
We should be very careful before allowing the provision of such a new
service. I believe that the PKI is already sufficiently complex so that we
make our best efforts not to introduced additional Trusted Service Providers
(that could be avoided). The only case to be supported should be the
"current time" and some time "soon after the end of validity of a
certificate" (i.e. a few weeks, in case someone being on holidays would like
to check, when coming back from holidays, if a received message, was signed
by a revoked certificate or not).

There was some sentiment for having the "was it valid then" function as provided in SCVP, but if there is not continued support we could delete it. I want to get more feedback on this issue.

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

[Steve]

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

[Denis]

We should remove the time stamp option.

Yes, we could.

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

[Steve]

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.


[Denis]

If you are not hard on this issue, let us remove the time stamping option.

:-)

I'll remove it if I hear from a few more people who agree that it is best provided as a separate call to a TSA.

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

[Steve]

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.


[Denis]

I have difficulties to understand how a client that would NOT be "PKI-aware
might acquire cert paths and/or revocation data" :-)

Once again, I am advocating a simple protocol for DPV to be used by PKI
ignorant clients.

As I noted, a client might acquire cert paths and CRLs via a protocol like SSL or IKE. Such clients could be ASN.1 capable but want to offload validation for the reasons cited earlier.

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

[Steve]

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

[Denis]

Yes and no. We clearly have different assumptions, but we need to find an
agreement. I am first advocating to separate the requirements for DPV from
the requirements for DPD. Then we need to discuss the requirements for each
of them. So we need to come with separate lists of requirements. This is
what I did in my response.

If we don't agree on whether a DPV client might still pass on certs and CRLs acquired via a protocol exchange, we can't proceed along these lines. Such a DPV client looks a lot like a DPD client in terms of what it might pass to the server in a request. In any case the servers do much the same function, with the primary differences being the form in which validation parameters are specified by the client, and the form of the answers returned by the server. The vast majority of the processing performed by the servers for DPD and DPV is the same, even for a PKI-ignorant client.

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


[Steve]

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.

[Denis]

Since these chains may not be complete, I would not consider such chains to
be "valid". These chains will comply with the request, but some elements
(more probably revovation information, but also certificates ?) may be
missing.

I don't think I have seen anyone suggest that DPD return partial path info, but maybe I have overlooked this. We obviously have different models here.

> 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.
>
[Steve]

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.

[Denis]

Two remarks:

1) What kind of different assumptions are you making on:

1) DPV in XML and
2) DPV in ASN.1 ?

2) You think that protocols 2 & 3 may be very similar, but you do not
provide arguments. On the contrary, I do not think the same and I have have
provided arguments to explain why they are pretty different.

Protocols 2 & 3 are quite similar because I assume that a DPV client using ASN.1 will be able to supply cert path and revocation status data in cases such as the ones I noted, e.g., when the protocols allow clients to pass this info around even if they do not understand it. We have examples of such protocols now. It's a reasonable design approach, allowing a mix of PKI-aware and PKI-ignorant implementations for the same protocol.

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

[Steve]

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.

[Denis]

Agreed.



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

[Steve]

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


[Denis]

OK. Let me try to explain more:

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

If a client requests DPV, it would normally like to get the response "passed
validation", and will ask whether or not it wants back the single proof (as
a blob) that lead to that conclusion. In that case, it does not care about
the OCSP response which has been used in the validation algorithm and is
part from the blob. A single chain is returned in that case.

I begin to see the differences in our perspectives here. Yes, return of a single path and associated revocation status data would seem to suffice for DPV, but I don't think that DPD necessarily returns multiple paths, and I certainly don't think of it doing so in most cases. Also, why would a DPV server not return OSCP responses as part of its revocation status data, in an opaque blob? I would assume that either type of server might return either CRLs or OCSP responses, unless otherwise directed by the client (or by locally configured parameters).

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

DPV is NOT designed for a PKI-aware client, but of course can be used by a
PKI aware client, that will behave as if it were PKI ignorant.

So the single combination that remains is between the two remaining
protocols for PKI-aware clients (i.e. OCSP and DPD). In that sense, DPD
could be piggy-backed on top of OCSP.

The wording here may be confusing me. Are you saying that DPD could be implemented as an extension to OCSP (as has been proposed), because an OCSP client must be PKI-aware, whereas a DPV client is nominally PKI-ignorant and thus would never use OCSP in the first place? I agree with that analysis, although it only suggests that the DPD/OCSP combination is plausible, not necessarily preferable, and that a DPV/OCSP combination is less plausible. though not impossible.

Steve