Subject: RE: The future of DVCS...

From: Michael Myers <[email-masked]>
Date: Wed, 11 Oct 2000 14:47:32 -0700

Chairs:
 
 I offer a second to Carlisle's proposal that the DVCS work effort should be
maintained as proposed.
 
Mike

-----Original Message-----
From: Carlisle Adams [mailto:[email-masked]]
Sent: Wednesday, October 11, 2000 12:40 PM
To: [email-masked]'; [email-masked]'
Cc: [email-masked]
Subject: The future of DVCS...

Hi, 

Over the past year or more, the question has arisen in various contexts as
to the status and role of the DVCS draft, especially with respect to TSP,
OCSP, SCVP, DPV, DPD, and whatever other variations might be incarnated in
the future.

DVCS precedes and, at some level, encompasses all of these other protocols.
However, these protocols -- many of them targeted for the standards track --
have been defined for the twin purposes of simplicity and rapid
implementation.  They are small and clearly defined; each one tries to solve
essentially one problem.  DVCS, on the other hand, is intended to be
general, embracing the sometimes abstract notion of the validation and
certification of arbitrary data.  The actual content of the data (the
payload) in a sense defines the function of the server (i.e., if the data is
a hash of something, then the server is providing a time stamp function; if
the data is a certificate, then the server is providing an OCSP or SCVP/DPV
function; if the data is a contract or legal document, then the server is
providing what (at least in North America) might be called a notarization
function; etc.).  It's not quite as loose as that, but that's the basic
idea.

In discussing this protocol with the other authors and with various members
of the community, I sense "rough consensus" on two things.  Firstly, it
makes sense to allow the more clearly-defined subsets of the DVCS
functionality to be handled by these other protocols (TSP, OCSP, etc.) since
they are relatively well-understood and implementations are already either
completed or underway.  Secondly, most real-world environments are not yet
ready to incorporate notarization functions for other data formats.  This
higher-layer purpose of DVCS is perhaps too early as a concept to engage
serious review and debate within the wider PKIX group right now.

Consequently, the authors of DVCS are recommending to the chairs that this
specification be preserved as an Experimental RFC.  It has received some
discussion (both public and private) over the years, but probably not
sufficient to warrant progression along the standards track.  Furthermore,
we are aware of only a single implementation at this time, so any
interoperability testing is out of the question, at least at the moment.
But enough work has gone into this protocol that letting it expire as an
Internet Draft and disappear completely seems inappropriate, especially if
(as we suspect) this higher-layer functionality will begin to be required in
PKI environments in the one- to three-year time frame.  We would like to see
the specification frozen and preserved for now; it can always be re-visited
later (and even re-targeted for the standards track) if the need arises.

In light of this recommendation, further revisions to this document seem
unnecessary; the authors are satisfied with the text in this -07 version
going to "Experimental" status.

Steve, Tim:  any comments or alternate suggestions? 

Carlisle. 

	---------- 
From:   [email-masked][SMTP:[email-masked]] 
Reply To:       [email-masked] 
Sent:   Friday, October 06, 2000 6:31 AM 
Cc:     [email-masked] 
Subject:        I-D ACTION:draft-ietf-pkix-dcs-07.txt 

	A New Internet-Draft is available from the on-line Internet-Drafts
directories. 
This draft is a work item of the Public-Key Infrastructure (X.509) Working
Group of the IETF. 

	        Title           : Internet X.509 Public Key Infrastructure
Data 
                          Validation and Certification Server Protocols 
        Author(s)       : C. Adams, P. Sylvester, M. Zolotarev, 
                          R. Zuccherato 
        Filename        : draft-ietf-pkix-dcs-07.txt 
        Pages           : 48 
        Date            : 05-Oct-00 
        
This document describes a general Data Validation and Certification 
Server (DVCS) and the protocols to be used when communicating with 
it.  The Data Validation and Certification Server is a Trusted Third 
Party (TTP) that can be used as one component in building reliable 
non-repudiation services (see [ISONR]). 
Useful Data Validation and Certification Server responsibilities in a 
PKI are to assert the validity of signed documents, public key 
certificates, and the possession or existence of data.

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 12 Oct 2000 10:53:36 +0200 (MET DST)

> 
> Carlisle,
> 
> I think your characterization of DVCS vs. OCSP and SCVP is very 
> accurate and I would be very comfortable with moving it to the 
> experimental track. I would like to hear an affirmation from Peter 
> Sylvester on this.

This had been discussed among the author's and we all seem
to be in violent agreement.

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 12 Oct 2000 12:34:32 +0200 (MET DST)

