Subject: Re: DPD & DPV requirements

From: Denis Pinkas <[email-masked]>
Date: Tue, 02 Jan 2001 11:50:05 +0100

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.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 5 Jan 2001 16:10:33 -0500

Denis,

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

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

>not yet available at the time of processing and a later attempt might

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.

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

>OCSPs needed for each certificate from the path).

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

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

>certificate, that might help to construct the path or the revocation

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.

>      fetching OR OSCP (OCSP should not be mandatory).

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

>perform all the checks himself. Therefor no validation status is returned by

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.

>integrity and data origin authentication service.

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

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.

>    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

---

From: Rich Salz <[email-masked]>
Date: Fri, 05 Jan 2001 20:29:28 -0500

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

It would be nice if some other folks got their lawyers to check about
infringement against that d--n Micali patent I mentioned here some weeks ago.
	/r$

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 08 Jan 2001 13:18:32 +0100

Steve,

See my responses embbeded with your comments.

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

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.

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

>      not yet available at the time of processing and a later attempt might

[Steve]

Incomplete validation is a reasonable response. 

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

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

>      OCSPs needed for each certificate from the path).

[Steve]

[Denis]

We should remove the time stamp option.

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

:-)

>      certificate, that might help to construct the path or the revocation

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

>      fetching OR OSCP (OCSP should not be mandatory).

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

>      perform all the checks himself. Therefor no validation status is returned by

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

>      integrity and data origin authentication service.
[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.  

>      ADDITIONAL QUESTION

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

>      2) The only protocol to be piggy-backed to OCSP would be DPD.

[Steve]

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

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

Denis

---

From: Stephen Kent <[email-masked]>
Date: Wed, 10 Jan 2001 12:43:40 -0500

Denis,

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

>The idea is to be able to use ESSCertID without the need to fetch the

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.

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

>contains a blob of what has been used, that can be blinding copied and

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.

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

>We should remove the time stamp option.

Yes, we could.

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

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

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.

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

>(more probably revovation information, but also certificates ?) may be

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.

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

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

>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

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 15 Jan 2001 15:05:13 +0100

Steve,

I have seen an avalanche of messages on that topic, but let me reply to your
message which is not that old.

[Steve]

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?

[Denis]

This would be quite an artificial way to do this, and more complex than
simply adding the elements to define the policy and naming constraints. The
proposal is simply to define the policy constraints and the name
constraints. Take a look at the document being progressed in the S/MIME WG
which defines a validation policy format for non repudiation: Electronic
Signature Policies <draft-ietf-smime-espolicies>

[Steve]

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.

[Denis]

You say "that providing anything other than the target cert per se has
potential problems and adds complexity to the server". However, you do not
provide arguments to support this statement. Let us take one example of use:
someone wants to checks whether a CMS structure is well signed. Such a
client is certainly ASN.1 aware since the CMS structure is described in
ASN1, but is not necessarily PKI aware.

Fortunately, the CMS structure contains two important data structures and
some "useful" attributes. The client may be able to collect the content of
these data structures or attributes. He may then pass each content *as a
blob* to the server. 

The CMS structure is the following:

      SignedData ::= SEQUENCE {
        version CMSVersion,
        digestAlgorithms DigestAlgorithmIdentifiers,
        encapContentInfo EncapsulatedContentInfo,
        certificates [0] IMPLICIT CertificateSet OPTIONAL,
        crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,
        signerInfos SignerInfos }

Candidate data structures to be passed as *optional* parameters are:

1. the CertificateSet,
2. the CertificateRevocationLists.

Candidate useful unsigned attributes to be passed as parameter are:

1. the Other Signing Certificate attribute 
[defined in <draft-ietf-smime-esformats>],
2. the Complete Certificate Refs attribute 
[defined in <draft-ietf-smime-esformats>],
3. the Complete Revocation Refs attribute 
[defined in <draft-ietf-smime-esformats>],

As a summary:

A. When providing either a reference to a certificate or a list of
certificates that *might* be useful for the server, we have four options:

1. the Other Signing Certificate attribute 
[defined in <draft-ietf-smime-esformats>],
2. the CertificateSet,
3. the Complete Certificate Refs attribute 
[defined in <draft-ietf-smime-esformats>],

B. When providing revocation information that *might* be useful for the
server, we have two options:

