No Subject

-----Original Message-----
From: Edward Shallow [mailto:ed.shallow@rogers.com]
Sent: Friday, July 11, 2003 6:01 PM
To: 'Trevor Perrin'
Cc: Gray Steve
Subject: RE: Fwd: RE: [dss] Fwd: RE: UPU CPC EPM Positioning Proposal
vis-a-vis the OASIS DSS


Trevor, (please post)

     A WSDL is a communications tool, and must convey service consumption
information clearly and succinctly. The world understands timestamping and
can easily associate with it and relate to it's nuances. You are losing
focus by turning the interface definition into an exercise in normalization
(or should I say abstraction and generalization). The final product will be
a painfully flat WSDL.

     Are saying that a SignAndVerifyAndTimeStamp request, which might
legitimately take place at origin by a document author wishing 1) to have
something signed (delegated), 2) have his own certificate Verified, and then
3) have that signature TimeStamped poses no problem for your 2 verb protocol
in terms of succinctness and callability ? Please show me.

     Will you be disallowing use of the optional nonce attribute in the DSS
based on your arguments against its usefullness ? 

     You claim that your Signing Policy construct (as yet expalined or
detailed) can handle the TSA policy separate from the SignaturePolicy
associated with signature being produced (in a Sign call). These are 2
separate policies. Will the DSS be able to delegate to a separate TSA, or
are you saying that the DSS will be a TSA ? Do you honestly think it will be
simpler for the caller ? As we get down into the detailed protocol
development this will become much more apparent. You refuse to even
ackowledge this possibility.

     At a minimum, why don't you postpone this decision (i.e. to separate
TimeStamp or not) ? 

Ed     


-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net] 
Sent: July 10, 2003 5:15 PM
To: dss@lists.oasis-open.org; Edward Shallow


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