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

[Trevor Perrin <trevp@trevp.net>]

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.

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?


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