Re: DPD & DPV requirements

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

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

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

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.

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.

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

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.

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.

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.


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.

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.


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

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

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.


Denis



> As promised, here is the strawman requirements specification for DPV and DPD. Questions that the WG needs to address as part of deciding on the scope of these requirements are in boldface.
> 
> Happy Holidays,
> 
> Steve
> --------
> 
> The WG has already decided to purse standardization of a protocol (or protocols) for delegated path discovery (DPD) and delegated path validation (DPV). This memo revisits and expands on the rationale for offering these services, notes the overlap in server functionality required for each, and proposes requirements for candidate protocols that will be considered for standardization by PKIX. The goal of the memo is to provide a strawman set of requirements and evaluation criteria that will be used to select PKIX standards.
> 
> A DPD or a DPV server may operate in either a public or private context. In the former case, clients are assumed to be from a broad community with no common organizational affiliation and the service may be offered for a fee. In the latter case, the service may be offered to a closed community under a common organizational structure, where there is an expectation that the server falls under the same administrative control as the clients and no explicit fee may be involved. Intermediate or hybrid models also may exist, but are not specifically identified here nor required as part of proposed solutions.
> 
> DPD allows a client to offload the communications and processing associated with retrieval of certificates and CRLs (or OCSP responses) to create a certification path terminating in a target certificate. The client supplies this target certificate, or it may supply a partial path, or a complete path (the latter two may have been acquired as part of a protocol exchange). In the last case, the DPD server assists the client by acquiring relevant revocation status information. The client might also supply some revocation status data, to aid the path discovery process, just as it may provide a partial or complete certification path. This might make sense if this revocation status data was supplied to the client as part of a protocol exchange, e.g., IKE and S/MIME make provisions for send such data.
> 
> The client may be bandwidth constrained and thus would benefit from having a server interact with repositories and other servers to acquire the requisite certification path and/or revocation status data. The client may be storage constrained, and thus can benefit from a server that caches certificates, CRLs and OCSP responses. Because multiple protocols may have to be employed in communicating with various servers (e.g., OCSP, LDAP, etc.) in performing path discovery, the size and complexity of client code may be reduced by reliance on a DPD server. Because the server can have more storage, a faster processor, and higher speed communications paths to these servers, the client may gain a performance advantage by delegating the task of path discovery.
> 
> DPV offloads all aspects of path validation to a server, which returns to the client, at a minimum, an indication of status of the target certificate. This status may be relative to the current time, or it might be a request to verify status at some previous time, e.g., as an aid to checking non-repudiation evidence. As above, the client may provide a partial or complete candidate path for validation, or may provide just the target certificate, and the client may provide some or all of the associated revocation status data. Also, the parameters for path validation must be provided, either explicitly in the request or via server configuration. As well as the benefits noted above (reduced bandwidth, storage and processing requirements and reduced client code size and complexity), DPV allows an administrator to centrally manage (via server configuration) some or all of the path validation parameters. Similar controls on path discovery could be present in a DPD server. Central
> management controls are viewed as especially attractive in closed, organizational environments as they mitigate configuration management problems for individual clients. For a public DPV service this is not an issue because there is no single, central authority responsible for configuration management of all clients.
> 
> A DPD client is assumed capable of performing path validation on the returned certificate chain(s), which implies that the client embodies validation software consistent with RFC 2459 (which is non-trivial in size and complexity) and thus is capable of parsing certificates, CRLs, and OCSP responses. Such a client may be termed "PKI-aware," i.e., it can parse ASN.1, verify digital signatures, perform path validation, and is cognizant of validation parameters. Thus, no apparent, significant benefit accrues from using a syntax other than ASN.1 for DPD queries and responses.
> 
> Because a DPD client is PKI-aware, it is capable of specifying the validation parameters used by a DPD server in constructing a candidate path. The goal of DPD is to return one or more chains that will be acceptable to the client, so it is important that the client be able to specify, e.g., via a DPD request, the set of validation processing parameters that it will use for local validation. Only by making the DPD server aware of these parameters can the server return a path (and supporting revocation status data) that will have a very high likelihood of being acceptable to the client. It may be desirable, especially in a closed environment, to assert centralized control over the validation processing parameters used by the server, even though such control is less stringent than that imposed in a DPV context. This suggests there should be provisions for configuring validation processing parameters into the server, and for allowing a client to select from among several possible
> parameter sets. See the discussion immediately below for a further examination of this issue.
> 
> DPV also requires a means to control the validation parameters defined in RFC 2459. If we assume that a DPV protocol will operate in both open and closed environments, and if we wish to accommodate PKI-aware clients, then there must be a means for a client to specify all of these parameters, or to specify a subset of them. The former requirement arises in the simplest, open server contexts; the latter may arise in such contexts if there is some other way to signal a default set of parameters for validation control, e.g., via reference to one of several validation policies configured in a server, as a basis for these parameter values. In a closed environment, it is still important that a client be able to specify validation parameters, e.g., as a means of selecting from among a set of parameters allowed by administrative controls managed at the server. For example, a server in an organizational environment may have a configured set of trust points, but a client may be permitted to
> select from a subset of these when requesting validation for a specific certificate. Such flexibility is needed because the validation parameters are a function of several variables that are context specific.
> 
> It seems reasonable to require a DPV or DPD client to be able to control validation via two means: specification of a validation policy configured at a server, or via client-specified parameters. These means are not mutually exclusive, and a server should support combinations of them, e.g., client-specified parameters constrained by reference to a server-configured validation policy. We need to refine the semantics here, e.g., can the server be configured with path validation parameters that CANNOT be overridden by a client, and if so, does the server have to inform the client when its explicitly-specified parameters were ignored, as part of response, or does the server just reject the request, note the offending parameters, and let the client try again?
> 
> It is tempting to suggest support for multiple policies specified in a request, but I'm not sure how one would make use of this. For example, is the server required to try to construct paths based on each of the policies, in succession, and to return all successful results, or is the server free to choose any one of the policies? Does the order in which the policies are specified indicative of preference? To keep life simple, for now, I suggest that we allow specifying only one policy in a request, but I am open to suggestions.
> 
> At a minimum, the parameters for server-configured policies must be those specified by the certificate path validation algorithm in RFC 2459. It is tempting to suggest that a vendor may elect to augment this set and provide a means by which a client can specify additional controls. The motivation here is that, over time, we may identify additional controls to provide "fuzzier" evaluation. For example, a client might be willing to accept a certificate if the server asserts that although the current CRL for the target certificate is not available, the certificate is not on the most recent CRL available to the server at the time of the request. This area is quite complex and does not yet appear suitable for standardization. The WG must decide if we wish to require (or discourage) such extensibility. Note that extensibility usually leads to added complexity, and possible non-interoperabilty, e.g., if private extensions are supported. Personally, I would recommend against such extensions
> at this time.
> 
> It has been suggested that a DPV server also should be capable of returning time-stamped certification path(s) and revocation data, for later use as evidence in a non-repudiation dispute. If so, then the data returned by a DPV server is potentially quite close to that provided by a DPD server. One could argue that a DPD server could provide an option for return of time-stamped path and revocation status data, also in support of non-repudiation, for the same reasons, which would make the responses for both types of servers even more similar.
> 
> It is important to ask to what extent should we assume that a DPV client is PKI aware? At one extreme one can imagine that the client is PKI-aware and that it should be able to specify all of the path validation parameters required in 2459. For such a client, returning a certificate and an indication of its validity seems appropriate. Alternatively, a DPV client may not be PKI-aware, but may still be ASN.1-capable. The client could parse a certificate returned to it, but it does not implement nor understand path validation. For such a client, it seems appropriate to control path validation only via reference to a policy, not by specifying individual path validation parameters. In the extreme case, a DPV client may not even be ASN.1-capable.
> 
> For a non-PKI aware, non-ASN.1-capable client, the results returned by the DPV protocol should not be merely a certificate and a status indication. Rather, the contents of a certificate that are relevant to the client application should be returned as distinct values, in a syntax appropriate for the client. For example, the public key and associated algorithm, the subject name (and/or alternate names) and the issuer name (and alternate names), the key usage bits, and the extended key usage field are all candidate values to be returned as distinct objects to the client. An argument could be made for using XML to represent some of these values, and to represent the syntax of the protocol messages. But, some of the certificate contents, specifically the issuer name and subject name, are intrinsically ASN.1 objects themselves, so these values would have to be decoded even further for use by a non-ASN.1-aware client. (There are scenarios that motivate return of ASN.1-encoded data, e.g.,
> certification paths and revocation data, as an opaque blob, e.g., for later use in a non-repudiation dispute. But this does not imply that the client is ASN.1-aware.)
> 
> If we wish to support DPV clients that are not ASN.1-capable, the WG is faced with a question; Shall we mandate support for another syntax in addition to (or in lieu of) ASN.1, for a DPV protocol? This question must be resolved soon, as it becomes an important input to DPV protocol requirements. In informal discussions at the IETF meeting, some folks suggested that the scope of issues associated with supporting non-ASN.1-capable clients (in the DPV context) is potentially very broad and that we should defer such support for now. But, the WG needs to weigh in on this question.
> 
> Finally, this analysis suggests that there are relatively few differences between a DPD and a DPV server. Both must be capable of constructing and returning certification paths and supporting revocation data, under the control of parameters that are either explicitly specified by a client or referenced via a server-configured policy. Both accept a range of inputs in the form of certificates or certificate chains, and revocation data "hints." Thus, the WG must decide if two distinct protocol formats, with different syntax are warranted, of if a single (slightly more complex) format for requests and responses is appropriate.
> 
> Based on the preceding analysis, I propose the following requirements for DPD and DVP protocols, based on the assumption of ASN.1 aware clients. Remember that the protocol specs will encompass not only the syntax of the bits on the wire, but also the processing that will be performed by clients and servers.
> 
> Unless otherwise qualified, he following requirements are proposed for both DPD and DPV protocols:
> 
> Client requirements:
> 
> 1.1 A client request can contain a single certificate or a certificate chain terminating in the "target" certificate, to assist the server in path construction.
> 
> 1.2 A client request can contain one or more revocation data items, to assist the server in path validation.
> 
> 1.3 A client request to a DPV server can specify the time relative to which the validation is to be performed. If omitted, the current time is assumed.
> 
> 1.4 A DPD client request must be able to specify whether only CRLs, only OCSP responses, or either, are acceptable forms of revocation status data to be returned. (We could apply this requirement to DPV requests as well, if the content of returned, substantiating evidence for non-repudiation needs to be similarly constrained.) [Shall we also allow the request to also impose constraints on the forms of OCSP responses that are acceptable, by type, and if the basic type is specified shall we require an ability to specify a time before which a pre-produced OCSP response is considered too old?]
> 
> 1.5 A DPV client request must be able to specify whether a certification path and revocation status data, plus a TSP response (for each returned certification path and revocation data set) should be returned by a server, in support of non-repudiation.
> 
> 1.6 A DPD client request must be able to specify whether a TSP response should be returned by a server (for each returned certification path and revocation data set), in support of non-repudiation.
> 
> 1.7 A client request must be able to specify validation processing parameter values both via reference to policies configured at a server and via specification of values for individual parameters. If no policy is specified and no parameters are specified, a default parameter value set, configured at the server, will be employed. If a policy is specified but no parameter values are specified by the client, then the parameter values associated with that policy are employed. If only client-supplied parameter values are present in the request, then they are employed. Any parameters not specified by the client will be supplied by the default set configured in the server. Also, if any of these default parameters are marked as not capable of being overridden by user-specified parameter values, then the default parameter values shall be employed. If a policy is specified and there are client-supplied parameter values, the policy is employed to select parameter values, and then the
> user-supplied parameter values are applied, overriding the policy-specified parameter values, except for any policy-specified parameters that are marked as not subject to user override. [whew!]
> 
> 1.8 Either the request/response protocol itself, or a specified lower layer protocol to be employed for requests and responses, there must be a provision for data origin authentication and connectionless integrity for requests and responses, and responses must be matched to requests. Request authentication & integrity is needed to support access control to the server, a requirement for public servers. Responses must be authenticated and integrity-protected to ensure that they are from the indicated server, and matched to the request in question. Additional security services may be offered optionally.
> 
> 1.9 The client must be able to query a server and request path validation policy parameter values for any policy configured on the server. The client must be able to specify policies by an ID (e.g., an OID) or to refer to the default policy. [A standard will have to specify the policy ID format.]
> 
> Server Requirements:
> 
> 2.1 A server must be able to process client requests invoking any of the features defined above for clients. Thus it must implement RFC 2459-compliant certificate validation procedures in support of both DPD and DPV. The path discovery process implemented by a DPD server operates under the same set of controls as path validation, and thus a DPD server returns paths only if they are valid with respect to the specified path validation parameter values.
> 
> 2.2 A server must be able to return one or more sets of certification paths and associated revocation data as a result of path discovery/validation. Each set shall consist of an ordered list of certificates and associated CRLs and/or OCSP responses.
> 
> 2.3 A server must be capable of returning a time stamp response (consistent with the TSP RFC that will soon be issued) covering each returned certification path and revocation data set. (See 1.4 & 1.5 above)
> 
> 2.4 A server must be configurable to support multiple sets of path validation parameters, each identified by a policy identifier. One such set, which must include values for all validation parameters, must be designated as the default policy. Each parameter in any policy must be capable of being marked as not subject to override by corresponding, client-specified parameters. (It is TBD whether the default policy supercedes other configured policies if there are conflicts in parameters that are marked as not being subject to override.)
> 
> 2.5 The means by which validation policy parameter values are configured will not be part of the standard.
> 
> 2.6 A server must be able to access both LDAP servers and OCSP servers in support of path discovery and revocation data acquisition.
> 
> 2.7 A server must be able to respond to a request from a client for the path validation policy parameters for the default policy, or for any identified policy. However, a server may impose access controls with regard to such requests so that it may reject a query if the client is not authorized to invoke the path validation policy in question.
> ------------------------------------------------------------------------------------------------------------------
> 
> My examination of both SCVP and the proposed OCSPv2 extensions suggests that neither meet the strawman requirements I set forth above. Of course, the WG also has to review these requirements and determine if there is consensus on them, or if they need to be modified (pruned or extended). The time table in my pre-Christmas message says that we have the next moth to reach closure on this.
> 
> Finally, one criteria for selecting a standard which seems important to many WG participants is the complexity of the client and server implementations. Arguments about simplicity based on extending an existing protocol are not objective in the absence of substantiating data. Thus, to create a level playing field, all proposed protocols must be accompanied by algorithmic descriptions of the processing by both client and server. Remember that a protocol is not just the syntax of the bits on the wire, but also encompasses the processing and semantics associated with the protocol. I have tried to allude to aspects of such processing in the requirements above, but more work remains. IETF standards have often failed to do a good job in this regard. Our recent experience with varying interpretations of OCSP (v1) responses demonstrate the importance of such specification. The level of detail required here is open for discussion, but it must be sufficient to allow WG members to create
> independent, interoperable implementations, and to allow prospective evaluation of the relative complexity of each candidate.