Subject: Re: Notary services requirements -- directions?

From: Peter Sylvester <[email-masked]>
Date: Tue, 5 Oct 2004 17:53:51 +0200 (MEST)

> Richard,
> 
> > I appreciate the feedback. I would suggest, however, that because the term
> > "Notary" is legally defined and most states actually have criminal penalties
> > for misappropriating the term or claiming to be a Notary when one is not,
> > the term is less flexible than you suggest. In fact, we are facing a serious
> > problem right now in the Western states over the issue of using the term
> > "Notario Publico" inappropriately. In Latin America, a Notario Publico is,
> > generally speaking, an attorney; in the US, a Notary Public is a ministerial
> > official of the court. Many citizens are being misled by scam artists
> > preying upon general confusion of the two terms.
> 
> This is a real problem indeed. Why not use the term eNotary or e-Notary 
> instead ?
> 

Would this change a lot? 

A little bit of history:

C. Adams(Entrust Technologies)
R. Zuccherato(Entrust Technologies)
February 27, 1997
Notary Protocols 
<draft-adams-notary-01.txt>

became:

C. Adams(Entrust Technologies)
R. Zuccherato(Entrust Technologies)
June 4, 1998
Data Certification Server Protocols 
<draft-adams-dcs-00.txt>

and later 

Network Working Group                                           C. Adams
Request for Comments: 3029                          Entrust Technologies
Category: Experimental                                      P. Sylvester
                                     EdelWeb SA - Groupe ON-X Consulting
                                                            M. Zolotarev
                                      Baltimore Technologies Pty Limited
                                                           R. Zuccherato
                                                    Entrust Technologies
                                                           February 2001
                Internet X.509 Public Key Infrastructure
           Data Validation and Certification Server Protocols

I don't know why the first change occured, but at least it avoids at
least two problems.

---

From: Larry Masinter <[email-masked]>
Date: Thu, 07 Oct 2004 22:30:42 -0700

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? 

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

---

From: "Andreas U. Schmidt" <[email-masked]>
Date: Fri, 08 Oct 2004 11:24:42 +0200

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

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 08 Oct 2004 10:42:11 +0200

Larry,

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:

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