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

[Paul Madsen <p.madsen@entrust.com>]

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.