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

[Trevor Perrin <trevp@trevp.net>]

At 09:52 AM 1/15/2004 +0000, Nick Pope wrote:


> > -----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[n't] built like 
>that.

maybe that's something we can fix :-)


>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.

If the client treats timestamp contents as opaque, and only processes them 
through the server, then the client shouldn't need to do testing for each 
different type.


>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.

How concrete do you envision this type being, though?
  a) server returns a <Timestamp>
  b) server returns a <Timestamp/XMLTimeStampToken>
  c) server returns a <Timestamp/XMLTimeStampToken> specific to an 
X.509-based TSA (similar to RFC 3161 - references the signing TSA's 
Distinguished Name, and its signing certificate through a signed attribute 
containing the certificate hash and IssuerSerialNumber).

I think (c) is the level of detail needed for a server implementation, and 
(a) is the level of detail needed for a client implementation.  So I vote 
for a document that defines a single (a) profile for the client, and then 
multiple (c)-level profiles for the server, which tell different ways the 
server can implement the interface in (a).

I would object to having a profile that just does (b), because it's neither 
specific enough to tell the server what to implement, nor general enough to 
let the client access different types of TSAs.


[...]
> > 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.

Do you like the approach above?



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

Yeah, it's hairy.  I think it's good to have this discussion, though, since 
these issues will appear in other profiles.

Anyways, opinions from other people (particularly potential implementors!) 
are welcome.


Trevor