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

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

John,

I do not see this a choice between simplicity and what is generally used.
Given a choice a sensible supplier would go for the simplest solution.

In this case I suggest the simplest solution is to define a profile to
support XML timestamp, which is my guess what would be most commonly
implemented, rather than a solution that supports multiple forms of
time-stamp.

Nick

-----Original Message-----
From: jmessing [mailto:jmessing@law-on-line.com]
Sent: 15 January 2004 14:02
To: Trevor Perrin; dss@lists.oasis-open.org; Nick Pope
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
.
>
>

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
.