OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

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

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?


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]