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

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

Trevor,

I also see what you are saying.

It is a question of what we would expect DSS client or DSS server to
support.  Whilst some systems may decide to support several forms of
timestamp this significantly adds to the complication of the implementation.
I doubt that clients would ever support more than one form of time-stamp,
and if a server does I suggest that this is done as several profiles.

So I still prefer the profiles to be more specific as I see that as what
would be implemented.

Nick

> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: 13 January 2004 22:05
> To: Nick Pope; dss@lists.oasis-open.org
> Subject: RE: [dss] Timestamping Profile Q 1/3: Type of "SignatureObject"
>
>
> At 08:59 PM 1/13/2004 +0000, Nick Pope wrote:
>
.....

>
> >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
>
>
> To unsubscribe from this mailing list (and be removed from the
> roster of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_wor
kgroup.php.