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

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

> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: 14 January 2004 19:54
> To: Nick Pope; dss@lists.oasis-open.org
> Subject: RE: [dss] Timestamping Profile Q 1/3: Type of "SignatureObject"
> - NP2
>
>
> At 10:38 AM 1/14/2004 +0000, Nick Pope wrote:
>
> >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,
>
> I'm not so sure.  If clients don't process the timestamps themselves, but
> only use a DSS server to create/verify them, then clients could
> ignore the
> contents of the <dss:Timestamp>.  Then clients could easily support
> different forms of timestamp with a single protocol.
>
Nice idea but my experience is that generally clients are built like that.
Unless very careful steps are made to make a program generic, with testing
with the different types, there is always something which makes a client to
a specific data types.

Making an application more generic certainly has costs.  I have no problem
with allowing clients / servers to do this if there was a customer need, but
generally I would expect the client to be written to work with a single
time-stamp server type.

> I like this because:
>   - the "infrastructure level" has lots of competing and still-evolving
> technologies (linking vs. signed vs. DB-stored; RFC 3161 vs.
> XMLTimeStampToken; X.509 vs. PGP vs. SPKI vs. XKMS vs. SAML vs.
> proprietary)
>   - client software is hard to roll-out, and hard to change once
> you've done so
>   - Thus, it would be good to insulate clients from the turbulence of the
> infrastructure level
>
>
> >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.
>
> I guess I prefer seeing the profiles as just referring to the protocol
> between client and server, not referring to everything that needs to be
> done to produce a complete implementation on the server-side.
>
> In the requirements doc, we talked about "protocol profiles" and
> "signature
> profiles", and then "application profiles" that combine these.  Maybe we
> should resurrect these terms?  I would be talking about protocol
> profiles,
> and you're talking about application profiles.
>
> Perhaps a single document could give a protocol profile, and then
> multiple
> application profiles based on that?  The client would just implement the
> protocol profile, but the server would choose and implement one of the
> application profiles?  For example, the timestamping profile
> document would
> have an added section that lists application profiles detailing how to
> produce/verify RFC3161 TimeStampTokens, and XMLTimeStampTokens..
>
> I kinda like that, what do you think?
>

I have no problem with two levels of "profile", but I would like to see a
means of referencing a logical set of choices that are specific enough to
maximise the chance of interworking.

Now we are getting into it, this concept of a profile is not as simple as it
may seem.

Nick




>
> Trevor
>
>
>
>
>
> >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.
> >
> >
> >
> >
> >
> >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_wo
> rkgroup.php.
>
>
> 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.
>
>
>