[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: RE: [dss] Fwd: RE: UPU CPC EPM Positioning Proposal vis-a-vis the OASIS DSS
Channelling Ed again: >Date: Wed, 09 Jul 2003 22:59:55 -0400 >From: Edward Shallow <ed.shallow@rogers.com> > >Trevor, ( please post to list ) > > I believe labelling a TimeStamp a Sign does not do the TimeStamp justice >and confuses. The verbs are already getting over-loaded, which is why you're >stuck. Why the reticence to add new operations. Strictly from a clarity >perspective, the world understands cryptographic timestamping in genreal. >Just add a TimeStamp operation. You are already into operations stacking ... >A place we were at 2 years ago. We simply added options to the primitives >that themselves could be primitives. That is why a Verify with a Timestamp >option, or a Verify preceded by a Decrypt (I know ... Scope) opertation, or >a Sign preceded by a VerifyCertificate (there's one you could add) operation >are all viable. I fail to see the need in trying to stick to just a Sign and >a Verify. Loosen up, let the use-cases take you were they take you. Much too >much constriction so early in the game. Besides, even if you don't do it >now, your protocol will be infinetelty more flexible moving forward. > > I don't like any of the options. Again, I recommend you add extensible >option directives to every primitive. Options themselves can be primitives. >Combinations of options and primitives can constitute your profiles. Only in >this manner can you truly keep the protocol insulated from the profiles. > >Ed > > >-----Original Message----- >From: Trevor Perrin [mailto:trevp@trevp.net] >Sent: July 9, 2003 2:45 PM >To: Edward Shallow >Cc: Gray Steve > >At 02:17 PM 7/9/2003 -0400, Edward Shallow wrote: > > >Are you saying we agree ? > >Well, in one respect, at least :-). Lest you think I buy into this whole >non-repudiation business.. > >But I think we'll need to agree to disagree on certain things like that >which are simply outside the scope of the protocol. At least, once we agree >on what the scope of the protocol is. > >To that end, Steve's latest post, and the conversation that results from >that, should be helpful. > > > >Bravo ! It sure took a lot of eMails to get to. > >This is exactly what the Government of Canada is doing. > >Any references? I'd be curious to read about it. Are they using EPM >External Sign? > >More importantly, do you think DSS's Sign operation would satisfy EPM's >External Sign needs? Do we need to change our requirements here to >accomodate EPM? > >I'd still like to produce another requirements draft before the next >meeting, so anything on the above you could post to the list would be >helpful. > >Here's the status of EPM's suggested requirements, as I recall: > - You proposed an "Ability to tie multiple business transaction lifecycle >events together under a common key", I made a proposal to add this to the >Requirements, I haven't heard back - >http://lists.oasis-open.org/archives/dss/200307/msg00021.html > - In the same mail I pushed back on many other things you suggested, as a >matter of scope, and I guess we're still discussing that. > - EPM's Verify/ApplyPostmark poses a unique challenge for DSS, since it >combines both our Verify and Signing operations. It's a very interesting >use case, and I'm glad you guys have contributed it. Here's my latest >proposal for handling this - >http://lists.oasis-open.org/archives/dss/200307/msg00045.html > >Other things you want to suggest? > > > >An enormous endevor > >which put it at the top of the eGovernment heap. However, this still > >recludes gernerally available Web Service offerings which espouse to sign >on > >your behalf and still be legally binding. This we cannot condone. > >To my way of thinking, whether a service is: > - "generally available", or available only within an organization, and > - legally binding or non-legally-binding > >are issues outside the scope of the protocol. You could take a service >that implements the protocol and run it inside a corporation or >outside. You could move it from one legal regime to another. > >The code for the server, and thus the protocol it implements, would not >change in the slightest. Yet in some cases it would be "generally >available", in some cases it wouldn't, in some cases it would be "legally >binding", in some cases it wouldn't. > >My point is, these questions of who runs the service, and what legal >guarantees it provides, are issues of deployment and of the legal/business >context DSS is being deployed within. DSS should concern itself only with >sending a document and getting back a signed document, and let other people >like EPM design "whole systems" that tackle these issues, and which will >incorporate DSS as only a small part. > >Trevor
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]