[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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> <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?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]