[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Timestamping Profile Q 1/3: Type of "SignatureObject" - NP2
Would it be useful, as a general principal in the construction of profiles, to begin with the more simple ones or the more generally used ones, as a version 1, with the notion that more complex and elegant methods can be used for subsequent versions, under the KISS approach? ---------- Original Message ---------------------------------- From: "Nick Pope" <pope@secstan.com> Date: Thu, 15 Jan 2004 09:52:43 -0000 > > >> -----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. >> >> >> > > > >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. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]