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

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

Trevor,

Two points:

1) Whilst the form of "SignatureObject" returned from Sign & Input to
Verify, I think that this warrent a separate section which identifies /
defines the form of signature supported by a specific profile.  Depending on
the profile this may be very broad or very specific, but but having such a
section the reader can immediately identify the form of signatures supported
by a profile.

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.

Nick

> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: 12 January 2004 20:42
> To: dss@lists.oasis-open.org
> Subject: [dss] Timestamping Profile Q 1/3: Type of "SignatureObject"
>
>
>
>
> Here's the 1st of 3 questions about the timestamping profile (but they're
> relevant to other profiles too):
>
>
> What should our timestamping protocol create and verify?
>    A) <dss:Timestamp> containing any type of TimeStampToken (XML,
> RFC 3161,
> Linking)
>    B) <dss:Timestamp> containing any type of <dss:XMLTimeStampToken>
> (X.509-based, PGP-based, XKMS-based, etc.)
>    C) <dss:Timestamp> containing a specific type of
> <dss:XMLTimeStampToken>
> (such as X.509-based)
>
> If we choose (C), the timestamping protocol is tied to a
> particular type of
> timestamp and a particular type of infrastructure (in the same
> way that the
> RFC 3161 Timestamping protocol is tied to the RFC 3161, X.509-based
> TimeStampToken).
>
> If we choose (A) or (B), the protocol is more generic.  I vote for (A),
> since it's the most generic - with (A), a client app that uses DSS to
> create and verify timestamps can be plugged into *any*
> environment that has
> a DSS-compliant timestamping server (or even just a DSS "proxy
> server" that
> receives DSS requests and forwards them to something like an RFC 3161
> Timestamp server).  If we do (C), then we're just an XML
> translation of RFC
> 3161, which seems a weaker value proposition.
>
> If we do (A), we'll have other work to do:
>    - we'll need to define the different types of TimeStampTokens - in
> particular, we may need to profile XMLTimeStampTokens for different
> infrastructures, and define LinkingTimeStampTokens.  Probably
> these should
> occur in separate documents.
>    - we may need to define <SignatureType> optional input values for
> different types of TimeStampTokens, so the client can request a
> particular
> type, or at least ensure that the server is returning what the
> client expects.
>
>
> Relevance to other profiles
> -----------------------------------------
> Other protocol profiles may want to operate on different types of
> "signature objects".  For example, maybe the codesigning profile
> could be a
> single protocol profile that can return different types of
> signature objects.
>
> This only works if 2 conditions are met:
>    - the signature objects have the same "top-level" type, so that the
> client can deal with the signature objects uniformly regardless of their
> differences.  For example, in (A), the DSS server always returns
> signature
> objects of top-level type <dss:Timestamp>.
>
>    - The different signature objects don't impose different
> requirements on
> the protocol.  If they do, then they probably deserve separate profiles.
>
>
> 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.