Re: DPD & DPV requirements

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Steve,

See my responses embbeded with your comments.

> Denis,
> 
>      Steve,
> 
>      First of all, many thanks for posting this long document.
> 
>      I will not respond using directly your text, since my arguments
>      are fairly different. I will however re-use some of your arguments.
> 
>      Let us use the concept of "validation policy", that you introduce, which is
>      all the set of rules to be followed when validating a certificate. It will
>      usually not simply be the rules mentioned in RFC 2459, but these rules with
>      additional conditions. Note that in the context of electronic signatures, a
>      "signature policy" is a specific example of a "validation policy".
> 
 
[Steve]

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


[Denis]

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

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

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

 
>      DPV
>      ===
> 
>      Let us start with DPV first. A DPV client will not necessarily be either
>      PKI-aware, nor ASN.1 aware. I thus see two flavors for a DPV protocol:
> 
>      1) one not using ASN.1 (e.g. using XML),
>      2) one using ASN.1.
> 
>      In both cases the client only supplies an unambiguous reference of the
>      certificate (CA name, serial number and a hash of the certificate) or the
>      certificate itself and specifies the rules to be followed to validate the
>      certificate: an identification of a pre-defined "validation policy" (e.g. an
>      OID and/or a URL to find the policy and a hash of that validation policy).
> 

[Steve]

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


[Denis]


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

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

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

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

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

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

[Steve]

Incomplete validation is a reasonable response. 

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

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

[Steve]

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


[Denis]

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


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

[Steve]

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

[Denis]

We should remove the time stamp option.

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

[Steve]

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


[Denis]

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

:-)

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

[Steve]

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


[Denis]

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

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

>      This means that, not only I do not agree with a common list of requirements
>      for both DPV and DPD, but also that I do not agree with many of the
>      requirements that you listed:
> 
>      For a DPV client:
> 
>      1.1. Only a single certificate should be allowed.
>      1.2. No revocation items should be allowed.
>      1.3. No request in the past should be allowed.
>      1.4. Imposing constraints for CRLs or OCSP responses should be hidden
>      under the "validation policy" that is selected.
>      1.5. and 1.6. Time stamped responses, if needed, should not be part of the
>      service.
>      1.7. Validation policies are not necessarily "configured at the server",
>      but can simply be pre-defined, outside the server. I any case, the
>      rules that has been followed - i.e. "validation policy" - must be
>      indicated in the response.
>      1.8. For DPV, responses must be signed.
>      1.9. The policy ID format can/will be specified in the protocol.
> 
>      For a DPV server:
> 
>      2.1. A DPV server, will have to do more than RFC 2459, hence why the use
>      of a validation policy is needed.
>      2.2. An opaque blob MAY be returned.
>      2.3. Time stamping is not needed.
>      2.4. The concept of policy overriding is too complex: a reference to
>      a validation policy is sufficient.
>      2.5. No comment.
>      2.6. A server must support LDAP for certificate fetching, and EITHER CRL
>      fetching OR OSCP (OCSP should not be mandatory).
>      2.7. No comment.
> 

[Steve]

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

[Denis]

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

>      DPD
>      ===
> 
>      Let us continue with DPD. I agree in general with many of the requirements
>      that you listed in that case. In particular, since a DPD client must be both
>      PKI-aware and ASN.1 aware, the protocol should only be described in ASN.1.
> 
>      The major difference with the previous protocol is that no evaluation of the
>      returned chain needs to be done, since the client is supposed to be able to
>      perform all the checks himself. Therefor no validation status is returned by
>      the server.
> 


[Steve]

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

[Denis]

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

 
>      The service is more a single place for shopping all (?) the needed
>      certificates and revocation status information.
> 
>      In the request, the client could either specify a validation policy or the
>      trusted points with, for each level of the chain, the indication whether
>      CRLs or OCSP responses are requested.
> 
>      One or more chains, corresponding to the request may be obtained.
> 
>      The response does not need to be signed, but only protected by a combined
>      integrity and data origin authentication service.
> 
>      CONCLUSION
>      ==========
> 
>      We could support three protocols:
> 
>      1° DPV in XML,
>      2° DPV in ASN.1,
>      3° DPD in ASN.1.
> 
[Steve]

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

[Denis]

Two remarks:

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

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

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

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

[Steve]

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

[Denis]

Agreed.

 
>      Before going at the technical details, it is important to raise the
>      following question: which combination(s) of the three basic requests (OCSP,
>      DPV and DPD) could make sense ?
> 
>      If a client requests DPV, then it does not care about OCSP and neither on
>      DPD (multiple certification chains to be tested).
> 
>      For a PKI-aware client, only OCSP + DPD makes sense.
> 
>      This means that :
> 
>      1) DPV does not need to be supported by OCSP.
>      2) The only protocol to be piggy-backed to OCSP would be DPD.
> 

[Steve]

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

OK. Let me try to explain more:

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

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

"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

> Steve