> 
> Carlisle,
> 
> Thank you for posting this E-mail. As explained hereafter, while I agree
> with many of your arguments, I do not share your conclusion.
> 
> > Hi,
> > 
> > DVCS precedes and, at some level, encompasses all of these other
> > protocols.  However, these protocols -- many of them targeted for the
> > standards track -- have been defined for the twin purposes of simplicity
> > and rapid implementation.  They are small and clearly defined; each one
> > tries to solve essentially one problem.  DVCS, on the other hand, is
> > intended to be general, embracing the sometimes abstract notion of the
> > validation and certification of arbitrary data.  The actual content of the
> > data (the payload) in a sense defines the function of the server (i.e., if
> > the data is a hash of something, then the server is providing a time stamp
> > function; if the data is a certificate, then the server is providing an
> > OCSP or SCVP/DPV function; if the data is a contract or legal document,
> > then the server is providing what (at least in North America) might be
> > called a notarization function; etc.).  It's not quite as loose as that,
> > but that's the basic idea.
> > 
> > In discussing this protocol with the other authors and with various
> > members of the community, I sense "rough consensus" on two things.
> > Firstly, it makes sense to allow the more clearly-defined subsets of the
> > DVCS functionality to be handled by these other protocols (TSP, OCSP,
> > etc.) since they are relatively well-understood and implementations are
> > already either completed or underway.  
> 
> I agree that more clearly-defined subsets of the DVCS functionality should
> be handled by these other protocols (TSP, OCSP, etc.) .. but this also means
> that this subset is not the right direction for the long run and thus should
> be deprecated. For that reason, this subset should *not* be placed in an
> experimental RFC. 

I think you are misunderstanding something: We are talking about putting DVCS
as experimental, and we leave it open to take subsets of functionality of
it into other protocols, i.e. to provide some additional building blocks.
 
> 
> > Secondly, most real-world
> > environments are not yet ready to incorporate notarization functions for
> > other data formats.  This higher-layer purpose of DVCS is perhaps too
> > early as a concept to engage serious review and debate within the wider
> > PKIX group right now.
> 
> I also agree. However, this is not an argument for saving this material in
> an experimental RFC either.
> 
> > sufficient to warrant progression along the standards track.  
> 
> I certainly agree that this specification has not received sufficient
> discussion to warrant progression along the standards track.

Thank you for your contributions in the past. Also for thse in this message.

> > Furthermore,
> > (as we suspect) this higher-layer functionality will begin to be required
> > in PKI environments in the one- to three-year time frame.  
> 
> The specification can certainly be saved without being transformed as an
> experimental RFC.

Yes, one could write a book. why are you against an RFC? 

> 
> > We would like
> > to see the specification frozen and preserved for now; it can always be
> > re-visited later (and even re-targeted for the standards track) if the
> > need arises.
> > 
> Hereafter are some more technical comments which related to version 06 (I
> have not read the recently posted version 07)
There are essentially just a few spelling changes. 
 
> The document covers four different services:
> 
> 1. Certification of possession of data,
> 2. Certification of claim possession of identity,
> 3. Validation of a Digitally signed document,
> 4. Validation of a public key certificate.

Have you really read the text, it says:

   - Certification of Possession of Data (cpd),
   - Certification of Claim of Possession of Data (ccpd),
   - Validation of Digitally Signed Document (vsd), and
   - Validation of Public Key Certificates (vpkc).
> 
> Note that, in the following comments, this services are NOT addressed in the
> same order as they are listed above.

> The second service (Certification of claim possession of identity) can
> simply be obtained using directly a Time Stamping server using the TSP
> protocol, by defining the structure of the whole message that must be hashed
> before it is presented to the TSA. So there is no need to define a new
> protocol, but instead to define a data format, which will basically be
> formed by the concatenation of some information that relates to the entity
> claiming the possession of the data (like first name, family name, home
> address, date of birth, place of birth, and any information able to identify
> unambiguously the entity claiming the possession of the data) and the data
> for which the possession is claimed. Note that there is no need to use any
> ASN.1 construct to do this. While it is recognized that this definition
> would be useful, it may be questioned whether this work should be done in
> the PKIX WG or another group.

There is no such thing as 'claim possession of identity'. It's claim
of possession of data.  

Anyway, you are defining something different. 

The difference of the defined service to time stamping is small,
what is provided is a common way to include in the dvc a reference to
the requestor and a reference to the location of the data, and this is visible in the timestamp.

The time stamp essentially becomes a statement like: 

  "We, the DVCS certify that the person identified as requestor is claiming
  to have a document available under the following URL for we he showed
  a hash at date J."

You can obviously achieve this by adding extensions to time stamping.

You are free to define any format describing 'data to be time stamped'
but this is something else IMHO.

> The first service (Certification of possession of data) is defined as being
> similar to the previous one, except that the full message (e.g. Megabytes)
> is transferred instead of a hash. This is not a desirable feature since the
> performance of such a service would be quite low and because the server
> would be able to know the content of the message, which is not desirable for
> several reasons: privacy reasons or when the content is related to IPR.

On the contrary. The server is a notary, archive server, legal depository or
whatever you want to call it. This is a desirable service, there is a trust
relationship between the notary and the client, the transaction is
be protected by ssl or other means.

