[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]