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