1. the CertificateRevocationLists,
2. the Complete Revocation Refs attribute 
[defined in <draft-ietf-smime-esformats>]

If we address the problem this way, then I can agree that a DPV client may
pass these parameters while still being PKI-ignorant. You will notice that
this is a move from my initial position.

> Yes, it will have to be one of the responses, hopefully with an explanation of what caused the response to be incomplete.
> 
>      [Denis]
> 
>      :-)
> 
>      [Steve]
> 

[Steve]

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.

[Denis]

I would rephrase your wording as :" Make sure that a DPV client can be used
by a PKI-ignorant client".

[Steve]

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.

[Denis]

So, let us wait and see ...

[Steve]

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.

[Denis]

Up to now, there has been one other message posted to the list, asking for
the TSA removal.

[Steve]

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.

[Denis]

I agree with you that "we already have application protocols where a client
that is not PKI-aware might acquire cert paths and/or revocation data that
he could pass on to a DPV server." The S/MIME example I provided is one such
example. However, this would mean that each blob able to contain such cert
paths and/or revocation data would have to be passed "as it is", i.e.
without being opened by the application. I made the list of such data
structures for three documents from the S/MIME working group. If we proceed
in that direction, then we should ask the other working groups (e.g. IPSEC,
TLS) to provide us with a list of the data structures that are relevant. If
this list is not too large, then it could make sense to support all of them,
otherwise, we would have to consider that this is not practical.

If you agree with this idea, it could be interesting that we raise the
question to the other working groups.

[Steve]

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.

[Denis]

The resolution on that point is pending the result of the number of "blob"
data structures that would need to be supported for:

a) certificate(s) or certificate references that *might* be useful for the
server,
b) revocation information that *might* be useful for the server.

[Steve]

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.

[Denis]

If the request parameters are "coarse" (e.g. no naming constraints or no
certification policy constraints), nothing would prevent the server to find
more than one acceptable certification path.

[Steve]

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.

[Denis]

A DPD client is supposed to be both ASN.1-aware and PKI-aware, so he may
format the cerths and the revocation data that he already got from the
application protocols in any desired way. The same assumption does not
necessarily stand for a DPV client that might be ASN.1-aware but would be
PKI-ignorant.

[Steve]

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

[Denis]

It is what I said. So we strongly agree. :-) If the OCSP response is part of
the blob, then it is no more directly visible. To this respect the
individual OCSP response that is indeed returned is of no interest anymore
since it is part of the revocation data blob. 

[Steve]

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? 

[Denis]

Yes, I mean this. 

[Steve]

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.

[Denis]

Good ! Since the later combination is, using your terminology, "less
plausible", I do not see why we should support it, taking into consideration
one further argument: the caller may be ASN1-ignorant (and XML-aware). In
such case it is not possible to piggy back the DPV protocol on top on an
ASN.1 protocol.

