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

[Trevor Perrin <trevp@trevp.net>]

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