Subject: RE: Notary services requirements -- directions?

From: Peter Sylvester <[email-masked]>
Date: Fri, 8 Oct 2004 15:41:28 +0200 (MEST)

> 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 <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: [email-masked]
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.

---

From: Peter Sylvester <[email-masked]>
Date: Sun, 10 Oct 2004 18:23:35 +0200 (MEST)

> Abstract
> 
> This document defines the requirements for e-Certification services. Such 
> services may be used when there is a need to register one or many documents 
> and to certify that these documents have been duly semantically verified by 
> a given person prior to registration. These persons may or may not be 
> Notaries, as understood by Civil Law or Common Law. The document to be 
> certified may or may not contain electronic signatures from other persons."
> 

Independant of the usage of the word "e-certification service" I am not
sure that the description is what we have in mind as services to be supported
by a protocol.

What is meant by 'registration'?

My understanding was that we can access to a service that performs certain
aspects of a semantical verification, and does not only rely on a person
doing this, or else, what is proposed looks to me as a front end to an 
archiving system (which may still be one of the use cases). 

At best, the title is one possible use case IMO. But I may be wrong.

Futhermore, it doesn't seem to me that we have agreement about whether
we talk about requirements for a protocol or for a service. 

To me we arec talking about protocol requirements, i.e. by what means
can we access to the services and the functions it provides, and what
information we can submit or and what do we obtain. 

Peter

---

From: Richard Hansberger <[email-masked]>
Date: Mon, 11 Oct 2004 18:35:15 -0800

Andreas,

The term "Electronic Notary" is perhaps a bit awkward for US Notaries. It
might work well in other countries, but in the U.S. we have model
legislation that regulates the "Electronic Notary," which a number of states
have adopted already. Thus, I could see confusion resulting from this
service.

"eCertification Services" or "e-certification service" isn't all that clumsy
and is, in fact, more acceptable to US Notaries. In the US, we have long
recognized that the certification services human Notaries now provide will
gradually be replaced by machine services that provide better certification
guarantees.

Notaries witness; machines certify. It makes sense to me.

Rich Hansberger
National Notary Association

-----Original Message-----
From: Andreas U. Schmidt [mailto:[email-masked]] 
Sent: Friday, October 08, 2004 2:25 AM
To: Denis Pinkas
Cc: Larry Masinter; [email-masked]
Subject: Re: Notary services requirements -- directions?

Denis,

certain examples in the form of scenarios and use-cases are necessary
*in the beginning* of this requirements document to delineate the scope,
clarify the subject, and provide rationales for the requirements proper.
What we have now, including two suggestions I posted earlier on, could
already be sufficient if we make good use of RFC3029 as a secondary
reference.

"e-Certification Serivces" to me seems overly clumsy - reading that title
one might wonder what such a thing might do *more* than a CA or a
Timestamping Service. At the moment I cannot think of a solid name
which avoids the conflicts with the legal domain of notaries public, and 
still
has some impact. How about "Electronic Notary (e-Notary) Services".
Still I think we should keep some relation to the title of the WG and
not make an ad hoc change which might then persist.

With regard to the abstract I would like to stick to Larry's last proposal.

AUS

Denis Pinkas wrote:

>
> Larry,
>
>> I was unaware of RFC 3029.  Should we add a reference to
>> RFC 3029 as an example of what is intended in the requirements
>> document? 
>
>
> A requirements document should not simply be a collection of examples.
> Examples can certainly be mentionned in informative annexes, but the 
> core document would still need to say what needs to be supported.
>
> RFC 3029 supports many use cases, maybe too many. A subset of RFC 3029 
> would certainly makes sense once we have define the document filling 
> the requirements (which still need to be defined). RFC 3029 contains 
> solutions to many problems, but it is not a requirements document.
>
> Besides the vocabulary problem about the use of the term "notary", we 
> would have first to define what would be the title and the topic of 
> the requirements document. I would propose something along the 
> following strawman proposal:
>
> "e-Certification Services requirements
>
> Abstract
>
> This document defines the requirements for e-Certification services. 
> Such services may be used when there is a need to register one or many 
> documents and to certify that these documents have been duly 
> semantically verified by a given person prior to registration. These 
> persons may or may not be Notaries, as understood by Civil Law or 
> Common Law. The document to be certified may or may not contain 
> electronic signatures from other persons."
>
> Denis
>
>> Would it be reasonable to rename the document:
>>
>>   Data Validation and Certification Protocol Requirements
>>
>> and replace 'Notary' with 'Data Validation or
>> Certification Service' as appropriate?
>>
>> RFC 3029 contains a few uses of the word 'notary', but
>> only in descriptions of patents and relationship to
>> prior work.
>>
>> Larry
>
>
>
>

