Subject: DPD DPV comparison

From: Peter Sylvester <[email-masked]>
Date: Thu, 26 Jul 2001 16:41:32 +0200 (MET DST)

I would like to try a comparison of the various
attempts to make so-called DPV/DPD protocol(s).

- DPV and DPD from Denis Pinkas

  It adds a lot of details about what should be requested and returned. The
  text references a lot of data structures from an ETSI text about electronic
  signature formats. The referenced text has been presented as an informational
  text to the S/MIME group, and does not have received much discussion in the
  S/MIME group. 
  
  The formats contain some ASN1 errors and unmotivated spec, e.g. why 
  default tags EXPLICIT. 

  DPV/DPD uses CMS to secure req/resp data units.

- DVP and DVD strawman from Steve Kent (IETF 50 slides)

  somewhat a pity that this didn't make into a draft.

  It shows *TWO* protocols. 

  An approach of just specifying syntactical elements.
  Although the names of elements in the protocol units seem to
  be self explaining, this may leads obviously to a false discussions
  about elemnts in the syntx and not about the service that carry. 
  
  It uses its own format to secure responses for integrity, similar to
  X.509 certificates. 

- DVP and DVP requirements from Denis Pinkas (50 IETF)

  Approach to define goals is good. There are some minimal goals defined,
  it isn't clear whether there is an agreement on that. not much
  discussion on the PKIX list so far.  
  
- OCSP-v2
  
  OCSP in general is a very general protocol with several layers in the
  requests and responses. The ability of adding almost everything in a three
  layer protocol unit structure by using different oids etc may be tempting
  to use it as a framework for many things.
  
  But: It required changements in the basic definitions of return values to fit
  for DPV and DPD (as far as I remember). 

  OCSP-v2 uses its own format to secure responses for integrity, similar to
  X.509 certificates.   

- SCVP

  This has made several ways: The format of messages has changed several times,
  (remember binary, XML, X509 SIGNED like, PKCS7 ...)

  The mixture of DPV and DPD features seems to complicate the request structures.
 
  SCVP provides a 'service description', this seems to be a good feature,
  in fact this allowed to be implementable in different formats. 
  One might conclude that the most important point in SCVP is the
  the attempt to make a service definition.

  SCVP specifies *TWO* protocols but in a very hidden way.  

  SCVP now uses CMS to secure data units. 

  It includes a small reminder of how a signeddata is filled with 
  unmotivated profiling (e.g., why just one signature or else.)

  Still letf-overs from previous versions and other probably unnecessary text
  (e.g., decription of 'Extension', Signeddata)

- DVCS
  
  This is RFC 3029: I pretend that it handles essential requirements of DPV.
  In mail from 19 january 1999 denis pinkas discussed some requirements for
  signature and certificate validation, it seems that the initial editor
  responded in favour in the sense that they are supported. 
  
  DVCS is pretty simply regarding the possibilities for asking for different
  ways to respond. The only parameter to control the amount of work to be 
  done is the 'policy'. This seems to be sufficient since the number of
  different behaviours seems very limited anyway. 

  The basic approach is that the question to the DVCS server is held as
  simple as possible, basically: Tell what You think about this certificate++
  under the policy xx. (++ means adding some additional hints about chains or else)

  DVCS make no provision for any DPD processing.

  DVCS responses can be validated using DVCS (long term validity).

  DVCS allows several types of relaying the request.

  DVCS used CMS to secure requests and responses.

  DVCS provides for incomplete answers and allows for multiple
  answers to be send asynchronously. 

--- Some observations/conclusions

- It seems to me that the actual debate stated when the first scvp
  definition came out. The document proposed *one* combined
  protocol for DPV and DPD (it doesn't use this terminology).

- There were two earlier protocols that address part of the problem:
  OCSP : *can* be interpreted as some part of DPV processing.
  DVCS: The protocol contained from the very beginning a specification
  for validation of public key certificates. 

- DDV and DPD requirements had been discussed in a very controversal way.
  There are *still*/*more and more* indications that these are *TWO*
  protocols:

  - OCSP-v2 specifies TWO protocols. 
  - The DPV/DPD draft from D.Pinkas specifies two protocols
  - strawman from Steve kent defines two different request/response pairs
  - Some people are saying that features of DPD requirements/protocols
    are either not well understood or not complete (This is my interpretation
    of messages positively filtered by my brain.)
  - some people have asked since years that OCSP is not sufficient, a
    positive assertion protocol was necessary. DCS (nows DVCS was an answer to DPV 
    already years ago). I can claim that RFC 3029 implements the essential
    requirements of DPV, i.e., let DPD *to be done* 

- Most protocols seems to concentrate on validation of certificates of certificates
  used for signatures. 
       
- All protocols use HTTP or HTTPS as underlying transport. It seems that this
  feature can easily folded out. 

  Several protocols use CMS as a container for requests and responses. OCSP-v2 and
  Steve kent's stawaman protocol are exceptions. 
  
  It seems that HTTP, HTTPS and CMS seems to be an appropriate method to transport
  whatever request/response format we need. 

  Requests and responses in an CMS envelope have different OID types.

  Concerning DPV, the protocols that use CMS have slight differences in the
  request and response format. 

- Most response formats are close, it shouldn't be very difficult to
  get a common format. 

- The requests are a little bit more difficult to handle. It is not clear whether
  the flexibility that is provided by some protocols is actually necessary
  to make a DPV. Prtocols Allow for different degrees to provide
  the end certificates, intermediate certs, hints, trust anchors, crls or else.

- A CMS secured response using SignedData has the obvious advantage that it
  can be validated like any other signed document in CMS format, both immediately
  and on long term.  
  
- Requests (and responses) for DPD seem to be still controversal, concerning
  the formats and the security requirements. It could be argued that DPD should
  be simply impemented as some kind of LDAP search and not as yest another 
  layer.  

---

The n-th proposal on how to continue:

  divide and conquer :
  - separate requirements for DPV and DPD.  

    DPV:
    - transport and how to secure it (e.g. HTTP and HTTPS)
	Very little is said about how to find 
        and to authenticate them (before sending a request).
 
    - how to secure a basic data unit (request and response).
        The CMS or ESS profiles seems to need some work if this
        would be the common format.
        reuse of answers in other elements, e.g., use in attributes
        of other signeddata. 
        how to validate the response *now* and mayebe longterm.

    - provide a service definition 
        use some SCVP stuff, transform requirements into services

    - define/take a request/response format.
        - decide on the degree of flexilibity in requests
        - define a structure for the output. 
          - how to include safe time together with the data
          - how to reference parts of other evidences. 

    DPD: I leave this to someone else. 

The ultimate proposal: Just give up and let the W3C do the work. 

I hope that this contribution helps a little bit.

Of course, I can be considered simply as suffering from psychological projection.

And, the comparison is far away from being complete. I am not really motivated to
resume all the different contributions to the issue during the last 4
years, i.e. discussions about OCSP, D(V)CS, SCVP, DPV/DPD etc.

Peter Sylvester