> 
> The last (fourth) service (Validation of a public key certificate) is
> closely related to remote path processing, a topic that is being addressed
> by two other specifications. There is still the need to have a single
> protocol to cover that functionality since the PKIX WG cannot afford
> multiple protocols for the same purpose.

DVCS is a different protocol than the OCSP++. I refer to a comment from
Michael Myers, who gave a good caracteristics. The protocols are complementary.  

> 
> The third service (Validation of a Digitally Signed Document) is more
> ambitious than the previous service, since every detail of the format of the
> signature itself will have to be known by the server. This goes behind the
> mathematical correctness of all digital signatures, since it is necessary to
> unambiguously know both which certificate has been used to sign the document
> and at which time. 

The client completely delegates the acceptablity of the document to
a server. Actually, it is not even necessary that the document is a signed
document, 

There is the possibility that no validation of a signature occurs
at all, for example if you validate a dvc 30 years ago. The server has at
least two possibilities, verifying signatures, or looking up an archive
of all dvcs issued. This possibility transforms a chain of trust elements
(in time) into a web. A chain can easily break, a web is much more difficult
to break. 
 
> The validation should not be necessarily made against a single root key.
No one says that. The client may have no idea about roots, trust points or whatever,
it is the server that has that knowledge. A client can also
add certs to the signed document which may be taken as hints by the server.  

> When multiple roots are considered, Certificate Policy (CP) constraints and
> naming constraints are fairly important. They should be able to be defined
> by the requester. When revocation status is looked for, there are cases when
> either CRLs or OCSP responses are adequate or only OCSP responses are
> acceptable. The requester should be able to express his wishes.

The point is to have the requestor as a dumb entity, it is the server who
knows what do do in the context of the application expressed
by a policy identifier. The whole trust management occurs at the server side. 

> 
> The document mentions the possibility to verify all signatures attached to
> the document. This level of complexity would mandate a rather complex
> definition of all the parameters to do this. This appear to be a much longer
> term goal.
The protocol only defined a transaction protocol and a certificate format.
The way how the server is implemented is not specified, only the result, the
dvc should contain a complete list of all actions that had been performed.

> Finally there would be two options: either the server testifies that the
> Digitally Signed Document is well signed and simply provides a signed yes/no
> answer, or does more by providing in addition the proof that led to that
> decision.

Both options are provided. A simple yes/no answer may be given for some
application contexts, but in general it is the idea that a dvc contains
not only a decision, but all elements that have been contributed, in
particular if they cannot easily be reproduced. 

> Conclusion
 
> The first two protocols supporting both "Certification of possession of
> data" and "Certification of claim possession of identity" should not be
> defined. A format describing of the document to be time-stamped should be
> defined instead of providing the second service currently called
> "Certification of claim possession of identity".
Possession of data is a useful service. 

I don't accept the 'INSTEAD of providing the'. You can have both since
these are different things. 

> The third protocol supporting "Validation of a Digitally signed document"
> should be restricted to the verification of a single signature. In order to
> simplify the protocol, the parameters to be presented should be restricted
> to the identification of the "Validation policy" to be used (using an OID to
> refer to that policy) and of the signed message. Note that the Validation
> Policy and a certificate policy are two concepts that should not be
> confused. However more information than the information that was presented
> will usually be needed to be returned, in order to get long term validity of
> the signature, in particular a Time Stamp, a certification path and
> certificate status for every element from that certification path. It is
> proposed to wait until the definition of the RPP service ("Remote Path
> Processing") is stabilized before addressing this level of complexity.
All what you ask for is provided. The requestPolicy defines a validation policy.
The DVC itself contains a time stamp, either provided by itself or by
an external service. The certification path, the certification status, and
all other kinds of OCSP repsonses, crls, dvcs are returned.  

> The last protocol supporting "Validation of a public key certificate" should
> be addressed under the current discussion related to "Remote Path
> Processing" (RPP), so that the WG ends up with a single protocol.
PKIX today says that the result of a cert validation is a verifiable
cert chain, the fact that the exact algorithm for path determination, and
the formats of lookups etc is not defined has not stopped X.509 or 2459.
  
> 
> With the arguments raised above, I am *not* supportive to make this
> specification an experimental RFC.
So be it. 

> Denis
Peter

---

From: Tim Polk <[email-masked]>
Date: Thu, 12 Oct 2000 13:39:44 -0400

Carlisle & Denis,

Like Steve, I am comfortable with moving this to Experimental.  I think 
DVCS has run its course, but I don't want to lose the ideas that were 
incorporated into the document.  This strategy permits us to document the 
good ideas in DVCS in more permanent fashion than periodically resubmitting 
the Internet-Draft.

In my opinion, duplication of functionality with standards track documents 
is not an issue.  I assume a "successful" experimental protocol *should* be 
the precursor to standards track RFCs that implement those experimental 
concepts in  a solid and interoperable fashion.   I realize this has 
already occurred to some extent, but there is no need to remove this overlap.

Let's move DVCS to experimental and free up the DVCS editors' time to 
contribute to the standards track documents that will follow.

Tim Polk