This means that there is no need to piggy back the two protocols (i.e. OCSP
and DPV) ... unless more information than simply revocation status data is
returned. OCSP *theoretically* allows to carry extensions. We have observed,
by experience, that different people had different interpretations on how
such extensions would work. :-(

At this point of time, I would imagine that DPV would also be able to carry
some extensions, e.g. to ask some additional information on the account of
the leaf certificate holder. We should take great care on how such
extensions would be supported.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 17 Jan 2001 14:10:15 -0500

Denis,

Your message is really too big, so I'll trim it in my response, with 
the attendant possibility that I'll through away some context that 
will later cause confusion, ...

><snip>

I don't think of it as artificial at all. Cross certification is a 
standard way to create links between PKIs, and to express constraints 
on these links. It has the advantage that path validation can be 
applied uniformly rather than having to treat each trust point 
specially, associating name and policy constraints etc. via special 
means. But, I'm not hard over on this.

><snip>
>provide arguments to support this statement.

Any means of referring to a cert, other than providing the cert, is 
problematic. For example, issuer name and serial number is ambiguous 
because we can't guarantee uniqueness of issuer names. A hash of a 
cert fails to help me locate the cert if I can't find it in a local 
cache. A subject key identifier has a similar problem.  We had 
similar discussions re certificate references in the attribute 
certificate realm.

Your example does not seem to address this concern, or maybe we're 
just miscommunicating on another level.

><snip>

OK.

><snip>

I'm not seeing any support for retrospective queries, so I think we'll drop it.

><snip>

OK, done.

><snip>

Good points. I have glibly discussed having these apps pass in certs 
and CRLs, but without taking into account the implications of this 
model. If we agree to support  data structures from these protocols, 
then we make life easier for these clients, but servers have to be 
aware of each distinct data structure.  We might standardize on a 
few, common formats now in use, and encourage future apps to make use 
of these structures, while still providing tags to identify them and 
thus accommodate new structures if needed.

><snip>

yes. see comments above.

><snip>

But these multiple paths should each be complete, not partial, 
relative to whatever constraints were established.

><snip>

If we adopt a small set of data structures for passing certs and CRLs 
(and maybe OCSP responses), then why can't DPD clients use the same 
structures? If so, then the ASN.1 protocols (2 & 3) look a lot alike. 
Anyway, I don't think we should devote too much more energy to this 
discussion, for 2 reasons. As I mentioned in responses to other 
messages this week, if we want to have different request/response 
formats for DPV and DPD (in ASN.1), then I'm comfortable doing that, 
even though I bet we'll see quite a bit of overlap in arguments. 
Paul's message suggests that we not mandate non-ASN.1 (e.g., XML) 
support  in DPV for now, so that we can make progress more quickly 
here. These two observations suggest that we don't need to argue 
about the similarities or differences for the 3 protocol cases you 
described.

><snip>

OK.

><snip>

OK.

>extensions would be supported.

I always worry about extensions in protocols, as they create 
opportunities for vendor-specific functions that result in 
non-interoperability. if we have an extension facility I would want a 
criticality flag analogous to v3 certificate extensions. If I had my 
druthers, I would not provide extensions but would insist on new 
version numbers as we add protocol features and change syntax.  But, 
you can't always get what you want ...

Steve

---

From: Steve Hanna <[email-masked]>
Date: Fri, 19 Jan 2001 16:18:35 -0500

I would like to second Steve Kent's comments against associating name
constraints with trust anchors. We need to balance flexibility and
complexity here, I believe.

Most users never tweak their trust anchors. They don't even know what a
trust anchor is. In most cases where trust anchors are modified from the
default, the set of trust anchors is configured by an administrator. For
the administrator who wants to configure a partially trusted CA (with
name constraints), the simplest and best solution is for the
administrator to establish his own CA, issue a cross-certificate to the 
partially trusted CA (with name constraints), and configure the
administrator's CA as the trust anchor. This allows the administrator to
modify the set of trusted CAs and the limits placed on that trust ad
infinitum without requiring the application's trust anchors to be
reconfigured (which is often painful).

Associating name constraints with trust anchors adds needless complexity
to application code and user interface. Added complexity increases the
likelihood of bugs and security holes. And this is a slippery slope.
Today, we want name constraints with each trust anchor. Tomorrow, policy
constraints. Then policy mapping. Imagine the user interface for that.
We already have a format for expressing these constraints. It's called a
cross-certificate. Let's not reinvent the wheel.

-Steve

---

From: Russ Housley <[email-masked]>
Date: Fri, 19 Jan 2001 17:02:57 -0500

I agree.  If were were to add any capability, I would consider an input to 
the path validation algorithm that allowed a user to provide name 
constraints.  There is already an input parameter for acceptable policies.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 22 Jan 2001 13:01:27 +0100

Denis,

[Denis]

I will do the same. :-)

Since we now understand much better each other, I will not reproduce all the
issues we agree on. I will answer to one of your questions and comment on 
one issue on which we both agree.

In order to progress, I suggest that we try first to agree on the goals.
Here is a proposal.

DPV goals: 

Validate a leaf certificate according either to a validation policy or one
(or more ?) trust anchor (public key value, CA name and optionally a
validity period) including CP and naming constraints. 

Obtain a signed " yes, no or incomplete " answer to the question together
with the date of validation.

Optionally provide a replay protection if no time is available on the
client.

Optionally obtain the evidence to support the yes answer 

Note 1: A complete certification path is one that satisfies all of the
validation criteria specified in RFC 2459bis and that terminates at a trust
anchor (public key value, CA name and optionally a validity period) that may
include Certification Policy constraints as well as naming constraints.

