RE: [dss] Timestamping Profile Q 1/3: Type of "SignatureObject"

[Trevor Perrin <trevp@trevp.net>]

At 08:59 PM 1/13/2004 +0000, Nick Pope wrote:

>Trevor,
>
>Two points:
>
>1) Whilst the form of "SignatureObject" returned from Sign & Input to
>Verify, I think that this warrent a separate section which identifies /
>defines the form of signature supported by a specific profile.  Depending on
>the profile this may be very broad or very specific, but but having such a
>section the reader can immediately identify the form of signatures supported
>by a profile.

Maybe we could add a "2.2 Signature Types Supported" section, to present 
that info near the top?


>2) Personally, I am more inclined towards a profile being more specific as
>this is closest to what is likely to be implemented and so greatly increases
>the chance of interopability.  The definition of other profiles for other
>forms of time-stamps should be a fairly straightforward matter given the
>example profile and the flexibility of the DSS Core.

I see your point - I think it depends on what type of interoperability you 
consider, though.  If you think of a 4-corner model, with client A and 
server A in one domain, and client B and server B in another, there's 2 
types of interop:
  - server-server interop (can server B verify timestamps produced by 
server A, and vice versa)
  - client-server interop (can client A create/verify timestamps with 
server A; ditto for B)

Server-server interop depends on the timestamp type, but shouldn't depend 
on the client-server protocols (for example, domain A could use the RFC 
3161 protocol to create RFC 3161 TimeStampTokens, and domain B could use 
DSS to verify them).  Client-server interop, conversely, depends on the 
client-server protocols, but shouldn't depend on the timestamp type (so I'm 
arguing).

If we make the client-server protocol independent of timestamp type, then 
we maximize interoperability between clients and servers.  For example, 
suppose servers A and B are using different timestamp types, so 
server-server interop is impossible.  Clients A and B are both using MS 
Word.  If Word only has to support a single timestamping protocol, 
client-server interop between Word and servers A and B is easier to achieve.

So I guess my argument is: even though ultimately, interop between domains 
A and B depends on the timestamp type, interop between client applications 
and servers is what's relevant to the protocol profiles, so we should try 
to make these profiles independent of timestamp type (or signature type) as 
much as possible.


Trevor