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

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

Trevor

See below

....[snip]

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

Thanks for correcting my inverse logic.

>
> maybe that's something we can fix :-)
>
I believe that standards should reflect how peolple implement things.  Tring
to fix peolple "bad" practices in a standard often results in the standard
being ignored.


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

I would expect clients to check that a time-stamp is valid before depending
on it.

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

I prefer the (c) and (a) levels being defined for the client then the
implementors can decide which is appropriate.
>
>
>
> >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.

I agree - other views?
>
>
> 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.
>
>
>