RE: [dss] freezing doc, and next steps

[Gray Steve <steve.gray@upu.int>]

Please refer to my answers to John's questions below, marked as <UPU>

-----Original Message-----
From: jmessing [mailto:jmessing@law-on-line.com]
Sent: Sunday, June 01, 2003 10:25 PM
To: dss@lists.oasis-open.org
Subject: RE: [dss] freezing doc, and next steps


This is in response to Steve Gray's postingo of May 27. I have some
questions and comments.

----------------------------------------------------------------------------
----

Subject: RE: [dss] freezing doc, and next steps

From: Gray Steve <steve.gray@upu.int> 
To: "'Robert Zuccherato'" <robert.zuccherato@entrust.com>, "'Nick Pope'"
<pope@secstan.com>, dss@lists.oasis-open.org 
Date: Tue, 27 May 2003 07:21:42 +0200 

----------------------------------------------------------------------------
----

<sg>
2.1 Corporate Seal

Status: Suppported

Comments: This is supported via the EPM Sign operation which is configured
at installation to use any subscriber private key for signing (i.e. a
configuration item)


2.2 SOAP Signing

Status: Supported

Comments: This I assume to mean inline signing of all SOAP messages
traversing a gateway or equivalent proxy setup. This can easily be done with
the vanilla EPM and some gateway specific client code again calling our Sign
operation.


2.3 Identified Requestor

Status: Supported

Comments: This is supported in spades !!! See our Participating Parties
construct working conjunction with our AccessScope option of the
StartLifecycle operation.


2.4 Individual Signatures

Status: Supported

Comments: The Posts told us that delegated signature creation was not in
keeping with prevailing Digital Signature Laws. However, similar to item
(2.3) above, we can support configuration of several Individual signing
keys.
</sg>

<jm>
As I read the version 6 posted by Trevor, verification in 2.1-2.3 is by way
of the public key of an organization, but in 2.4 it is by way of the public
key of the requestor. Therefore, I have trouble understanding your comments
to 2.3 and 2.4. Do you mean the reverse of what you stated?

</jm>

<UPU>
Yes, I think there was a misunderstanding with regard to the comments
provided here. As stated in 2.1, the EPM will sign with whatever private key
it is configured to sign with. Issues associated with Organisation
certificates and certificates identifiying roles within organsiations become
Certificate Policy, CPS, naming convention issues and the relevant business
apllication then must be configured to recognise these certificates and act
accordingly.  Our original comments were misconstrued with applications that
required multiple signatures for a single transaction or document. For
example, signing a NDA involving 2 or more parties (hence the reference to
StartLifeCycle
</UPU>


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

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/ 
</UPU>
<sg>

2.10 Court Filings

Status: Neutral

Comments: We saw no need to standarized the whole Challenge Support and
Evidence Submission process due to the huge differences across
jurisdictional and country boundaries, ot to mention the distinct court
processes across levels of government even withina jurisdiction. We
considered this very low priority in terms of relative value and importance.

</sg>

I do not understand what you mean by a "Challenge Support and Evidence
Submission process". This is not a recognized legal doctrine or term.
Whatever it is, it is not involved in this use case. 

Can you explain how you see relevant "jurisdictional and country boundaries"
or "distinct court processes across levels of government even withina
jurisdiction"? Which jurisdictions are you referring to you? Which
processes? Can you give an example?

I think there is a misunderstanding about this use case, or else a severe
miscommunication about what is meant. Can you explain further, please?

<UPU>
As per my response for eNotarisation, I would like some clarification on if
this is really a requirement or a USe case
</UPU>


You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php