RE: [dss] freezing doc, and next steps

["jmessing" <jmessing@law-on-line.com>]

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>

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

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