This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed.  If you have received this email message in error, please notify the sender immediately.

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 14 Oct 2004 13:26:54 +0200 (MEST)

> 
> 
> Personally, I don't think we get into too much trouble
> using the word 'Notary' in the title of the working group
> or even in the title of a document here and there, as long
> as we're clear -- after all, it's a term that's been used
> already in the industry, and we're not particularly offering
> those services for sale, in any case. 
I tend to agree. 

> 
> I think the requirements document might note that the
> term may have restricted use in some legal jurisdictions,
> and I think it is reasonable to add some wording to that effect.

Would someone mind writing down a small paragraph that could
explain the issue, i.e., resume the last exchange of messages,
so we have something to be put into the RFCs but also I can
add this in a kind of disclaimer section in the web server
in order to avoid that in a few months new participants ...

> 
> Are time-stamping services associated with unsigned
> data out of scope, because they're already covered?

- Time stamping of signed data, i.e. digital signature is
  also already covered by existing proposals.

- I think we have several questions to clarify, like

  - what are "our" requirements of the stability of time stamps,
    i.e., currently they are at best the 'lifetime' of a
    hash function.

  - what means does archiving provide (or not), to cover
    long term, e.g., if I just have to archive invoices
    for about three months, i can live withe short term
    time stamping.
  
  (to be a litle bit provocative, current time stamps are not 
  good for long term IMO, since they were never intended as such)
 
> Are combined archive-and-certification services
> (which archive data and also provide for the certification
> of the data archived) out of scope?

- If we make it right, then we have just a combination of
  three quarks: Notarisation (voluntarily written with an s),
  Archiving, and Evidence creation/recording to do this. 
  Or, in other words, it is a particular use case of a
  combination of basic techniques. 

- The role of such a notary can just be "I perform the
  archiving, and certify that the "reference" returned
  from the archive. 
  Whether one consider this minimal notarisation as
  a front end client related service of the archive or
  as an independant service, seems to me an organisational
  matter, or, in other words, it depends on the client needs.

- There may be a lot of cases where the information (the
  references) provided by the archiver does not need to be 
  "secured" at lot when given to the client. That's why I
  think it is important to clearly distinguish between
  (more or less real time) security measures and the payload.

- As far as I have understood from discussions with notaries
  there is some particular kind of archive+notary application
  which is based on the observation that notaries (at least
  in some places) perform some information reduction, for 
  example, a 'signature validation' can be done in such
  a way that the notary collects all the validation data,
  performs the validation, time stamps all that, archives
  them, but just delivers a statement that everything is
  of+the refereces to the archive. in fact, the archived
  data correspond to his activity log. 

  This is somehow the exact opposite operation of what
  is provided by some profile of DVCS or by SCVP, where
  the validation data are returned by a service. Again,
  an information reducing notary would be able to ask
  an information collecting service (+ a validator) to
  provide the information, then all this can be archived,
  and a 'reduced' result produced.

  If one looks at such use cases as molecules, I wonder
  where are our atoms.

Peter

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 15 Oct 2004 12:13:08 +0200 (MEST)

> > > Is there an additional need to define means for 
> > representing notarial 
> > > acts performed by humans?
> > > 
> > No. The best is to have the equivalent of a framework paper 
> > that has a free form text place where the nature of the 
> > notarial act and anything else can be noted.
> > 
> > These elements are not subject to automatic treatment by our 
> > core protocol
> > 
> > it may be useful to more than  "free' text, i.e. some schema 
> > or oid based document piece like for soap content or CMS 
> > content types, in order to allow plugin logic do additional 
> > work for semantic validation in a correct way. 
> 
> Seems like part of you says "No" and another part says "Yes":-)  A schema,
> or some such, might be a useful parallel to the signature formats, bindings
> and certification protocol.

It seems to me that your question has two aspects:

- The content to be notarized
- The notarization (envelope)