Note 2 : if a "ValidationPolicyRef" parameter or the trust anchor is missing
in the request, then the server will return back either the
ValidationPolicyRef that has been used or alternatively a description of the
validation policy or of the root key that has been used.

Note 3 : In order to be able to store the yes /no answer in one place
without the need to store the evidence (that may be quite big) in the same
place, it is proposed to include the hash of the evidence in the signed
answer. This does not augment too much the size of the answer while
providing integrity protection without the need of a second digital
signature. 

DPD goals:

Obtain one or more certification paths and optionally its associated
revocation information for a leaf certificate according either to a
validation policy or a trust anchor.

Optionally specify naming and CP constraints.

Provide a replay protection (no date is necessary).

Note 1 : Either a full certification path is returned or nothing (no
certification path nor revocation information).

Note 2 : When a full path is found, all the associated revocation
information is not necessarily found. However, the revocation information
that has been found is returned.

Note 3 : For one element of the path, both a CRL (or base CRL and delta) and
an OCSP response may be returned (if both exist) as associated revocation
information.

Note 4 : if the validation policy or a root key (public key value and CA
name) is missing, then the server will designate in the response the default
validation policy or root key or the self-signed certificate that has been
used.

Note 5: each path starts with the leaf certificate (or its reference) and
ends up either with a self-signed certificate or a root key associated with
a CA name.

Note 6 : When only the reference of the certificate is provided in the
request (i.e. ESSCertID) and when requested, the server may include the leaf
certificate in the returned paths.

Note 7: in case full revocation information is not found, the client may
send back (using the sequence of useful certificates and a sequence of
useful revocation information) one of the certification path and the
associated revocation information that he got, in order to try to obtain
more revocation information. This avoids to have a stateful server. 

If we can agree on these goals, then I am ready to send a detailed proposal
for the input and output parameters for each protocol.

Let me now answer to one of your questions and then comment on another one. 

1. [Steve]

[Denis]

When you use ESSCertID (defined in RFC 2634), it does address your concern,
since ESSCertID may carry both the properties you mentioned: issuer name and
serial number (to locate the certificate) but also a hash of a cert (to make
it unambiguous).

2. [Denis]

>he could pass on to a DPV server." The S/MIME example I provided is one
>such example. However, this would mean that each blob able to contain 
> such cert paths and/or revocation data would have to be passed 
>"as it is", i.e. without being opened by the application. I made the list 
> of such data structures for three documents from the S/MIME working 
> group. If we proceed in that direction, then we should ask the other 
> working groups (e.g. IPSEC, TLS) to provide us with a list of the data 
> structures that are relevant. If this list is not too large, then it could 
> make sense to support all of them, otherwise, we would have to 
> consider that this is not practical.
>

[Steve]

[Denis]

We both agree. So would you be sending such a request on the IPSEC and TLS
mailing lists ?

Regards,

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 22 Jan 2001 17:52:39 +0100

Russ,

> constraints.  There is already an input parameter for acceptable policies.

This is fine for DPD.

The next question is : is this also fine for DPV ? 

Not sure, some validation policies may request some (even private)
extensions in the leaf certificate to be present for a certificate to be
"valid" according to a validation policy. Hence a response "valid", should
be interpreted as a minimum condition to be valid, but not always as a
sufficient condition. We would have to be very careful when explaining what
a "valid" status means.

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 22 Jan 2001 18:16:20 +0100

> constraints.  There is already an input parameter for acceptable policies.

I would like to second Russ Housley's comments above for associating name
constraints with trust anchors. Without naming constraints we would get
security threats that would imply global trust, which is not a real life
situation. If other words, I want to be able to detect when company X
certifies a name from a user (or entity) from company Y, and when this is
not allowed.

Denis

---

From: Stephen Kent <[email-masked]>
Date: Mon, 22 Jan 2001 18:31:18 -0500

Denis,

>validity period) including CP and naming constraints.

yes

>with the date of validation.

yes

>Optionally provide a replay protection if no time is available on the

I would say that replay protection is necessary, period. The question 
is whether the protocol will meet this requirement via nonces or some 
other mechanism.

>Optionally obtain the evidence to support the yes answer

I think it is a client option to request evidence, but a server MUST 
be able to provide the evidence.

>include Certification Policy constraints as well as naming constraints.

yes, plus any other validation parameters defined by 2459bis.

