[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Policy-wise Server profile (was: RE: [dss] Timestamping Profile Q 1/3: Type of "SignatureObject")
Hi Paul, I agree with Nick: there's a qualitative difference, so I would call this an abstract profile, or meta-profile, or "guidelines to profile design" or something, instead of just a plain "profile". I'm not sure what exactly to call it - maybe as we move forward on this and the other profiles, it will become more apparent what their relationship is. Trevor At 03:28 PM 1/14/2004 +0000, Nick Pope wrote: >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. > > > > > >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]