I am just saying that we probably would not go further down
that having a common envelope for some 'ANY DEFINED BY' 
(to use some obsolete terminology), a 'signature format'
if one prefers this term. 

it looks like we have a similarity with the problem of
archive transformation and metadata, i.e., the extent to
which an archiver has knowledge about the relationship
of 'outer' metadata and some 'inner' structure of the
data.

---

From: "Tobias Gondrom" <[email-masked]>
Date: Fri, 15 Oct 2004 18:20:26 +0200

> > From: Larry Masinter [mailto:[email-masked]]
> > Sent: Tuesday, October 12, 2004 7:25 PM
> > Subject: RE: Notary services requirements -- directions?
> >
> > Personally, I don't think we get into too much trouble using
> > the word 'Notary' in the title of the working group or even
> > in the title of a document here and there, as long as we're
> > clear -- after all, it's a term that's been used already in
> > the industry, and we're not particularly offering those
> > services for sale, in any case.
> 
> I don't mind the title either.

I also agree. I can understand possible problems when a company sells a
notary service and is not allowed to, but this is neither the case with
the name of the WG or the Name of the requirements - basically I like to
call the things by the best fitting name if I find one at all... ;-)

So I see no problem calling a document requirements for notary services,
e.g.

> 
> > I think the requirements document might note that the term
> > may have restricted use in some legal jurisdictions, and I
> > think it is reasonable to add some wording to that effect.

Full ACK, although I wouldn't add too much - there will always be one
place in the world where some wording might cause legal conflicts and it
is always up to the companies to resolve these conflicts when the
implement things and sell products to local customers.

> > Are time-stamping services associated with unsigned data out
> > of scope, because they're already covered?
> 
> I'm not sure what you mean out of scope.  If you mean outside the
scope
> for
> new specification work, I think so.  If you mean outside the scope of
what
> we may refer to as a notary service, I don't think so.  Timestamping
seems
> like a fundamental component.  We've explicitly included support for
> unsigned data in the archive discussion and since those have so far
been
> discussed pretty much solely in terms timestamp solutions, I think
this is
> in scope (if already covered elsewhere).
> 
> > Are combined archive-and-certification services (which
> > archive data and also provide for the certification of the
> > data archived) out of scope?
> 
> I think this combination is very much in scope.  It seems natural for
the
> data certification service we define to be capable of verifying the
> structures defined for long-term archive purposes.  For some purposes,
> this
> combination may be invest too much trust in a single entity.  For
other
> purposes, it seems like the ideal pairing (e.g. a binding that
verified
> the
> evidence record upon data retrieval).

I also agree with Carl - this is a possible but not necessary
combination.

Tobias

---

From: "Tobias Gondrom" <[email-masked]>
Date: Mon, 18 Oct 2004 18:13:43 +0200

I fully agree with Denis statement that we need to clarify more what
kind of services should be offered per example.

E.g. should there be a service for administering of oaths (just to
choose one) - how would it look like ?

Please, this is the question for me to the mailing list: What kind of
use case/scenario do you see ?

I would really appreciate a first version of a strawman definition so
that we can focus again on gaining a hold on what the definition should
be.

Tobias

> The current text states:
> 
>     The functions of notaries
>     include the attestation of documents and certification of their
due
>     execution, administering of oaths, witnessing affidavits and
>     statutory declarations, certification of copy documents, noting
and
>     protesting of bills of exchange and the preparation of ships'
>     protests.
> 
> This tells what the functions of notaries are, but still does not tell
> what
> notary services are or will be.
> 
> Later on the text says:
> 
>     A notary service should support and enable a human notary to
fullfill
>     his tasks with electronic documents as well as he already does
with
>     paper based documents and processes.
> 
> This is is closer but still does not tell what "notary services" are
or
> will be.
> 
> Finally we have:
> 
>        Notary service: electronic service that supports a human notary
>        to provide his/her services on electronic based processes and
>        documents.
> 
> Is this definition sufficient ? I do not think so, since it is too
broad
> and
>   is not self-descriptive.
> 
> I understand that the "notaries services" that we will consider will
only
> cover a *subset* of all the services a (human) Notary can perform, and
we
> have not yet identified that subset of services and both the different
or
> common characteristics of that subset.
> 
> So I ask the editor (or others) to propose a strawman definition that
we
> can
> discuss.