>validation policy or of the root key that has been used.

yes, from the configured, default policy

>providing integrity protection without the need of a second digital

this is getting a bit detailed to be a goal, but I agree with the motivation.

>validation policy or a trust anchor.

As above, this may be a client option to request, but a server must 
be prepared to provide the revocation status info.

>Optionally specify naming and CP constraints.

I assume the same set of constraints as for DPV, right?

>Provide a replay protection (no date is necessary).

Necessary.

OK.

>that has been found is returned.

No. I want the path to be valid, and if the server can't provide the 
revocation status info, then it does not know if the path is valid.

>an OCSP response may be returned (if both exist) as associated revocation

For EACH (not one) element ...

>validation policy or root key or the self-signed certificate that has been

right, see note above re point Note 2 under DPV.

>ends up either with a self-signed certificate or a root key associated with

each path ends with a trust anchor

OK.

>more revocation information. This avoids to have a stateful server.

The strawman spec already allows the client to submit a set of certs 
and revocation status data so this is an unduly narrow 
characterization.

>for the input and output parameters for each protocol.

we're getting closer, but I see most of these "goals" as a subset of 
or refinement of the strawman spec. I don't want to reduce the scope 
of that spec to the subset required above. also, I've seen some 
comments suggesting that optional support for post-facto validation 
for DPV is desirable.

>serial number (to locate the certificate) but also a hash of a cert (to make

Good point. IF we adopt that structure, it would avoid the problems I 
noted above.

>We both agree. So would you be sending such a request on the IPSEC and TLS

Yes.

Steve

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 23 Jan 2001 10:16:23 +0100

Steve,

Thanks for your detailed answer. We now mostly agree. See a few comments
below.

> is whether the protocol will meet this requirement via nonces or some

O.K. 

> be able to provide the evidence.

O.K.

> be prepared to provide the revocation status info.

O.K.

> I assume the same set of constraints as for DPV, right?

Right, while I would expect a DPV client either to reference a validation
policy or look if the used policy is acceptable, rather than specifying in
detail that validation policy.

> revocation status info, then it does not know if the path is valid.

We have a slight disagreement here. You accepted the goal which is: "Obtain
one or more certification paths and optionally its associated revocation
information for a leaf certificate according either to a validation policy
or a trust anchor.". In that sentence, the word "valid" does not exist. In
other words, DPD only *helps* a PKI-aware client to know whether a
certificate is valid. It is better to return what can be returned as far a
revocation information is concerned rather than nothing. You also noticed
that a client may only request the certification path, without the
revocation information.    

> For EACH (not one) element ...

Correct.

Yes.

> comments suggesting that optional support for post-facto validation

This topic is being discussed on another thread and is still open.

Denis

Note: No more comments below.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 23 Jan 2001 12:14:55 -0500

Denis,

>sufficient condition. We would have to be very careful when explaining what

Good point. The issue you're getting at here is how far beyond 2459 
do we go in providing explicit controls on validation for DPV, since 
it is not unreasonable for folks to impose such constraints in 
various application contexts.  I think we have some flexibility here, 
but we need to pick a set of parameters and go forward.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 23 Jan 2001 18:32:38 -0500

>that a client may only request the certification path, without the

My oversight.  I still want DPD paths to be valid.

Steve

---

From: Russ Housley <[email-masked]>
Date: Wed, 24 Jan 2001 13:59:32 -0500

One thing that I think we should add to DPD is the ability to mandate the 
presence of a particular name form in the end entity certificate.  For 
example, and IPsec client might want an IP address or DNS name in the 
certificate.  An S/MIME client might want an RFC 822 address in the 
certificate.

Russ

At 12:14 PM 1/23/2001 -0500, Stephen Kent wrote:
>Good point. The issue you're getting at here is how far beyond 2459 do we 
>go in providing explicit controls on validation for DPV, since it is not 
>unreasonable for folks to impose such constraints in various application 
>contexts.  I think we have some flexibility here, but we need to pick a 
>set of parameters and go forward.
>
>Steve
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 24 Jan 2001 14:07:27 -0500

Denis,

>certifies a name from a user (or entity) from company Y, and when this is

I agree with the need for name constraints, and I have been persuaded 
that associating them with trust anchors is preferable to creating 
cross certs.

Steve