RE: [dss] freezing doc, and next steps

[Trevor Perrin <trevp@trevp.net>]

At 05:50 PM 6/3/2003 +0200, Gray Steve wrote:

>Please refer to my answers to John's questions below, marked as <UPU>
>
>-----Original Message-----
>From: jmessing [mailto:jmessing@law-on-line.com]
>
><sg>
>2.9 eNotarization in Presence of Notary
>
>Status: Neutral
>
>Comments: We do not agree that this feature should be a protocol issue. For
>example if we EPM-enabled a Canadian Bar Association application or a
>specific application utilized within Doyle, Selusci, Jacobs, and Associates
>... we would have accompished all that this requirement is intending to
>achieve without burdening the protocol. Besides this is the domain of RFC
>3126 and ETSI 101 733 Signature Policy anyway.
>
></sg>
>
><jm>
>
>I have reviewed RFC 3126, which states it is identical to ETSI 101 733 and
>indicates that it is informational only, not a standard. As for RFC 3126, it
>is PKI specific.
>
>In the context of the use case, I have trouble understanding your comments.
>They are directed to long term electronic signatures, I assume because of
>the reference, but this is different from notarized signatures, which also
>involve other considerations.
>
>Can you explain further?
>
>
></jm>
>
><UPU>
>What we are saying is that the EPM is also a Notary service for the
>electronic world. Using the analogy of a Notary "on paper" a document is
>notarised by witnessing a document being signed.  The EPM does the same
>thing for electronic documents, but the "witnessing" is performed by the
>Posts EPM Server once the integrity of the document and the digital
>signature has been verified, again by the Postal EPM server. The evidence
>supporting the signed and EPM'd document is then stored and archived by the
>Posts.

The eNotary service alluded to in the DSS requirements is a little 
different - the client would authenticate to it (using a password, say), 
and the service would sign the document using its own private key, while 
adding the client's name as a signed attribute (this is what we mean by 
"Identifying the Requestor").  Whether this is a better or worse analogue 
of a "physical-world" notary I dunno.  The chief difference is that an EPM 
notary assumes the client already has a keypair/cert he can sign with, 
while an eNotary assumes the client only has some way of authenticating 
himself.


>Perhaps I need some clarification as to the scope of this Requirements
>documnet. In my view, eNotarisation and Court Filings are "Use Cases" not
>requirements for use cases. That is why we have stated that we do not think
>this feature needs to be addressed in the subsequent protocol/

You're right - things like "eNotarisation" and "Court Filings" are use 
cases, not requirements.  The contents under 2.9 and 2.10 are "particular 
features" of these use cases which the requirements proper (in section 3) 
are intended to take into account.


Trevor