[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] RE: ProcessingOptions example and discussion
At 10:36 AM 9/3/2003 -0400, Tim Moses wrote: >Colleagues - OK. Let's get a list of compound operations before we decide >how to deal with them. If there are three primitives (V,S & T) and if it is >not valid to repeat an operation and if it makes no sense to do V anywhere >but as the first operation, then there are four possible dual-operations and >two possible triple-operations (see below). I don't think it makes sense >for us to say which of these are invalid: someone may one day want to do any >one of them. We should simply provide the framework in which one could do >any one of them. All the best. Tim. > >Here they are ... > >VS, VT, ST, TS, VST, VTS. I like this approach. I would contend that ST and TS are just instances of the Signing Protocol - they're producing a signature that contains some sort of TimeStamp. But the client may not need to explicitly request the signature, or he may request the signature just by passing an "ApplyTimeStamp" boolean. I would not call such a simple technique a "compound operation". I also contend that T should be a profile of the signing protocol, as I've argued before. So if we can use S* for (S, T, ST, or TS), then the only "compound operation" is VS* - first verify, then update/ refresh/ augment/ whatever the signature. So I'd argue we don't need a general framework for compound operations, we just need to support this *particular* compound operation. This simplifies the problem. Do people agree? Trevor
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]