Subject: The future of DVCS...

From: Carlisle Adams <[email-masked]>
Date: Wed, 11 Oct 2000 15:40:25 -0400

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: Stephen Kent <[email-masked]>
Date: Wed, 11 Oct 2000 22:46:52 -0400

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.

Steve

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 12 Oct 2000 09:25:33 +0200

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.

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

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

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

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

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.

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.

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.

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.

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 validation should not be necessarily made against a single root key.
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 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.

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.

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

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.

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.

With the arguments raised above, I am *not* supportive to make this
specification an experimental RFC.

Denis

>      This draft is a work item of the Public-Key Infrastructure (X.509)
>      Working Group of the IETF.
>