Re: DPD & DPV requirements

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Steve,

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

> Denis,
> 
>      Steve,
> 
>      See my responses embbeded with your comments.
> 
>      > Denis,
>      >
>      > Steve,
>      >
>      > First of all, many thanks for posting this long document.
>      >
>      > I will not respond using directly your text, since my arguments
>      > are fairly different. I will however re-use some of your arguments.
>      >
>      > Let us use the concept of "validation policy", that you introduce, which is
>      > all the set of rules to be followed when validating a certificate. It will
>      > usually not simply be the rules mentioned in RFC 2459, but these rules with
>      > additional conditions. Note that in the context of electronic signatures, a
>      > "signature policy" is a specific example of a "validation policy".
>      >
> 
>      [Steve]
> 
>      We need to be explicit about what are the parameters that control path
>      validation. The 2459 validation algorithm has a well-defined set, but if
>      there are others, we need to have them specified and agreed upon. One
>      conversation that took place in San Diego noted that one could imagine a lot
>      of parameters that a user might want to express re path validation, but
>      which have not been standardized, and for which we do not have general
>      agreement. A very rich list of this sort, and the associated complexity that
>      would accompany an enhanced validation algorithm that used thise parameters,
>      was thought to be out of scope for now, more an R&D topic vs. a topic for
>      standardization. So we have to be careful here.
> 
>      [Denis]
> 
>      The current validation algorithm described in RFC 2459 is fine but too
>      restritive. It works fine with a single root key in the case where there are
>      no naming constraints nor Certification Policy constraints, or in the case
>      where there are are included in the (root) self-signed certificates. I have
>      worked with Tim Polk so that in the "son-of-RFC2459" we will have the
>      description of an enhanced path validation algorithm that will take care of
>      multiple roots, each one associated with different naming constraints or
>      Certification Policy constraints - which will not necessarilly be included
>      in the root self-signed certificates.
> 
 
[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>

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

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

 
>      > As a result, the client expects a signed response which reproduces the
>      > requested parameters and includes a status. The status is not simply:
>      > "passed validation", "failed validation", or "don't' know" but can also be
>      > "incomplete validation", meaning that some revocation status information is
>      > not yet available at the time of processing and a later attempt might
>      > succeed.
>      >
> 
>      [Steve]
> 
>      Incomplete validation is a reasonable response.
> 
> Yes, it will have to be one of the responses, hopefully with an explanation of what caused the response to be incomplete.
> 
>      [Denis]
> 
>      :-)
> 
>      [Steve]
> 
>      maybe we should include the
>      set of parameters used for the validation, including ones not supplied by
>      the client, e.g., defaults, or overrides imposed by the server, or the
>      values bound to a policy that was specified.
> 
>      [Denis]
> 
>      We are not on the same track here. I am assuming that a DPV client is PKI
>      ignorant. You are making the assumption that the client MAY simply some
>      elements of the certification path, where I make the assumption that the
>      single element that MAY be supplied in a DPV request is the leaf
>      certificate. For all the other elements of a certification path, the server
>      is supposed to have access to the various repositories. The response
>      contains a blob of what has been used, that can be blinding copied and
>      stored.
> 

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


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

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

>      > If a client is interested in a later proof, then it should obtain that
>      > information from the server at the time the information is still available.
>      > This means that a client should have the possibility to ask the server to
>      > optionally return an opaque blob that contains all what has been used to
>      > validate the certificate (i.e. a certification path and all the CRLs or
>      > OCSPs needed for each certificate from the path).
>      >
> 
>      [Steve]
> 
>      We have this requirement already, with a time stamp option.
> 
>      [Denis]
> 
>      We should remove the time stamp option.
> 
> Yes, we could.
> 
>      > A question arises from the requirements 1.5 and 1.6 that you listed: should
>      > that opaque blob be time-stamped ? If there is a fear that some of the
>      > issuing keys used in the certification path might later on be compromised,
>      > then this can be useful. This case should be very seldom and hence this
>      > service would not always be required. In addition, why should that service
>      > be embedded in this protocol ? This could be obtained using directly the
>      > TSP, leaving more possibilities: free choice of the TSAs, time stamp of the
>      > full blob, time stamp of the certification chain only, time stamp on both
>      > the certification chain and the revocation information. Thus I do not favor
>      > to piggy-back the two services.
>      >
> 
>      [Steve]
> 
>      Yes, one could keep the services separate. I am not hard over on this, and
>      can be persuaded to remove the requirement, or to make server support for it
>      optional.
> 
>      [Denis]
> 
>      If you are not hard on this issue, let us remove the time stamping option.
> 
>      :-)

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


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

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

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

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

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

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

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

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

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

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

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

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

 
> Steve