RE: Notary services requirements -- directions?

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

> I was unaware of RFC 3029.

Something maybe worth to read from the PKIX list almost 4 years ago
explaining the status of DVCS = RFC3029 

At that time I was tempted to simplify the services in DVCS and to
combine the validation of of signed data and certificates into some
common thing, i.e., to perform some validation on some document
whose structure and semantics are known, and for which a validation
procedure is defined. 

Even with 3029 one has already some bricks of such procedures,
one for signed documents, one for attestations itself, several
for public key certs where one can distinguish between signature
and encryption, etc., ...  
Furthermore, the validation algorithm itself may include that
external services are required, e.g., to archive each "document"
and obtain the attestations from someone else. 

It is not clear (to me) whether such procedures need
to implemented as code or as more or less complicated parameters
to some generic algorithm. 

I wonder whether such a technical system is somethig we are looking for
as an 

'functional architecture of a technical system to support activities of notaries and others'    

Peter
----

From: Carlisle Adams <carlisle.adams@xxxxxxxxxxx>
To: "'kent@xxxxxxx'" <kent@xxxxxxx>, "'wpolk@xxxxxxxx'" <wpolk@xxxxxxxx>
Cc: ietf-pkix@xxxxxxx
Subject: The future of DVCS...
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.