RE: [dss] Fwd: RE: UPU CPC EPM Positioning Proposal vis-a-vis th e OASIS DSS

[Trevor Perrin <trevp@trevp.net>]

At 09:34 AM 7/10/2003 +0200, Gray Steve wrote:

>Trevor
>
>I apologise for not commenting on the Time-stamping discussion previously,
>but there are so many emails flying around, I struggle to get to read them
>all.

No problem, it's getting hectic..


>Therefore, I am certainly relying on the requirements document and any
>changes that are made there. My current interpretation is that
>Timestamping/Timemarking is a distinct requirement in section 2.12 and 3.7.4
>
>Is my interpretation correct or are you proposing to change this based on
>your's and Nick's proposal.

There's a bunch of issues swirling around -

My and Nick's proposal, and my last post[1], were about using the DSS 
Signing protocol as a timestamp protocol like RFC 3161.  If people agree we 
can use the Signing protocol in this way, we can move to the next issues:

Right now *both* our Signing and Verifying protocols could return a 
time-stamped signature:  3.7.4 is about using the Verify protocol to get a 
signature verified and timestamped.  The bullet about "signing time" in 
3.4.4 is about using the Sign protocol to create signatures that might 
include a time-stamp.

3.7.5 also covers using the Verify protocol to get "verification info" 
attached to a signature, perhaps including a timestamp.  So we've got 
timestamps oozing out of everywhere.

A related issue is how to do something like EPM Verify / ApplyPostmark in 
DSS, where the client uses a single request to both verify a document and 
get it postmarked, aka time-stamped (or counter-signed, which may be 
equivalent).  For this I suggested[2] letting the client use a single 
request to send a document and request multiple operations on it, like 
Verify and Sign (meaning, well, time-stamp).

Ed disagreed with this[3], but I think his disagreement was more about 
using the Sign protocol for time-stamping, then about the particular new 
thing I thought I was proposing (multiple operations per request).  However 
he also made some suggestions I didn't fully grasp: "We simply added 
options to the primitives that themselves could be primitives... That is 
why a Verify with a Timestamp option...[is] viable... Again, I recommend 
you add extensible option directives to every primitive.  Options 
themselves can be primitives".  I don't understand this, because the text 
sounds like he's talking about nesting operations or something, but looking 
at the wsdl I just see a Verify operation with an ApplyPostmark 
boolean.  Which is simple, and seems about equivalent to what we have with 
the "Return Verification Info" flag.

Anyways, so the multiple-operations-in-one-request thing might work as the 
DSS equivalent of Verify / ApplyPostmark.  It might also let us eliminate 
3.7.4 and 3.7.5.  These are bothersome because they use the Verify protocol 
to produce new signatures, instead of just returning information about old 
ones.  It seems like a number of requirements on the Sign operation would 
thus apply here: Output Delivery (return the whole thing or just the 
signature), Intended Audience, Signing Policy, Explicit Signed/Unsigned 
Attributes..

So if we could send both a Verify and Sign operation in one request, we 
wouldn't need the "Return Verification Info" flag, because the Sign request 
would accomplish that function (it would ask the server to produce a 
signature over the current signature).

Or maybe a better choice is, as Ed says, to define a new 
operation.  VerifyAndSign (or VerifyAndCounterSign) or something, that 
inherits from both Verify and Sign...

As you can see, your poor editor is quite confused and hopes the TC gives 
guidance :).....


[1] http://lists.oasis-open.org/archives/dss/200307/msg00060.html
[2] http://lists.oasis-open.org/archives/dss/200307/msg00045.html
[3] http://lists.oasis-open.org/archives/dss/200307/msg00059.html


Trevor