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

[Trevor Perrin <trevp@trevp.net>]

 From Ed -

>Date: Thu, 10 Jul 2003 12:44:25 -0400
>From: Edward Shallow <ed.shallow@rogers.com>
>
>Trevor, (as usual please post)
>
>     We actually moved away from stacked operations (i.e.
>VerifyAndSign,VerifyAndCounterSign, etc ...) in favor of focusing on the
>prime objective of the service call which was then accompanied by additonal
>directives or options. These options (all manifesting themselves as WSDL
>booleans or structures) can be crypto primitives themselves, as is the case
>with ApplyPostMark and VerifyCertificate, or they can simply be directives
>to return additional information such as ReturnX509Info and
>ReturnVerificationInfo, or even directives to include selected attributes.
>
>     On a related note, we contend that the Verify and TimeStamp operations
>are legitimate operations on their own. Trevor, you said in an earlier
>exchange, that a subscriber may use a separate Validation Authority and
>TimeStamp Authority. The TSP protocol carries a whole bunch of stuff that is
>truly unique to timestamping, like the nonce, a separate TSA policy, clock
>accuracy, the very specific and mandated return of the timestamp token and
>the timestamp information strucure (i.e. TSTInfo). These are all very
>different from the more conventional Sign request / response structures. A
>caller is not even allowed to specify a signing (timestamping) key, that is
>the TSA's responsibility. You will have to create all sorts of
>pre-conditions on your Sign operation for the TimeStamp requests. Sure you
>can simply abstract out the details claiming it is fundamentally a Signature
>creation exercise, but I believe you loose a lot of context and you confuse
>by overloading the Sign with a radically different profile (See Vincent
>Girier's ISSE XML TimeStamping submission to this group).
>
>     I contend that a Verify operation with an ApplyTimeStamp option
>directive would be better. Furthermore, I believe an elementary TimeStamp
>deserves its own primary verb. TimeStamping has been around a long time and
>is well understood and deployed under its current definition. Don't lose
>that momentum.
>
>     In this multi-operation-per-request scenario (as you call it) you have
>to keep and return the results of each operation separately. The caller is
>definitely interested in the Verify results containing both signature and
>certificate verification info as well as the timstamp results containing the
>timestamp time, the timestamp token (perhaps inserted back into the incoming
>signature as an unsigned attribute, perhaps separate).
>
>     Another scenario you have not addressed is one where the incoming
>signature already has a timestamp attached to it. Perhaps the subscriber
>just wanted an origin timestamp (e.g. a filed my tax return on time) and
>requested a TimeStamp or a Verify with ApplyTimeStamp. Then the tax
>department wants this incoming signature (tax filing) verified. The tax
>department calls the DSS with a destination Verify ApplyTimeStamp. Does the
>DSS obliterated the origin timestamp embodied in the signature ? I doubt it.
>Does it verify both the signature and the timestamp contained therein ? Or
>does it verify both signature and origin timestamp AND return a destination
>timestamp ?
>
>    Effects on the operation and its options ? Large. Please throw this
>scenario into the demand side of the equation, it will happen in real life.
>
>Ed
>
>
>-----Original Message-----
>From: Trevor Perrin [mailto:trevp@trevp.net]
>Sent: July 10, 2003 4:20 AM
>To: Gray Steve; Edward Shallow; dss@lists.oasis-open.org
>
>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