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

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

Paul,

I prefer your suggestion of a "meta-profile" which can be used in
conjunction with other profiles which are directly implementable.

Nick

> -----Original Message-----
> From: Paul Madsen [mailto:p.madsen@entrust.com]
> Sent: 14 January 2004 15:02
> To: dss@lists.oasis-open.org
> Subject: RE: [dss] Timestamping Profile Q 1/3: Type of "SignatureObject"
>
>
> Nick's point below about the desirability of a profile being as
> specific as
> possible to aid interoperability got me thinking.
>
> I've been working on a 'Policy-wiser Server' profile, the jist of which is
> that its appropriate when the DSS client is either ignorant of
> signing/verifying policy or has no authority to specify it. I had been
> thinking of its specific to the creation/verification of an XML Signature.
>
> The 'Policy-wise Server' profile, unlike the others being proposed, is
> designed to capture a characteristic of the relationship between
> client and
> server (or their supporting infrastructure) rather than a particular
> application, e.g. timestamping or WS-Security. And this particular
> relationship character (dumb client/smart server) may be
> applicable to other
> more specific application profiles.
>
> For instance, if the WS-Sec profile describes how a client
> interacts with a
> server in order to create XML Signatures apprporiate to insertion in a
> WS-Sec <Security> header, some such clients could be policy-aware, others
> not.
>
> Do people imagine that a dumb client in this scenario would
> support both the
> WS-Sec profile and the policy-wise server profile?
>
> Or, should we recognize that there appears to be a qualitative difference
> between these two profiles, one specific to a particular application
> scenario, the other a sort of metaprofile that other specific
> profiles could
> draw upon or not.
>
> Thoughts?
>
> Paul
>
> >-----Original Message-----
> >From: Nick Pope [mailto:pope@secstan.com]
> >Sent: Tuesday, January 13, 2004 4:00 PM
> >To: Trevor Perrin; dss@lists.oasis-open.org
> >Subject: RE: [dss] Timestamping Profile Q 1/3: Type of
> >"SignatureObject"
> >
> >
> >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.
> >
> >
> >
> >
> >
> >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_wor
kgroup.php.