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

["Nick Pope" <pope@secstan.com>]

Ed, Trevor,

I suggest that in the context of DSS we do not confuse a profile for a
time-stamp whose semantics is purely this data existed at this time, and a
profile for something linked verify which significantly different semantics.
Otherwise, as you suggest, there is a threat that a time-stamp against a
signature could be misinterpreted as meaning that the signature has been
verified.

Nick

> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: 10 July 2003 23:15
> To: dss@lists.oasis-open.org; Edward Shallow
> Subject: Re: Fwd: RE: [dss] Fwd: RE: UPU CPC EPM Positioning Proposal
> vis-a-vis the OASIS DSS
>
>
>
> Hi Ed,
>
> So there's 2 issues here:
>   - whether we need a separate Timestamp protocol, or can use the
> Sign protocol
>   - how to support a Verify / ApplyPostmark operation (i.e.
> Verify and then
> Timestamp)
>
> I'll tackle the first, cause I have a definite opinion, and it's
> a simpler
> issue.  But I'm not ignoring your other points, I'd just like to ponder
> some more and see what other people say.
>
> At 10:06 AM 7/10/2003 -0700, Trevor Perrin wrote:
>
>
> > 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,
>
> The nonce could be added to a "Timestamp profile" (as Nick suggested) of
> our Signing protocol, as an "Other Signed/Unsigned Attribute" that the
> client requests to be added into the produced signature or timestamp.
>
> [As a side note, is it really needed?  It "allows the client to
> verify the
> timeliness of the response when no local clock is available".  So
> it's only
> useful when:
>   - the client doesn't have a clock
>   - the client isn't using authenticating the server with TLS or similar
>   - an attacker replays a TimeStampResp *that has the same
> messageImprint*
> as the requested TimeStampReq from the TSA
>
> All this replay does is give the client an earlier timestamp then he
> requested.  Is this an attack?  If so, consider that even with the nonce,
> the attacker can still *exhibit* an earlier timestamp with the same
> messageImprint, he just can't replay it within the protocol.
>
> Shouldn't the client just use a binding like TLS, or a clock?  And also
> make sure that it only time-stamps documents that are unique enough that
> they won't collide with earlier documents, if that's an issue?]
>
> >>  a separate TSA policy,
>
> This is easily handled by our "Signing Policy" requirement.
>
> >>  clock
> >>accuracy, the very specific and mandated return of the
> timestamp token and
> >>the timestamp information strucure (i.e. TSTInfo).
>
> This is all stuff that goes into the TST, it doesn't affect the protocol
> itself, which is already general enough to be used with things as
> different
> as XML-DSIG and CMS.
>
>
> >>  These are all very
> >>different from the more conventional Sign request / response structures.
>
> In a previous mail I pointed out all the similarities.  In each case, the
> client sends a hash or a bunch of documents to be hashed as input to
> creation of a "thingie", and receives back the document with a thingie
> (signature or timestamp) attached, or just the thingie itself.
> The client
> tells the server what the thingie covers, where to place it, whether to
> return just it or the whole document, what audience it's intended for,
> under what policy it should be produced, and other things that should be
> placed inside it.
> http://lists.oasis-open.org/archives/dss/200307/msg00060.html
>
> I think these commonalities are far greater than the differences you
> pointed out, and justify making Timestamping just a profile of Signing.
>
> >>  A
> >>caller is not even allowed to specify a signing (timestamping)
> key, that is
> >>the TSA's responsibility.
>
> Which key to use we group under "Signing Policy".  I don't see
> why this is
> any different for Signing or Time-stamping.  In either case, the
> client may
> choose not to specify such a policy, or implicitly specify one by the
> server he contacts, or he may go out of his way to request a
> particular policy.
>
> >>  You will have to create all sorts of
> >>pre-conditions on your Sign operation for the TimeStamp requests.
>
> like what?
>
> >>  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
>
> like what?
>
> >>  and you confuse
> >>by overloading the Sign with a radically different profile
>
> don't see the differences.
>
> >>  (See Vincent
> >>Girier's ISSE XML TimeStamping submission to this group).
>
> On casually skimming it, I don't see anything it does that we would have
> trouble doing, except we won't define linking schemes in v1.
> http://lists.oasis-open.org/archives/dss/200212/pdf00000.pdf
>
> It's a good input though, and deserves more study.
>
>
> >>     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.
>
> We could have Signing and Timestamping protocols inherit from an
> "abstract
> base protocol" that contains all the common functionality I pointed
> out.  In that case we'd just have 2 different "verbs" with the same
> contents.  Better not to multiply things unnecessarily, just have 1
> protocol and profiles.
>
> Trevor
>
>
> You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php